Không, việc đó cần ít nỗ lực hơn thế
(smartguess.is)- Khi bên ngoài đội ngũ phát triển gây áp lực hạ ước lượng mà không có thông tin mới, ước lượng bị biến thành thứ như đối tượng thương lượng, khiến niềm tin và chất lượng lập kế hoạch Agile cùng suy giảm
- Khối lượng công việc thực tế phần lớn không phải thứ đội ngũ phát triển có thể tùy ý cắt giảm; đội dựa vào vận tốc của đội, dữ liệu các story đã hoàn thành và throughput hiện tại để ước tính nỗ lực dự kiến
- Bỏ qua quy trình hoặc hạ chất lượng để khớp với ước lượng thấp hơn có thể khiến lịch trình trước mắt trông ngắn lại, nhưng về sau rất có thể sẽ quay lại dưới dạng chi phí lớn hơn
- Cuộc trao đổi hiệu quả hơn không phải là “ước lượng thấp hơn đi”, mà là cùng xem xét ngân sách, những phần tốn thời gian, các ẩn số lớn, phương án thay thế, chia nhỏ story và kiểm chứng sớm
- Nếu chỉ hạ con số trong khi phạm vi tính năng cố định, khách hàng sẽ có kỳ vọng sai về thời điểm bàn giao; cần thảo luận việc loại bỏ các tính năng có nỗ lực cao nhưng giá trị thấp
Sự méo mó do áp lực hạ ước lượng khi không có thông tin mới
- Tình huống các bên liên quan bên ngoài đội ngũ phát triển, với kiến thức kỹ thuật hoặc hiểu biết về codebase còn hạn chế, thường nói “Không, việc đó cần ít nỗ lực hơn thế” để cố hạ ước lượng xảy ra khá thường xuyên
- Bề ngoài họ yêu cầu “ước lượng tốt hơn”, nhưng trên thực tế nhiều khi họ muốn ước lượng thấp hơn
- Khi xem ước lượng như một con số có thể thương lượng, cả bên liên quan lẫn đội phát triển đều đi đến một thỏa thuận không bên nào hài lòng, và doanh nghiệp có kỳ vọng tệ về thời điểm có thể bàn giao phần mềm cho khách hàng
- Nguồn trích dẫn liên quan được liên kết tại Is tasking developers with creating detailed estimates a waste of money?
Ước lượng gần với dự báo hơn là kiểm soát
- Có những trường hợp có thể chất vấn ước lượng
- Khi nội bộ đội phát triển thảo luận về story
- Khi có thông tin mới ảnh hưởng đến khối lượng công việc thực tế
- Việc một bên liên quan bên ngoài không hiểu chi tiết triển khai hoặc không cung cấp thông tin mới mà yêu cầu ước lượng thấp hơn cũng giống như nói với nhà khí tượng rằng “dự báo ngày mai sai rồi và thời tiết sẽ tốt hơn”
- Nhà khí tượng không kiểm soát thời tiết; họ dự báo dựa trên kiến thức và dữ liệu quan sát
- Đội phát triển cũng gần như không kiểm soát được khối lượng công việc thực tế, mà ước tính nỗ lực dự kiến dựa trên kiến thức và dữ liệu
Những gì đội phát triển có thể và không thể kiểm soát
- Đội phát triển ước lượng bằng cách sử dụng vận tốc đội đã được thiết lập, dữ liệu rà soát các story đã hoàn thành và quy trình được cải thiện qua từng sprint
- Để giảm khối lượng công việc, họ có thể bỏ qua một số quy trình và bàn giao phần mềm chất lượng thấp hơn
- Đây không phải cách được khuyến nghị
- Thường sẽ phải trả chi phí lớn hơn về sau
- Đội có thể còn dư địa cải thiện tốc độ, nhưng tại thời điểm ước lượng, phải dựa trên throughput hiện tại chứ không phải throughput kỳ vọng trong tương lai
- Nếu trong công ty xuất hiện kiểu trao đổi “làm lâu hơn là được”, môi trường như vậy gần như là công thức dẫn đến thảm họa
- Ba bình luận Reddit được liên kết như các ví dụ trải nghiệm liên quan:
Cuộc trao đổi nên có thay vì cắt giảm con số
- Phát triển phần mềm rất phức tạp và thường mất nhiều thời gian hơn mọi người nghĩ
- Nếu bên liên quan cho rằng họ chỉ có thể chi đến một khoản tiền nhất định, thay vì hạ ước lượng, nên thảo luận các điểm sau
- Có thể chi bao nhiêu cho story này
- Phần nào của story tiêu tốn nhiều thời gian nhất
- Ẩn số lớn nhất nằm ở đâu
- Có những phương án nào để xử lý các phần tốn thời gian và các ẩn số đó
- Cũng cần xem xét các lựa chọn thay đổi cách kiểm chứng và bàn giao
- Cắt story thành nhiều phần để bàn giao
- Kiểm chứng từng phần càng sớm càng tốt
- Nếu có thể, kiểm chứng bằng prototype
- Đặc biệt, cần tìm cách loại bỏ khỏi story những tính năng đòi hỏi nhiều nỗ lực nhưng có giá trị thấp nhất
Biến câu hỏi về lịch trình trở nên hữu ích hơn
- Thay vì hỏi để hạ ước lượng, các câu hỏi làm rõ mối quan hệ giữa tính năng với lịch trình và phạm vi sẽ hiệu quả hơn
- Các câu hỏi sau được liên kết như những nội dung sẽ được bàn trong một bài viết riêng
- Khi nào có thể bàn giao Feature A
- Có thể bàn giao gì trước cuối quý tới
- Có thể bàn giao Feature A trước cuối quý tới không
- Bài viết được liên kết: converting story points to hours
2 bình luận
Nếu dịch tiêu đề gốc của bài báo bằng DeepL thì sẽ ra như thế này:
Có ai nói: "Không, còn đỡ tốn công hơn thế!" không?
Ý kiến trên Hacker News
Phép so sánh rằng “ép nhân viên bán hàng tăng doanh số/chỉ tiêu cũng giống như đòi nhà khí tượng học phải tạo ra nắng” trong ngữ cảnh này không có vẻ gì là quá vô lý
Thực ra nó gần hơn với việc yêu cầu họ làm việc hiệu quả hơn để hoàn thành cùng một công việc nhanh hơn
Nếu để nhân viên bán hàng tự đặt chỉ tiêu, họ sẽ chọn một con số đủ an toàn để có thể đạt được, vì việc chốt hợp đồng vốn có rất nhiều yếu tố phức tạp và bất định nên họ không muốn trông như mình thất bại
Nhưng con số đó có thể thấp hơn mức doanh nghiệp cần, nên người ta mới đưa ra chỉ tiêu cao hơn và thúc họ cố hơn một chút để đạt được
Điều này càng quan trọng hơn nếu phần thưởng gắn trực tiếp với việc đạt được con số đó
Thế nhưng nhân viên bán hàng lại không liên tục viết bài rằng “chỉ tiêu do mình tự đặt là thiêng liêng, chỉ có nhân viên bán hàng mới được quyết, và ban lãnh đạo đòi hiệu suất cao hơn là ngu dốt”
Một phép so sánh gần hơn sẽ là khi đội bán hàng nói về một thương vụ cụ thể rằng “xác suất chốt là 70%, doanh thu định kỳ hằng năm khoảng 5 triệu USD”, rồi ban lãnh đạo đáp lại “có thể biến nó thành 80% và 7 triệu USD không?”
Việc vừa tăng xác suất chốt vừa tăng giá có thể là khả thi, nhưng cũng giống như hoàn thành một tính năng trong nửa thời gian, sẽ cần một thay đổi lớn hoặc một sự nhượng bộ đáng kể ở đâu đó
Chỉ là thay vì biến ước tính thành mục tiêu mong muốn, tốt hơn nhiều là hoàn thành nhanh hơn so với ước tính
Cách tốt nhất là sắp xếp công việc theo mức độ ưu tiên và các điều kiện tiên quyết, bảo đảm có đủ story đã sẵn sàng để phát triển, và khi cần gấp thì phân ticket một cách chiến lược, chấp nhận cái giá dài hạn là năng lực trong nhóm bị lệch đi
Khi bị áp lực thời gian, cần loại bỏ mọi thứ “có thì tốt” khỏi tất cả các tính năng hoặc đẩy chúng xuống cuối backlog, đồng thời mọi trao đổi với đội khác hay tư vấn từ chuyên gia bên ngoài đều phải bị giới hạn thời gian nghiêm ngặt
Cần loại bỏ các cuộc họp và gián đoạn không cần thiết, cho phép lập trình viên từ chối họp hoặc chặn lịch, và nâng tiêu chuẩn cho việc refactor lên mức chỉ làm khi hiệu quả so với chi phí trước deadline là thật sự rõ ràng, tức là tiếp cận theo kiểu vay mượn từ tương lai
Tuy nhiên, phải hết sức cẩn thận để không biến cách làm này thành phương thức làm việc tiêu chuẩn
Nếu bạn có thể chuyển đổi 10% số lead, thì khi cần chuyển đổi 5 thay vì 4 hợp đồng, đại khái chỉ cần gọi thêm khoảng 10 người nữa
Một phép so sánh phù hợp hơn với phần mềm là xây một kiểu công trình mới, chẳng hạn một ngôi nhà mái vòm địa trắc học, trong khi bạn không có kinh nghiệm và cũng chưa rõ sẽ gặp phải những vấn đề gì
Thế mà lại bị yêu cầu đưa ra báo giá thật chính xác, rồi sau đó còn bị ép cắt xuống thêm nữa
Điều quan trọng nhất là hành vi lừa dối khách hàng, chứ không chỉ là kiểu “nói quá bình thường nhưng có lợi cho công ty”
Ví dụ như hứa hẹn những điều công ty không thể thực hiện, hoặc bán các tính năng tương lai mà muốn làm được thì phải bắt đội ngũ lao vào death march, hy sinh chất lượng và tính bền vững
Dù cấp C có không nhìn thấy thì hệ quả vẫn xảy ra
Điều đó không có nghĩa là phải luôn tin vô điều kiện vào các ước tính của lập trình viên, nhưng đó là một hang thỏ còn sâu hơn nữa, và giờ đào vào thì mệt quá
Nó chỉ khiến cách hiểu về lịch trình trở nên phi thực tế hơn mà thôi
Việc tìm ra những cách giải quyết sáng tạo khác cho cùng một vấn đề, hoặc hiểu rõ có thể cắt bớt phạm vi ở đâu để kịp mục tiêu, thì hoàn toàn khả thi
Nhưng điều đó hoàn toàn khác với việc bảo “cứ làm đúng y hệt như thế nhưng nhanh hơn đi”
Khi nói đến chuyện ước lượng, các lập trình viên thường hầu như không đứng từ góc nhìn của phía kinh doanh, cũng không cố hiểu vì sao cần ước lượng và vì sao phương án ngắn hơn luôn được xem là tốt hơn phương án dài hơn
Thay vào đó, họ cố bảo vệ thánh địa của phát triển phần mềm, đồng thời khoét sâu thêm khoảng cách giữa kỹ sư và “những người còn lại”
Khi đó sự cay nghiệt và mỉa mai sẽ lộ ra, và cuối cùng dẫn đến những ước lượng phi thực tế
Tôi đã từng làm lập trình viên, PO, quản lý, giám đốc, đến cả CTO, nhưng tôi vẫn ngạc nhiên vì phần lớn lập trình viên quá xa rời thực tế về việc tạo ra giá trị và yếu tố thời gian
Với tư cách là lập trình viên, việc được hỏi sẽ mất bao lâu, rồi có cơ hội giải thích, phản biện và bảo vệ con số ước lượng của mình, ngược lại còn là điều may mắn
Thực tế đáng buồn là nhiều lập trình viên rất kém trong việc tham gia vào các cuộc trò chuyện ở cấp độ kinh doanh để bày tỏ suy nghĩ, ý tưởng, mối lo và đề xuất, giúp PM và quản lý nhìn ra độ phức tạp của công việc và có được thảo luận chi phí/lợi ích lành mạnh
Cần xem lead developer có tham gia các cuộc họp kinh doanh không, đội phát triển có cùng xem số liệu và ngân sách, cùng tham gia vào roadmap, và có cùng làm nghiên cứu người dùng cùng brainstorming tính năng với phía business/UX hay không
Nếu không, thì khó có thể kỳ vọng lập trình viên sẽ hiểu được kinh doanh
Sự tách biệt giữa phát triển và kinh doanh khiến mỗi bên bị nhốt trong silo của mình mà vẫn mong chuyên gia bên kia phải hiểu rõ vấn đề của mình, và điều đó tạo ra sự thần thánh hóa việc phát triển phần mềm
Có vẻ như nhiều công ty chỉ đơn giản là vẫn vận hành được dù vai trò bị silo hóa cực độ, rồi vì tiền vẫn tiếp tục chảy vào nên họ lầm tưởng cách đó là ổn
Thường chỉ là ai đó muốn nhét vài con số vào bản PowerPoint phục vụ chính trị nội bộ
Đôi khi họ đang cần quyết định nên làm A hay B, và trong trường hợp đó thứ thực sự cần một cách chính đáng không bao giờ là ước lượng tuyệt đối, mà chỉ là ước lượng tương đối
Thỉnh thoảng có một deadline thật sự, nhưng ngay cả khi đó điều cần thiết cũng không phải là ước lượng mà là “liệu có thể kịp ngày này không” hoặc hữu ích hơn là “cần phải làm gì để kịp ngày đó”
Làm việc gần phía kinh doanh nhất có thể là điều tốt, và ngay từ đầu lý do người ta dùng phần mềm thường cũng là để giải quyết nhu cầu kinh doanh
Nhưng riêng về chuyện ước lượng thì rất thường xuyên họ sai và chúng ta đúng
Nếu ngắn hơn lúc nào cũng tốt hơn, thì giờ cứ nói mọi ước lượng đều là 1 ngày đi, như vậy có tốt hơn không?
Nếu một lập trình viên có thể viết code, ước lượng và giao hàng đúng với lịch kinh doanh, thì người đó không phải nhân viên mà là nhà sáng lập
Điều họ muốn là những người ngây thơ có thể giao hàng như nhà sáng lập nhưng lại không nhận phần chia lợi nhuận
Dù bạn hay tôi có bỏ ra thêm bao nhiêu nỗ lực thì em bé cũng không thể ra đời nhanh hơn
Không có gì mơ hồ ở đây cả
Điều gây bực bội nằm ở cách đặt câu hỏi như thể lập trình viên có thể biết trước thời điểm hoàn thành
Khả năng của ai đó trong việc chuyển giao giá trị nhanh chóng là chuyện hoàn toàn khác với khả năng ước lượng thời gian cần thiết
Bạn vẫn có thể mang lại giá trị lớn dù ước lượng sai hoàn toàn
Nếu thực sự có một cách để ước lượng thời gian cho công việc phần mềm, các công ty hẳn đã tuyển chuyên gia ước lượng giống như họ có product team
Không có lý do gì phải bắt lập trình viên làm việc đó
Tất nhiên người khác cũng không làm được, còn lập trình viên thì ít nhất cũng đoán được mức sàn, nên người ta vẫn tiếp tục hành hạ họ, nhưng bản thân quy trình đó vốn đã ngớ ngẩn một cách quá rõ ràng
Muốn biết một việc sẽ mất bao lâu thì phải liệt kê ra mọi bước để làm việc đó, nhưng trong phát triển phần mềm điều này là bất khả thi
Lập trình viên có thể đưa ra mức sàn cho các yêu cầu được giao, và nếu hoàn toàn không có chuyện bất ngờ nào xảy ra thì thậm chí có thể ước lượng chính xác, nhưng ở 95–98% dự án thì ước lượng vẫn ngắn hơn thực tế
Cuối cùng, “ước lượng của lập trình viên” trở thành thước đo cho việc lập trình viên muốn chèn bao nhiêu vùng đệm vào dự án lần này
Việc yêu cầu ước lượng đã đặt sai hoàn toàn khung của cuộc đối thoại
Câu hỏi thực sự phải là đầu vào từ phía lập trình viên về vấn đề mà doanh nghiệp đang có lúc này, vấn đề có khả năng phát sinh sau 6 tháng nữa, và hiệu quả so với chi phí để giải quyết vấn đề đó
Sau đó cần đưa ra quyết định mang tính định tính theo hướng giảm thiểu rủi ro
Kết quả tốt nhất của việc ước lượng phần mềm là mọi người phớt lờ rồi quên nó đi, còn mọi kết quả khác thì đều phá hủy giá trị kinh doanh
Tôi hiểu ý chính, và trong những tổ chức có các bên liên quan thiếu trách nhiệm thì rủi ro thực sự cũng cao.
Tuy vậy, phép so sánh với nhà khí tượng học không hay lắm.
Nhà khí tượng học có cốt lõi công việc là dự báo thời tiết, còn lập trình viên thông thường là người làm việc trong chính thời tiết đó, và kinh nghiệm dự báo chính xác của họ tương đối ít.
Điều gây bức bối cho các bên liên quan là những ước lượng vô lý, không bắt đầu từ thời gian làm việc thực tế mà cũng chẳng kết thúc ở một khoảng thời gian khả thi.
Điều này càng đúng ở mức các tác vụ vi mô; có những việc tối đa 30 phút mà nếu chỉ có quyền truy cập thì tôi có thể tự làm còn nhanh hơn, nhưng lại nhận về ước lượng kéo dài nhiều tuần.
Ngay cả khi nó tạo ra chi phí vận hành nghiêm trọng và thuộc nhóm “phải dừng mọi thứ để xử lý” thì vẫn như vậy.
Tất nhiên, một việc 30 phút sẽ không thực sự chỉ mất 30 phút vì còn kiểm thử và tài liệu hóa, nhưng ước lượng càng gần mức vớ vẩn thì quan hệ tin cậy càng bị tổn hại.
Cần phân biệt giữa việc hỏi thời gian làm việc thực tế cho một tác vụ cụ thể, hay hỏi thời gian trôi qua từ bây giờ đến lúc nó được triển khai.
Trong gần như mọi đội, cả hai đều bị chi phối bởi thời gian công việc phải chờ đợi thứ gì đó, nhưng trường hợp sau thì đặc biệt nghiêm trọng.
Thời gian thực sự ngồi gõ bàn phím thường gần như chỉ là sai số làm tròn so với phần điều phối và sắp lịch.
Nếu đội chưa đầu tư vào cách làm việc trái với trực giác, thì ticket trung bình gần như luôn chờ lâu hơn áp đảo so với thời gian làm thực tế.
Hơn nữa, đội thường hoàn toàn không nhìn ra sự mất cân đối đó, cũng không nhận ra nó là điều quan trọng.
Ai cũng muốn sửa nhanh rồi chuyển đi.
Vấn đề là nếu không có triển khai liên tục được tự động hóa hoàn toàn, thì 30 phút không phải là 30 phút.
Công việc 30 phút đó phải được xem xét xem có ảnh hưởng tới bộ phận khác hay không, rồi cần điều phối lịch, thông báo và triển khai, có thể kéo thêm 2–3 người khác vào.
Nếu là việc có lịch, nó gần như thành 2 giờ trải dài qua nhiều người; còn nếu là hotfix hay ticket hỗ trợ thì trong trường hợp có quy trình QA ngoài kiểm thử tự động, sẽ thành tổn thất năng suất 4–6 giờ.
Nếu cộng thêm 6 người khác cũng yêu cầu những “việc 30 phút” mà chưa rõ sẽ ảnh hưởng thế nào đến người khác trong công ty, thì chẳng có gì được hoàn thành cả.
Đội của tôi có quy trình hotfix, nhưng phải là tình huống khẩn cấp thật sự làm đình trệ hoạt động công ty.
Trừ những trường hợp cực kỳ rõ ràng, phải có cấp trưởng bộ phận trở lên yêu cầu.
Thiệt hại từ việc không thể xử lý ngay mọi ticket khẩn cấp còn nhỏ hơn rất nhiều so với thiệt hại khi một bản sửa cho một người lại gây vấn đề cho nhiều người, hoặc khiến các dự án lớn có tính chiến lược không thể hoàn tất.
Hẳn phải có cách cấp quyền truy cập cần thiết trong tổ chức.
Nếu câu trả lời gần với kiểu “đó không phải việc của tôi”, thì tổ chức đó được cấu trúc để đề cao các bộ phận liên kết với nhau nhưng có trách nhiệm rất chặt chẽ.
Trong những tổ chức như vậy, việc chi phí giao tiếp hoàn toàn chi phối năng lực đầu ra là điều đương nhiên.
Nếu phối hợp tốt thì chất lượng có thể cao, và nếu vai trò rõ ràng thì thông lượng cũng có thể lớn, nhưng độ trễ thấp thì tuyệt đối không thể có.
Thời gian phản hồi bị hy sinh để đổi lấy những thứ khác.
Với một cấu trúc như thế, việc một tác vụ nhỏ bị ước lượng thành 1 tuần là điều có thể dự đoán trước.
Khi lịch đã kín, công việc mới nhiều khả năng chỉ được phân vào vài tuần sau, và nếu trách nhiệm bị chia nhỏ đến mức cần hơn một người thì thời gian chờ sẽ cứ thế cộng dồn.
Nếu điều đó không phù hợp với công việc, thì chính tổ chức đó không phù hợp với công việc ấy.
Nó không hiệu quả với tất cả những người liên quan.
Đội của tôi có tính tự chủ cao, không bấm giờ cũng không có bên ngoài soi năng suất, nhưng khi cần thì không có thời gian để trau chuốt code.
Nếu thấy một việc “30 phút”, chúng tôi đưa nó vào buổi review buổi sáng và hỏi liệu khi đụng vào chủ đề đó có nên làm luôn những phần lân cận hay không.
Dù không có gì thêm, chúng tôi vẫn dành trọn 1 ngày, hoặc nửa ngày nếu là dự án cực kỳ quen thuộc.
Nửa ngày dùng để rà lại code, nửa ngày còn lại dành cho các cập nhật như chú thích nhỏ, nâng cấp phiên bản, cải thiện code, đổi tên biến.
Tôi cho rằng ngay cả với từng cá nhân đóng góp độc lập, việc thúc đẩy họ làm như vậy cũng hiệu quả hơn về mặt thời gian.
Người mới tham gia với vai trò cá nhân đóng góp sẽ dùng khoảng thời gian đó để học code cũ, và cuối cùng các vấn đề legacy cũng giảm đi miễn là không có thay đổi lớn.
Cây đũa thần duy nhất trong phát triển phần mềm là đơn giản hóa yêu cầu.
Yêu cầu lúc nào cũng sai.
Hoặc quá rộng, hoặc quá mơ hồ, hoặc dựa trên những giả định sai.
Năng lực thực sự xuất sắc là biết bỏ đi một số giả định và đề xuất một lời giải đơn giản hơn.
Đó là cách tốt nhất và cũng là cách duy nhất để rút ngắn tiến độ.
Yêu cầu đơn giản thì thường dễ đầy đủ và chính xác hơn, nhưng cũng có thể có những yêu cầu thực tế không thể đơn giản hóa.
Khi đó, thứ cần thiết là đặc tả tốt hơn.
“They write the right stuff”, nói về nhóm phần mềm tàu con thoi, về cơ bản là câu chuyện làm đúng việc đó: https://www.fastcompany.com/28121/they-write-right-stuff
Phần lớn lỗi phần mềm thực ra là lỗi yêu cầu, và khi có yêu cầu tốt thì tốc độ làm phần mềm nhanh đến mức khó tin.
Tôi từng thấy một dự án đi từ kho mã trống đến triển khai production chỉ trong 2 tháng nhờ yêu cầu hoàn toàn rõ ràng và không thay đổi.
Ngược lại, tôi cũng từng thấy một tính năng chỉ khoảng 30 dòng code bị kéo dài hàng tháng vì yêu cầu mơ hồ và thay đổi liên tục.
Hiện giờ chỉ có vài chục mục, nhưng họ nói vài năm nữa sẽ thành vài nghìn.
Nhà thiết kế dựa trên tài liệu yêu cầu sản phẩm dài 20 trang để thiết kế toàn bộ luồng tìm kiếm, và chỉ sau khi mọi kế hoạch, chuẩn bị hoàn tất thì bên kỹ thuật mới được gọi vào để viết story và ước lượng công việc.
Họ thường có đủ kiến thức miền và biết trong bối cảnh đó thì cần gì để xây được thứ gì.
Đáng để thảo luận xem nên thay đổi phạm vi thế nào để đạt được cân bằng chi phí/lợi ích phù hợp với các bên liên quan
Tôi đã thấy cả trường hợp lập trình viên giả định rằng cần quá nhiều việc, lẫn trường hợp người không phải lập trình viên bỏ qua những phần then chốt làm tăng thời gian
Đôi khi người ta cố tạo ra một giải pháp tổng quát hóa, trong khi thứ thực sự cần chỉ là ai đó ngồi xử lý trên bảng tính trong một ngày
Vấn đề mà planning poker cố giải quyết là: người ta thường bị hỏi vì sao ước tính quá cao, nhưng gần như không bao giờ bị hỏi vì sao ước tính quá thấp
Ý tưởng là mọi người đưa ra độ khó của công việc mà không bị ảnh hưởng bởi nhau, rồi nếu kỳ vọng lệch nhau thì đem ra thảo luận
Rất có thể ai đó đang bỏ sót điều gì đó
Lý do tôi nghĩ thứ gì đó là đơn giản cũng có thể là vì tôi đã bỏ sót phần phức tạp của vấn đề, hoặc vì tôi nhìn ra một cách giải quyết gọn hơn
Một ví dụ điển hình là khi khách hàng đưa ra yêu cầu bất khả thi về mặt toán học hoặc vật lý
Dù có ngồi planning poker cả ngày về những mong muốn đó, cuối cùng vẫn có thể chỉ đi tới một thỏa hiệp bất khả thi
Khi còn làm freelancer, tôi thích cách nghe giải thích rất kỹ về vấn đề, nếu cần thì đứng xem qua vai người hiện đang xử lý vấn đề đó, rồi biến mất vài ngày và quay lại với phương án thiết kế mà tôi cho là có thể giải quyết thanh lịch và đáng tin cậy nhất
Trừ khi là người có nhiều kinh nghiệm với các bài toán phức tạp, đa số chỉ giỏi mô tả vấn đề của họ chứ không thể đề xuất giải pháp
Vì giải pháp luôn lấy những thứ quen thuộc mà bản thân biết làm hình mẫu
Tôi đã thấy rất nhiều yêu cầu kỳ quặc được ghép lại từ hàng loạt giả định của nhiều người, trong khi thực ra chẳng ai từng yêu cầu
Ví dụ như xây kiến trúc microservice mở rộng vô hạn cùng một ứng dụng SPA đầy đủ chỉ để mười hai người dùng nội bộ tải dữ liệu xuống dưới dạng bảng tính Excel
Nó đòi hỏi giả định rằng cả đội đã đủ quen với toàn bộ tập tính năng, và hiểu cách dùng một hệ thống để xử lý chênh lệch tất yếu kiểu A đánh giá X còn B đánh giá X*3
Chỉ cần nhìn các cuộc bàn luận về việc Scrum bị vận hành sai là thấy những giả định này hoàn toàn không được đảm bảo
Nó cũng không tính đến chuyện đội ngũ có thể lệch khỏi những giả định đó bất cứ lúc nào vì chuyển việc hoặc có tính năng mới
Quá thường xuyên, mọi người chỉ nhướng mày nhìn nhau rồi đi đến kết luận “X sẽ làm nên ước tính của X là chuẩn”, hoặc lấy trung bình/lấy giá trị nhỏ hơn khiến người ước tính cao hơn là người duy nhất chịu thiệt
Nếu vậy thì tôi chẳng hiểu ngay từ đầu chơi poker để làm gì
Chuyện này còn Machiavelli hơn thế nữa
Người trung gian muốn một kèo mà mặt ngửa thì tôi thắng, mặt sấp thì anh thua
Họ muốn hưởng lợi bằng cách đưa ra con số thấp để thuyết phục phía bên mình
Vì vậy họ dùng đủ mọi kỹ thuật để khiến lập trình viên tự nói ra con số họ muốn, nhưng không để trông giống như ra lệnh hay ép buộc
Vì nếu trông như vậy thì con số đó sẽ trở thành con số của chính họ và thế cờ sẽ hỏng
Nhưng khi mọi thứ tất yếu mất lâu hơn nhiều, họ có thể chỉ vào con số do lập trình viên đưa ra và nói rằng mình chỉ truyền đạt lại những gì đã nghe nên không phải chịu trách nhiệm
Ngôn ngữ duy nhất kiểu người này hiểu là gửi đi thông điệp bằng cách khiến kết quả của mọi yêu cầu “rà soát” ước tính luôn tăng lên
Thứ nhất, ước tính chỉ có ích nếu doanh nghiệp dùng nó để thích nghi, nhưng ngoài đời thì chẳng có sự thích nghi nào cả
PM bị sếp ép phải hoàn thành trước một hạn chót đại khái nào đó
Nếu đằng nào người ta cũng không quan tâm đến ước tính của tôi thì tại sao lại còn phải ước tính?
Thứ hai, đội ngũ chẳng có động lực thực tế nào để ước tính đúng
Có được thưởng huy chương nếu chính xác không? Thực tế là mọi động lực đều đẩy theo hướng thổi phồng khối lượng công việc thông qua ước tính
Thứ ba, toàn bộ điệu nhảy và nghi thức ước tính này chỉ là thứ mà quản lý chấp nhận để trông có vẻ hiệu quả và có ảnh hưởng hơn thực tế
Khi là kỹ sư, tôi nói rất dứt khoát rằng “không có cách nào làm nhanh hơn việc này, nên đừng gây áp lực chỉ để lấy được con số anh muốn nghe”
Xong là xong, và tôi sẽ làm nó vững chắc, tử tế, nên đừng cản trở
Nhưng khi là quản lý, những lúc tôi ép theo ước tính nhỏ hơn là vì trong thực tế kinh doanh, điều cốt lõi là giao được thứ gì đó trong khoảng thời gian đã định
Dù phải dựng một ngôi nhà bằng bài và cắt bớt các góc đi chăng nữa, ít nhất vẫn phải sống sót đủ lâu để còn xử lý vấn đề đó về sau
Khi ấy từ phía kỹ thuật xuất hiện đúng kiểu phản đối mà nếu ở vị trí đó tôi cũng sẽ làm
Rằng đây là một ý tưởng tồi tệ, sẽ khiến tương lai thất bại, và nếu muốn tránh đau đớn về sau thì phải bỏ công ngay từ bây giờ
Giờ tôi lại quay về làm kỹ sư, nhưng trải nghiệm làm quản lý giúp tôi khá nhiều khi xử lý những khoảng cách kiểu này
Đây là kiểu người “vặn lên tới 11”
Giống cái ampli trong Spinal Tap, nếu bình thường bạn đặt mức công suất tối đa là 9 thì khi họ muốn, vẫn còn chỗ để vặn thêm một nấc nữa
Tất nhiên làm vậy thì bạn sẽ làm việc chậm hơn bình thường
Nhưng nếu muốn có một lập trình viên “lên tới 11”, thì rõ ràng chỉ có đúng một cách vận hành như vậy
Quản lý của tôi và cấp trên của họ đúng là kiểu này: thúc ép deadline tùy tiện không phải vì khách hàng chờ, mà chỉ để trông đẹp mắt với sếp của họ
Khi ước tính tất yếu thất bại, tất cả lại giơ tay phủi trách nhiệm rồi bắt đầu đưa người ta vào kế hoạch cải thiện hiệu suất vì các ước tính tồi của chính họ
Làm kỹ sư mà phải sống trong kiểu căng thẳng liên tục này, rồi còn đánh đổi cả thời gian với gia đình và bạn bè để được gì?
Chỉ là để làm cho những ước tính bất tài của quản lý mình trông có vẻ ổn hơn
Một trong những chiêu cũ kỹ là dựng ra một tầm nhìn và đưa ra cam kết, rồi nói “tôi đã làm phần việc của tôi, giờ kỹ thuật chỉ cần làm phần việc của họ thôi”
Trong lúc chốt một bản phát hành, tôi lại nhớ tới người quản lý thỉnh thoảng thêm tính năng chỉ vài giờ trước đó mà chẳng hề báo trước
Họ còn từng gắn thêm tính năng vào cả những bản phát hành vốn đã xong
Có vẻ trong đầu họ, chỉ cần gắn tính năng vào bản phát hành là nó sẽ hoàn tất ngay lập tức
Khó khăn lớn nhất là khi dự án chỉ mới được mô tả vỏn vẹn trong một đoạn, mọi người đã lập tức đòi ước lượng ngay.
Thêm nữa, lúc nào cũng có cảm giác “còn tùy vào việc sau khi xem code thì có bao nhiêu nợ kỹ thuật”.
Câu trả lời hợp lý duy nhất mà đến nay tôi đưa ra là: “Cần 1–2 ngày để thúc ép phía bạn chốt yêu cầu cho chắc, đồng thời tạm dừng để rà soát codebase trước khi bắt đầu và tìm các rủi ro.”
Có cách nào làm tốt hơn ở đây không?
Mục tiêu không phải là tạo ra các thẻ hoàn hảo, mà là ít nhất phải có một ticket cho mọi việc có vẻ như cần làm trong dự án.
Khi đó sẽ có hàng loạt thẻ một dòng như “tạo API endpoint sinh hàng loạt”, “di chuyển dữ liệu từ bảng cũ sang bảng mới”.
Nếu có hơn 5 thẻ thì tôi ước lượng bằng
((số thẻ / số lập trình viên) * số ngày làm việc dự kiến cho mỗi thẻ) + số ngày nghỉ dự kiến.Có thể không chính xác, nhưng PM và sếp của họ sẽ cảm thấy ước lượng khi đó đã được cân nhắc và hợp lý.
Sau này nếu cần giải thích chuyện chậm tiến độ thì cũng dễ nói rằng “chúng tôi đã giả định mọi thẻ đều tốn thời gian tương tự nhau, nhưng hai thẻ này lại là ngoại lệ lớn hơn dự kiến”.
Về cơ bản nó giống quy trình sprint, nhưng không cần phải theo dõi vận tốc sprint theo kiểu ước chừng
Ban lãnh đạo công ty đòi ước lượng khi gần như không có thông tin gì, và nếu bạn nói cần tìm hiểu thêm và xem codebase thì họ lại bảo họ “chỉ” cần một con số để quyết định có phê duyệt việc này và làm dự án hay không.
Cứ lòng vòng như vậy rồi cuối cùng tôi phải đưa ra một ước lượng rất lớn, vì mọi ẩn số đều bị cộng vào, kể cả những thứ mà ngay cả phạm vi còn chưa rõ.
Và rồi với lãnh đạo thì nó trở thành quá lớn và quá đắt
Theo thuật ngữ Agile, đó là một spike ticket 3 điểm, và đầu ra là yêu cầu chi tiết, hạng mục bàn giao, cùng ước lượng có kèm các đánh đổi đã được cân nhắc.
Đây là cách làm hoàn toàn bình thường.
Bạn vẫn có thể đưa ra ước lượng trước khi làm spike, nhưng nên gắn càng nhiều điều kiện càng tốt.
Ví dụ có thể nói kiểu “độ tin cậy 60% là dưới 3 tuần, 80% là 5 tuần, 90% là 6 tuần”.
Nhìn chung, tôi thường từ chối ước lượng deadline vượt quá 1–2 tuần, và ưu tiên ước lượng theo từng phần nhỏ nếu có thể.
Chẳng hạn như “dự án này gồm 7 hạng mục bàn giao, mỗi hạng mục mất 1–2 ngày công”.
Vì có việc có thể chỉ là 10 ngày công kỹ thuật, nhưng do đổi ưu tiên này nọ nên việc tính deadline thực tế gần như trở nên vô nghĩa.
Nếu các “quản lý” không hiểu điều này thì tiếc là rất khó yên ổn
Đó là đừng quan tâm đến nợ kỹ thuật và chất lượng code, cứ vội vàng tung ra thứ gì đó chỉ vừa đủ chạy.
Khi đó họ sẽ hài lòng
Cảnh hack trong phim hành động điển hình là thế này:
Sếp: “Mất bao lâu để hack mainframe?”
Kỹ thuật viên: “Đối thủ là hacker cực giỏi, ít nhất phải 2 tiếng.”
Sếp: “Cho anh 1 tiếng. Làm đi.”
Sau đó là cảnh bay lượn trong hệ thống tệp 3D.
Mỗi lần xem mấy cảnh này tôi đều tự thêm lời thoại nội tâm cho anh kỹ thuật viên:
“Ước lượng thật ra là 20 phút. Chắc tôi sẽ xong vào khoảng phút thứ 50, rồi bay lòng vòng thêm 10 phút trong hệ thống tệp 3D cho bận rộn để sếp khỏi nảy ra ý tưởng điên rồ gì nữa.”
Cũng không hẳn hoàn toàn đúng.
Nhiều tính năng có thể được làm theo nhiều mức, từ kiểu khung sườn tối thiểu cho đến bản trau chuốt bóng bẩy hoàn toàn.
Đôi khi một đồng nghiệp ước lượng 2 tuần cho một tính năng mà theo tôi tối đa chỉ mất một ngày, nhưng thực ra là vì họ đang giả định thêm rất nhiều thứ chưa hề được yêu cầu, hoặc họ biết những phần mà tôi không nhận ra là cần thiết.
Khi ai đó yêu cầu thay đổi ước lượng, hãy xem đó là lời mời để thảo luận thêm một chút về yêu cầu và cách triển khai được đề xuất.
Có thể tồn tại một giải pháp đơn giản hơn rất nhiều mà vẫn đạt được 90% mục tiêu và hoàn toàn chấp nhận được.
Nhà khí tượng học thì không có lựa chọn như vậy.
Sự khác biệt giữa việc quăng vào một combobox/select box mặc định và việc tạo ra một thành phần UI tùy chỉnh tốt hơn, phù hợp ngữ cảnh hơn, thường không truyền đạt được cho người ngoài ngành IT.
Có thể giải thích bằng hình ảnh, nhưng vì các bên liên quan không được nhìn và chạm vào nên họ vẫn không hiểu chuyện gì đang diễn ra.
Vì thế, nhìn chung là bạn phải làm cho nó chạy được rồi đem ra cho họ xem.
Có những khách hàng bảo “hãy làm đơn giản nhất có thể”, rồi khi bạn đưa GUI prototype, GUI thiết kế hoàn chỉnh, rồi sau đó là bản prototype, họ chẳng thèm nhìn hai cái đầu mà duyệt luôn.
Nếu bị thúc ép, họ có thể nghịch thử prototype rồi vẫn bảo “ổn, cứ làm tiếp”, nhưng đến khi vào server test và sờ vào thứ đang chạy thật thì lại nói “đây không phải ý chúng tôi”.
Tôi đã gặp chuyện này từ các cửa hàng gia đình chỉ có hai vợ chồng cho tới các công ty Fortune 500 nơi giám đốc khu vực và CTO toàn cầu đều nhảy vào cho ý kiến.
Đây mới chỉ là chuyện frontend; backend và DevOps lại là một câu chuyện hoàn toàn khác, nhưng ở đó khoảng cách giữa làm phần xương sống tối thiểu và trau chuốt bóng bẩy cũng rất lớn.
Giờ tôi đã hiểu trò chơi này, nên dạo gần đây kiếm khá nhiều tiền nhờ chính cái quy trình méo mó đó
Năm 1975, Fred Brooks đã viết thế này:
“Để sinh một đứa trẻ thì dù có bao nhiêu phụ nữ tham gia cũng vẫn mất 9 tháng.”
Không có cách diễn đạt nào hay hơn câu này.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Mỗi lần thêm một người thì lại càng mất lâu hơn.
Cách giao hàng nhanh nhất là đừng quấy rầy lập trình viên solo, cứ để họ làm việc thôi