Closing a Project: What you need to do as a Project Manager

Tình huống

Bạn là một project manager (PM) (hay Scrummaster (SM)) được điều động vào một dự án phát triển (phần mềm) thay thế PM/SM cũ. Dự án đang ở giai đoạn cuối. Theo báo cáo từ PM/SM cũ, dự án "gần xong, một chút nữa là xong" nhưng một số cái (deliverables, specs, requirements...) không thể "chốt" hay close được với khách hàng. Mục tiêu được giao từ cấp trên là close dự án này, càng sớm càng tốt, giải phóng (bớt) nhân sự, không để dự án dai dẳng, tốt công của và thời gian. Với tư cách là PM/SM, bạn nên/phải làm gì?

Dự án đang ở đâu?

Trả lời câu hỏi này để biết được hiện trạng của dự án. Một số câu hỏi cần đặt ra

1. Dự án cần làm những gì? 
1. Schedule/WBS (Work Breakdown Structure) ở đâu, đã làm được gì?
2. Product backlog/sprint backlogs ở đâu, đã làm được gì?
2. Những gì (chức năng/user story) đã hoàn thành, những gì chưa hoàn thành, những gì đang "treo" (đang được confirm). Nên trả lời riêng câu hỏi này.
3. Dự án đang trong phase nào? (yêu cầu, thiết kế, lập trình, kiểm thử đơn vị, kiểm thử tích hợp, deploy, tạo tài liệu). Một số chức năng có thể ở phase này, hoặc ở phase khác. Cần liệt kê cụ thể.
4. Đầu vào của dự án gồm những gì? (tài liệu yêu cầu, user stories, thiết kế, nếu có)
5. Đầu ra của dự án gồm những gì? Đã làm được gì? Trạng thái (being confirmed, being reviewed, done...)
6. Kế hoạch và trạng thái (schedule, burndown chart)

Vấn đề của dự án là gì?

Cần họp toàn team, lắng nghe thông tin từ tất cả những người liên quan.

Risk và issue log là hai tài liệu quan trọng nhất cần có. Với những dự án quản lý kém, hai tài liệu này thường không tồn tại hoặc quản lý kém. Đặc biệt, với dự án không chạy tốt theo khung Scrum, thường hai tài liệu này không tồn tại và cần được tạo lại.

Lưu ý rằng trong danh sách issue log không chỉ chứa các vấn đề kỹ thuật mà cần bao gồm cả danh sách các vấn đề về nhân sự, communication, yêu cầu, thiết kế, kỹ thuật, năng lực của cả nhóm.

Cận biên tích hợp của dự án

Xác định những hệ thống, chức năng có tích hợp, liên kết với dự án chúng ta tiếp quản. 

Một pattern hay thấy ở các  dự án phần mềm là, từng module đơn lẻ đã hoàn thành nhưng phần tích hợp các module đó trong phạm vi nội bộ do nhóm phát triển đảm nhận không được ý thức tới, chưa làm, hoặc làm nửa vời, không có issue log.

Một pattern khác hay thấy hơn là phân tích hợp hệ thống/phần mềm chúng ta tiếp quản với hệ thống bên ngoài làm chưa tốt. Với phần này, cần xác định các hệ thống liên quan, những người chịu trách nhiệm (đầu mối) của các dự án đó, họp và xác định trạng thái, công việc tồn đọng, issue list.

Tiếp theo phải là gì?

Sau khi đã tiến hành ba bước trên, cần refine lại danh sách công việc còn lại cần làm, tạo schedule/WBS hay masterplan cho các sprint tiếp theo. Trả lời câu hỏi: Cần khoảng bao nhiêu thời gian (và tiền) (ở mức high level) để hoàn thành nốt công việc tồn đọng. Nếu tốt hơn, nên tạo plan cho từng sprint ở mức high level.

Tiếp theo phải là gì?

Tiến hành dự án theo cách thông thường mà bạn, với tư cách là PM/SM nghĩ là hợp lý để hoàn thành dự án với mức độ tự tin và quyết liệt cao nhất. Luôn chú ý tới communication và risk (là hai yếu tố khá "cao cấp" với PM/SM non tay)

Kết luận

Theo kinh nghiệm cá nhân, việc xác định issue log và các hệ thống cận biên cần tích hợp tới là các điểm nóng cần làm để có thể close được dự án.

Image credit: http://www.geograph.org.uk/photo/785504

--

Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン　ヒュン　ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.