Ước lượng lập trình hay trễ vì người ta thường chỉ tính phần ngồi viết mã, mà quên thử nghiệm, xem lại, sửa lỗi, họp hành và bị ngắt quãng, và vì có những điều chưa biết chỉ lộ ra khi bắt tay vào làm. Chia việc nhỏ, ước lượng theo khoảng, nói rõ giả định và báo sớm khi có thay đổi sẽ giúp ước lượng của bạn đáng tin hơn nhiều.
Chào bạn, đây là Nhà Lập Trình. Câu hỏi việc này mất bao lâu có lẽ là câu hỏi khó nhất mà một lập trình viên phải trả lời mỗi tuần. Trả lời ngắn thì bị trễ, trả lời dài thì bị nghĩ là lười. Tập này mình kể vì sao ước lượng khó, và vài cách để bớt khổ.
Phần chìm của tảng băng
Khi được hỏi thêm một chức năng lọc đơn hàng theo ngày mất bao lâu, đầu bạn hình dung phần viết mã: thêm ô chọn ngày, sửa truy vấn, hiện kết quả. Chừng nửa ngày. Bạn nói nửa ngày.
Nhưng phần viết mã chỉ là phần nổi. Phần chìm gồm: đọc lại mã hiện có để biết sửa ở đâu, xử lý múi giờ và những ngày không có đơn, viết thử nghiệm, chạy thử trên nhiều trình duyệt, gửi xem lại mã, sửa theo góp ý, đưa lên máy thử, chờ người dùng thử xác nhận, đưa lên máy thật.
Cộng thêm những thứ không liên quan đến việc này mà vẫn ăn thời gian: một buổi họp, một lỗi khẩn ở chỗ khác, một đồng nghiệp hỏi, một buổi chiều máy chạy chậm. Nửa ngày thành hai ngày.
Người có kinh nghiệm không giỏi đoán hơn người mới. Họ chỉ nhớ tới phần chìm, và cộng nó vào.
Những điều chưa biết
Nguồn trễ thứ hai là những điều bạn không biết lúc ước lượng. Bạn tưởng thư viện hỗ trợ lọc theo ngày, hoá ra không. Bạn tưởng bảng đơn hàng có cột ngày tạo, hoá ra có hai cột ngày với ý nghĩa khác nhau và không ai nhớ cột nào đúng.
Những điều này không thể biết trước khi bắt tay vào làm. Chúng chỉ lộ ra khi bạn mở mã, chạy thử, hỏi người dùng. Và chúng hầu như luôn làm việc dài ra, hiếm khi làm ngắn lại.
Vì vậy, việc càng mới, càng lạ, càng chạm vào phần hệ thống bạn chưa quen, thì ước lượng càng không chắc chắn. Sửa một lỗi nhỏ ở phần bạn viết tuần trước thì ước lượng khá chuẩn. Tích hợp một dịch vụ bên ngoài lần đầu thì có thể lệch gấp ba.
Nói ra điều này với người hỏi là trung thực, không phải là đùn đẩy.
Áp lực của con số đẹp
Nguồn trễ thứ ba mang tính con người. Người hỏi thường mong một con số nhỏ. Người trả lời, nhất là người mới, muốn tỏ ra có năng lực, nên nói một con số nhỏ. Có khi người hỏi còn đẩy thêm: không nhanh hơn được à.
Con số nói ra dưới áp lực thường là con số của trường hợp mọi thứ suôn sẻ. Mà mọi thứ hiếm khi suôn sẻ. Con số đó trở thành một lời hứa, và khi trễ, bạn mất niềm tin.
Một chị trưởng nhóm ở Hà Nội kể chị dạy các bạn trong đội một câu: con số của em là thông tin, không phải lời hứa. Chị muốn nghe con số thật, kể cả khi nó không đẹp, vì chị cần nó để lên kế hoạch và nói chuyện với khách hàng.
Nếu bạn ở vị trí hỏi, hãy tạo không khí để người ta dám nói con số thật. Ép một con số nhỏ không làm việc nhanh hơn, chỉ làm cho kế hoạch sai hơn.
Ước lượng theo khoảng và nói rõ giả định
Thay vì nói một con số, hãy nói một khoảng: khoảng hai tới bốn ngày. Khoảng rộng hay hẹp tuỳ độ chắc chắn. Việc quen thì khoảng hẹp. Việc lạ thì khoảng rộng. Khoảng này truyền đạt thêm một thông tin quý: mình chắc chắn tới đâu.
Nói rõ giả định: hai tới bốn ngày, nếu thư viện hiện tại hỗ trợ được, và nếu không phải đổi cấu trúc bảng. Khi giả định sai, mọi người hiểu vì sao ước lượng thay đổi.
Chia việc lớn thành việc nhỏ trước khi ước lượng. Ước lượng một việc hai tuần gần như là đoán. Ước lượng mười việc mỗi việc một ngày thì chính xác hơn nhiều, vì khi chia, bạn buộc phải nghĩ qua từng bước và phát hiện phần chìm.
Với việc có quá nhiều điều chưa biết, hãy đề xuất một khoảng thời gian ngắn để tìm hiểu trước: cho mình một ngày tìm hiểu rồi mình ước lượng lại. Đó là cách làm chuyên nghiệp, không phải trì hoãn.
Báo sớm khi mọi thứ thay đổi
Dù ước lượng giỏi đến đâu, bạn vẫn sẽ có lúc trễ. Điều phân biệt người đáng tin với người không đáng tin không phải là không bao giờ trễ, mà là báo trễ sớm hay muộn.
Ngày thứ hai của một việc ước lượng ba ngày, bạn phát hiện phải đổi cấu trúc bảng. Hãy báo ngay: mình phát hiện điều này, ước lượng mới là năm tới sáu ngày, hoặc có thể cắt bớt phần này để giữ ba ngày. Người phụ trách có thời gian điều chỉnh.
Đừng im lặng tới ngày thứ ba rồi mới nói chưa xong. Lúc đó mọi kế hoạch phụ thuộc vào việc của bạn đều vỡ, và không còn thời gian xoay xở.
Ghi lại ước lượng và thời gian thật của mình qua nhiều việc. Sau vài tháng, bạn sẽ thấy mình thường lệch bao nhiêu, và tự điều chỉnh. Ước lượng là kỹ năng, và như mọi kỹ năng, nó tốt lên khi có phản hồi.
Câu hỏi thường gặp
Vì sao lập trình viên hay ước lượng thiếu thời gian?
Vì thường chỉ tính phần viết mã, quên thử nghiệm, xem lại, sửa lỗi và các gián đoạn, và vì có những điều chưa biết chỉ lộ ra khi bắt tay vào làm. Áp lực muốn nói con số đẹp cũng góp phần.
Nên ước lượng bằng một con số hay một khoảng?
Nên dùng khoảng, ví dụ hai tới bốn ngày, kèm giả định. Khoảng thể hiện mức độ chắc chắn và giúp người lập kế hoạch chuẩn bị tốt hơn.
Làm sao ước lượng việc chưa từng làm?
Đề xuất một khoảng thời gian ngắn để tìm hiểu trước, rồi mới ước lượng. Chia việc thành các phần nhỏ cũng giúp phát hiện những bước bị bỏ sót.
Khi biết sẽ trễ thì nên làm gì?
Báo ngay khi phát hiện, kèm lý do, ước lượng mới và các lựa chọn như cắt bớt phạm vi. Báo sớm giúp mọi người kịp điều chỉnh kế hoạch.
Làm sao cải thiện kỹ năng ước lượng?
Ghi lại ước lượng và thời gian thực tế cho từng việc, xem lại định kỳ để biết mình hay lệch bao nhiêu và thường quên phần nào, rồi tự điều chỉnh.
