Bên cạnh việc khó khăn trong dự đoán tương lai, có một yếu tố rất con người giải thích tại sao các ước lượng (thời gian, chi phí, nhân lực..) trong dự án phần mềm lại khó đến vậy. Yếu tố tâm lý đằng sau các ước lượng trong xây dựng phần mềm là rất hấp dẫn và một số nghiên cứu đã chỉ ra một số kết quả khá thú vị. Biết về thành kiến của chính bạn và tâm lý con người có thể giúp cải thiện tính hiện thực của các ước lượng phần mềm. Như Dan Ariely đã tóm tắt một cách độc đáo trong tiêu đề cuốn sách của mình, con người chúng ta là Phi lý trí (Predictably Irrational) có thể đoán trước được.
Để ước lượng thời gian tốt hơn, điều quan trọng là phải hiểu thành kiến của chúng ta, để biết những dấu hiệu cần chú ý. Không giống như dự đoán thời tiết, trong đó dự đoán không ảnh hưởng đến kết quả, ước lượng phần mềm có một số tác động đến kết quả. Ví dụ, nếu ước tính quá thấp và mọi người phải gấp rút hoàn thành đúng thời hạn, chất lượng của kết quả có thể giảm xuống. Vậy, ảnh hưởng có thể có của áp lực thời gian đến năng suất và chất lượng là gì? Trước khi chúng ta tìm hiểu sâu hơn về câu hỏi này, hãy bắt đầu với quá trình tư duy hoạt động.
Liệu chúng ta có đang lạc quan quá mức và góp phần vào việc ước lượng dự án phần mềm một cách không thực tế? Hãy tưởng tượng một kịch bản trong đó có nhiều nhà thầu để giành được hợp đồng phát triển phần mềm, một trong những nhà thầu đưa ra một ước tính dẫn đến chi phí ít hơn đáng kể. Vì giảm chi phí là một động lực cho nhiều tổ chức, nhà thầu này giành được hợp đồng (với đội ngũ bán hàng tuyệt vời) nhưng dự án kết thúc một cách thất bại. Ai là người có lỗi ở đây?
Có phải nhà thầu đã cố tình đưa ra dự toán thấp? Có phải khách hàng đã nhấn mạnh chi phí là yếu tố then chốt? Hay chúng ta thiếu sự kiến thức về ước lượng? Đây là một trong những khó khăn. Người đặt giá thầu có thể không cố ý hạ thấp ước tính, nhưng họ đã được khen thưởng vì đã làm như vậy. Khách hàng có thể muốn một hợp đồng với thời gian cố định và phạm vi cố định, đó là mô hình thác nước (water fall), nhưng họ nói rằng họ muốn một cái gì đó linh động (agile).
Phần thưởng của những lượng tính lạc quan có thể có tác động tiêu cực. Kịch bản cũng xảy ra khi mọi người cố gắng chấp thuận các dự án từ người quản lý của họ. Bạn đã bao giờ đặt giá thầu cho một dự án và cảm thấy áp lực phải giảm chi phí? Hoặc bạn đã bao giờ được hỏi một cái gì đó sẽ mất bao lâu và được trả lời rằng nó quá lâu? Chắc chắn rằng bạn đã từng gặp những trường hợp như vậy. Vì vậy, cơ hội tốt nhất mà chúng ta có để phá vỡ sự bế tắc là thông qua giáo dục và sử dụng khoa học để giúp đưa ra quyết định tốt hơn.
Magne Jørgensen từ Phòng thí nghiệm Nghiên cứu Simula (Simula Research Laboratory) đã nghiên cứu và xuất bản về chủ đề ước lượng phần mềm từ năm 1995. Cuốn sách gần đây của ông, Dự đoán thời gian: Hiểu và tránh chủ nghĩa không thực tế trong lập kế hoạch dự án và cuộc sống hàng ngày ( Time Predictions: Understanding and Avoiding Unrealism in Project Planning and Everyday Life) chứa đầy nhiều nghiên cứu và ví dụ thú vị. Bài viết này được tham khảo rất nhiều từ những nghiên cứu này .
Lý do tôi (tác giả bài viết này, xem ở cuối bài) thực sự thích cuốn sách của Jørgensen là ông ấy sử dụng khoa học để mang lại bằng chứng hỗ trợ cho một số hoạt động trong ngành.
Tại sao các nhà phát triển phần mềm (và các nhà thiết kế) lại quá tối ưu với các ước lượng của họ?
Mọi người thường nghĩ rằng họ tốt hơn mức trung bình. Đặc biệt là khi hoàn thành những công việc tương đối đơn giản mà họ có năng lực. Hiệu ứng tốt hơn mức trung bình (better-than-average effect) có thể được nhìn thấy trong cách mọi người đánh giá bản thân trong nhiều nhiệm vụ như lái xe, điểm trong kỳ thi, v.v. Đây là một kiểu tối ưu hóa quá mức.
Một ví dụ khác được nêu bật bởi Hamilton, người đã xuất bản một phân tích thực nghiệm về lợi nhuận của việc tự kinh doanh trên Tạp chí Kinh tế Chính trị (Journal of Political Economy) . Người ta thấy rằng các doanh nhân có xác suất thất bại cao và kiếm được trung bình ít hơn 35% so với những nhân viên làm công việc tương tự sau 10 năm kinh doanh. Tôi đã cười thành tiếng khi tìm thấy cái này. Là người sáng lập của một công ty khởi nghiệp công nghệ, tôi chắc chắn biết được mình đã làm được những gì.
Jørgensen dành một chương của cuốn sách này để nói về những dự đoán quá tối ưu. Đó là tầm quan trọng của nó đối với ước lượng phần mềm. Điều thú vị là ông ấy xem xét những lợi ích của việc tối ưu hóa quá mức theo quan điểm tiến hóa, bắt đầu từ thời kỳ đồ đá. Ông đặt câu hỏi, có thể nào rằng chủ nghĩa tối ưu quá mức là hợp lý và thích nghi? Giả sử rằng một thợ săn phát minh ra vũ khí mới có một cơ hội nhỏ, thì việc lãng phí thời gian (và năng lượng) vào nhiệm vụ này dường như không phải là một quyết định đúng đắn. Nhưng nếu thợ săn có thể đổi mới, thì họ có thể mang lại cho mình và bộ tộc của họ một lợi thế khác biệt trong bối cảnh cạnh tranh của họ.
Tương tự, đối với các dự án đầy tham vọng, hầu hết chúng sẽ thất bại. Nhưng nếu một trong số chúng thành công, điều đó có thể mang lại cho họ lợi thế cạnh tranh trong thế giới kinh doanh. Bạn đã bao giờ tham gia vào một cuộc trò chuyện mà ai đó muốn có một sản phẩm sáng tạo nhưng không sẵn sàng chấp nhận rủi ro thất bại? Đây là một nghịch lý khác mà một số người không thể di chuyển quá khứ một cách hợp lý nên cuối cùng họ sẽ gắn bó với hiện trạng.
Vì vậy, tại sao các nhà phát triển phần mềm (và các nhà thiết kế) lại quá tối ưu với các ước lượng của họ? Có vẻ như bẩm sinh nó là con người và có một số quá khứ tiến hóa cho đến nay. Một mặt, tốt nhất là bạn nên gắn bó với đám đông vì có sự an toàn về số lượng. Mặt khác, vận may ủng hộ những người mạnh dạn. Có vẻ như việc tối ưu hóa quá mức đã nằm sâu trong DNA của chúng ta và chúng ta hãy xem xét bảy xu hướng dự đoán thời gian bên dưới.
Ảnh hưởng có thể có của áp lực thời gian đối với năng suất và chất lượng là gì?
Ước lượng phần mềm có thể ảnh hưởng đến kết quả của một dự án. Điều quan trọng cần biết là bất kỳ quy trình ước tính nào bạn sử dụng đều có thể ảnh hưởng đến kết quả của dự án. Và chắc chắn bạn muốn thiết lập dự án của mình để thành công.
Dường như có mối tương quan giữa ước lượng phần mềm với năng suất và chất lượng của thành quả. Nan và Harter đã nghiên cứu tác động của áp lực ngân sách và kế hoạch lên thời gian và nỗ lực của chu trình phát triển phần mềm và được xuất bản trong IEEE Trans Transaction on Software Engineering. Những gì họ nhận thấy là tác động của áp lực ngân sách và lịch trình lên thời gian và nỗ lực của chu trình phần mềm như các đồ thị hình chữ U như dưới đây:
Một trong những giá trị mà bạn nên chú ý: khẩn trương nhưng không gấp gáp. Đối với tác động có thể có đối với năng suất như được thấy trong sơ đồ trên, tôi nghĩ rằng áp lực cao khiến mọi người trở nên vội vã và năng suất giảm xuống. Có vẻ như áp lực phù hợp là một điều tốt. Để có thể ảnh hưởng đến chất lượng, nếu ước lượng phần mềm quá thấp (dự đoán quá thấp) và nhóm không có đủ thời gian, chất lượng sẽ giảm xuống. Nhưng khi họ có nhiều thời gian hơn để làm việc trong dự án, chất lượng sẽ tăng lên. Tôi nghĩ tất cả chúng ta đã cảm thấy điều đó.
Sự tín nhiệm có thể có ảnh hưởng đến cách ước lượng phần mềm?
Sau khi thảo luận về ảnh hưởng có thể có của áp lực thời gian đối với năng suất và chất lượng ở trên, có vẻ như có một điểm đáng chú ý là áp lực thời gian nhất định có thể dẫn đến sự đánh đổi giữa năng suất và chất lượng. Vì vậy, từ quan điểm của những người làm ước lượng, cách tốt nhất để nói điều này với ban quản lý (hoặc khách hàng) là gì? Và từ quan điểm của các nhà quản lý, làm thế nào để bạn biết rằng người tính toán ước lượng là đủ tốt?
Đây là những câu hỏi thú vị và khi chúng được giải quyết sớm dường như có tác động tích cực đến dự án. Vậy sự tin tưởng (ở người khác) có thể có ảnh hưởng đến cách ước lượng phần mềm không? Trong một thử nghiệm do Jørgensen thực hiện về việc sử dụng độ chính xác của các ước lượng nỗ lực phát triển phần mềm để truyền đạt sự không chắc chắn, một số kết quả rất thú vị đã xuất hiện có thể giúp xây dựng lòng tin.
Trong thử nghiệm, mọi người được yêu cầu xem xét ước tính thời gian của 4 developer trong một nhiệm vụ. Và sau đó, họ được hỏi, trong số bốn ước tính: Developer nào là người có năng lực nhất? Năng lực thấp nhất? Đáng tin cậy nhất? Và ít đáng tin cậy nhất? Kết quả của thí nghiệm được trình bày trong bảng dưới đây.
|
Developer
|
Ước lượng thời gian
|
Có năng lực nhất (%) |
Năng lực thấp nhất (%) |
Đáng tin cậy nhất (%) |
Ít đáng tin cậy nhất (%) |
|---|---|---|---|---|---|
| A | Cần 1020 giờ làm việc | 6 | 31 | 7 | 49 |
| B | Cần 1000 giờ làm việc | 11 | 13 | 7 | 14 |
| C | Cần từ 900 đến 1100 giờ làm việc | 74 | 1 | 70 | 1 |
| D | Cần từ 500 đến 1500 giờ làm việc | 9 | 55 | 16 | 36 |
Kết quả cho thấy Nhà phát triển C được coi là người có năng lực nhất và đáng tin cậy nhất. Ước lượng của họ sử dụng một phạm vi và khoảng cách không quá lớn. Nhà phát triển D là người kém năng lực nhất và ít đáng tin cậy nhất mặc dù ước tính của họ có xác suất đúng cao nhất. Như Jørgensen đã viết trong cuốn sách của mình; không có gì đáng ngạc nhiên, mặc dù đáng tiếc là nhiều người thích sai chính xác hơn là đúng gần đúng trong dự đoán thời gian của họ. Cũng có vẻ như từ thí nghiệm, rằng nếu các dự đoán thời gian quá chính xác, mọi người sẽ không tin vào chúng. Bạn có thể đọc thêm về nghịch lý tính chính xác để trở nên thuyết phục hoặc đúng: một câu hỏi về tính chính xác ( to be convincing or to be right: a question of preciseness).
Sử dụng thang đo fibonacci và kích cỡ áo phông có mang lại hiệu quả?
Các thang đo fibonacci (fibonacci scales) và kích cỡ áo phông (T-shirt sizes) là những kỹ thuật phổ biến trong phát triển phần mềm Agile. Một dãy Fibonacci bắt đầu từ 1 và số tiếp theo trong dãy là phép cộng của hai số trước đó. Ba số đầu tiên của dãy là 1,2,3 (1 + 2 = 3), số thứ tư là 1,2,3,5 (2 + 3 = 5), v.v. Vì vậy, bạn kết thúc với dãy số 1, 2, 3, 5, 8, 13,… Cỡ áo thun là một cách để thay thế số trong dãy bằng một đơn vị khác.
- Cực nhỏ (xs) = 1
- Nhỏ = 2
- Trung bình (m) = 3
- Lớn (l) = 5
- Cực lớn (xl) = 8
- Cực cực lớn (xxl) = 13
Và như thế.
Vì vậy, bạn kết thúc với xs, s, m, l, xl, xxl, v.v. Lý do đằng sau việc sử dụng kỹ thuật thang đo fibonacci hoặc kích thước áo phông có một vài lợi ích:
- Thứ nhất, bằng cách chỉ có một số giá trị để lựa chọn, nó có thể giúp quá trình ước lượng nhanh hơn vì người ước tính chỉ có thể chọn các giá trị này và buộc phải đưa ra quyết định bằng cách sử dụng phán đoán chuyên môn của họ.
- Thứ hai, Bằng cách loại bỏ khái niệm thời gian, ước tính trở thành tương đối. Nếu nhiệm vụ A là Nhỏ và nhiệm vụ B là Lớn, thì nhiệm vụ C có thể phù hợp với Trung bình. Sau khi một nhóm biết vận tốc của mình (có bao nhiêu story points thường được hoàn thành trong một lần chạy nước rút), họ có thể tính ra bao nhiêu stories có thể hoàn thành dựa trên ước tính tương đối của họ. Nhưng có một sự thiên vị có thể dẫn đến quá lạc quan và điều quan trọng là bạn phải nhận thức được điều đó nếu bạn sử dụng cách tiếp cận như thế này.
Xu hướng trọng tâm của phán đoán (central tendency of judgement) đã được Hollingworth công bố năm 1910 trên Tạp chí Triết học, Tâm lý học và Phương pháp Khoa học. Xu hướng trung tâm của sự phán đoán cho biết rằng chúng ta có xu hướng bị ảnh hưởng bởi những gì được coi là trung bình của thang đo đã chọn. Vì vậy, khi thang đo không tuyến tính (như thang đo fibonacci), khoảng giữa có thể làm lệch kết quả theo hướng ước tính lạc quan. Vì vậy, các phương pháp thang đo fibonacci và kích thước áo phông có phải là tốt? Khoa học không thể kết luận giúp chúng ta với câu hỏi này nhưng điều quan trọng là phải nhận thức được xu hướng trọng tâm của phán đoán.
7 thành kiến về ước lượng thời gian bạn phải biết
7 thành kiến dự đoán thời gian này được trích dẫn trong chương 3 của cuốn sách Tiên đoán thời gian Hiểu và Tránh Chủ nghĩa Phi thực tế trong Lập kế hoạch Dự án và Cuộc sống Hàng ngày ( Time Predictions Understanding and Avoiding Unrealism in Project Planning and Everyday Life). Trong sự nghiệp của mình với tư cách là một kỹ sư phần mềm, tôi đã trải nghiệm qua những điều này và khi đọc chúng được liệt kê theo thứ tự như thế này, tôi thực sự thấy thú vị. Tôi liệt kê ra đây (với sự cho phép của Jørgensen). Nhưng bạn hãy đọc cuốn sách vì có rất nhiều thông tin mà rất khó để tóm tắt chỉ trong một bài viết.
1. Sai lầm về quy mô nhóm
Một lực lượng lao động lớn gấp đôi có xu hướng làm ra sản lượng ít hơn gấp đôi trên một đơn vị thời gian do sự gia tăng nhu cầu phối hợp. Khi dự đoán việc sử dụng thời gian cho các dự án có nhiều người, chúng ta cần bao gồm tỷ lệ công việc quản lý và điều hành dự án lớn hơn và giả định năng suất thấp hơn so với các dự án nhỏ hơn.
2. Hiệu ứng mỏ neo (anchoring effects)
Ảnh hưởng của Hiệu ứng mỏ neo (anchoring effect) trong bối cảnh dự đoán thời gian thường rất mạnh. Phương pháp an toàn duy nhất để tránh các hiệu ứng mỏ neo là tránh tiếp xúc với thông tin có thể hoạt động như một neo dự đoán thời gian.
Mỏ neo có nhiều hình dạng và cách che dấu, chẳng hạn như ngân sách, kỳ vọng sử dụng thời gian, các từ liên quan đến các nhiệm vụ phức tạp hoặc đơn giản, thời hạn sớm và thậm chí những con số hoàn toàn không liên quan khiến bạn chú ý trước khi dự đoán thời gian sử dụng.
3. Hiệu ứng trình tự (sequence effects)
Dự đoán thời gian trước của bạn thường sẽ ảnh hưởng đến dự đoán thời gian tiếp theo của bạn. Dự đoán thiên về dự đoán trước đó, có nghĩa là dự đoán thời gian của một nhiệm vụ trung bình sau một nhiệm vụ nhỏ có xu hướng làm cho dự đoán thời gian quá thấp và dự đoán thời gian của một nhiệm vụ trung bình sau một nhiệm vụ lớn có xu hướng làm cho dự đoán thời gian quá cao.
4. Hiệu ứng định dạng (Format effects)
Khi khoản thời gian ngắn và phải thực hiện một lượng lớn công việc, định dạng (format) yêu cầu ngược lại, “Bạn nghĩ bạn có thể làm được bao nhiêu trong X giờ?”, có xu hướng dẫn đến các dự đoán thời gian tối ưu hơn.
5. Hiệu ứng độ lớn (magnitude effect)
Các dự án lớn hơn thường bị đánh giá thấp hơn các dự án nhỏ hơn (sai lệch về độ lớn – magnitude bias) nhưng với dữ liệu quan sát (trái ngược với các thí nghiệm được kiểm soát), mối liên hệ giữa quy mô nhiệm vụ và độ chệch dự đoán có thể là do yếu tố thống kê.
Các thí nghiệm có kiểm soát, tránh các vấn đề thống kê của các nghiên cứu quan sát, cho thấy rằng có một sai lệch về độ lớn thực sự tồn tại, ít nhất là đối với các dự đoán về các nhiệm vụ tương đối nhỏ.
Dự đoán rằng việc sử dụng thời gian gần với mức trung bình của các tác vụ tương tự sẽ dẫn đến sai lệch về độ lớn nhưng cũng có thể làm tăng độ chính xác của các dự đoán trong các tình huống có độ không chắc chắn cao.
6. Độ dài của mô tả nhiệm vụ
Các mô tả nhiệm vụ dài hơn có xu hướng tăng ước lượng thời gian, nhưng những người có kinh nghiệm họ có thể ước lượng thấp hơn.
7. Hiệu ứng đơn vị thời gian (Time Unit Effect)
Việc lựa chọn và sử dụng các đơn vị trong ước lượng thời gian là vấn đề quan trọng. Các đơn vị chi tiết có xu hướng dẫn đến dự đoán thời gian cao hơn. Trong bối cảnh mà các dự đoán thời gian tối ưu quá mức là điển hình thì điều quan trọng là tránh dự đoán thời gian theo các đơn vị thời gian chi tiết, chẳng hạn dùng đơn vị là giờ làm việc cho các nhiệm vụ cần đến cả tháng để hoàn thành.
Việc lựa chọn đơn vị thời gian khi dự đoán khối lượng công việc phải hoàn thành trong một thời gian nhất định dường như không có tác dụng hoặc ít, chẳng hạn như dự đoán khối lượng công việc có thể hoàn thành trong hai giờ so với 120 phút.
Tóm lược
Với tất cả những thành kiến và cạm bẫy của ước lượng dự án phần mềm, có vẻ như đây là một nhiệm vụ bất khả thi để thực hiện ước lượng chính xác. Tuy nhiên, một trong những điều quan trọng nhất bạn cần biết là chúng ta có thể đoán trước được sự phi lý trí. Có thể tạo ra một quy trình ước lượng phần mềm nếu bạn nhận biết đúng đắn về việc này. Có rất nhiều cuốn sách bổ ích (như cuốn của Magne Jørgensen) có cái nhìn cân bằng về các thành kiến và thói quen dự đoán của chúng ta. Trong bài viết này, chúng ta đi sâu hơn một chút vào bốn câu hỏi sau:
- Tại sao các nhà phát triển phần mềm (và các nhà thiết kế) lại quá tối ưu với các ước lượng của họ?
- Ảnh hưởng có thể có của áp lực thời gian đối với năng suất và chất lượng là gì?
- Sự tin tưởng có thể có ảnh hưởng đến cách ước tính phần mềm được nhìn nhận không?
- Các phương pháp thang đo fibonacci và kích thước áo phông có mang lại điều tích cực?
Bằng cách nghiên cứu và xem xét một số phương pháp khoa học, chúng ta có thể hiểu được tâm lý đằng sau các ước lượng trong dự án phần mềm. Và chúng ta biết rằng con người có thể quá tối ưu. Chúng ta cũng biết rằng áp lực về thời gian có lợi cho năng suất và chất lượng. Và nếu chúng ta có thể đưa ra các ước lượng đúng lúc, nó có thể có ảnh hưởng tốt đến dự án. Giờ đây, chúng ta cũng biết rằng cách chúng ta trình bày các ước lượng có thể xây dựng lòng tin, điều này cũng có thể có tác động đến dự án. Và cuối cùng, chúng ta nhận thức được xu hướng phán đoán trung tâm khi sử dụng phương pháp thanh đo fibonacci và kích thước áo phông. Trên thực tế, có rất nhiều điều cần chú ý như 7 thành kiến dự đoán thời gian mà bạn phải biết.
Với một số lý thuyết nền tảng giải thích lý do tại sao ước lượng dự án phần mềm lại khó đến vậy, giờ đây bạn có thể tiếp tục hành trình của mình để thực hiện ước lượng về dự án phần mềm của chính bạn tốt hơn.
Bài của tác giả Eban Escott đăng trên codebots.com
Bạn có biết?
tham gia cộng đồng ITguru trên Linkedin, Facebook và các kênh mạng xã hội khác có thể giúp bạn nhanh chóng tìm được những chủ đề phát triển nghề nghiệp và cập nhật thông tin về việc làm IT mới nhất
Linkedin Page:
Facebook Group:
cơ hội việc làm IT : ITguru.vn
