Estimate (ước tính khối lượng công việc) thường là chủ để gây tranh cãi lớn nhất giữa DEV và quản lý tiến độ dự án (PM, Leader, Client).

Có một thực tế: Estimate chính xác thời gian thực hiện task là một việc rất khó!

Vì các task cần estimate thường là những task mới, mơ-hồ và có nhiều yếu tố không-xác-định xuất hiện trong suốt quá trình thực hiện. Tôi cảm thấy estimate giống như việc dự đoán tương lai, phải may mắn lắm mới có một kết quả chính xác. Việc này tương tự như trò ném phi tiêu trúng hồng tâm vậy… xác suất trúng là rất thấp! Tôi không thích suy nghĩ này. Để tránh những tổn thất sau mỗi lần release muộn, tôi bắt đầu tìm kiếm những đội khác cũng gặp phải vấn đề tương tự, tổng kết lại các phương pháp xử lý và lấy ra các giải pháp hiệu quả nhất.

Và đây là giải pháp mà anh em tổng kết lại “Sau khi estimate thời gian để hoàn thành một tính năng X, hãy x3 con số này lên. 😅”

Hiển nhiên, đây không phải là công thức estimate chính xác.

Trong quá trình tìm kiếm giải pháp cho vấn đề này, tôi đã học được một thứ đó là không hề có mẹo hay lối tắt để giải quyết vấn đề. Chúng ta cần thực hiện đầy đủ tuần tự các bước để có kết quả estimate chuẩn nhất.

Dưới đây là 4 bước mà tôi đã sử dụng để estimate cho các dự án của mình

Bước 1. Phân bổ thời gian dành cho việc estimate

Nếu bạn thực sự muốn đội của mình có thể đưa ra estimate chính xác nhất, cố gắng đừ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 ra đượ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.

Việc này để để sau khi estimate xong, để quyết định xem có nên xóa một phải chức năng phức tạp quá hay không.

Bước 2. Chia nhỏ công việc thành các công việc con

Thô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.

“Khi bạn còn chưa biết được cụ thể bạn sẽ làm những gì, bạn sẽ không thể biết khi nào bạn sẽ hoàn thành nó” –Joel Spolsky, Stack Overflow CEO

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.

Bước 3. Phân loại task

Sau 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.

Hiếm có dự án nào mà DEV không cần phải học thêm một cái gì đó mới để có thể làm được. Việc phải học thêm các công nghệ mới để hoàn thành dự án là không thể tránh khỏi. 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

Bước 4. Estimate lại

Tớ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.

Hãy quan sát biểu đồ sau để thấy được sự liên hệ giữa thời gian estimate và mức độ rõ ràng của các yêu cầu cũng như các giải pháp để thực hiện các yêu cầu.

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.

Hãy chú ý 4 thứ sau trong khi bạn đang estimate project

Điều 1. Lưu ý những câu có từ “Chỉ” – “Just”

Có một luật bất thành văn là thường những task có nhiệm vụ “Chỉ” làm một tính năng nào đó lại là những task tốn kém nhất.

• 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 đâu.

Nhữ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 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 stand-up meeting 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.

Do đó, có một TIP cho anh em DEV, là nếu bất chợt PM có yêu cầu làm task gì, hãy cố gắng nhớ cho kỹ yêu cầu của task, sau đấy bình tĩnh về chỗ tìm hiểu estimate và hẹn đưa thông tin estimate cho PM vào một thời gian khác. Anh em còn làm ăn với nhau lâu dài, không việc gì phải vội. Thà làm lâu mà tính năng hoạt động ổn định, còn hơn làm vội mà sau đấy phải mất rất nhiều thời gian để fixbug.

Điều 2. Người nào làm, người đó estimate

Ngườ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.

Điều 3. Đừng bỏ qua những task lặt vặt

Thường trong quá trình thực hiện project, bạn sẽ nhận được mộ lô những task lặt vặt kiểu như:

• Checkbug
• Fixbug
• Review code
• Build App
• Deploy App

Nhì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ỏ.

Điều 4. Xem xét tới một vài khả năng gây ra việc delay bất thình lình

Mộ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ú ý ở đây là trong quá trình làm project, bạn cố gắng để ý tới các sự kiện không mong đợi, khả năng xuất hiện của bug theo thời gian để có thể có những chú ý cho những lần estimate tiếp theo

Kết luận

Đối với việc estimate, tìm ra các kết quả chính xác thường rất khó. Do vậy, anh em DEV chúng ta nên chấp nhận thực tế này. Tuy nhiên, chúng ta cũng nên estimate càng sát với thực tế càng tốt, dẫu có không thể tìm được kết quả chính xác, nhưng phải luôn cố gắng nỗ lực để làm được điều đó. Quá trình này sẽ giúp anh em DEV chúng ta hiểu biết rõ-ràng và nắm được chính-xác các bước để giải quyết các vấn đề.

Cuối cùng, chúc dự án của anh em hoàn thành đúng hạn!