Công thức ước lượng công việc khi thực hiện dự án cho project manager

Estimate (ước tính khối lượng công việc) thường là vấn đề đau đầu nhất của mọi PM, Kế hoạch thường được xây dựng dựa trên ước tính của các thành viên của team dự án, có khi lại bị ép bởi khách hàng, hay các ràng buộc khác nhau về nguồn lực và mức độ ưu tiên hay môi trường có nhiều thay đổiBạn (PM) đã bao giờ gặp các tình huống này chưa?Kế hoạch đặt ra, PM báo cáo chốt tiến độ, thời gian, team commit và thực hiện theo kế hoạch. Sát tới ngày chuyển giao, team dev thông báo phát sinh thêm một mớ lỗi mới và kế hoạch sẽ fail

8 LƯU Ý

LƯU Ý 1: phân bổ thời gian dành cho việc estimateĐừng bắt đầu câu chuyện bằng những câu kiểu như “tôi cần bạn hoàn thành toàn bộ các đầu việc này trước thời điểm X”.Đưa ra thời điểm cần hoàn thành trước, rồi mới yêu cầu anh em estimate sẽ khiến cho việc estimate không còn đúng với lẽ tự nhiên. Kéo theo kết quả estimate sẽ không gần với thực tế.Khi anh em dev bị giới hạn thời điểm deadline và liên tục bị giục hoàn thành việc estimate, mọi người sẽ khó có thể nhìn nhận các yếu tố phức tạp của bài toán để estimate, và sẽ estimate theo kiểu cố gắng làm hài lòng người quản lý là chính.Do vậy, tốt hơn hơn là cho phép cả team một khoảng thời gian, tùy vào khối lượng của project để nhìn nhận được các vấn đề phức tạp tiềm ẩn và không đề cập tới hạn deadline của các tính năng trước khi estimate.

LƯU Ý 2: Chia nhỏ công việc cho đến khi nó có thể hoàn thành bởi 1 người, trong khoảng thời gian từ 1 ngày đến 1 tuần làm việcThông thường vào thời điểm bắt đầu dự án, bạn không có đủ thông tin chi tiết về tính năng phải làm. Do vậy, số ngày mà bạn estimate được thường không phản ánh đúng số ngày thực tế.Tuy nhiên, nếu bạn chia nhỏ công việc cần estimate thành những công việc nhỏ hơn, bạn sẽ có khả năng nhìn thấy được cụ thể những bước cần phải. Do vậy, bạn sẽ estimate được chính xác hơn.Nguyên tắc ở đây là bạn cứ tiếp tục chia nhỏ task cho đến khi thời gian estimate hoàn thành mỗi task nhỏ là từ 8-10h.

LƯU Ý 3: Phân loại công việcSau khi chia nhỏ công việc thành những công việc nhỏ hơn, bạn cần lùi lại một chút để nhìn được tổng thể những công việc sẽ phải làm. Bạn sẽ để ý thấy được có vô vàn những việc bạn có thể bắt tay vào làm luôn, một vài việc vẫn còn lờ mờ, và một vài việc vẫn có nhiều điều bí ẩn như là vùng tối phía bên kia của mặt trăng.Cụ thể hơn, chúng ta có 3 loại công việc sau:+ Task đã rõ những việc phải làm (Known Tasks): Đây là những task mà bạn đã biết rõ input, output và cụ thể các bước cần phải làm để có được output. Do vậy thời gian estimate để hoàn thành công việc này là xác định.+ Task mới chỉ rõ một phần những việc phải làm (Partially Known Tasks): Đây là loại task mà bạn mới chỉ nắm được input, output và nắm được sơ bộ cách làm. Tuy nhiên bạn ước lượng sẽ mất chừng 15-30 phút để tìm hiểu thêm hoặc cần thêm sự trợ giúp từ những người đã gặp vấn đề tương tự để có thể hoàn thành được task.+ Task không xác định (Unknown Tasks): Thường những task này sẽ cần bạn dành khoảng vài giờ tới cả ngày để hiểu công nghệ mà bạn sẽ định sử dụng để hoàn thành task.Việc xây dựng phần mềm hiếm khi là việc xây dựng những thứ bạn đã biết cách nó hoạt động như thế nào. Thông thường bạn sẽ cần phải tìm những công cụ, nền tảng API khác khau để giải quyết các bài toán. Do vậy, thời gian dành cho việc tìm hiểu hay nghiên cứu là yếu tố quan trọng cần phải được tính vào estimate.Sau khi phân loại task, bạn cần cố gắng đặt mục tiêu tìm hiểu thêm về project để cố gắng chuyển task Partially Known Tasks và Unknown Tasks về loại Known Tasks

LƯU Ý 4: Estimate lạiTới bước này, tất cả các task của bạn đã được chuyển thành Known Task, bạn đã có thêm nhiều thông tin cụ thể hơn cho công đoạn implement. Do vậy, kéo theo là kết quả estimate sẽ chính xác hơn.Một ưu điểm của bước này là bạn có cơ hội xem lại các yêu cầu, có cái nhìn tổng quan hơn. Và sẽ có thể phát hiện ra những vấn đề mà ở các bước trước bạn chưa kịp nhìn ra. Một điểm chú ý ở đây là, mỗi khi bạn có thêm thông tin gì mới về project, bạn nên estimate lại để có con số chính xác nhất.

LƯU Ý 5: Không thỏa hiệpĐã bao giờ các bạn nghe thấy các câu kiểu thế này?+ Task này chỉ nhỏ như con muỗi ấy mà!+ Chắc chỉ mất 5 phút để fix lỗi thôi+ Chắc task này không chiếm quá 15 phút đâuNhững task này ban đầu nhìn có vẻ tốn ít thời gian, nhưng té ra lại thường là loại task tốn kém nhất. Những loại task như thế này hay là nguyên nhân khiến team trễ deadline.Nguyên nhân chính khiến những loại task này chiếm nhiều thời gian hơn mong đợi là chúng thường xuất hiện từ các cuộc họp standup hàng ngày hoặc qua những cuộc trò chuyện giữa mọi người. Khi dev không có đủ thời gian để xem xét độ phức tạp của task, họ sẽ đánh giá thấp độ phức tạp và dẫn đến estimate sai.

LƯU Ý 6: Người nào làm, người đó estimateNgười được giao nhiệm vụ làm task thường là người hiểu rõ hoặc có động lực để hiểu rõ nhất công việc phải làm. Người này sẽ có khả năng nhìn thấy những chi tiết lặt vặt mà cũng không kém phần quan trọng của công việc. Đây là những yếu tố quan trọng để có được estimate chính xác nhất.

LƯU Ý 7: Không bỏ qua những việc phụMột số ví dụ về việc phụ: + Checkbug+ Fixbug+ Review code+ Build App+ Deploy AppNhìn qua thì những việc này không tốn thời gian lắm. Tuy nhiên luôn có vấn đề nào đó xảy ra. Và bạn sẽ khó mà lường trước được độ phức tạp. Hơn nữa, ngay cả khi không có vấn đề, khi bạn cộng gộp thời gian lại, bạn sẽ có được con số không hề nhỏ.

LƯU Ý 8: Có kế hoạch cho rủi ro bất chợtMột thành viên nào đó đột nhiên bị ốm, hoặc có kỳ nghỉ mát, hoặc có một vài ngày nghỉ bắt buộc, hoặc một vài bug khủng xuất hiện vào những lúc không ngờ tới. Bạn cố gắng dựa vào kinh nghiệm đã làm của mình, để xem xét đưa những yếu tố này vào kết quả estimate của mình.

Chúc các bạn may mắn!