"Mất bao lâu để làm điều này?"
"Khó khăn thế nào để làm thay đổi này?"
Nếu bạn bắt đầu giận dữ và bực bội, bạn có lẽ là software developer. Estimation (định lượng) đau đớn, đặc biệt khi người yêu cầu estimate (Gọi họ 'Bob') chỉ có ý tưởng sơ bộ về điều họ yêu cầu. Nhiều nỗi đau này do sự khác biệt giữa những gì Bob muốn và những gì bạn nghĩ Bob muốn.
Estimate không phải là mục tiêu
Là dev, tôi nghĩ estimate là "Trung bình mất bao lâu để hoàn thành task?" Tôi bực vì thường không đủ thông tin trả lời câu đó, và tôi biết tôi sẽ bị gắn với lời nói của mình. Tôi giả định khả năng hit estimate sẽ là chỉ số performance tổng thể, nên tôi stress và annoyed.
Chúng là công cụ giao tiếp
Mọi product ship đều có thứ phụ thuộc vào nó. Tùy quy mô công ty, có thể là marketing, publicity, business analysis, future product planning, hoặc nhiều thứ khác. Điều này nghĩa là câu trả lời Bob tìm là "Khi nào tôi có thể bắt đầu giả định việc này xong, để plan thứ phụ thuộc vào nó?"
Tôi trả lời "Này nên xong vào...", nhưng Bob tìm "Này sẽ xong vào...".
David Bryant Copeland có cuốn sách hay, The Senior Software Engineer, nói về điều này ở chương 1:
Senior software engineer được tin cậy và kỳ vọng làm việc quan trọng nhất và làm nó reliably. Cách làm đó là focus mọi thứ bạn làm vào delivery của results.
Giữ điều đó trong tâm trí, tốt nhất là gặp Bob theo điều khoản của anh ấy. Điều này nghĩa là:
-
Estimate nên làm ở 90% confidence, không phải 50%
Bob muốn biết khi nào có thể plan thứ phụ thuộc. Nếu nghĩa là estimate cần pad (có lẽ), thì ok. Nếu nghĩa là bạn phải quay lại với anh ấy sau một hai tiếng, cũng ok.
-
Estimate nên dựa trên time-to-ship, không phải time-to-test-handoff hay time-to-deploy-queue hay bất cứ thứ gì khác
Quay lại focus trên delivery of results. Nếu Bob đợi project ship, không có ích gì nếu nó kẹt ở QA. Thường nghĩa là estimate cần pad lại, cũng ok.
-
Estimate tốt nhất thường là "Tôi không trả lời được bây giờ, nhưng tôi sẽ quay lại."
Dễ dàng hơn đạt estimate 90%-confidence time-to-ship nếu estimate chia thành phần nhỏ, mỗi phần dễ hiểu hơn. Nhiều sách thảo luận tactics estimate chính xác, nhưng ngoài phạm vi bài này.
Nếu tôi bị bảo là tôi không đi đủ nhanh thì sao?
Mọi nơi tôi làm, tôi được bảo management muốn chúng tôi đi nhanh hơn. Không quan trọng product deliver nhanh đến đâu, ngay cả khi quality hy sinh hoàn toàn, ngay cả khi estimate điên rồ, ngay cả khi bạn làm việc 20h/ngày, management vẫn muốn nhanh hơn. Việc của dev là thấy đó chỉ là wish và làm việc của mình: giữ pace nhanh nhưng maintainable, predictable, deliver results, và giữ quality bar cao.
Nếu tôi vượt estimate bằng số lớn và trông như estimate của tôi được pad nhiều?
Tôi chưa bao giờ thấy ai regularly overestimate bị trừng phạt, và nó sẽ trả lời lần sau project kéo dài hơn dự kiến. Overestimation bằng một lượng tốt hơn nhiều underestimation cùng lượng (tôi nghĩ giống Loss Aversion). Hầu hết thời gian, sẽ có backlog và bạn có thể bắt đầu task tiếp theo sớm. Tuyệt!
Nếu bạn target 50% case, unexpected complication có thể demolish toàn bộ product schedule. Bạn làm thế khoảng nửa thời gian! Nếu target 90% case, ngay cả khi chuyện xấu xảy ra, phần còn lại schedule vẫn hoạt động như dự định. Product ship on time, mọi người vui, bạn được raise promotion và phần thưởng tốt nhất: Bạn được làm thêm estimate!