- Không thể ước lượng chính xác thời gian của dự án phần mềm, và phần lớn công việc bị chi phối bởi những “việc chưa biết” không thể dự đoán
- Ước lượng được dùng như một công cụ chính trị của ban quản lý chứ không phải của kỹ sư, đóng vai trò quyết định mức độ ưu tiên của dự án và phân bổ ngân sách
- Trên thực tế, ước lượng định nghĩa công việc, và các nhóm làm việc bằng cách tìm ra hướng tiếp cận kỹ thuật khả thi trong khoảng thời gian được giao
- Để ước lượng hiệu quả, kỹ sư cần tập trung vào nắm bắt bối cảnh chính trị, đánh giá rủi ro chưa biết, và đưa ra nhiều kịch bản thực thi
- Cách tiếp cận này đề cao niềm tin và sự hợp tác thực tế hơn là độ chính xác, đồng thời nhấn mạnh năng lực kỹ thuật gắn với việc hiểu cấu trúc ra quyết định trong tổ chức
Hư cấu về việc ước lượng phần mềm
- Trong ngành tồn tại một “hư cấu lịch sự” cho rằng các nhóm giàu kinh nghiệm có thể dự đoán lịch trình chính xác nếu nỗ lực đủ nhiều
- Trên thực tế, hầu hết kỹ sư đều nhận thức rằng không thể dự đoán chính xác
- Một số nhóm dùng cách phân loại theo cỡ áo thun để ước lượng, nhưng cuối cùng vẫn bị quy đổi sang đơn vị thời gian và chuyển lên các tầng quản lý
- Thậm chí còn có những heuristic phi thực tế như “lấy ước lượng ban đầu nhân đôi rồi cộng thêm 20%”
Vì sao không thể ước lượng
- Công việc nhỏ và rõ ràng thì có thể dự đoán, nhưng phần lớn dự án được thực hiện trong các hệ thống phức tạp và đầy bất định
- Ví dụ: việc đổi dòng chữ của một liên kết có thể dự đoán là 45 phút, nhưng thay đổi một hệ thống lớn thì không thể
- Phần lớn lập trình là một hoạt động nghiên cứu mang tính khám phá, nên không thể biết trước cần làm gì chỉ bằng kế hoạch ban đầu
- Cách thiết kế kiến trúc tập trung trong quá khứ đã thất bại, và người trực tiếp xử lý mã nguồn mới là người phải đưa ra quyết định
- Kết quả là phần việc đã biết chỉ chiếm khoảng 10% tổng thể, còn 90% còn lại không thể ước lượng vì thuộc vùng chưa biết
Ước lượng là công cụ của quản lý, không phải của kỹ sư
- Ước lượng không liên quan đến việc cải thiện năng suất của nhóm, và nhiều nhóm làm việc hiệu quả vẫn hoạt động mà không cần ước lượng
- Ban quản lý thường cố điều chỉnh ước lượng cho khớp với kết quả họ mong muốn; lịch dài thì bị gây áp lực rút ngắn, lịch ngắn thì bị yêu cầu thêm vùng đệm
- Chỉ những dự án bất khả thi về mặt kỹ thuật mới là ngoại lệ hiếm hoi có thể dẫn tới đánh giá thực tế
- Ở những khu vực ít được tổ chức quan tâm, các thủ tục hình thức đôi khi vẫn được giữ nguyên
- Vì vậy, ước lượng vận hành như một phương tiện chính trị để người ngoài kỹ thuật chọn hoặc hủy dự án
Ước lượng định nghĩa công việc
- Trái với nhận thức phổ biến, không phải công việc quyết định ước lượng mà ước lượng được chốt trước, rồi mới xác định hướng tiếp cận kỹ thuật phù hợp
- Ví dụ: cách triển khai tính năng “trò chuyện với PDF” trong 6 tháng và trong 1 ngày sẽ hoàn toàn khác nhau
- Ràng buộc thời gian quyết định độ sâu và chất lượng của thiết kế mã, và kỹ sư sẽ chọn lời giải có thể thực hiện trong khoảng thời gian được giao
Cách ước lượng trong thực tế
- Trước hết cần xác định bối cảnh chính trị để hiểu mức độ quan trọng của dự án và thời hạn được kỳ vọng
- Sau đó khám phá các hướng tiếp cận khả thi dựa trên khoảng thời gian đã được định sẵn
- Càng có nhiều vùng chưa biết (unknowns) thì ước lượng càng lớn, và phạm vi tiếp cận càng cần phải thu hẹp
- Cuối cùng, thay vì đưa ra một khoảng thời gian chính xác, hãy trình bày đánh giá rủi ro và nhiều kịch bản thực thi
- Ví dụ: tự giải quyết toàn bộ yếu tố, lách qua một phần, hoặc nhờ nhóm khác hỗ trợ
- Vai trò của kỹ sư không phải là “sẽ mất bao lâu” mà là “trong khoảng thời gian này có những cách nào khả thi”
Phản biện và cách đáp lại
- Một số kỹ sư tránh ước lượng trong điều kiện bất định, nhưng điều đó lại khiến người không có chuyên môn kỹ thuật phải ước lượng thay
- Không hợp tác với quản lý và luôn giữ thái độ đối đầu là phản tác dụng, đồng thời làm suy yếu niềm tin
- Những nhóm không cảm thấy áp lực có thể đơn giản là đang ở một khu vực ngoài vùng quan tâm của tổ chức
Kết luận
- Trên thực tế, quản lý thường tiếp cận nhóm với một mốc thời gian đã có sẵn trong đầu, còn nhóm sẽ tìm lời giải kỹ thuật có thể thực hiện trong khung đó
- Ước lượng là công cụ đàm phán giữa các cấp quản lý, và chỉ các dự án bất khả thi mới đôi khi trở thành phương tiện truyền đạt thực tế
- Một bản ước lượng đúng đắn cần bao gồm rủi ro và các lựa chọn, chứ không chỉ là một con số chính xác
- Không thể ước lượng chính xác công việc phần mềm, và việc ước lượng thành công phụ thuộc vào khả năng nhận diện cũng như quản lý các rủi ro chưa biết
2 bình luận
> Trước tiên nắm bối cảnh chính trị để hiểu mức độ quan trọng của dự án và tiến độ được kỳ vọng
> Sau đó dựa trên khung thời gian đã được ấn định sẵn để tìm kiếm cách tiếp cận khả thi
Ồ hô
Ý kiến trên Hacker News
Chia sẻ bảng tiêu chí ước lượng dự án của tôi theo kiểu nửa đùa nửa thật
Với các dự án nội bộ (ví dụ: chuyển đổi vendor, không ảnh hưởng người dùng), tôi đặt thời gian đủ để có thể thuyết phục sếp
Với các dự án có ảnh hưởng tới người dùng (ví dụ: thêm tính năng mới), tôi làm chừng nào ROI còn dương
Với các dự án cần phối hợp với đối tác bên ngoài, đội sales chốt deadline, còn đội kỹ thuật sẽ điều chỉnh nhẹ định nghĩa MVP để khớp lịch đó
Tôi thắc mắc vì sao không ai nhắc đến planning poker hay story point
Không hoàn hảo, nhưng đây là cách khá ổn. Mọi công việc đều phải hoàn thành trong một sprint, nếu quá lớn thì phải tách nhỏ
Cả nhóm phải đồng thuận về point, và chính quá trình đó tạo ra giá trị của thảo luận thực sự
Sau vài tháng, velocity của nhóm sẽ ổn định và có thể dự đoán với độ chính xác khoảng ±10%
Nó không phải phép màu, nhưng giúp chuyển giao giá trị đều đặn và buộc mọi người xem lại hiệu quả so với chi phí sau mỗi sprint
Người mới vào có thể mất hơn gấp đôi thời gian cho cùng một ticket
Thêm nữa, tổ chức lại đặt ra những quy tắc như phải review PR trong 24 giờ, nên càng lệch xa thực tế
Developer và QA cùng so sánh độ phức tạp khi ước lượng, còn QA đánh giá độ khó kiểm thử hay khả năng tự động hóa
Nhờ vậy chỉ số tốc độ phát triển ổn định và ước lượng theo phiên bản cũng khá chính xác
Nó chỉ có ý nghĩa khi cả nhóm có chung cách hiểu về đơn vị nhỏ nhất và có thể quy đổi nó sang thời gian
Mà đến lúc đó thì dùng luôn thời gian là được, bản thân point trở nên không cần thiết
Tôi dùng cách hỏi theo mốc “2 giờ, 2 ngày, 2 tuần, 2 tháng, 2 năm” để ước lượng dựa trên khoảng tin cậy
Nếu khoảng quá rộng thì chia nhỏ thêm, còn nếu không thể thì cân nhắc xem có đáng bỏ thời gian để thu thập thêm thông tin hay không
Nếu không thì hủy luôn dự án
Nếu định nghĩa kết quả rõ ràng và chia ý tưởng thành các bước nhỏ thì có thể ước lượng thực tế hơn
Nếu chưa thể tách xuống mức từng ngày hay từng tuần thì nghĩa là kế hoạch vẫn chưa đủ rõ
Với kiểu này thì bản chất là vừa thử nhiều cách khác nhau vừa học trong quá trình làm, nên tôi thấy rất khó ước lượng
Nó buộc người ta suy nghĩ theo hành động chứ không chỉ đoán độ dài công việc
Trước đây tôi từng xếp việc migrate mật khẩu từ plain text sang hash vào một sprint, nhưng thực tế mất tới 6 tháng
Tôi chỉ phát hiện ra khách hàng đã dùng mật khẩu không phân biệt chữ hoa chữ thường khi họ quay video cho xem
Chưa hết, image PHP còn bị xóa nên build cũng thất bại
Ước lượng lúc nào cũng là một cuộc phiêu lưu thú vị
Cuốn này đưa ra thống kê vượt ngân sách dựa trên dữ liệu dự án thực tế
Dự án IT trung bình vượt 73%, chỉ đỡ tệ hơn kho lưu trữ hạt nhân, Olympic và thủy điện
18% dự án IT vượt quá 50%, và mức vượt trung bình của nhóm đó là 447%
Rốt cuộc nó cho thấy trong hầu hết ngành nghề, ước lượng về mặt cấu trúc vốn đã quá lạc quan
Tôi thấy lạ là nhiều kỹ sư và quản lý lại không ước lượng dựa trên metric của các dự án trước đây
Nếu nhìn vào dữ liệu throughput của nhóm thì có thể tính ra thời gian tương đối cùng khoảng tin cậy (ví dụ: 90%, 70%, 50%)
Làm vậy cũng giúp cung cấp bối cảnh xác suất cho các bên liên quan bên ngoài
Nhưng nhiều kỹ sư xem đó là gánh nặng hành chính
Thực hành tốt là dùng ước lượng theo khoảng, như kiểu PERT mô hình hóa ba trường hợp: tốt nhất, kỳ vọng, tệ nhất
Những kỹ sư giỏi nhất lại thường có xu hướng quá tự tin vào khả năng tự ước lượng thời gian của mình
Cách mỗi người tự ước lượng rồi cộng bù thêm 20% từng cho kết quả khá khớp
Nếu ban lãnh đạo ép deadline, thì cần giải thích phạm vi có thể làm trong thời gian đó hoặc đề xuất ước lượng lại sau khi chốt scope rõ ràng
Tham khảo: PMI PMP, Lessons Learned Repository của PMBOK
Prediction cho phép học qua sai số, còn prescription thì lại dễ biến thành áp lực năng suất
Tôi xem ước lượng là một quá trình đàm phán
Giống như các gói cấu hình xe hơi: Economy, Mid-tier, Luxury
Phía business lúc nào cũng muốn tính năng của gói số 3 với ngân sách của gói số 1, nên cuối cùng tôi phải tự điều chỉnh theo tình hình
Nếu chuẩn bị sẵn kế hoạch #1, bạn có thể xoay nhanh khi khủng hoảng và hình dung rõ cái giá của đường tắt trong quá trình thương lượng
Nhờ vậy tôi đã nhiều lần tránh được những quyết định phi lý từ PM hay lãnh đạo đang hoảng
Tôi làm với hệ thống phân tán quy mô lớn kiểu FAANG, và ở đó chuyện ước lượng chính xác gần như là bất khả thi
Có quá nhiều unknown-unknowns, và chỉ riêng việc làm prototype cũng đã cần lượng dữ liệu và thời gian khổng lồ
Vì vậy tôi tập trung vào quản lý bất định hơn là ước lượng
Cách đáng tin nhất là so sánh với các dự án tương tự
Kiểu như “cái này phức tạp hơn dự án X 20% nên sẽ mất thêm 20% thời gian”
Tuy nhiên, để làm được vậy thì phải ghi lại đều đặn dữ liệu thời gian thực tế của các dự án trước
Ban đầu tôi định phản đối quan điểm “ước lượng là bất khả thi”, nhưng rồi nhận ra thực ra vai trò trong tổ chức mới là thứ quan trọng hơn
Dù nhóm có nhìn vào năng lực so với ước lượng và nói là không thể, thì deadline vẫn không đổi
Cuối cùng vẫn phải khớp bằng cách thu hẹp phạm vi hoặc đánh đổi chất lượng
Vì thế có lẽ nói “ước lượng vô dụng” còn chính xác hơn
Tôi cảm thấy cốt lõi của ước lượng nằm ở độ mơ hồ (ambiguity)
Có những việc trông nhỏ như tinh chỉnh UI nhưng thực ra lại là kiểu vừa làm vừa học
Ngược lại, có những thay đổi rất lớn nhưng nếu được định nghĩa rõ ràng thì vẫn xong nhanh
Trong thời đại LLM, không phải quy mô thay đổi mà chính mức độ bất định mới là yếu tố quyết định thời gian cần bỏ ra