Posted by Trước đây khi trao đổi với dev về ước tính thời gian hoàn thành một dự án để lên kế hoạch, khi tôi hỏi họ cần bao lâu để hoàn thành một task thì họ thường hỏi ngược lại tôi “Anh có nhiều kinh nghiệm lên kế hoạch hơn, nên theo kinh nghiệm thì anh thấy sẽ mất bao lâu?”
Đúng là theo kinh nghiệm thì tôi cũng có thể lờ mờ đưa ra được một khoảng thời gian, nhưng tôi nghĩ nếu có một khuôn khổ nào đó để giảm rủi ro sai lệch do cảm tính thì tốt hơn. Tôi tìm hiểu thì đọc được slide thuyết trình của Ken Norton về việc dẫn dắt team liên chức năng (cross-functional), trong đó có công thức ước tính thời gian hoàn thành công việc. Bạn có thể xem slide đó tại đây, tuy nhiên nội dung chính của slide thuyết trình này là về việc Product Manager có thể hỗ trợ các thành viên như thế nào trong tiến trình phát triển sản phẩm.
Trao đổi với người phụ trách task ba câu hỏi sau.
- Để hoàn thành task này thì mất bao lâu? = Ước tính khả quan (Likely estimate, L)
- Nếu có vấn đề đột xuất thì để hoàn thành task này sẽ mất bao lâu? = Ước tính bi quan (Pessimistic Estimate, P)
- Nếu mọi chuyện thuận buồm xuôi gió thì để hoàn thành task này sẽ mất bao lâu? = Ước tính lạc quan (Optimistic Estimate, O)
Ken Norton đưa ra công thức ước tính thời gian hoàn thành công việc như sau:
[O + (L*4) + P]/6
Ví dụ: Nếu dự tính thông thường (L) là 9 ngày, dự tính bi quan (P) là 15 ngày, dự tính lạc quan (O) là 7 ngày thì có thể đưa ra dự tính hoàn thành là [7 + (9*4) + 15)]/6 = 9.7 ngày
Hi vọng chia sẻ này có giá trị với bạn. Tôi nghĩ dù không làm Product Manager thì cái này vẫn có ích khi lên kế hoạch công việc cá nhân.
Bạn có thể tìm đọc định nghĩa các thuật ngữ như Agile, Scrum, Sprint, … tại đây.
6 comments