15 bước của BA để có một dự án thành công

1. Tiếp cận dự án: Lúc này các thông tin về dự án ở dạng sơ khai, high level. Thường có thể nêu vấn đề của business ví dụ công ty A gặp khó khăn trong việc quản lý nhân viên và quản lý kho hoặc thể hiện mong muốn của sponsor (Nhà đầu tư dự án) hoặc stakeholder kiểu như tôi muốn xây dựng hệ thống ERP để phục vụ cho việc quản lý quy trình của các phòng ban chức năng của công ty chúng tôi. Lúc này có các thông tin BA có được có thể do nhận được từ người khác như Presale, PM hoặc giám đốc mà công ty BA đang làm việc. => Lúc này, BA có nhiệm vụ thu thập càng nhiều càng tốt hoặc research nhằm biết được domain mà mình cần phải handle trong dự án này là gì. Mục đích là giúp cho BA có cái nhìn tổng quan hoặc lường trước được để có phương án. Giả sử ERP là Domain quá mới đối với BA. Vậy BA cần phải research hoặc tìm hiểu qua các kênh hoặc mối quan hệ để hiểu rõ về cách ERP vận hành. Ngoài ra, BA cũng nên cũng cần nắm được vài requirement dạng high level của stakeholder vào thời điểm này như Budget của dự án (Nếu có), timeline của dự án (nếu có), công nghệ stakeholder muốn áp dụng (Nếu có), môi trường sẽ triển khai dự án (Nếu có). Càng có nhiều thông tin, BA càng trở nên “thông thái” hơn trong dự án này. Chắc chắn là các thông tin này không tự nhiên mà đến để BA có thể sở hữu được mà phải thông qua hoạt động Elicit (Khơi gợi) bằng cách đặt các câu hỏi mở nhằm mục đích “đào” được thông tin.

2. Tiếp cận stakeholder và elicit business: Đây là lúc BA và cộng sự (Project Manager) tìm cách hẹn gặp stakeholder để lắng nghe trực tiếp các requirement dạng high level hoặc nghe các vấn đề (Business problem) của doanh nghiệp. => Lúc này, BA có nhiệm vụ take note tất cả các thông tin và các business problem trong doanh nghiệp. Và cũng nhân cơ hội này, BA sẽ đặt các câu hỏi để elicit business nhằm mục đích biết rõ quy trình quản lý bên trong doanh nghiệp cũng như vai trò của từng actor đang tham gia vào và các business problem ở từng phòng ban.

Một tip cho BA đó là hãy đặt câu hỏi để stakeholder kể theo quy trình vận hành của business từ lúc bắt đầu. Thường xuất phát vào quy trình đặt hàng (Nếu là doanh nghiệp sản xuất) hoặc quy trình ghi nhận thông tin (Nếu là dịch vụ). Nếu stakeholder đưa các thông tin không theo trình tự, BA hãy chủ động huớng cuộc trò chuyện để mục đích có được thông tin có tính logic và việc ghi chép các thông tin ấy trở nên rõ ràng và hiệu quả hơn.

Việc elicit business sẽ diễn ra có thể trong nhiều buổi và có thể qua các kênh khác nhau như trực tiếp, gián tiếp. BA cần chủ động booking để có được cơ hội triển khai hoạt động này. Ngoài ra, đây cũng là lúc BA cần quản lý Stakeholder.

Tức là trong 1 dự án sẽ có nhiều stakeholder với nhiều vai trò khác nhau. Thường họ được chỉ định bởi sponsor sẽ phối hợp cùng với BA để làm việc. BA cần chào hỏi để tạo connection, đặt các câu hỏi nếu chưa biết vai trò của họ, ghi chép các thông tin liên lạc của stakeholder qua các hình thức hoặc những trở ngại nếu có của việc giao tiếp liên lạc. Ví dụ như có stakeholder chỉ thích email và làm việc trên email. Tất cả các câu hỏi đều phải được thông qua email. Có stakeholder chỉ thích gặp trực tiếp, có stakeholder chỉ có thể video call vì khoảng cách địa lý. BA cũng cần phải quản lý thời gian sẵn sàng của stakeholder.

Giả sử công ty nọ có thói quen họp buổi sáng hàng tuần từ 7h-8h, vậy chắc chắn lịch hẹn phải nằm ngoài khoảng giờ này. Để biết được Stakeholder thường có thể sẵn sàng làm việc với BA vào lúc nào thì BA phải chủ động hỏi. ví dụ như :”Không biết trong tuần em có thể liên lạc cho anh Nam vào thứ mấy, tầm mấy giờ anh rảnh để không ảnh hưởng đến công việc thường ngày của anh Nam”. Lúc này anh Nam sẽ cân nhắc và trả lời :”Thường 14h00 tới 16h00 thứ tư và thứ sáu là anh ít việc nhất”. Em có thể meeting với anh vào lúc đó”. Lúc đó BA sẽ lập tức confirm “Nếu vậy thứ tư tuần tới lúc 14h00 anh cho em xin lịch vào khung giờ này để em tìm hiểu thêm thông tin về …”. Việc này cũng thể hiện được trách nhiệm không thể thoái thác và trước đông người anh Nam đã nói ra như vậy. Lí do cần làm việc này vì hầu hết các stakeholder đều bận và họ thường phải làm công việc thường ngày của họ. Nên khi có dự án mới, họ phải làm thêm việc nên việc sẵn sàng hỗ trợ BA không phải lúc nào cũng diễn ra đúng mong đợi.

Ngoài ra, BA cũng cần lên kế hoạch elicit business cho tất cả các stakeholder nhằm đảm bảo việc quản lý thời gian. Tránh trường hợp làm xong cái này mới nghĩ đến cái khác rồi book stakeholder đột ngột sẽ dễ có rủi ro bị từ chối hoặc thoái thác. Output của bước này, BA sẽ clear được business của từng phòng ban, các quy trình và của cả doanh nghiệp. BA lúc này có thể sử dụng kỉ thuật vẽ BPMN để sơ đồ hoá lại trước khi hẹn gặp stakeholder để mô tả lại xem mình hiểu đã đúng chưa về business.

Trường hợp nếu doanh nghiệp đã có các quy trình theo dạng bảng vẽ thế này, BA có thể chủ động xin bản copy để tham khảo và cam kết không lộ ra bên ngoài, có thể stakeholder sẽ chia sẻ và BA có thể giảm được lượng lớn thời gian. Tuy nhiên, cũng xin lưu ý, các tài liệu được nhận từ stakeholder thì BA cũng nên cân nhắc version của tài liệu là bao nhiêu, lần cuối cập nhật là khi nào, có phải là bản mới nhất không? Tránh trường hợp nghiên cứu xong rồi mới phát hiện quy trình này đã lỗi thời và không còn được áp dụng nữa.

3. Phân tích business và nghiên cứu giải pháp: Sau khi có được bản vẽ BPMN của business ( Bước này rất quan trọng vì nhờ nó, BA chụp hình được business và hệ thống logic các quy trình bên trong của doanh nghiệp), BA đưa ra các giải pháp nhằm giải quyết business problem, đáp ứng high level business requirement của sponsor hoặc là sự kết hợp của cả 2. Nên nhớ, giải pháp này phải được cân nhắc dựa trên công nghệ mà công ty BA có thể handle được, nguồn lực có thể đáp ứng được, timeline có thể reach được, đây vừa là cơ hội vừa là rủi ro. Chỉ sơ xuất thì rủi ro đền hợp đồng là rất cao. Lúc này, giải pháp của BA cũng cần có sự tham vấn của PM, Tech lead hoặc director. Sau khi nhận được sự phản hồi, cập nhật chỉnh sửa và validate, BA sẽ show up với stakeholder và sponsor. Giải pháp này bắt buộc phải giải quyết được các pain point của doanh nghiệp hoặc đáp ứng được nguyện vọng của sponsor, và phải chứng minh được added value (Giá trị gia tăng) mang lại cho doanh nghiệp hoặc cơ hội tương lai có được sau khi áp dụng giải pháp. Nếu không, khả năng cao sẽ không thắng được dự án. Lưu ý BA khi trình bày giải pháp cũng nên cần phải sắp xếp thứ tự ưu tiên của từng giải pháp, có thể theo phương pháp MOSCOW để sắp xếp. Giải pháp có thể chia theo từng MVP ( tham khảo ở đây https://nghialagi.vn/san-pham-kha-dung-toi-thieu-minimum…) để phù hợp với kinh phí, nguồn lực, timeline và công nghệ áp dụng.

4. Trình bày giải pháp: Sau khi có được giải pháp tổng thể được validate, BA sẽ hẹn stakeholder và sponsor để trình bày giải pháp. => Lúc này, BA sẽ đại diện công ty thuyết trình và nghe phản hồi từ stakeholder và sponsor. Take note lại sau đó tiếp tục cập nhật để chỉnh sửa để lại thuyết trình giải pháp lần 2 nhằm có được sự đồng thuận.

5. Xác định Scope of Project (Phạm vi dự án): Giả sử lúc này, BA đã được sự đồng thuận từ Sponsor và stakeholder về giải pháp. BA sau đó sẽ xác định phạm vi dự án bằng cách liệt kê các module, mô tả và các tính năng cần có nhằm đáp ứng được business hoặc giải pháp lúc đầu. Các tính năng này có thể nói là middle level vì chắc chắn nó rõ ràng hơn so với high level nhưng chắc chắn không chi tiết bằng functional và non functional requirement.

6. Giao diện hoá hệ thống bằng mockup và elicit requirement (Khơi gợi yêu cầu chi tiết): Dựa trên danh sách các tính năng và mô tả, BA sẽ vẽ giao diện chính là bản proposal được thực hiện lần lượt theo từng module. Tất nhiên để làm được cái này không chỉ dựa trên các thông tin có được từ bước 2 mà còn cần thực hiện kỉ thuật elicit requirement. Khi có được các thông tin cần thiết, BA vẽ mock up. Sau đó review chỉnh sửa trước khi hẹn stakeholder để get confirm. Tuỳ theo dự án, có thể BA làm việc với UI/UX designer để “Mông má” và nâng cao trải nghiệm người dùng trước khi show up stakeholder. Nếu có thời gian, BA có thể thiết kế 1 bản Prototype hoàn hảo để “hớp hồn” stakeholder.

7. Trình bày mock up/Prototype và flow: BA thuyết trình lại giải pháp của mình bằng hình ảnh thông qua mock up/Prototype. Trong buổi này, BA giải thích cho stakeholder hiểu ý nghĩa của từng giao diện, và mường tượng được flow của hệ thống, user là actor nào sẽ sử dụng và lợi ích có được sau khi sử dụng. Stakeholder sẽ đặt các câu hỏi hoặc phản biện. BA lắng nghe, phản biện lại hoặc ghi nhận để tiếp tục chỉnh sửa giao diện cho đến khi có được sự đồng thuận.

8. Document: Sau khi đạt được sự đồng thuận về giao diện, BA tiến hành viết tài liệu, tuỳ theo cách thức vận hành dự án như Agile hoặc Waterfall mà BA chọn cho mình cách thức trình bày phù hợp. Nếu Agile thì BA có thể chỉ cần viết đủ document để chạy 1-2 sprint đầu tiên rồi lại tiếp tục các bước 6,7,8. Nếu chạy theo Waterfall, BA cần viết đầy đủ requirement của toàn bộ hệ thống. Sau đó gửi cho stakeholder liên quan để review. Các feedback của stakeholder sẽ được BA ghi nhận, phản hồi và tiếp tục cập nhật cho đến khi đạt được sự đồng thuận (Sign off). Tất nhiên trong quá trình document, sẽ có thể phát sinh các điểm mập mờ, lăn tăn. Lúc này BA lại tiếp tục triển khai hoạt động Elicit requirement (việc làm này không bao giờ dừng lại, nó có thể xảy ra trong suốt dự án)

9. Development: Giả định lúc này dự án đã sign off, BA tiến hành transfer requirement qua cho development team và testing team. BA sẽ trình bày bằng giao diện và cả tài liệu để team review và feedback. Sau đó team developer sẽ tiến hành phát triển sản phẩm.

10. Testing: Mỗi khi dev hoàn thành các tính năng, QA/QC sẽ testing để đảm bảo Product thoả mãn các yêu cầu được đặt ra trong Document. BA lúc này cũng trải nghiệm sản phẩm và đưa ra các điều chỉnh hoặc feedback.

11. Demo: Tuỳ theo mô hình vận hành dự án việc Demo này có thể được thực hiện mỗi sprint hoặc cuối của dự án. Dù là gì đi nữa, BA cũng cần chuẩn bị để thực hiện buổi Demo với stakeholder và sponsor. Họ sẽ đưa ra các feedback sau buổi demo. BA sẽ lắng nghe, giải thích, phản hồi, cập nhật lại để thay đổi (Nếu có) nhằm đạt được sự đồng thuận của các stakeholder.

12. UAT: Giả định lúc này hệ thống đã được chỉnh sửa và cập nhật theo các feedback từ buổi demo, BA và đội ngũ tiến hành triển khai sản phẩm lên môi trường UAT để stakeholder và các end user hoặc tester của stakeholder thực hiện testing. Chắc chắn trong quá trình testing, sẽ phát sinh các bug và các enhancement cho hệ thống. BA là người trực tiếp tiếp nhận, phân tích và phản hồi xem đây có phải là ưu tiên cần xử lý không, xác thực đây có phải là bug không, đây có phải là Change request hoặc Out of Scope không. Sau khi tiếp nhận, BA sẽ đưa ra các giải pháp theo từng trường hợp. Lúc này việc elicit requirement, update document và development có thể tiếp tục được diễn ra cho đến khi team tester và stakeholder đã testing hết các test case cần thiết.

13. Inspection: Giả định lúc này đã UAT đã kết thúc, Stakeholder và sponsor sẽ tiến hành sign off ( kí nghiệm thu dự án), việc nghiệm thu này có thể được xảy ra nhiều lần và lặp lại hoặc vào cuối dự án tuỳ theo mô hình vận hành dự án theo Agile hoặc Waterfall.

14. Deployment và Transformation: Hệ thống sẽ được tech team triển khai lên server của doanh nghiệp và chắc chắn cần có các bước chuyển đổi như dữ liệu từ quy trình cũ hoặc hệ thống cũ qua hệ thống mới. Và cả hoạt động hướng dẫn hoặc viết tài liệu huớng dẫn sử dụng cho end user.

15. Update version: Sau quá trình end user sử dụng, có thể phát sinh các lỗi hoặc các enhancement, BA lúc này tái hiện lại các hoạt động như lúc UAT

P/s: Đây là quy trình chung của 1 dự án outsourcing kiểu mẫu. Tuỳ theo tình hình thực tế, một vài bước có thể bị bỏ qua hoặc có thể xảy ra đồng thời. BA cần phải “Flexible” theo hoàn cảnh.