Mar 28, 2020

Yêu Cầu Dự Án (Requirements)

Yêu Cầu Dự Án (Requirements) - Gian nan chuyện viết gì và viết như thế nào

Đầu tiên thì chúng ta thử nhắc lại với nhau xem yêu cầu dự án (requirement) là gì đã. Theo IIBA có định nghĩa tại BABOK V3.0 (để tìm hiểu IIBA là gì và BABOK thì các thử search google với các keywords đó nhé) có đưa ra rằng:

“A requirement is a usable representation of a need. Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled.”

(lược dịch) Một yêu cầu là một đại diện khả dụng của một nhu cầu người dùng. Yêu cầu tập trung vào việc hiểu giá trị mà yêu cầu đó mang lại sau khi được đáp ứng.”

Trong BABOK cũng có nhắc tới các loại yêu cầu tuỳ vào đối tượng cung cấp: Yêu cầu người dùng, yêu cầu doanh nghiệp, hay yêu cầu giải pháp...Trong các mảng việc dự án mình từng tham dự thì yêu cầu giải pháp (solution requirements) là được phân tích và quản lý trực tiếp bởi các BA trực chiến dự án. Bởi ở đó tập trung các yêu cầu cụ thể để đội phát triển có thể thực hiện việc xây dựng giải pháp, bao gồm yêu cầu chức năng (functional requirements) và yêu cầu phi chức năng (non-functional requirements). Đây cũng là loại yêu cầu phổ biến nhất bởi phần lớn dự án phát triển sản phẩm. Vậy thì là các BA trực tiếp làm việc với team giải pháp hay team development thì khi được yêu cầu viết tài liệu chúng ta nên viết gì? và viết như thế nào đây?...

Hãy thử cùng nhau đặt câu hỏi và trả lời xung quanh vấn đề này xem sao các bạn nhé

Thứ nhất, tại sao mình lại nói là “được yêu cầu viết tài liệu"

Có rất nhiều dự án họ muốn tối giản hoá tài liệu và sử dụng các bộ công cụ nhằm mô hình hoá yêu cầu thay vì sử dụng word, excel, powerpoint để viết và lưu trữ theo cách truyền thống. Ví dụ: Promap được sử dụng để vừa mô hình hoá và quản lý quy trình nghiệp vụ, quản lý workflow đồng thời có tính năng để giải thích thêm các điều kiện hay ràng buộc... Invision, Miro được sử dụng để tạo prototype và flow màn hình, dòng thao tác người dùng...Việc của BA sẽ là bám sát các team tham gia từ SME tới UX, PO, Delivery Manager, development team(s) để kết nối thông tin, đảm bảo thông tin được đồng bộ và tiến trình go-live của các yêu cầu được mượt mà, phù hợp với product roadmap của PO. Vậy thì document chỉ cần thiết khi có các quyết định mấu chốt giải quyết các vấn đề phát sinh, phân tích ảnh hưởng của thay đổi khi có xảy ra (điều này thì luôn luôn xảy ra rồi)...Và khi cần có update thì các bên liên quan cùng nhau update trên các tool sẵn có đã sử dụng...

Tuy nhiên những dự án thế này lại không nhiều. BA chúng ta luôn được yêu cầu “viết tài liệu dự án” trong job description khi tuyển dụng và luôn có lợi ích của việc viết documents mà không phải BA nào cũng chấp nhận ngay, nhất là các dự án migration mà các bạn phải thực hiện reverse engineering để viết ra yêu cầu cho giải pháp mới, hay các dự án các bạn take over từ một vendor khác và vendor lại “lười" viết documents...và cũng không phải development team nào cũng hào hứng cùng bạn “đọc code thằng khác”

Thứ hai, viết gì?

Cá nhân mình thấy để đưa ra được một câu trả lời thoả mãn hết các bạn sẽ rất khó. Mỗi dự án, mỗi công ty, khách hàng sẽ có những yêu cầu khác nhau cho việc viết tài liệu. Đặc biệt là mỗi development team sẽ có cách đọc khác nhau, yêu cầu khác nhau...Nhưng dù gì thì tài liệu này cần trả lời được câu hỏi của development team: Yêu cầu này liên quan người dùng nào?, họ sẽ đạt được gì từ yêu cầu này? và làm thế nào để yêu cầu được đáp ứng?

Để biết BA nên viết gì, các bạn thử nghĩ tới một vài gạch đầu dòng như thế này nhé:

Tạo một buổi họp để thảo luận cách viết, các chi tiết cần có trong specs (tài liệu chi tiết của yêu cầu). Hãy coi development team như 1 khách hàng của BA, hãy đưa cho họ một tập sticky notes và vài cây viết và chúng ta thực hành requirements elicitation với họ. Đảm bảo sẽ ra được các yêu cầu với việc viết tài liệu của BA. Mình đã từng áp dụng và vẫn tiếp tục tìm cơ hội lặp lại việc này mỗi khi có cơ hội (thường là sau mỗi dự án) để team và bản thân cùng tiến bộ

Challenge templates nếu có. Các dự án đã có sẵn template thì tốt quá rồi, BA cứ theo đó mà viết thôi. Phần nào đi sâu technical có thể quay sang Tech Lead để hỏi hay kêu gọi hợp tác hoàn thiện requirements. Tuy nhiên mình khuyến khích các bạn BA mình từng làm việc chung hay từng lead là hãy challenge chính cái template mình dùng, nếu thấy quá cồng kềnh, hay phần nào đó là không cần thiết cho dự án mình đang làm thì cứ mạnh dạn speak up.

Tạo buổi họp để giải thích requirements cho các bên liên quan thay vì chỉ gửi documents và hỏi “let me know if any comments". Kể cả khi các bạn làm dự án outsource và giờ bạn có thể họp là giờ khách hàng đang...ngủ. Hãy thử đề xuất thời gian họp phù hợp nhất như đi làm sớm hơn 1-2 tiếng hay ở lại trễ hơn 1-2 tiếng. Mình tin điều này không xảy ra hàng ngày, và mình cũng tin vào việc khi bạn thể hiện được commitment của bản thân thì niềm tin sẽ được tạo dựng, không chỉ với team mà còn với khách hàng.

Nếu các bạn thử google về cách viết tài liệu hiệu quả thì quả thực đọc mải mê không hết nhưng tựu chung sẽ có các chuẩn mực chung với yêu cầu như 5C, INVEST... Ở đây mình không bàn tới điều này mà mình muốn lược lại các kinh nghiệm của mình như thế này

Hãy cố gắng dùng hình ảnh thay cho chữ viết

Một wireframe dù vẽ tay cũng dễ hình dung hơn nhiều là bạn giải thích dù cụ thể tới bao nhiêu.

Nếu yêu cầu là thay đổi xảy ra trên một hay nhiều màn hình của ứng dụng có sẵn, hãy chụp màn hình và take note ngay trên hình chụp màn hình đó.

Nếu yêu cầu là một thay đổi liên quan tới nhiều màn hình, nhiều bước thực hiện người dùng hãy tạo một luồng màn hình bằng cách đơn giản nhất bạn có thể (paint, excel, hay miro…) để đưa vào tài liệu.

Nếu là change thì rất nên có 2 phần: Hiện tại (Current hay As-Is) và Mong muốn (Expected hay To-Be). Việc này nhằm giúp người đọc hình dung nhanh nhất thay đổi là gì và xảy ra ở đâu.

Thay việc viết Use Case bằng swimlane flow chart. Các bạn có thể thấy qua cách mình viết bài là mình đang cố gắng sử dụng tiếng Việt càng nhiều càng tốt nhưng khả năng dịch thuật không mạnh nên mình đảm bảo có nhiều chỗ các bạn đọc mà không hiểu “bả đang muốn nói cái gì"...Mình viết document biết rõ nhược điểm này nên tối đa sử dụng hình vẽ, dù là vẽ tay loằng ngoàng

Cuối cùng là viết như thế nào?

Thực tế thì bản thân mình cũng nhiều lần trải nghiệm đau thương từ việc bị khách hàng phàn nàn, team development phàn nàn về cách viết requirements quá dài làm họ ngại đọc, qúa nhiều chi tiết không tập trung...nên mình rất đồng cảm với các bạn bị càm ràm từ chính thức tới không chính thức về tài liệu mình viết. Một số kinh nghiệm đúc kết của mình xin được chia sẻ như sau:

Đừng ôm tài liệu ngồi viết rồi khi nào xong mới gửi review, hãy biến nó thành một quá trình như các bạn development làm việc trong team là bạn cũng setup các buổi elaboration để bạn giải thích requirement và team cùng thảo luận.

Hãy review live với khách hàng ngay khi có cơ hội. Và cũng biết nó thành một practice thường xuyên. Giả sử có ngày nào bỗng nhiên ta hết chuyện về requirements hãy tranh thủ “tâm sự" cũng là một cách xây dựng mỗi quan hệ tốt. Sử dụng các tool như webex, teams các bạn đều có thể có e-meeting với tài liệu mở trước mặt để cùng review và confirm những điểm cần thiết.

Đối chiếu hay keep track requirements mapping thường xuyên. Đây là điểm mình bị đánh giá “khó tính và ôm đồm" khi mình luôn hỏi product roadmap, kiến trúc dự án và delivery plan. Các bạn có thể bỏ qua bước đó nhưng với requirement mapping thì nên làm, tự làm một note riêng cho mình cũng được vì cách này có thể giúp bạn nắm rõ mối quan hệ giữa các requirements (dependency) và tương tác (integration) để đảm bảo khi có change xảy ra thì impact sẽ được phân tích đầy đủ, tránh rủi ro của việc thiếu thông tin.

Hãy mạnh dạn hẹn một senior BA hơn trong cty hay đơn vị giúp mình khi cần một lời khuyên.

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 chị Annia Trần - Biên tập nội dung bởi BAC

Click để đọc tiếp

Một ngày làm Business Analyst khi có AI hỗ trợ: Khác gì so với trước đây?

Công việc chính của BA gồm thu thập yêu cầu, phân tích nghiệp vụ, viết tài liệu và phối hợp với stakeholder cùng đội phát triển. Tuy nhiên, sự phát triển mạnh mẽ của AI, đặc biệt là GenAI như ChatGPT, Gemini hay Claude, đã làm thay đổi đáng kể cách BA vận hành.
Nghệ thuật biến dữ liệu khô khan thành câu chuyện khiến người nghe phải gật gù

Sống trong thời đại dữ liệu thống trị nhưng có một sự thật trớ trêu: dữ liệu ngày càng nhiều phần lớn lại bị lãng phí. Không phải vì thiếu thông tin, mà vì cách chúng ta trình bày quá… chán.
IT Business Analyst cần trang bị kỹ năng gì trong năm 2025?

IT Business Analyst là vai trò yêu cầu nhiều kỹ năng bao gồm cả kỹ thuật và kỹ năng mềm. Cùng với sự phát triển mạnh mẽ của lĩnh vực công nghệ, tiêu chuẩn về một IT Business Analyst cũng có nhiều thay đổi. Hãy cùng BAC khám phá chi tiết.
Top 5 kỹ năng mềm và kỹ thuật BA cần có để thành công trong dự án

BA đóng vai trò trung gian trong doanh nghiệp, giúp chuyển hóa nhu cầu kinh doanh thành giải pháp cụ thể. Để đảm bảo dự án vận hành suôn sẻ, BA không chỉ cần kiến thức nghiệp vụ mà còn phải sở hữu những kỹ năng, kỹ thuật then chốt.

Bình luận

Lê Anh Tuấn

Chuyên viên HO - Kỹ thuật Ngân hàng số Eximbank

Tôi là nhân sự thuộc Trung tâm Phát triển CNTT – Khối Ngân hàng số, hiện đang đảm nhiệm vai trò kiểm thử phần mềm (tester). Việc tham gia khóa học Business Analyst đã mang lại cho tôi góc nhìn toàn diện và rõ ràng hơn về vai trò của BA trong lĩnh vực ngân hàng.

Khóa học Fundamental Business Analysis tại BAC không chỉ giúp tôi hiểu đúng bản chất công việc BA mà còn hỗ trợ phát triển tư duy nghiệp vụ – từ tiếp cận giải pháp kỹ thuật sang tập trung vào nhu cầu người dùng. Phương pháp giảng dạy kết hợp lý thuyết và thực hành thực tiễn, cùng các hoạt động mô phỏng, thảo luận nhóm đã giúp tôi nâng cao kỹ năng giao tiếp, phân tích và trình bày yêu cầu – những năng lực thiết yếu để phối hợp hiệu quả giữa các bên trong dự án công nghệ.

Xem chi tiết +
Huỳnh Cao Cường

Nhân viên HO - Kỹ thuật Ngân hàng số Eximbank

Tôi hiện đang công tác tại Trung tâm Phát triển CNTT – Khối CNTT, với vai trò là nhân sự chức năng phụ trách mảng Ngân hàng số, chuyên sâu về kiểm thử phần mềm (Tester). Trước khi tham gia khóa học Fundamental Business Analysis do BAC tổ chức, tôi từng hình dung BA chỉ đơn thuần là cầu nối giữa bộ phận kỹ thuật và nghiệp vụ.

Tuy nhiên, quá trình học đã giúp tôi nhận thức rõ hơn về bản chất và tầm quan trọng của vị trí này. BA không chỉ kết nối các bên liên quan, mà còn giữ vai trò định hình yêu cầu, đảm bảo giải pháp được thiết kế đúng mục tiêu và sát với nhu cầu thực tế. Khóa học đã trang bị cho tôi tư duy phân tích bài bản, khả năng diễn đạt yêu cầu rõ ràng, và kỹ năng phối hợp hiệu quả trong môi trường dự án đa chiều.

Với nền tảng công nghệ thông tin sẵn có, khóa học là bước chuyển hướng quan trọng giúp tôi phát triển tư duy nghiệp vụ vững chắc và sẵn sàng theo đuổi lộ trình nghề nghiệp chuyên sâu trong lĩnh vực Business Analysis tại Eximbank.

Xem chi tiết +
Nguyễn Thị Mai Bình

Business Analyst

Với một người ngoại đạo như mình thì những chuyên đề về "kỹ thuật" của BA hết sức quan trọng. Ví dụ như sử dụng các diagram để mô hình hóa requirement, viết User Story/Use case, v...v..

Đến với khóa học Fundamental Business Analysis, mình đã được gặp thầy Lộc, một người người rất nhiệt tình và có tâm. Ngoài việc chia sẻ các kinh nghiệm thực tế trên lớp thì thầy còn dành thời gian ra để tư vấn, hỗ trợ, góp ý CV cho mình. Bên cạnh đó trung tâm và anh Phụng cũng hỗ trợ gửi CV, kết nối học viên tới mạng lưới các công ty đối tác chất lượng, điều này giúp học viên như mình tìm được công việc phù hợp nhất. Cảm ơn BAC.
Xem chi tiết +

Professional Transfer Services in Batumi

Luxury Georgian Transfer Services – Tbilisi & Batumi

Airport Transfers in Georgia

Một ngày làm Business Analyst khi có AI hỗ trợ: Khác gì so với trước đây?

Nghệ thuật biến dữ liệu khô khan thành câu chuyện khiến người nghe phải gật gù

IT Business Analyst cần trang bị kỹ năng gì trong năm 2025?

Top 5 kỹ năng mềm và kỹ thuật BA cần có để thành công trong dự án

CÔNG TY CỔ PHẦN ĐÀO TẠO VÀ TƯ VẤN BAC