What does "We need more time" mean ??

We, as techies, spend little time talking about communication, project management and prioritization. These are the skills that make a good programmer an excellent engineer. Today I am going to focus on one aspect of project management, in which we are obviously bad - the art of estimating deadlines.



If there is any doubt that this is a really necessary skill, remember this terrible, but often asked question: “How long will it take?”. Even if you are super-Agile and do not believe in deadlines, be sure that someone will break under pressure and give a date to which your team will be tied. And when this date comes, and you are not ready to start, your manager will be angry because she will look stupid because of you; the sales team will be angry because they promised the most important customers a product today; and your team will be angry too, because they worked five consecutive weekends trying to invest in an impossible deadline. So let's avoid all this and create a plan fit for life.
')
For example, I want to suggest an exercise, which I borrowed from the course “Intro to Development” from Microsoft. The goal is to estimate the painting time of the room. This is a type of exercise that does not require any specific knowledge of any system.

Now, before scrolling down, think and sketch your estimate - how long will it take to paint the room? Do not skip this part - it is important to record your thoughts in order to follow their evolution.





Is it done?

I hope not, because you do not even know the details of the task! Start by asking for specifications and asking clarifying questions.

Initial requirements

1. Big room? 12 ′ x 10 ′ x 10 ′, the most common room.
2. Do you already have materials for painting? Not.
3. Is there a lot of furniture in the room? And what about the doors, windows and other pieces that should be excluded from the painting process? Yes, you will receive photos.
4. What color is the room now, and what color will it be painted in? Now it is the color of Kermit the Frog, and we want to paint it light yellow.

Even such a seemingly simple task may require a lot of clarifications. OK, let's start over. Write down your best grade before reading further.



Ready?

We break into tasks

1. Confirm all requirements. You need to be sure that everyone agrees on this color, and they are going to paint the same walls. (5 minutes)
2. Learn how to paint a room if you don't know yet. You are likely to clarify many important questions about the primer, and how long you need to wait before applying the next layer. Re-clarify any ambiguities at the customer - maybe you just learned that the paint also differs in the degree of gloss. (15 minutes)
3. Make a shopping list and purchase all the necessary materials: paint, rollers, paint trays, brushes, clothing, etc. (2 hours)
4. “Zaprototype” your work on a small area of ​​the room to be sure that the original color does not appear under the new. This can save a lot of time if, for example, you did not think that you would need a primer, but it was needed (10 minutes for painting, 2 hours for drying)
5. Remove everything from the walls: paintings, curtains, switch covers. Move the furniture away and cover it with something. And the floor too, especially if you need to paint the ceiling. (30 minutes)
6. Wash the walls and inspect them for cracks or roughness. You will need to fix all this before painting. (1 hour)
7. Protect everything from baseboards, from paint drops. Tape masking tape all edges (windows and doors, for example). (1 hour)
8. Prime the room. (1.5 hours)
9. Allow the primer to dry. (30 minutes, if you start painting from the same point where you started the primer)
10. Wash all equipment necessary for painting from the primer. (20 minutes, but you can do it and the paint dries)
11. Apply paint. (2 hours)
12. Get out. (30 minutes)

So let's take a break from painting for a minute to return to the world of software and note some similar points.

Some of these steps may seem silly. Double check color? But if you omit something from the details in the preparation of the specification, you can spend a lot of time creating something that does not need anyone. The smallest difference in the specification (“Oh, you wanted waterproof, different shades and on the same wall?”) Can be costly in the future, in this case almost doubling the original time.

Without research or a prototype, you can waste a lot of time. Omit the framework that does exactly what you need, for example. And then the prototype will show that the framework documentation blatantly lied, and it really does not suit you! If the prototype was simple and cheap, you just saved yourself from the time spent trying to implement the framework.

Further, if you do not break the task into several fairly small pieces, you can skip any important points. For example, if you forget that furniture needs to be moved away, you may not have a partner to move these giant bookcases.



And the most important factor in the accuracy of time evaluation is whether you have had this experience before or not. Even with a long and expensive study, it is difficult to know how many layers of paint will be needed on this particular wall, what is your painting speed, or how humidity in a room affects drying time. In fact, if you have already done such a project, you can skip steps one to four. But if not, you will constantly be surprised by things that you have forgotten, and your initial estimate of time will be farther from the real one. This means that more or less plausible deadlines will appear only after the fulfillment of clause 4. Everything that has been said up to this point will be a simple guess, which you can later regret, so the safest way is to say “I don't know, but I can say through several days".

OK, back to the paints. We estimated the project at about 12 hours. It's all?

Nuu ... steps with primer and painting are clearly less detailed than the rest. Humble, you still do not know how this part will be implemented, and all the estimates - again, guesses. Applying the principles above, we will try a little deeper.

1. Prepare the paint by mixing everything in a large bucket. Pour some into the tray. (15 minutes)
2. Paint the edges with a brush, not forgetting the corners, and skipping everything that should not be yellow. If it takes you 3 minutes to one and a half meters of plinth, and only 65 meters, then everything will take about two hours. Plus 20 minutes to crawl up and down the stairs. And if you do not have a ladder, it would be good to add it to the shopping list. (let it be 2.5 hours)
3. One race having dipped the roller in the paint, you will most likely be able to cover a section of the wall from floor to ceiling as wide as a roller in a couple of passes, so that a section of one and a half meters is likely to last about ten minutes. (1,5 hour)
4. Your “prototype” will tell you how many layers of paint you need. This can significantly increase the total time, so this also needs to be taken into account. (Multiply by the number of layers, given the drying time factor)

You will also find that the primer is not much different from painting, so we increase it two more times.

So, in the case of only one layer, it turns out 15 hours. Fuh, it's really a lot more than we thought at the beginning! And just in case, add a little more time for all kinds of surprise, like the need to install a strainer. So round up to 17 hours. That's starting to paint, right?



Nope, still not!

External factors

Yes, we estimated how much time it would take to paint. But this is not what everyone wants to know. They want to know how long it will be before the room is painted. This is a subtle but important distinction. When I ask about the bug, it's good to hear that you can fix the fix in an hour, but what I really need to know is that you won't have time to do it until next week, so I’ll get a patch in a week plus one hour ! The fact that I only technically asked about the time to create a fix can only be noticed by an engineer. -_-

So are we still missing? Breaks for washing and eating, casual interruptions, and a war of priorities. Work can be delayed by a bunch of problems, expected and unexpected. Maybe today you need to finish early, because the day of washing, or something unexpected happened. How is it possible to predict anything in case of such uncertainty?

The answer is a lot of buffer time added based on previous experience. You can calculate the multiplier for your estimates by comparing the original estimate for each task and the time actually spent on it. Since each project is different from the previous one, this method will not give fantastic accuracy. But such a factor applied to the estimated time of the entire project can cover everything, including your natural optimism, the increased number of meetings and the time for procrastination on the Internet.

I will not go into details, because on this subject there is already a detailed article from Joel Spolsky Evidence Based Scheduling . Although this method may seem long, tracking timesheets for at least a couple of projects can seriously improve your grades. Like all other skills, this one also takes time and effort.

Catching bad grades

All the above is good if you are asked to rate time. But, as a programmer, evaluation usually comes to you as a ready-made together with the project. Maybe the deadline was set by marketing, because they want to get it before Christmas, or by a manager who needs a date to coordinate with other teams that also have their own deadlines. Or there are no specific dates, but according to their glitter in their eyes one can tell from Certain Expectations. The bottom line is that if you think that deadlines are unrealistic, you need to say about it.

Ideally, every engineer should be able to evaluate their part of the work independently, without reference to a plan issued by someone. You can easily convince yourself that you can make a project in two weeks, or just not to bother much about this period set by the manager. You can understand that everything is bad only when you take up the real work.

It is really important to carefully evaluate the deadlines as early as possible and discuss all unrealistic deadlines. Just remember that when you resist bad deadlines, you are not Debbie Downer, who fights against the magical world, where you finish the project for Christmas and everything is fine. Such a world does not exist. You simply prefer a world in which everyone is looking for a compromise between a date and a set of features in order to achieve a goal, a world in which deadlines are transferred or a huge piece of functionality is brought to them. If your team or PM doesn’t buy it, send them to the Evidence Based Scheduling article.

Yes, it sounds like we have a lot of work. But I can assure you - for any important project, a careful assessment of the timeline can avoid a lot of trouble. I hope you now have more tools for better project evaluation.

Translator's note. I can not refrain from quoting the famous formula in narrow circles :)