Một người phát triển phần mềm viết cho tôi: “Người quản lí của tôi cho tổ chúng tôi một lịch biểu không thể nào đáp ứng được. Chúng tôi biết đó là ước lượng tồi nhưng không biết làm sao mà nói được vì chúng tôi sợ nói ngược lại đòi hỏi của người quản lí. Không ai muốn bị đuổi việc. Thầy có lời khuyên nào cho chúng tôi không?”

Đáp: Vấn đề ở đây là liệu nói dối hay nói thật. Khi được cho một hạn chót tồi, phần lớn người phát triển sẽ nói “Tôi sẽ cố gắng hết sức” cho dù họ biết rằng không thể nào đáp ứng được lịch biểu tồi. Nếu bạn nói bạn sẽ cố gắng, tất nhiên bạn thậm chí vẫn không tin rằng bạn có khả năng chuyển giao nó đúng hạn? Không có gì sai với việc cố gắng đáp ứng hạn chót nhưng lời nói cũng gợi ý rằng cái gì đó khác sẽ xảy ra.

Lí do nhiều người phát triển nói điều đó là vì họ không muốn tranh cãi với người quản lí. Họ không muốn bất đồng với người quản lí cho nên họ nói “Tôi sẽ cố gắng.” Người quản lí giỏi phải hiểu cảm giác này và nên truy tìm vào trong nó. Người quản lí kém sẽ nghĩ: “Tôi cho họ một nhiệm vụ không thể được nhưng họ sẽ làm nó bằng mọi cách. Nếu họ không đáp ứng được lịch biểu của tôi, tôi sẽ quở trách họ vì không làm được việc tốt.” Điều gì sẽ xảy ra nếu tổ không đáp ứng được lịch biểu? Điều gì sẽ xảy ra nếu người quản lí trách mắng bạn? Điều gì sẽ xảy ra nếu người quản lí dự án nói với người chủ công ti rằng bạn chịu trách nhiệm vì không đáp ứng lịch biểu và làm cho khách hàng giận?

Ước lượng phần mềm là rất khó. Nó đầy rủi ro và là quyết định khó khăn. Người quản lí cần giúp đỡ với những quyết định đó và điều duy nhất có thể giúp cho họ là sự thực. Cho nên khi người quản lí cho bạn một hạn chót không thể thực hiện được, bạn phải nói với người quản lí đó sự thật. Nếu bạn không tin bạn có thể đáp ứng được lịch biểu đó, bạn phải để cho họ biết. Tôi thường khuyên sinh viên nói: “Để tôi xem kĩ ước lượng lịch biểu này rồi tôi sẽ cho ông biết tôi đi tới kết luận gì.” Ít nhất bạn có thời gian nào đó để làm ước lượng riêng của bạn. Không ai sẽ giận bạn nếu bạn muốn kiểm thêm dữ liệu. Tất nhiên bạn phải biết cách ước lượng và đi tới một ước lượng logic mà bạn biết rằng bạn có thể đáp ứng được.

Tất nhiên, nói sự thực có thể không thoải mái nhưng nếu bạn có thể chỉ ra cho người quản lí của bạn về ước lượng của bạn thì điều logic với người quản lí là chỉ ra cho bạn tại sao ông ấy đi tới ước lượng khác. Không có đảm bảo rằng bạn đúng hay ông ấy đúng nhưng ít nhất cả hai có cơ hội để thảo luận về ước lượng lịch biểu. Dựa trên cái vào từ sinh viên của tôi, khi chỉ ra các ước lượng khác nhau, phần lớn người quản lí sẽ thay đổi ước lượng lịch biểu bằng việc tổ hợp hai ước lượng thành cái gì đó mà cả người phát triển và người quản lí sẽ cảm thấy thoải mái. Đó là thương lượng. Bằng việc làm như vậy bạn có cơ hội để học kĩ năng mềm về thương lượng lịch biểu.

Người quản lí dự án có kinh nghiệm chưa bao giờ ước lượng lịch biểu trong chỗ cô lập, người đó thường hỏi cái vào từ những người phát triển. Khi người quản lí hỏi về ước lượng, người phát triển phải cung cấp dự đoán tốt nhất của họ và gợi ý về rủi ro. Chẳng hạn, người phát triển có thể ước lượng một nhiệm vụ 10 ngày, với hai ngày phụ thêm nếu cái gì đó đi sai. Nhiệm vụ có thể mất mười ngày, nó có thể mất tới 12 ngày. Bằn việc cho người quản lí cái gì đó như cách đo hợp lí về tính bất định sẽ giúp cho người quản lí đi tới lịch biểu tốt nhất. Xin nhớ cho rằng công việc dự án phần mềm là công việc tổ và tổ cũng bao gồm người quản lí dự án.

—-English version—-

Schedule Estimation

A software developer wrote to me: “My manager gives our team a schedule that is impossible to meet. We know that is a bad estimate but do not know how to say because we are afraid speaking against the demands of our manager. Nobody wants to get fired. Do you have any advice for us?”

Answer: The question here is whether to lie or to tell the truth. When given a bad dateline, most developer would say “I will try my best” even they know that it is impossible to meet a bad schedule. If you say you will try, of course you will even you do not believe that you will be able to deliver it on time? There is nothing wrong with trying to meet the dateline but the words also suggest that something different will happen.

The reason many developers say it because they do not want to argue with the manager. They do not want to disagree with the manager so they say “I will try”. A good manager must understand this feeling and should inquire into it. A bad manager would think: “I give them an impossible task but they will do it anyway. If they do not meet my schedule, I will blame them for not doing a good job.” What would happen if the team misses the schedule? What would happen if the manager blames it on you? What would happen if the project manager tells the company owner that you are responsible for not meeting the schedule and make the customers angry?

Software estimation is very difficult. It is full of risks and tough decisions. Managers need help with those decisions and the only thing that can help them is the truth. So when a manager gives you an impossible deadline, you have to tell that manager the truth. If you do not believe you can meet that schedule, you have to let them know. I often advise students to say: “Let me look more into this schedule estimate than I will let you know what I come up with.” At least you have some time to do your own estimates. No one would be angry at you if you want to check out more data. Of course you must know how to estimate and come up with a logical estimate that you know that you could meet.

Of course, telling the truth might be uncomfortable but if you can show your manager of your estimate than it is logical for the manager to show you why he come up with different estimate. There is no guarantee that you are correct or he is correct but at least both of you have a chance to discuss about the schedule estimation. Based on inputs from my students, when showing different estimates, most managers would change the schedule estimates by combining the two estimates into something that both developers and managers would feel comfortable. That is negotiation. By doing so you have a chance to learn a soft-skill on schedule negotiation.

An experienced project manager never estimates schedule in isolation, he often asks for inputs from developers. When manager asks for estimates, developers should provide their best guess and a suggestion for risk. For example, a developer might estimate a task at 10 days, with two days extra if something goes wrong. The task might take 10 days, it might take 12. By giving manager something such as a reasonable measure of the uncertainty would help the manager to come up with a better schedule. Please remember that software project work is teamwork and the team also includes the project manager.