Nhiều dự án phần mềm có vấn đề bởi vì lịch biểu khách hàng đặt cho họ. Bởi vì người quản lí dự án không biết cách ước lượng thời gian cần để hoàn thành dự án cho nên họ đồng ý với bất kì ngày tháng nào khách hàng đặt ra. Không may, phần lớn các khách hàng cũng không biết dự án có thể được thực hiện trong bao lâu cho nên họ đặt một ngày tháng tuỳ tiện mà họ thích. Đó là lí do tại sao dự án ở vị thế xấu vì ngày tháng bị đặt dựa trên phỏng đoán chứ KHÔNG dựa vào thời gian cần thiết.

Nhiều người quản lí dự án cũng không biết cách lập kế hoạch cho công việc của họ. Họ vội vàng cho dự án bắt đầu bằng việc ra lệnh cho tổ dự án xô vào thiết kế và bắt đầu viết mã bởi vì với họ phần mềm là mã. Chẳng mấy chốc mọi người có thể viết mã nhanh hơn họ có thể hoàn thành dự án. Một số người quản lí dự án muốn chứng tỏ “tiến độ của họ” cho người quản lí cấp cao bằng việc cho tổ viết mã và kiểm thử sớm nhất có thể được bởi vì người quản lí cấp cao chỉ thấy tiến độ khi dự án đi vào pha kiểm thử, vì điều đó có nghĩa là dự án gần hoàn thành và sẵn sàng cho chuyển giao. Điều này sẽ đưa dự án vào tình huống sinh lỗi vì công việc được thực hiện vội vàng để sang pha kiểm thử.

Nhiều người phát triển không biết cái gì tốt hơn. Họ chi tuân theo chỉ đạo của người quản lí dự án bởi vì họ thích viết mã. Tất nhiên, họ biết về các pha khác trong vòng đời nhưng phần lớn các trường nhấn mạnh vào viết mã cho nên họ làm điều họ đã học giỏi nhất bằng việc làm pha viết mã. Tôi đã thấy nhiều người phát triển đổ xô qua yêu cầu, thiết kế trong vài ngày để họ có thể viết mã. Một số người thậm chí còn nói: “Viết mã trước, hỏi câu hỏi sau.” Kết quả là sản phẩm phần mềm với nhiều lỗi và có thể không có được điều khách hàng cần.

Tất nhiên khách hàng không hài lòng và nhiều người yêu cầu: “Đó KHÔNG phải là điều tôi muốn. Thay đổi nó đi nếu không tôi sẽ không trả tiền.” Người quản lí cấp cao muốn đạt tới sự thoả mãn của khách hàng sẽ gây sức ép lên người phát triển: “Trở về và đổi mã của các anh theo điều khách hàng muốn nhưng chóng chóng lên vì không còn nhiều thời gian đâu.” Dưới loại sức ép này, mọi người sẽ trách móc ai đó khác.

Kịch bản này thường xảy ra trong mọi công ti nhưng ít người biết phải làm gì bởi vì mọi người đều trách ai đó khác. Là người phát triển, bạn có thể biết rằng lịch biểu là không hợp lí và nói với người quản lí dự án “Lịch biểu đó dường như không đúng.” Tuy nhiên, người quản lí có thể nói “Lịch biểu đó tới từ khách hàng. Anh không hiểu về sự hài lòng của khách hàng sao? KHÔNG phải việc của anh đi bảo khách hàng rằng họ là sai.” Cho nên bạn lắc đầu và trở lại viết mã bởi vì đó KHÔNG phải là lỗi của bạn. Tất nhiên người quản lí cũng có cùng cảm giác không thoải mái nhưng đó cũng KHÔNG phải là lỗi của người đó bởi vì người đó đã không đặt ra ngày tháng. Khách hàng cũng có cùng cảm giác nhưng người đó nghĩ, đó KHÔNG phải là lỗi của mình vì người đó đã đặt ngày tháng tuỳ tiện nhưng tổ đằng nào cũng đã chấp nhận nó rồi. Khi không ai chịu trách nhiệm về bất kì cái gì thì dự án sẽ thất bại. Khi điều đó xảy ra, sẽ có tổn thất vì khách hàng sẽ KHÔNG chấp nhận sản phẩm và sẽ KHÔNG trả tiền. Người quản lí sẽ KHÔNG tự sa thải mình cho nên người dễ nhất chịu trách móc là người ở vị trí thấp nhất: người phát triển. Mọi người sẽ nói rằng đó là lỗi của người phát triển vì anh ta không hoàn thành dự án tương ứng theo điều khách hàng yêu cầu. Là người phát triển, bạn là cái bung xung cho mọi thứ.

Cho nên bạn phải làm gì? Khi bạn mua máy MP3, điện thoại di động, hay laptop bạn có thương lượng về giá, đúng không? Cho nên tại sao bạn không học cách thương lượng lịch biểu? Tại sao bạn chấp nhận nó mà không hỏi gì? Điều bạn cần là chuẩn bị cho thương lượng. Khi người quản lí nói ngày chuyển giao là sáu tháng, bạn phải bảo họ: “Để tôi kiểm lại xem liệu tôi có thể làm được điều đó trong lịch biểu mà ông yêu cầu không.” Cho dù bạn biết lịch biểu đó là không hợp lí, ĐỪNG tranh cãi vào lúc đó bởi vì bạn CHƯA chuẩn bị để thuyết phục họ. Bạn cần thời gian để đi tới lịch biểu logic và hợp lí bằng việc kiểm điểm lịch đã cho với tổ. Năm hay mười người là tốt hơn một người cho nên cùng với tổ, bạn làm ra kế hoạch dự án với mọi việc được chia ra tới mức chi tiết về bao nhiêu chức năng, bao nhiêu nhiệm vụ, cũng như nỗ lực được cần tới để hoàn thành toàn thể dự án và thời gian kết thúc chúng. Bây giờ, bạn có thể tới người quản lí như một tổ và bảo họ lịch biểu là gì. Như một tổ, bạn chỉ cho người quản lí thấy bản kế hoạch dự án với mọi công việc và thuyết phục người quản lí rằng tổ biết điều họ đang nói tới.

Nếu bạn có thể chỉ ra cho người quản lí cách bạn đi tới lịch biểu mới hoặc là ông ấy đồng ý với bạn hoặc là ông ấy phản đối nó bằng kế hoạch khác. Về căn bản, cả bạn và người quản lí bắt đầu thương lượng trên cách thức logic và hợp lí để giải quyết vấn đề này. Nếu dự án cần tám tháng và KHÔNG phải sáu tháng, điều cuối cùng người quản lí muốn là đồng ý với lịch biểu sáu tháng bởi vì nó sẽ thất bại. Người quản lí sẽ phải trở lại với khách hàng và báo cho người đó biết về lịch biểu mới. Không người quản lí nào muốn dự án thất bại nếu người đó biết rằng người đó có thể mất việc của mình. Không người quản lí nào muốn thấy người của họ bảo họ: “Tôi đã bảo ông rằng cần tám tháng nhưng ông đã không chịu nghe.” Cho nên đến lượt người quản lí thuyết phục khách hàng và rất có thể là ông ấy sẽ đề nghị bạn đi cùng ông ấy bởi vì đó là công việc của bạn và bạn biết tất cả chi tiết. Đây là cơ hội của bạn để chứng tỏ cho khách hàng về năng lực ước lượng của bạn và kĩ năng thương lượng của bạn. Nếu họ đồng ý với bạn và dự án hoá ra thành công, mọi người sẽ biết về bạn và đó là cơ hội của bạn có được cái nhìn tốt trước quản lí cấp cao và khách hàng.

Tất nhiên, bạn phải học nhiều về ước lượng dự án và cách thương lượng và trao đổi. Không may, phần lớn các trường KHÔNG dạy những kĩ năng này cho nên bạn cần tự học chúng.  Có nhiều bài báo tuyệt vời trên internet về những chủ đề này cho nên xin tìm chúng đi. Khi bạn có thể đi tới lịch biểu hợp lí, khi bạn có thể thương lượng với khách hàng thì bạn sẵn sàng bước sang vai trò tiếp: Vị trí quản lí dự án.

—-English version—-

Project estimates

Many software projects have issue because of the schedules that customers set for them. Because project managers do not know how to estimate the time it takes to complete the project so they agree to whatever date the customers set. Unfortunately, most customers also do not know how long the project could be done so they just arbitrary set a date that they like. That is why project is in a bad position as the date is set based on a guess NOT on the time required.

Many project managers also do not know how to plan their works. They hurry to get the project starts by order the team to rush through designs and start coding because to them software is code. The sooner people can code the faster they can complete projects. Some project managers want to demonstrate “their progresses” to senior managers by having the team codes and tests as soon as possible because senior managers only see progress when project is getting into testing phase because it means the project is almost complete and ready for delivery. This will put the project into an error-prone situation as the work is done in a hurry just to get to the testing phase.

Many developers do not know anything better. They just follow the project manager’s direction because they like to code. Of course, they know about other phases in the life cycle but most schools emphasize coding so they do what they learn best by get to the coding phase. I have seen many developers rush through requirements, design in a matter of days so they can  code. Some even say: “Code first, ask question later”. The result is a software product with a lot of defects and may not have what customer’s needs.

Of course the customer is not happy and may request: “That is NOT what I want. Change it or I will not pay”. Senior managers who want to achieve customer’s satisfaction will pressure the developers: “Go back and change your code to what the customer wants but hurry as there is not much time”. Under this kind of pressure, everyone will blame somebody else.

This scenario happens often in every company but few people know what to do because everybody is blaming somebody else. As developer, you may know that the schedule is unreasonable and tell the project manager “That schedule does not seem correct”. However, the manager may say “That schedule comes from the customer, Don’t you understand about customer satisfaction? It is NOT your job to tell the customer that he is wrong.” So you shake the head and go back to code because it is NOT your fault. Of course the manager also has the same uncomfortable feeling but it is NOT his fault either because he did not set the date. The customer also has the same feeling but he think, that is NOT his fault as he sets an arbitrary date but the team accepted it anyway. When no one is responsible for anything than the project will fail. When it happens, there will be casualty as customer will NOT accept the product and will NOT pay. Manager will NOT fire himself so the easiest person to blame is the people in the lowest position: The developer. Everybody will say that it is the fault of the developer as he does not complete the project according to what the customer ask for. As developer, you are the scapegoat for everything.

So what should you do? When you buy a MP3, a Mobile phone, or a laptop you do negotiate on prices don’t you? So why don’t you learn on how to negotiate the schedule? Why do you just accept it without any question? What you need is to prepare for negotiation. When managers say the delivery date is six months, you must tell them: “Let me check to see if I can do it within the schedule that you ask for”. Even you know the schedule is unreasonable, do NOT argue at that time because you are NOT prepare to convince them yet. You need time to come up with a logical and reasonable schedule by review the given schedule with the team. Five or ten people is better than one so together with the team, you make a project plan with all the work breakdown to detailed level of how many functions, how many tasks, as well as the needed efforts to complete the entire project and the time to finish them. Now, you can approach the manager as a team and tell them what the schedule is. As a team, you show the manager the project plan with all the works and convince the manager that the team know what they are talking about.

If you can show the manager how do you come up with the new schedule either he agrees with you or counter it with another. Basically, both of you begin to negotiate on a logical and reasonable way to solve the problem. If the project needs eight months and NOT six months, the last thing your manager wants is to agree to a six months schedule because it will fail. In that case, your manager will have to go back to customer and let him know about the new schedule. No manager would want a fail project if he knows that he could lose his job. No manager would like to see their people tell them : “I already told you that it needs eight months but you did not listen”. So it is the manager’s turn to convince the customer and very likely that he will ask you to come with him because it is your work and you know all the details. This is your chance to demonstrate to the customer about your ability to estimate and your negotiation skill. If they agree with you and the project turns out successful, everybody will know about you and that is your chance to look good in front of senior managers and customers.

Of course, you must learn more about project estimate and how to negotiate and communicate. Unfortunately, most schools do NOT teach these skills so you need to learn them yourself.  There are many excellent articles on the internet about these topics so please do search for them. When you can come up with a reasonable schedule, when you can negotiate with customers then you are ready to step into your next role: The project manager position.