7 Bước Hiệu quả trong việc thu thập thông tin
7 Bước Hiệu quả trong việc thu thập thông tin
Dựa trên nội dung cốt lõi của sách, 7 bước effective requirements gathering được đề cập như một quy trình logic, lấy cảm hứng từ "How to Efficiently Gather Requirements" and lean/agile methods
Các
bước đầy đủ là:
1. Identify
all project stakeholders (Xác định tất cả các bên liên quan đến dự án).
2. Ask
stakeholders the right questions (Hỏi các bên liên quan những câu hỏi đúng).
3. Determine
the best requirements gathering techniques (Xác định các kỹ thuật thu thập
requirements tốt nhất).
4. Document
everything (Tài liệu hóa mọi thứ).
5. Analyze
the results (Phân tích kết quả).
6. Verify
the results (Xác minh kết quả).
7. Sign-off
(Ký phê duyệt).
Áp Dụng 7 Bước Thu Thập Thông Tin Hiệu Quả Để
Thành Công Trong Dự Án Thực Tế
Trong bối cảnh kinh doanh ngày nay, nơi sự không chắc chắn vốn có trong
quá trình phát triển hệ thống như trong ebook nhấn mạnh, thu thập thông tin là
bước then chốt để đảm bảo dự án thành công và những giá trị cộng thêm trong
kinh doanh.
Theo tác giả Ifra, quá trình thu thập yếu kém là nguyên nhân
chính gây thất bại, dẫn đến phí thời gian, tiền bạc và cơ hội. Cuốn sách "7
Steps to Effective Requirements Gathering for Project" cung cấp một
framework lean and agile to gather requirements, giúp người phân tích dự án chấp
nhận sự không chắc chắn và mang lại giá trị.
Trong bài viết này, tôi sẽ giải thích chi tiết 7 bước, với
mô tả, lý do cũng như đưa ra những ví dụ thực tế để có thể ứng dụng vào dự án
như phát triển trang web hoặc hệ thống doanh nghiệp. Bằng cách thực hiện tuần tự
các bước này để giảm thiểu rủi ro, cải thiện sự hợp tác và phù hợp với các mục
tiêu kinh doanh.
Bước 1: Xác Định Tất Cả Các Bên Liên Quan Đến Dự
Án (Identify All Project Stakeholders)
Mô tả và giải thích chi tiết: Bước
này đòi hỏi lập bảng tất cả các cá nhân hoặc nhóm bị ảnh hưởng hoặc tác động đến
dự án, từ các bên liên quan chính (ví dụ: nhà tài trợ, người dùng) đến các bên
liên quan thứ cấp (ví dụ: nhà cung cấp, cơ quan quản lý).
Điều này nhấn mạnh rằng việc thiếu các bên liên quan sẽ dẫn
đến việc yêu cầu không đầy đủ và dự án thất bại.
Sử dụng các kỹ thuật như ma trận phân tích các bên liên quan
để phân loại họ theo mức độ ảnh hưởng và lợi ích (cao/thấp).
Bước này đặt nền tảng cho sự hợp tác đảm bảo các quan điểm
đa dạng được đưa vào để giảm thiểu sự không chắc chắn.
Ví dụ ứng dụng thực tế: Trong
dự án phát triển ERP cho một công ty sản xuất, không chỉ xác định đội ngũ CNTT
và ban điều hành mà còn cả công nhân nhà máy (người dùng cuối) và nhà cung cấp
(cho nhu cầu tích hợp). Trong một trường hợp thực tế tôi đã xử lý, việc thiếu bộ
phận pháp chế trong một dự án ERP đã dẫn đến các vấn đề về tính tuân thủ, khiến
việc triển khai bị trì hoãn 3 tháng.
Cách áp
dụng: Tạo ma trận RACI trong Excel cho buổi họp khởi động, liệt
kê các bên liên quan và vai trò của họ, sau đó xác nhận với ban lãnh đạo.
Bước 2: Hỏi Các Bên Liên Quan Những Câu Hỏi Đúng
(Ask Stakeholders the Right Questions)
Mô tả và giải thích chi tiết: Tiếp
nối bước 1 bằng cách đặt ra các câu hỏi mở để khám phá nhu cầu, mục tiêu và điểm
yếu thực sự.
Điều này nhấn mạnh rằng người dùng thường không biết họ muốn
gì, vì vậy hãy sử dụng các câu hỏi như "Bạn kỳ vọng giá trị kinh doanh
nào?" để gợi mở các yêu cầu rõ ràng. Tránh đặt câu hỏi dẫn dắt để tránh
thiên vị, và lặp lại dựa trên phản hồi, tuân thủ các nguyên tắc tinh gọn để loại
bỏ lãng phí trong các câu trả lời mơ hồ.
Ví dụ ứng dụng thực tế: trong
một dự án phần mềm chăm sóc sức khỏe, việc hỏi các bác sĩ lâm sàng "Bạn
đang gặp phải những thách thức hàng ngày nào với hệ thống hiện tại?" cho
thấy nhu cầu truy cập những thông tin bệnh án trước đó của các nơi khám khác, vốn
không nằm trong phạm vi ban đầu. Làm rõ hơn là các bác sĩ ngoài việc nắm thông
tin từ việc trao đổi trực tiếp với khách hàng họ đưa ra những chỉ định trực tiếp
thì trong phạm vi trước đó của phần mềm chưa kết nối được với những trung tâm/
bệnh viện trước đó mà bệnh nhân có thể đã khám qua. Thì việc cần làm là chuẩn bị
sẵn những tình huống có thể khai thác thông tin tại chỗ.
Áp dụng: Chuẩn
bị mẫu câu hỏi trong tài liệu dùng chung, thực hiện phỏng vấn hoặc hội thảo và
ghi lại câu trả lời để theo dõi.
Bước 3: Xác Định Các Kỹ Thuật Thu Thập Yêu Cầu Tốt
Nhất (Determine the Best Requirements Gathering Techniques)
Mô tả và giải thích chi tiết: Chọn
các phương pháp như phỏng vấn, nhóm tập trung, khảo sát, quan sát, tạo mẫu hoặc
mô hình hóa quy trình dựa trên bối cảnh dự án (hệ thống, đơn vị, doanh nghiệp).
Nhấn mạnh kết hợp các
kỹ thuật để bao quát toàn diện, sử dụng phương pháp Agile/Lean để thích ứng (ví
dụ: vòng phản hồi ngắn). Bước này giúp giảm thiểu sự không chắc chắn bằng cách
nắm bắt yêu cầu từ nhiều góc độ, như đã thảo luận trong bài viết "Cách Thu
thập Yêu cầu Hiệu quả".
Ví dụ ứng dụng thực tế: Trong
lần ra mắt sản phẩm mới cho một ứng dụng khởi nghiệp, chúng tôi sử dụng sản phẩm
mẫu để lấy phản hồi của người dùng và khảo sát thị trường để xác thực.
Doanh nghiệp thực tế đã sử dụng phương pháp quan sát quy
trình làm việc để đánh giá các yêu cầu tiềm ẩn, giúp tiết kiệm 15% chi phí làm
lại.
Áp dụng: Đánh
giá các kỹ thuật với ma trận quyết định (ví dụ: chi phí so với chiều sâu)
Giải thích
về ma trận quyết định:
- Ma
trận quyết định:
Đây là một công cụ được sử dụng để so sánh và đánh giá các lựa
chọn khác nhau dựa trên các tiêu chí đã xác định. Ma trận này giúp đưa ra
quyết định khách quan hơn bằng cách gán trọng số cho các tiêu chí và chấm điểm
cho từng lựa chọn.
- "Độ
sâu" trong ma trận quyết định:
- Cấu
trúc phân cấp: Ma trận quyết định có thể được tổ chức
theo cấu trúc phân cấp, trong đó các tiêu chí được chia thành các nhóm và
phân nhóm nhỏ hơn, tạo thành các cấp độ khác nhau. Độ sâu ở đây chỉ
ra số lượng cấp độ trong cấu trúc này.
- Giai
đoạn quyết định: Trong một quy trình ra quyết định
phức tạp, có thể có nhiều giai đoạn quyết định liên tiếp. Mỗi giai
đoạn có thể có một ma trận quyết định riêng, và kết quả của giai đoạn trước
sẽ ảnh hưởng đến ma trận quyết định ở giai đoạn sau. Độ sâu ở đây chỉ
ra số lượng các giai đoạn quyết định trong quy trình.
Ví dụ
minh họa:
Giả sử bạn đang xem xét việc mua một chiếc xe mới. Bạn
có thể sử dụng ma trận quyết định để so sánh các mẫu xe khác nhau dựa trên các
tiêu chí như giá cả, tính năng, độ an toàn, và hiệu suất nhiên liệu.
- Độ
sâu 1 (Đơn giản):
Bạn có thể chỉ sử dụng một ma trận quyết định duy nhất để so
sánh tất cả các mẫu xe.
- Độ
sâu 2 (Phân cấp):
Bạn có thể chia tiêu chí thành các nhóm như "Tiêu chí
tài chính" (giá cả, chi phí bảo trì) và "Tiêu chí hiệu suất" (động
cơ, tính năng an toàn). Sau đó, bạn có thể sử dụng một ma trận quyết định
cho mỗi nhóm, và kết hợp kết quả để đưa ra quyết định cuối cùng.
- Độ
sâu 3 (Quy trình):
Bạn có thể chia quá trình mua xe thành nhiều giai đoạn:
- Giai
đoạn 1: Xác định ngân sách và các loại xe phù hợp (sử dụng ma trận quyết
định).
- Giai
đoạn 2: So sánh các mẫu xe đã chọn (sử dụng ma trận quyết định khác).
- Giai
đoạn 3: Lái thử và đánh giá thực tế (sử dụng ma trận đánh giá).
- Kết
quả của giai đoạn 1 ảnh hưởng đến giai đoạn 2, và kết quả của cả hai giai
đoạn 1 và 2 ảnh hưởng đến giai đoạn 3.
Bước 4: Tài Liệu Hóa Mọi Thứ (Document
Everything)
Mô tả và giải thích chi tiết: Ghi lại
tất cả dữ liệu, thay đổi và giả định đã thu thập được vào tài liệu.
Cảnh báo rằng việc ghi chép kém có thể gây ra hiểu lầm, đồng
thời khuyến khích ghi chép đúng lúc để tránh tình trạng cũ kỹ. Sử dụng các mẫu
từ kho lưu trữ (ví dụ: Confluence) để đảm bảo khả năng truy xuất nguồn gốc và hỗ
trợ phân tích.
Ví dụ ứng dụng thực tế:. Trong
một dự án trước đây, tài liệu không đầy đủ đã dẫn đến việc vượt phạm vi scope của
dự án phát triển web, gây tốn kém thêm 10.000 đô la; tài liệu phù hợp đã hạn chế
điều này trong lần thực hiện tiếp theo. Áp
dụng: Sử dụng các mẫu chuẩn hóa với các trường như "Mã yêu cầu, Mô tả,
Bên liên quan, Ngày" và kiểm soát phiên bản cho các bản cập nhật. Giải thích
thêm việc không chuẩn hóa tài liệu dẫn đến những bất cập và mỗi người dùng 1
format hay form khác nhau điều này dẫn đến khó khăn trong việc tài liệu hóa. Nên
việc đưa ra 1 quy định – quy tắc chung để chuẩn hóa tài liệu là cần thiết.
Bước 5: Phân Tích Kết Quả (Analyze the Results)
Mô tả và giải thích chi tiết: Kiểm
tra các yêu cầu đã được ghi chép về tính đầy đủ, khả thi và giá trị bằng các
công cụ như phân tích chi phí-lợi ích hoặc ưu tiên (MoSCoW).
Nhấn mạnh việc phân tích theo ngữ cảnh (ví dụ: chiến lược so
với tính năng) để xác định giá trị thực, áp dụng phương pháp tinh gọn (lean) để
loại bỏ các hạng mục không tạo ra giá trị gia tăng và phương pháp linh hoạt
(agile) cho quá trình lặp lại.
Ví dụ ứng dụng thực tế: Đối với
doanh nghiệp phân tích các dự án khả thi
để tính ROI, loại bỏ các dự án có giá trị thấp. Trong quá trình nâng cấp phần mềm,
phân tích cho thấy các yêu cầu trùng lặp, làm giảm phạm vi dự án 20%. Áp dụng:
Sử dụng phân tích SWOT hoặc các phiên tinh chỉnh backlog, xếp hạng theo giá trị
kinh doanh trong các công cụ như Excel hoặc Azure DevOps.
Bước 6: Xác Minh Kết Quả (Verify the Results)
Mô tả và giải thích chi tiết: Xác
nhận các yêu cầu với các bên liên quan thông qua các đợt đánh giá hoặc thử nghiệm
để xác nhận tính chính xác và giải quyết xung đột.
Lưu ý rằng bước này bao gồm việc kiểm tra và điều chỉnh để lường
trước sự không chắc chắn trước khi triển khai.
Ví dụ ứng dụng thực tế: việc
thực hiện demo các chức năng và thảo luận thường xuyên ở từng giai đoạn của sản
phẩm phần mềm với các bên liên quan nhằm xác minh đúng kết quả mong muốn trước
khi hoàn thiện sản phẩm.
Bước 7: Ký Phê Duyệt (Sign-Off)
Mô tả và giải thích chi tiết: Nhận
được sự chấp thuận chính thức từ các bên liên quan chính để chốt các yêu cầu và
thiết lập trách nhiệm giải trình. Đây được xem là sự cam kết, để khỏi những
thay đổi sau này và cho phép dự án tiến triển theo đúng hạn mục và trong phạm vi.
Ví dụ ứng dụng thực tế: Việc
không làm rõ ngay từ đầu giữa các bên dẫn đến dự án bị trì hoãn và tăng chi phí
rất nhiều. Trong một dự án ERP trước đây việc không rõ ràng giữa đơn vị tư vấn
(bên được doanh nghiệp thuê riêng) và bên triển khai dự án – các thông tin không
rõ ràng hay hiểu sai ý một số chức năng làm dự án kéo dài thêm 6 tháng và chi
phí đội lên 40%.
Nhận xét
Đăng nhận xét