Skip to Main Content
Module 13 · Sau khi dự án hoàn thành

Thực hiện Project Review sau dự án

Hiểu Project Review là gì, vì sao BA nên tham gia review sau dự án và cách rút ra bài học kinh nghiệm để cải thiện các dự án sau.

9 phút đọcBeginner

Project Review là gì?

Project Review là hoạt động nhìn lại dự án sau khi đã hoàn thành một giai đoạn quan trọng hoặc sau khi dự án kết thúc. Mục tiêu là đánh giá điều gì đã làm tốt, điều gì chưa tốt, điều gì cần cải thiện và bài học nào nên mang sang dự án tiếp theo.

Với Business Analyst, Project Review rất quan trọng vì BA thường tham gia từ lúc hiểu vấn đề, khai thác requirement, phân tích, đặc tả, phê duyệt cho đến lúc hỗ trợ triển khai. Vì vậy BA có nhiều góc nhìn về chất lượng requirement, sự phối hợp giữa các bên và mức độ đáp ứng nhu cầu business.

Project Review nên nhìn lại những gì?

1
Mục tiêu dự án

Dự án có đạt mục tiêu kinh doanh ban đầu không? Giá trị kỳ vọng có được tạo ra không?

2
Requirement

Requirement có rõ không, có bị thay đổi nhiều không, có bị hiểu sai trong quá trình triển khai không?

3
Stakeholder

Các bên liên quan có được tham gia đúng lúc không, có phản hồi kịp thời không, có xung đột nào chưa xử lý tốt không?

4
Quy trình làm việc

Cách giao tiếp, review, approval, change request và phối hợp giữa BA, Developer, Tester, PM có hiệu quả không?

5
Bài học kinh nghiệm

Điều gì nên tiếp tục, điều gì nên dừng lại và điều gì nên cải thiện trong dự án sau?

Vì sao BA nên tham gia Project Review?

BA là người kết nối giữa business và technical team. Trong Project Review, BA có thể giúp nhóm nhìn lại xem requirement ban đầu có đủ rõ không, stakeholder có được khai thác đúng chưa, tài liệu có hữu ích cho Developer và Tester không, acceptance criteria có đủ để kiểm thử không.

Nếu dự án gặp vấn đề như scope creep, hiểu sai requirement, thay đổi liên tục hoặc user không hài lòng, Project Review là cơ hội để tìm nguyên nhân gốc thay vì chỉ đổ lỗi cho một cá nhân hoặc một team.

Câu hỏi BA nên dùng trong Project Review

  • Dự án có đạt mục tiêu kinh doanh ban đầu không?
  • Requirement nào bị hiểu sai hoặc thay đổi nhiều nhất?
  • Giai đoạn elicitation có bỏ sót stakeholder nào không?
  • Requirement specification có đủ rõ cho Developer và Tester không?
  • Approval có diễn ra đúng người, đúng thời điểm không?
  • Change request có được quản lý rõ ràng không?
  • Người dùng có gặp khó khăn khi tiếp nhận hệ thống không?
  • Dự án sau nên làm khác điều gì?

Project Review không phải buổi tìm lỗi

Một Project Review tốt không nên biến thành buổi chỉ trích. Mục tiêu là học hỏi và cải thiện. BA nên giúp cuộc trao đổi tập trung vào dữ kiện, tác động, nguyên nhân và hành động cải thiện.

Ghi nhớ

Project Review giúp BA trưởng thành hơn sau mỗi dự án. Dự án nào cũng có bài học, kể cả dự án thành công.

Ví dụ liên hệ dự án Oracle APEX

Trong một dự án Oracle APEX, Project Review có thể nhìn lại các điểm như: bảng dữ liệu có được thiết kế đúng nhu cầu không, form có dễ dùng không, report có đúng kỳ vọng không, dynamic action có gây khó hiểu không, phân quyền có rõ không, workflow approval có đúng rule nghiệp vụ không và hiệu năng truy vấn có đáp ứng thực tế không.

Kết luận

Project Review giúp tổ chức học từ dự án vừa hoàn thành. Với BA, đây là cơ hội để cải thiện cách khai thác, phân tích, đặc tả, phê duyệt và quản lý requirement trong các dự án tiếp theo.

← Bài trướcĐây là bài đầu tiên
Bài tiếp theo →Xác nhận việc hoàn thành dự án