Quy trình dự án, BA làm gì ở trỏng? (P1)
Quy trình dự án, BA làm gì ở trỏng? (P1)
Hế lôôôô anh em,
Từ lúc lập blog đến giờ mình có viết 2 bài về Business Analyst, đó là: concept tổng quan và những công việc cụ thể hằng ngày. Đợt rồi mình có ngồi dòm lại những bài này thì hình như thấy nó thiếu thiếu gì đó.
Với những người mới, thì bài tổng quan có thể dễ hiểu, nhưng chưa cụ thể lắm. Còn bài công việc hằng ngày thì lại… quá cụ thể, đến mức hơi lộn xộn, khó để anh em hình dung 1 cách tổng thể.
Do đó mình nghĩ phải có 1 bài ở giữa 2 bài này, để hệ thống lại rõ hơn công việc của BA theo trình tự thời gian làm dự án. Từ đó anh em sẽ có cái nhìn rõ ràng hơn về công việc của BA.
Quy trình làm dự án
Đầu tiên sẽ là quy trình tổng quan như sau.
Quy trình dự án
Như anh em thấy quy trình làm phần mềm nó gồm 6 bước:
- Analysis: phân tích xem mình sẽ làm những gì
- Design: mình sẽ thiết kế phần mềm như thế nào
- Develop: mình sẽ code ra sao
- Test: phần mềm được đem đi test
- Deploy: phần mềm được đưa vào sử dụng
- Maintain: giai đoạn bảo trì, hỗ trợ khách hàng sử dụng phần mềm.
Quy trình dự án về cơ bản gồm 6 bước trên, nhưng thực tế nó sẽ linh hoạt theo từng phương pháp quản lý dự án (project management methodology).
Phương pháp quản lý dự án là những thứ như: Scrum/Agile, Waterfall, Kanban, Lean…
Ví dụ đối với Waterfall thì quy trình sẽ đi theo trình tự từ trái qua phải (không đi ngược lại), mỗi bước chỉ đi qua 1 lần.
Cụ thể như analysis xong rồi, thì mới tới giai đoạn design, rồi xong design thì mới tới develop, tương tự là test >> deploy >> maintain.
Tức mình phải đợi dự án chạy từ đầu tới cuối thì mới dòm được thành phẩm cuối cùng hình dạng nó ra sao.
Còn đối với Scrum thì anh em sẽ chia nhỏ requirements ra thành các User Story, gom vào từng Sprint Backlog để làm dần dần. Tức mình chia nhỏ ra thành từng cục để làm.
Vậy thì quy trình trên sẽ không đi từ đầu tới cuối 1 lần duy nhất, mà đi nhiều lần từ analysis -> deploy, tạo thành nhiều sprint, nhiều vòng lặp. Mỗi vòng lặp sẽ làm một số tính năng nhất định, nên thời gian sẽ được rút ngắn còn khoảng từ 2-4 tuần/ sprint.
Do đó, khách hàng sẽ thấy ngay được sản phẩm của mình thành hình dần dần, từ đó góp ý để cải thiện sản phẩm ngày một phù hợp hơn với họ.
Mình nói đoạn này để anh em hiểu bản chất làm dự án phần mềm nó cũng chỉ gồm 6 bước thôi, dù cho có làm Scrum hay Waterfall, hay bất cứ phương pháp nào.
(mặc dù ở mỗi phương pháp nó có 1 tí râu ria liên quan khác nhau, cái này mình sẽ nói sau nhé anh em…)
Một điểm nữa là requirement sẽ đi xuyên suốt từ đầu đến cuối dự án thông qua 6 bước này. Là BA, chúng ta cũng sẽ phải đi xuyên suốt từ đầu đến cuối dự án qua 6 bước này luôn.
Requirement xuyên suốt từ đầu đến cuối dự án
Giờ mình sẽ nói chi tiết về từng bước có trong dự án, và BA làm gì ở trỏng nhé anh em 
Nội dung [Hide]
- 1. Analysis
- 1.1. Project Definition
- 1.2. Elicitation
- 1.3. Analysis
- 1.4. Documentation
- 1.5. Verification
- 1.6. Management
1. Analysis
Analysis là giai đoạn team dự án sẽ phân tích để hiểu được vấn đề của khách hàng và những gì mà họ đang mong đợi.
Đối với BA, đây chính là giai đoạn lấy yêu cầu.
Anh em sẽ làm rất nhiều bước nhỏ trong bước Analysis này để lấy yêu cầu một cách bài bản nhất (chứ không phải nói “lấy yêu cầu” là bay zô làm cái một, hỏi tùm lum tùm la là được)
Cụ thể Analysis gồm 6 bước nhỏ sau.
Thực chất mình chỉ cần focus vào 2 bước Elicitation và Analysis, vì các bước còn lại khá đơn giản, đều là những bước hiển nhiên mình phải làm.
1.1. Project Definition
Mục đích của bước này là để anh em BA chúng ta hiểu được project. Hiểu được project này làm gì, khách hàng là ai, lĩnh vực gì, vấn đề của họ ra sao, mục tiêu của họ là gì, scope dự án như thế nào…
Problem to be solved
Ví dụ như khách hàng đang dùng hệ thống SAP gặp lỗi nhiều quá, họ muốn build mới một hệ thống khác chạy ngon hơn.
Hoặc họ đang không có hệ thống quản lý kho bãi, vẫn đang tốn tiền nhân công, hiệu suất thấp, và sai sót vẫn còn xảy ra; thì đây chính là vấn đề họ cần giải quyết
Business Goal
Ví dụ họ muốn quản lý quan hệ khách hàng bằng một phần mềm nào đó. Hoặc triển khai thành công hạ tầng IoT cho 5,000 hecta cà phê đang trồng chẳng hạn.
Business Case
Là những hiện trạng cụ thể của khách hàng. Ví dụ công ty con này mới thành lập được 5 năm, hoặc công ty mới vừa bán hàng cho thị trường Châu Mỹ được gần 1 năm.
Project Scope
Phạm vi của dự án. Là BA, anh em cần phải hiểu rõ khoản này. Thường anh em sẽ chú ý tới:
- Organization Scope: ví dụ dự án được thực hiện tại Head Office ở Hồ Chí Minh, địa chỉ bao nhiêu đó. Công ty con ở Đà Nẵng hay Hà Nội không được áp dụng.
- Users Scope: hệ thống có bao nhiêu người dùng, thuộc những bộ phận nào.
- Functional Scope: cái này quan trọng nhất – mô tả những chức năng của hệ thống mà khách hàng mong muốn.
- Integration Scope: thực chất nó là 1 Non-Functional Requirement, nhưng được tách ra phần riêng, mô tả phạm vi tích hợp: hiện tại khách hàng đang dùng những hệ thống gì, cần tích hợp những components nào, tần suất ra sao, vâng vâng…
- Và cuối cùng là OUT OF SCOPE: anh em xác định trước những thứ sẽ nằm ngoài phạm vi dự án, kiểu như rào trước vậy đó.
Project Plan
Anh em đã nắm được lịch dự án của PM hay chưa, có khó khăn về thời gian không, theo lịch thì có đoạn nào cần gấp, dồn sức nhiều hay không… Và cuối cùng là.
Success Criteria
Cái này anh em có thể trao đổi với PM để hiểu hơn về dự án, về khách hàng: đâu là điểm họ kỳ vọng nhất, làm họ happy nhất. Focus vào điểm đó, anh em sẽ dễ đóng dự án hơn rất nhiều!
…
Sau khi hiểu được tổng quan dự án, anh em sẽ bắt đầu vô bước MOI MÓC YÊU CẦU – Elicitation
1.2. Elicitation
Elicitation tức là moi móc thông tin, moi móc yêu cầu từ phía khách hàng. Moi móc nghĩa là nó không có sẵn để anh em lấy, mà phải làm tùm lum tùm la mới ra được.
Sự khác biệt giữa Collect và Elicit.(Nguồn ảnh: ModernAnalyst.com)
Ở bước Elicitation, anh em cần nắm được các phương pháp moi móc thông tin. Phổ biến nhất có 11 phương pháp sau:
- Meeting
- Data Analysis
- Interface Analysis
- Prototyping
- Business Rules Analysis
- Observation
- Bench Marking
- Mind Mapping
- Process Analysis and Modeling
- Survey
- Document Analysis
Sau khi nắm được 11 phương pháp, anh em sẽ đi vào quy trình Elicitation, gồm 4 bước nhỏ sau.
Mình có 2 bài note nói về nội dung này, anh em bấm vào link dưới tham khảo thêm nhé:
- 11 phương pháp moi móc yêu cầu
- 4 bước moi móc yêu cầu (như link trên)
- Những lưu ý khi lấy yêu cầu
Sau bước này anh em sẽ có output là thông tin, rất nhiều thông tin.
Trong mớ thông tin này, anh em có thể có luôn yêu cầu cụ thể, yêu cầu mơ hồ, câu trả lời từ phía khách hàng; hoặc đơn giản chỉ là những thứ mà khách hàng nói với mình vì họ nghĩ những thông tin đó là cần thiết.
1.3. Analysis
Sau khi anh em đã hiểu dự án (project definition) và moi móc được một mớ thông tin (elictation), giờ anh em sẽ lấy mớ thông tin đó ra, và bắt đầu phân tích nó.
Thường thì mọi người không hiểu “phân tích” cụ thể sẽ làm những gì. Mình cũng vậy, cho đến khi mình gặp 1 anh Manager đẹp chai mà mình rất hâm mộ. Ảnh nói rằng:
Phân tích đơn giản chỉ là sắp xếp & phân loại mọi thứ lại cho đẹp đẽ, sạch sẽ mà thôi 
Hay Sandhya Jane (tác giả cuốn Business Analysis: The question and answer book) cũng có nói rằng:
“Analysis means simply breaking down the information of an object, entity, process, or anything else to understand its functioning“
Sandhya Jane
Ngẫm đi ngẫm lại thì đúng là vậy anh em ạ.
Giám đốc ngân hàng yêu cầu phân tích xem: vì sao quý này nợ xấu lại tăng cao đến như vậy?
Lúc này bộ phận kinh doanh sẽ làm gì? Chẳng phải anh sếp kinh doanh ảnh sẽ yêu cầu đổ toàn bộ dữ liệu các giao dịch cho vay trong khoảng thời gian phù hợp. Rồi phân loại rõ ràng theo các tham số: đối tượng khách hàng, phân khúc sản phẩm, hạn mức, kỳ hạn trả, vâng vâng và vâng vâng…
Anh em có nhận ra anh sếp kinh doanh này đang làm gì không? Chính xác là ảnh đang sắp xếp & phân loại mọi thứ cho ra ngô ra khoai
Để từ đó ảnh mới có thể làm tiếp công việc mà ảnh được trả hàng nghìn đô một tháng để làm, đó là: nhìn số liệu >> tìm ra vấn đề >> và giải quyết.
…
Phân tích với BA cũng tương tự như vậy.
Khi khách hàng có vấn đề trong bộ máy hoạt động, họ sẽ tìm đến mình. Và sau một loạt các buổi elicit requirement, chúng ta sẽ lấy được rất rất nhiều thông tin từ khách hàng (hoặc không).
Nhiệm vụ của anh em là phải xác định được: Đâu mới là vấn đề thực sự của khách hàng, và đâu mới là cái họ cần nhất ngay lúc này.
Hãy tưởng tưởng từ một mớ hỗn độn thông tin lấy được, chúng ta sẽ rất khó để biết được:
- Đâu mới là vấn đề thực sự của họ
- Đâu là những yêu cầu thực tế
- Đâu là những yêu cầu tầm bậy tầm bạ
- Và đâu là những thứ khách hàng thực sự nên ưu tiên vào lúc này…
Bước Analysis sẽ giúp anh em làm rõ những điều trên. Cụ thể ở bước này anh em sẽ làm những thao tác sau.
Theo trình tự, anh em sẽ:
(1) Organize
Tức là sắp xếp, tổ chức lại các requirement.
Ví dụ: tệp ảnh ra tệp ảnh, tệp ghi âm ra tệp ghi âm, thông tin về nhóm nghiệp vụ quản lý khách hàng gom chung lại 1 chỗ, nghiệp vụ quản lý chất lượng gom chung lại 1 chỗ khác, ví dụ vậy. Để mình có cái nhìn tổng quan nhất.
(2) Functional Decompose
Bước này anh em sẽ phân rã các yêu cầu thành các yêu cầu nhỏ hơn, cụ thể hơn. Mục đích là để có cái nhìn thực tế nhất về tính khả thi của các yêu cầu này.
Ví dụ họ muốn hệ thống có khả năng nhắc nhở các buổi họp định kỳ với đối tác của khách hàng (*).
Vậy thì anh em sẽ phân rã ra, để làm được yêu cầu trên thì hệ thống phải có chỗ ghi nhận được các buổi họp định kỳ đúng không anh em? Sau đó phải có một cái job nó chạy định kỳ, cứ trước 3 ngày diễn ra cuộc họp là gửi email nhắc nhở.
Vậy thì sau khi phân rã (*), anh em sẽ có như sau:
- Tính năng lưu trữ thông tin cuộc họp
- Tính năng gửi email nhắc nhở dựa trên thời gian cuộc họp.
Để sau này khi ngồi lại với dev, anh em sẽ dễ dàng giải thích và cũng dễ để xác nhận với khách hàng hơn, là: “à tụi em sẽ làm như vầy, như vầy nha chị…”. Kiểu vậy.
(3) Prioritize
Bước này là bước đánh số thứ tự ưu tiên cho từng yêu cầu cụ thể của khách hàng.
Ví dụ có 3 yêu cầu sau:
- Hệ thống phải lưu trữ được thông tin khách hàng (a)
- Hệ thống phải tự động thông báo những khách hàng đã mua hàng trên 5,000,000đ trong tháng (b)
- Hệ thống phải tạo được đơn hàng với thông tin bảng giá lấy từ hệ thống quản lý bán lẻ A Á Ớ Bờ Cờ (c)
Thì mình sẽ đánh giá mức độ ưu tiên của yêu cầu (b) thấp hơn yêu cầu (a) và (c). Vì phải có dữ liệu khách hàng và đơn hàng thì mới có thể lọc được thông tin khách mua hàng trên 5 triệu trong tháng.
Anh em có thể tham khảo một vài tiêu chí phân loại Requirements dưới đây.
Tiếp theo là 2 bước Validate và Verify. 2 bước này đều là 2 bước xác nhận, nhưng nó khác nhau ở chỗ:
(4) Validate
Do the thing right
(5) Verify
Do the right thing
…
Nói về bước Analysis, anh em tham khảo thêm bài note này nhé, mình có nói chi tiết kèm ví dụ ở note này: Hiểu về Requirement như thế lào cho đúng???
Sau 3 bước quan trọng đầu tiên: Project Definition >> Elicitation >> Analysis, anh em sẽ đi tiếp tới 3 bước cuối cùng.
Nãy giờ chúng ta đã đi được 3 bước này.
1.4. Documentation
Bước documentation nôm na nghĩa là anh em sẽ tài liệu hóa, tức là đem toàn bộ những thứ làm được nãy giờ bỏ vô tài liệu.
Tài liệu đó chính là SRS, hoặc FRD, tùy loại dự án mà mình có những loại tài liệu khác nhau nhé anh em. Nhưng mục đích chung thì vẫn là để mô tả chi tiết yêu cầu của khách hàng.
Để document thì anh em sẽ áp dụng 2 thứ sau:
- Tận dụng các template có sẵn
- Dùng ngôn ngữ mô hình hóa để document.
Ngôn ngữ mô hình hóa có khoảng 20 loại. Trong đó có 2 loại phổ biến nhất là BPMN và UML.
Template thì tùy công ty. Công ty của anh em dùng template gì thì anh em cứ dùng template đó thôi. Có thời gian mình sẽ share về các template này sau nhé.
1.5. Verification
Sau khi document xong, anh em sẽ chuyển cho team verify lại một lần nữa. Cụ thể là QA hoặc PM.
Họ sẽ kiểm tra lại xem thử anh em đã document đúng chưa, đủ các phần yêu cầu chưa. Đặc biệt là PM sẽ kiểm tra lại các yêu cầu của khách hàng đã được document chính xác và hợp lý hay chưa.
1.6. Management
Bước cuối cùng là management, tức là anh em sẽ quản lý các document sau khi đã xong xuôi. Quản lý ở đây là quản lý gì?
Ví dụ nếu requirement thay đổi, tức nội dung của tài liệu SRS hoặc FRD thay đổi, thì anh em phải đánh dấu version như thế nào, duyệt nội bộ rồi gửi cho khách hàng duyệt như thế nào.
Quản lý requirement sao cho dễ keep track cũng là một vấn đề khá nhức nhối :)) anh em nào có kinh nghiệm share bên dưới cho mình nhé.
Stop station…
Dừng chân recall một chút về 6 bước nãy giờ nhé anh em. Mục đích mình làm bài bản 6 bước này là để ra được 1 loại document mô tả chi tiết yêu cầu của khách hàng.
Như mình nói ở trên nó là SRS (Software Requirement Specification) hoặc FRD (Functional Requirement Document). Và có thể là 1 số loại template khác nữa, tùy công ty.
Trong 6 bước này, anh em lấy bước Elicitation và Analysis làm trọng tâm. Vì hầu như các bộ kỹ năng cứng của BA đều nằm ở đây hết.
Cái BA mình cần deliver được sau 2 bước này chính là REQUIREMENT. Nếu nhìn xuyên suốt qua cả 2 bước, anh em sẽ thấy requirement nó đi như sau:
Vậy là anh em đã đi xong giai đoạn Analysis trong quy trình làm dự án.
…
Bài này dài quá nên mình sẽ cắt ra. Anh em xem tiếp tập 2 ở đây nhé: Quy trình dự án, BA làm gì ở trỏng? (P2).
Nguồn: thinhnotes.com
