Quản lý kế hoạch dự án như thế nào ? Lộ trình từ Developer lên PM (Phần 4)
Tiếp nối phần 3 về kỹ thuật estimate, trong phần 4 này mình sẽ chia sẻ về cách quản lý kế hoạch dự án. Việc bạn tạo ra 1 schedule tốt nhưng bạn lại không quản lý nó tốt thì cũng sẽ không thể giúp dự án hoàn thành theo đúng kế hoạch được.
Để quản lý schedule của dự án hay kiểm soát tiến độ là một quy trình trong monitoring và controlling , nhằm giám sát tiến độ của dự án so với lịch trình đã được lập ra, đảm bảo các tài liệu được xây dựng trong quá trình Scheduling được cập nhật.
Project Manager cần xác định trạng thái tiến độ hiện tại của dự án, dựa trên các dữ liệu quan sát, đo lường được để nhận ra các sai lệch và lập kế hoạch cho các hành động khắc phục để giảm thiểu rủi ro, bất lợi.
Dự án đang dùng cách nào để quản lý schedule ?
Đầu tiên cần xác định team đang đang quản lý schedule bằng cách nào. Ngoài ra khi nào thì các tài liệu này được update.
- Master schedule: Dự án đang quản lý bằng excel hay dùng tool nào khác ?
- Milestone schedule: Công ty mình dùng excel để quản lý
- Detail schedule: Thông thường ở công ty mình sẽ sử dụng Backlog để quản lý
Kế hoạch có chậm so với master schedule không ? Có risks gì cần chú ý không ?
- Khi PM nhìn vào Master Schedule thì có thể thấy được so với tiến độ thực tế thì kế hoạch có bị chậm ở đâu không ? Có công việc nào không nằm trong Master Schedule & Detail Schedule không ?
- Nếu các công việc trong sprint hoàn toàn khớp với Master schedule thì dự án đang theo đúng tiến độ.
- Hằng tuần PM nên đánh giá xem dự án có rủi ro gì không ? Làm hết các Sprint thì có chắc hoàn thành được dự án ?
- Tài liệu Master Schedule & Detail Schedule có được update thường xuyên không ? Nếu chưa update thì cần update ngay.
Các thay đổi (nếu có) đã trao đổi, thống nhất với khách hàng chưa ?
Sau khi rà soát kế hoạch dựa trên thực tế và Master Schedule, Detail Schedule thì PM cần chia sẻ các nội dung thay đổi trong schedule cũng như các rủi ro đi kèm với khách hàng để khách hàng cũng nắm được tình hình. Tránh tình trạng báo cáo muộn sau đó để trễ tiến độ sẽ khiến khách hàng không vui và ảnh hưởng tới kế hoạch của khách hàng.
Khi khách hàng và PM đã chốt thống nhất các nội dung, phương án với những rủi ro đã chia sẻ thì PM sẽ cần note lại và chia sẻ với team dự án.
Team đang estimate và lên kế hoạch cho từng Sprint như thế nào ?
Thông thường ở công ty mình thì sẽ lên kế hoạch cho từng sprint như sau:
- Các task lớn, tính năng chính (Dtask) được chia nhỏ thành các sub-task, estimate trên file excel
- Mỗi sub-task được estimate theo kinh nghiệm của Dev, thường mỗi sub-task kéo dài từ 1h đến 12h
- Bên QC dựa vào schedule sẽ estimate theo DTask, đưa ra 1 bản test plan riêng và gửi cho PM phê duyệt
- Các task sẽ fill cả Estimated hours và Actual hours trên Backlogs
Team update và kiểm soát tiến độ hàng ngày bằng cách nào ?
Thông thường nếu dự án chạy theo Agile/Scrum thì sẽ có buổi daily meeting hằng ngày. Trong buổi này cả team sẽ cùng cập nhật tiến độ công việc của ngày hôm qua, công việc ngày hôm nay và những khó khăn gặp phải có thể ảnh hưởng đến tiến độ.
Cuối ngày, PM nên rà soát lại các task member thực hiện, trạng thái của các task đã được phản ánh đúng thực tế chưa, từ đó update và kiểm soát tiến độ dự án.
Làm sao để đánh giá một task là chậm tiến độ hay hoàn thành đúng tiến độ ?
- Đây là câu hỏi dành cho PM, ngoài việc dựa vào báo cáo của members, đâu là cách để bạn biết 1 task có đang đảm bảo tiến độ hay không ?
- DoD của 1 task cho Dev là gì ?
- Khi nào 1 task được coi là xong, trạng thái sẽ như thế nào ?
- Bằng cách update trạng thái đơn thuần
- Bằng cách chụp ảnh màn hình làm evidence
- Bằng cách thêm link dev for test
- Một số bạn làm rất tốt bằng cách thêm PR + link dev for test hoặc PR + evidence
- Thống nhất cùng 1 cách làm trong team ? Ví dụ quy định:
- Chuyển trạng thái sang resolved bắt buộc phải hoàn thành coding và có PR
- Chuyển trạng thái sang closed bắt buộc phải có link dev for test hoặc evidence
Nếu có issues chậm tiến độ, team xử lý bằng cách nào ?
- Đánh giá độ ưu tiên của task bị chậm tiến độ → có bắt buộc phải keep deadline trong sprint này không hay có thể đẩy lùi sang sprint khác ?
- Nếu phải xử lý ngay thì đưa người cứng hỗ trợ nếu bạn hiện tại quá sức; cần thời gian, khách hàng không đồng ý thì mới OT
- Tìm hiểu nguyên nhân của task bị chậm tiến độ
- Break nhỏ, chia cho các members khác hỗ trợ
Tình trạng kế hoạch, tiến độ của dự án đang như thế nào ? Cần actions gì ?
Với câu hỏi này, PM cần phải nắm rõ được tình trạng của dự án như thế nào để có những action phù hợp. Ví dụ : Team bị chậm tiến độ Sprint 5 -> Action đưa ra là OT và cover được hết các vấn đề vào cuối tuần.
Tổng kết
Tổng kết lại, để quản lý kế hoạch dự án không hề đơn giản, bạn cần luôn theo sát mục tiêu dự án, trả lời hết các câu hỏi được nêu ở trên để có thể nhìn nhận ra các vấn đề ảnh hưởng tới kế hoạch, tiến độ dự án. Trong phần tiếp theo của series lộ trình từ developer lên PM , mình sẽ chia sẻ cách quản lý phạm vi của dự án.