#1. Hãy bắt đầu với WHY – Tại sao BA hay phải viết?
– Quy trình làm requirements có 4 công đoạn phối hợp lẫn nhau (elicitation – analysis – specification – validation) thì Viết là bước to đùng trong đó.
– Nhiều stakeholder liên quan, lại “tam sao thất bản”, cứ phải viết ra cho cụ thể, cho rõ nghĩa
– Làm “baseline” cho các việc khác (design, code, test)
– Với một số người thì Viết cũng là một cách học, nhất là khi lượng thông tin nhiều lên
– (bạn nào có thêm lí do khác bổ sung nhé)
#2. Khi mới đi làm, mình thường bắt đầu với WHAT
– Viết cái gì, dẫn đến những việc đầu tiên thường là:
– Có template không? Hỏi xung quanh ai đã làm rồi cho tôi xem? Chưa có thì tạm “xào” qua một cái
– Tìm cách điền thông tin vào các mục trong template
#3. Sau đó đến WHO
– Ai cần dùng đến tài liệu này? Tức là stakeholder nào.
– Liệt kê các stakeholder, từ quan trọng cho tới ít quan trọng hơn. Tham khảo sơ đồ củ hành trong BABOK.
– Đặc tính và mối quan tâm của từng loại stakeholder. <== Tại sao cần có bước này? Để trả lời câu hỏi tôi viết cho Có hay tôi viết cho họ dùng. Không biết họ quan tâm gì thì viết ra chắc gì họ đã dùng. Nếu không ai dùng thì viết làm gì cho mất công (có khi còn làm khó nhau, kiểu chuyền bóng sửa lưng / làm khó đồng đội).
[onion diagram]
Không nhìn thấy chữ BA trong hình nhưng người BA xuất hiện trong cả 4 vòng tròn.
– Là thành viên trong development team
– Phải đặt vào vị trí end-user lúc phân tích và phát triển requirements
– Thường xuyên họp hành với mấy ông đại diện cho end-user. Nhờ bước nhận biết stakeholder ở trên, phần này sẽ nhẹ gánh hơn.
– Đôi lúc phải gặp mấy ông làm luật, làm chính sách, hay cần nghiên cứu xu thế, thông tư, và những mục tiêu xa hơn
#4. Nghĩ tới đây rồi, giờ mới là HOW
– Viết dư lào?
– Viết trên Word hay excel? Tớ thường bắt đầu từ notepad / textpad hay notes trên mobile,… hay bất cứ cái gì tiện tay nhất.
– Gạch đầu dòng các ý tưởng trước
[notes]
– Nếu là tài liệu dự án thì xây dựng bộ khung / cấu trúc tài liệu. Có thể dùng template sẵn nếu có nhưng lưu ý bạn cần nắm vững từng mục trong template đó, mục nào không chắc thì xoá hết đã (cần thì đưa vào sau). Mục nào chắc chắn phải có nhưng chưa kịp làm thì dùng “TBD”, “TBC”,… để người đọc biết chỗ đó sẽ bổ sung sau.
– Viết từ trên xuống dưới, cũng có thể từ dưới lên trên, từ sơ bộ đến chi tiết. Nếu bạn là team lead, phải viết minh hoạ cho người khác dùng, có thể viết thật chi tiết một vài mục (minh hoạ mà) và bỏ qua những phần khác.
Ôn lại này,
– Khi mới đi làm thì: What – How – Who (và quên mất Why, còn When thì cứ từ từ)
– Đi làm một thời gian thì: How – What – Who (vì đã biết sơ sơ về What rồi)
– Nhưng phải là: Why – những thứ còn lại. Dùng why để bắt đầu, cũng dùng why để lý giải cho những cái khác, và cũng vẫn why để làm động lực viết.
#5. Một vài nguyên tắc khác
– Nếu là requirements cho dự án, xác định rõ mức độ reqs nào (business – users – software). Mỗi kiểu sẽ lại có cách viết khác nhau.
– Viết reqs sẽ khác với viết guidelines / manuals (hướng dẫn, dẫn dắt), khác với viết email (có xưng hô), khác với viết proposals, khác với viết báo, viết CV, và càng khác với viết truyện, viết sách. Cố gắng phân biệt khác nhau trong những cái này, dù đều là viết. Muốn viết tốt còn cần đọc nhiều nữa.
– Sử dụng thuật ngữ, ngôn ngữ đúng ngữ cảnh. Đừng quên… gúc gồ, vd: “business analyst resume examples” nếu bạn muốn viết CV tốt.
– Nhớ là “requirements” tức là đề bài, nghề của BA xoay quanh việc tìm cách đặt ra đúng đề bài và diễn đạt cho hợp lý. Có đề bài tốt sẽ có những thứ khác tốt.
– Cũng đừng quên đặt mình vào vị trí người đọc để rà soát, chỉnh sửa. Nếu là requirements thì sử dụng “perspective-based review”, nhờ vào củ hành mà.
– Về requirements thì còn một loạt nguyên tắc riêng cho reqs nữa, ví dụ correct, complete, verifiable / testable, feasible, free-implementation,… Chắc dành dịp khác cho phần này.
Chúc anh em thành công nhé.
CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN
Khoá học Online:
Khoá học Offline:
Tại Tp.HCM:
Tại Hà Nội:
Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất.
Chia sẻ của anh Thái Sơn – Biên tập nội dung bởi BAC