Estimation: có gì ngoài những con số?
Không chỉ là đoán thời gian, mà còn là ván bài giữa kinh nghiệm, logic và khả năng dự đoán rủi ro.
Chào bạn 👋,
Nếu bạn đang là kĩ sư phần mềm và đã từng phải estimate một task, chắc chắn bạn đã trải qua tình huống này ít nhất một lần (hoặc nhiều lần! 😅):
💬 "Task này có vẻ đơn giản, chắc mất tầm 2 ngày." → Nhưng rồi một tuần trôi qua, bạn vẫn đang vật lộn với bug từ thư viện bên thứ ba.
💬 "Dự án này kéo dài khoảng 5 tháng." → Nhưng đến tháng thứ tư, bạn nhận ra scope ban đầu đã thay đổi quá nhiều, và deadline chỉ còn là một khái niệm mơ hồ.
💬 "Tích hợp API này chắc mất 1 tuần." → Nhưng rồi bạn phát hiện tài liệu API bị thiếu, support của bên thứ ba phản hồi chậm, và bạn mất đến 3 tuần để hoàn thành.
Chuyện bị hố estimation là vấn đề không của riêng ai khi đã theo nghiệp làm phần mềm 😆. Nhưng thay vì trách móc bản thân hay đổ lỗi cho hoàn cảnh, có cách nào để estimate thực tế hơn không?
Trong bìa viết tuần này, mình sẽ nói về những lầm tưởng phổ biến khi estimate, tại sao chúng luôn khiến chúng ta dự đoán sai, và quan trọng nhất: làm thế nào để sai ít hơn?
Cùng bắt đầu nào! 🚀
📌 Disclaimer: Bài viết này dựa trên kinh nghiệm cá nhân và góc nhìn của một kỹ sư phần mềm, không đại diện cho tất cả tình huống thực tế. Thành công hay thất bại của một dự án còn phụ thuộc vào nhiều yếu tố khác như quy trình quản lý, văn hóa công ty, năng lực đội nhóm, và cả yếu tố khách quan bên ngoài. Mọi quan điểm trong bài mang tính tham khảo, khuyến khích bạn kết hợp với trải nghiệm thực tế của riêng mình để đưa ra quyết định phù hợp.
👨🏻💻 Trước khi đi vào chi tiết...
Nếu đây là lần đầu bạn đọc newsletter này, thì xin tự giới thiệu:
Mình là Bryant (Dũng) 👨🏻💻 host của Growth Engineering Journal - nơi mình chia sẻ mỗi tuần về tư duy phát triển bản thân, kỹ năng làm việc, và những thứ hay ho dành cho kỹ sư phần mềm. 😜.
Nếu bạn chưa subscribe thì đây là 4 bài viết gần nhất bạn đã bỏ lỡ:
Đừng để lỡ những bài viết thú vị tiếp theo – subscribe ngay để nhận những chia sẻ mới nhất mỗi tuần nhé!
🔎 Những lầm tưởng thường gặp về estimation
❌ Lầm tưởng 1: estimation là một cam kết
Nếu dựa vào kết quả estimation để đánh giá năng lực kỹ sư phần mềm thì đó là một quan điểm thiếu công bằng. Đặc biệt, nếu bạn không có background kỹ thuật và không nắm rõ các yếu tố ảnh hưởng đến việc thực thi, rất dễ dẫn đến hiểu lầm trong quá trình làm việc.
Mình từng tham gia một dự án đang trong giai đoạn nước rút, gần cháy deadline. Vừa onboard được 1 ngày, mình đã được giao một task kèm câu hỏi kinh điển:
💬 "Em estimate xem mất bao lâu để làm xong?"Dù chưa có đủ thông tin về hệ thống, mình vẫn đưa ra một con số dựa trên hiểu biết và những gì quan sát được từ tại thời điểm đó. Nhưng khi bắt tay vào làm, thực tế bắt đầu vả thẳng vào mặt:
Hệ thống quá phức tạp – codebase legacy, tài liệu thì thiếu sót.
Thư viện bên thứ ba dính bug – fix xong bug này lại lòi ra bug khác.
Business logic chồng chéo – một thay đổi nhỏ có thể ảnh hưởng đến nhiều phần khác của hệ thống.
Và vì mình mới vào team nên stakeholders thấy estimation của mình một đằng, nhưng thời gian thực tế lại một nẻo. Điều này khiến mối quan hệ giữa mình với team và PM có chút căng thẳng.
Những ngày sau đó, mình dành hàng giờ đọc code, hỏi han team member, đọc cả repo GitHub của thư viện để hiểu cách nó hoạt động. Mỗi ngày lại có thêm thông tin mới, và mỗi thông tin mới lại làm thay đổi estimation ban đầu.
Phải mất gần một sprint (2 tuần), mình mới phần nào có đủ bức tranh toàn cảnh để estimate chính xác hơn. Đồng thời, mình cũng hướng dẫn team cách tiếp cận, giúp mọi người có một góc nhìn chung thay vì chỉ trích estimation ban đầu quá sai lệch.
🚀 Kinh nghiệm rút ra
Estimation không phải là lời hứa, mà là một công cụ để ra quyết định. Nếu tình hình thay đổi, estimation cũng phải thay đổi.
"Individuals and interactions over processes and tools."1 Task là công việc cá nhân, nhưng kết quả là của cả team. Chủ động giao tiếp, cập nhật thường xuyên, báo sớm khi có vấn đề – để để nước tới chân mới nhảy.
Những người code giỏi chưa chắc estimate tốt, và ngược lại. Ngoài code thì mình hay đầu tư thời gian tìm hiểu về business, quy trình, và con người – những yếu tố non-technical nhưng ảnh hưởng trực tiếp đến dự án.
Mỗi dự án đều khác nhau. Nhất là với fixed-price projects hoặc các sự kiện lớn có deadline cố định, việc estimate là một chuyện, còn khi bắt tay vào làm thì lại là chuyện khác, nên phải luôn chủ động để sync up với tất cả các bên liên quan nhằm tìm giải pháp phù hợp.
❌ Lầm tưởng 2: dành nhiều thời gian phân tích thì estimation càng chính xác
Hãy tưởng tượng bạn muốn build một game mobile đơn giản như Flappy Bird vào năm 2013. Bạn nghĩ đơn giản “cứ làm nhanh rồi launch, có gì tinh chỉnh sau."
Là một dev có kinh nghiệm, bạn tự tin lập kế hoạch chi tiết. Bạn lao đầu vào tìm hiểu thuật toán điều khiển con chim bay. Tìm hiểu cách lập trình game bằng Objective-C (iOS) và Java (Android). Chia task theo module, estimate từng task theo giờ.
Estimation mà bạn có:
💡 "Dự án có 10 task, trung bình khoảng 2h/task, vậy sau 20h thì sẽ hoàn thành. Buffer thêm khoảng 5h để sửa lỗi lặt vặt vậy tổng cộng cần khoảng 25h cho game con chim nhảy"
Ngày đầu tiên, mọi thứ đúng như dự tính. Nhưng đến ngày thứ hai, bạn bắt đầu cảm thấy có gì đó sai sai:
Con chim bay quá nhanh trên Android nhưng lại chậm trên iOS. Debug mới phát hiện FPS2 của từng thiết bị ảnh hưởng đến tốc độ nhảy.
Lỗi score double-counting khi người chơi chạm màn hình liên tục.
Âm thanh bị delay trên một số dòng máy vì hiệu ứng nén dữ liệu.
Kết quả? Dự án mất đến 40h thay vì 25h như dự tính ban đầu.🤡
🚀 Kinh nghiệm rút ra
Việc estimate quá chi tiết từ đầu chỉ tạo ảo tưởng kiểm soát, nhưng thực tế bạn không thể đoán trước mọi thứ.
Bắt đầu với range estimation (vd: 8-12h thay vì 10h) để có không gian điều chỉnh khi có rủi ro.
Dành thời gian validate assumptions thay vì chỉ chia nhỏ task. Một số task tưởng đơn giản nhưng khi triển khai lại phức tạp hơn dự đoán rất nhiều.
Trong thực tế, bạn sẽ phải thực hiện những task tích hợp hệ thống bạn không biết rõ với công nghệ quen thuộc (hoặc không). Phần lớn rủi ro sẽ nằm ở thời gian tìm hiểu hệ thống, công nghệ. Việc nghiên cứu trước là cần thiết vì ngoài nắm được requirement ra thì hiểu công nghệ làm được gì và làm tới mức độ nào cũng sẽ giúp bạn đưa ra estimate sát thực tế. Nếu mọi thứ quá mới thì hãy làm một PoC3 để đánh giá tính khả thi của giải pháp.
❌ Lầm tưởng 3: chỉ dev mới liên quan đến estimation
Một lần khác, team mình nhận task tích hợp hệ thống thanh toán với bên thứ ba. Cả team estimate rất tự tin: "API có sẵn, tài liệu đầy đủ, chắc mất 3 tuần là xong."
Nhưng đời không như là mơ:
🚩 Tuần 1:
Bắt tay vào code, phát hiện API thiếu tài liệu cho một số edge case4.
Liên hệ support, nhưng đối tác trả lời chậm, mỗi tuần chỉ họp được 1 lần.
🚩 Tuần 2:
QA test thử, phát hiện giao dịch đôi khi bị mất dữ liệu.
Đào sâu mới biết hệ thống có cơ chế chống gian lận, nhưng tài liệu không đề cập rõ ràng.
🚩 Tuần 3:
PM bắt đầu sốt ruột vì deadline cận kề.
PO vẫn nghĩ team dev sắp xong, trong khi thực tế chưa ai tích hợp thành công full flow giao dịch thực tế.
Kết quả là trễ deadline, blame lẫn nhau. PM trách dev estimate sai. Dev trách PO không involve từ đầu. QA trách PM không chừa buffer test. Ai cũng đúng theo góc nhìn của họ, nhưng sai ở chỗ không ai có cái nhìn toàn diện từ đầu.
🚀 Kinh nghiệm rút ra
Estimation không chỉ là việc của dev, mà cả team phải tham gia ngay từ đầu. Trong các buổi planning, mình hay khuyến khích team đặt câu hỏi để hiểu càng nhiều requirement càng tốt:
"QA có cần test gì đặc biệt không?"
"PM có thông tin về case business quan trọng nào không?"
"Có rủi ro nào cần buffer thời gian không?" v,v…
Ngoài ra trước sprint planning, mình (role tech lead) sẽ có buổi họp grooming để làm rõ thông tin, requirement trước. Điều này giúp chính anh em dev hiểu rõ hơn về yêu cầu, tránh việc vào họp trong sprint planning mà không có sự chuẩn bị chẳng khác nào đoán đại ra 1 con số rồi bỏ vào estimate. Nếu bạn chỉ là dev thì cũng có thể chủ động đi hỏi scrum master, BA và ngó qua task trước rồi tự tìm hiểu, vừa có cơ hội chọn được task vừa ghi điểm vì tinh thần chủ động trong công việc.
🎯 Estimation: một phần tất yếu của trò chơi
Estimation không phải một con số tuyệt đối, mà là một công cụ để quản lý expectation và rủi ro.
Nếu xem nó như một lời hứa, bạn sẽ dễ thất vọng.
Nếu xem nó như một công cụ, bạn sẽ biết cách điều chỉnh và thích nghi khi tình hình thay đổi.
Google Maps có thể tối ưu tuyến đường và dự đoán ETA5, nhưng bạn vẫn có thể đến muộn do kẹt xe hoặc thời tiết xấu.
Phát triển phần mềm cũng vậy – bug bất ngờ, scope creep6, phụ thuộc vào team khác… tất cả đều có thể làm lệch dự đoán ban đầu.
Một nguyên lý căn bản để estimate hiệu quả là trước khi nghĩ đến con số, hãy chắc chắn rằng bạn đã hiểu rõ yêu cầu của task. Nếu không thực sự hiểu mình cần làm gì, thì estimation chỉ là một phép đoán may rủi. Công việc càng mơ hồ, estimation càng sai lệch.
Cách mình làm để hiểu rõ requirement hơn.
Đọc kỹ user story hoặc spec document, nhưng đừng chỉ đọc mà hãy cố gắng hình dung cách triển khai.
Đặt câu hỏi: technical constraints7 là gì? Có phần nào phụ thuộc vào team khác không? Có edge case nào có thể làm chậm tiến độ không?
Trao đổi với BA, PM hoặc team lead để làm rõ những điểm chưa chắc chắn.
Nếu vẫn chưa rõ ràng, hãy thử PoC trước khi đưa ra con số estimation.
💡 Estimation không chỉ là việc đoán mất bao lâu, mà còn là quá trình hiểu vấn đề, xác định rủi ro và lên kế hoạch hợp lý.🚀 Cách mình hay làm để estimate tốt hơn
Đừng cố chính xác 100%, estimate theo khoảng thời gian (range estimation) thay vì dùng con số cố định.
Chủ động giao tiếp và cập nhật lại estimation khi có thêm thông tin mới.
Involve cả team vào estimation, đừng để nó là trách nhiệm của riêng dev.
Tham khảo data trong quá khứ: theo dõi thời gian thực tế vs. estimation để rút kinh nghiệm cho lần sau.
Chia nhỏ task để kiểm soát tốt hơn, thay vì ôm một khối lượng công việc khổng lồ và đoán mò.
✌️ Hẹn gặp lại bạn trong bài viết sau!
Đọc xong bài viết này chắc chắn không làm bạn giỏi lên ngay lập tức, nhưng nếu biết kết hợp với quan sát và luyện tập có chủ đích, thì mình tin là ít nhiều bạn cũng sẽ cải thiện được kĩ năng này. Còn từ đây tới lúc đó thì vẫn như mình hay nói:
enjoy the process!🙌🏻
Bài viết cũng chỉ là một góc nhìn và kinh nghiệm của bản thân trong hành trình mình đã trải qua. Tuy đã cố gắng hết sức nhưng cũng không tránh khỏi ý kiến chủ quan.
Bạn đã từng gặp vấn đề gì với estimation chưa? Thả ❤️ hay để lại comment cho mình biết nhé! Mình rất mong nhận được ý kiến từ độc giả của mình (và nếu bạn đọc được đến đây mà không scroll ào ào, thì chắc chắn bạn là một fan cứng của mình rồi 😁). và đừng quên subscribe để không bỏ lỡ những chia sẻ thú vị nhé!
See ya 🤖!
Bryant!
Một số nguồn tham khảo:
Mệnh đề đầu tiên trong Agile Manifesto
Frame per second
Proof of concept
Trường hợp lỗi khó xảy ra nhưng vẫn xảy ra
Estimated Time of Arrival
Requirement cứ phình to không kiểm soát dẫn đến delays, hết budget, project fail…
Giới hạn về mặt công nghệ ảnh hưởng tới thiết kế hệ thống, hoặc về mặt delivery
Em có câu hỏi về ý “involve cả team vào estimation”: có nên involve các bạn product vào session grooming hay task breakdown/estimation không? Và nếu có thì các bạn nên tham gia ntn cho hiệu quả