Một người phát triển viết cho tôi: “Làm sao chúng tôi ước lượng được lịch biểu cho dự án? Chúng tôi nên dùng kĩ thuật nào? Người quản lí của tôi không muốn chúng tôi trượt lịch biểu vì điều đó sẽ làm cho khách hàng giận. Xin thầy giúp đỡ.”

Đáp: Rất khó ước lượng lịch biểu dự án (dự án sẽ mất bao lâu) vì lúc bắt đầu dự án phần mềm, có nhiều điều bạn không biết và mọi sự cũng sẽ thay đổi trong quá trình dự án.

Phần lớn các dự án đều nhận được lịch biểu từ khách hàng nhưng nhiều người quản lí dự án chưa bao giờ hỏi làm sao khách hàng ước lượng được thời gian cho dự án (lịch biểu). Nếu họ hỏi thì họ sẽ thấy ra rằng phần lớn khách hàng cũng không biết cho nên họ chỉ  đoán chừng. Nếu phải mất sáu tháng để hoàn thành dự án nhưng khách hàng đoán rằng nó có thể được làm trong ba tháng thì tất nhiên dự án sẽ trượt lịch. Câu hỏi của tôi là tại sao bạn chấp nhận một phỏng đoán? Tại sao bạn tuân theo lịch biểu không hợp lí? Tại sao bạn đồng ý với cái gì đó mà bạn không biết và khách hàng của bạn cũng không biết?

Có nhiều kĩ thuật khoa học và công cụ phần mềm cho ước lượng dự án. Có nhiều sách được viết ra về ước lượng dự án nữa. Tuy nhiên, có một kĩ thuật đơn giản mà tôi thường dùng. (Đây là cách không khoa học và tôi chắc nhiều người không đồng ý với tôi. Tuy nhiên nó là thực hành). Tôi khuyến cáo rằng những người phát triển nên ước lượng nỗ lực (dự án sẽ cần bao nhiêu công việc) thay cho lịch biểu (thời gian).

Bạn bắt đầu bằng việc phân rã các yêu cầu dự án thành các nhiệm vụ nhỏ hơn (cấu trúc phân việc) cho tới khi bạn nhận được nhiệm vụ mà một người có thể làm trong vòng một tuần. (Thường phải có ít nhất 6 tới 8 mức của phân rã.) Chẳng hạn, nếu dự án có ba chức năng. Chức năng số một được phân rã thành ba nhiệm vụ; chức năng số hai được phân rã thành năm nhiệm vụ; và chức năng số ba được phân rã thành sáu nhiệm vụ. Tổng của tất cả các nhiệm vụ là: 3+ 5+ 6 = 14 nhiệm vụ. Giả sử rằng tất cả các nhiệm vụ này có thể được thực hiện đồng thời và từng nhiệm vụ có thể được thực hiện bởi một người vậy thì bạn cần 14 người (nỗ lực). Cho nên bằng việc có 14 người, bạn có thể hoàn thành dự án trong vòng một tuần (thời hạn).

Tất nhiên, đây chỉ là ước lượng đơn giản vì thời gian để hoàn thành nhiệm vụ là tuỳ thuộc vào kĩ năng của người thực hiện nhiệm vụ và không phải mọi nhiệm vụ đều có thể được thực hiện cùng lúc. Tuy nhiên bằng việc có ước lượng nỗ lực bạn có cái gì đó để thương lượng với khách hàng. Bạn có thể nói rằng nếu tôi có một người, thì phải mất 14 tuần, nếu tôi có 2 người thì có thể mất 7 tuần vân vân. Dùng những con số này để thương lượng về nỗ lực để đi tới cái gì đó hợp lí.

Tôi thường thêm 20% “lót phụ” vào trong con số. (Vâng, đó là “thủ đoạn” nhưng nó có tác dụng). Cho nên thay vì yêu cầu 14 tuần tôi sẽ yêu cầu 17 tuần để cho dự án cái gì đó để thương lượng. Nhớ rằng nỗ lực về công việc được thực hiện là không đổi (giả sử yêu cầu là không đổi) trong khi thời gian cần để làm công việc này là tuỳ thuộc vào kĩ năng của người làm nó cho nên phần thêm 20% sẽ giảm rủi ro và cho dự án sự thuận tiện nào đó và ít căng thẳng hơn. Tôi hi vọng điều đó có ích.

—-English version—-

Project estimation

A developer wrote to me: “How do we estimate the schedule for a project? What technique should we use? My manager does not want us to slip schedule because it will make the customer angry. Please help.”

Answer: It is very difficult to estimate project schedule (how long a project will take) because at the beginning of the software project, there are many things that you do not know and things will also change during the course of the project.

Most projects receive a schedule from the customer but many project managers never ask how does customer estimate the time for the project (Schedule). If they ask then they will find out that most customers also do not know so they just guess. If it takes six months to complete the project but customer guesses that it can be done in three months than of course, the project will slip schedule. My question is why do you accept a guess? Why do you follow an unreasonable schedule? Why do you agree to something that you do not know and your customer also does not know?

There are many scientific techniques and software tools for project estimation. There are many books written on project estimation too. However, there is a simple technique that I often use. (This is a non-scientific and I am sure many people do not agree with me. However it is practical). I recommend that developers estimate efforts (how much work project will need) instead of schedule (time).

You start by decomposing project requirements into smaller tasks (Work Breakdown Structure) until you get to task that a person can do within a week. (Usually it takes at least 6 to 8 levels of decomposition). For example, if the project have three functions. Function number one is decomposed into three tasks; function number two is decomposed into five tasks; and function number three is decomposed into six tasks. The sum of all tasks is: 3+ 5+ 6 = 14 tasks. Assume that all the tasks can be done at the same time and each task can be done by one person then you need 14 people (Efforts). So by having 14 people, you can complete the project within one week (duration).

Of course, this is just a simple estimation because the time to complete the task is depending on the skills of the people who implement the task and not all tasks can be done at the same time. However by having efforts estimates you have something to negotiate with the customer. You can say that if I have one person, then it may take 14 weeks, if I have 2 person then it may take 7 weeks and so on. Using these numbers to negotiate the efforts to come up with something reasonable.

I often add 20% “extra padding” into number. (Yes, it is a “trick” but it works). So instead of asking for 14 weeks I would ask for 17 weeks to give the project something for negotiation. Remember that the efforts of work to be done do not change (Assume requirements do not change) while the time required to do the work is dependent on the skills of people doing it so having extra 20% will reduce the risk and give project some comforts and less stress. I hope it helps.