Essential for programmers: project time estimation skills

Introduction

A PM recently told me a dilemma she faced: "Software engineers can never estimate how long their projects will take. What should I do?" Two other CEOs told me the same thing recently. matter. At a high level, the problem is that engineers, PMs, managers, PR, and everyone else have different perspectives when it comes to time estimation. What most engineers instinctively think about is the minimum amount of time it will take to write a usable prototype if everything goes according to plan. But what people downstream want to know is when the project will be ready for release - and that's another story entirely.

A PM recently told me about a dilemma she faced: "Software engineers can never estimate how long their projects will take. What do I do?" Two other CEOs recently told me the same thing.

"Why can't programmers accurately estimate project time?" 》(http://blog.jobbole.com/24924/), we all understand it deeply. I once encountered a project that was expected to take two days to complete, but ended up taking four months. In this case, even using the empirical estimate of "double time", there is still a difference of an order of magnitude. This really affects the business. I’ve seen entire companies struggle to host a launch event, only to have to postpone it for months.

At a high level, the problem is that engineers, PMs, managers, PR, and everyone else have different perspectives when it comes to time estimation. What most engineers instinctively think about is the minimum amount of time it will take to write a usable prototype if everything goes according to plan. But what people downstream want to know is when the project will be ready for release - and that's another story entirely.

For engineers, getting a handle on estimating how long a project will take is a lifelong journey. Ignoring this issue can cause problems for you and everyone you come into contact with directly or indirectly. Accurately estimating how long a project will take will make you stand out, and colleagues will associate this with your professionalism, stability and quality of work.

Why do we need time estimation

First, let me answer a question often asked by engineers: "Why do we need to estimate time?" Many engineers complain (with some reason) that this is an indirect cost. "If I work at full capacity, I'll finish the project faster!"

There are two main reasons: external dependencies and priorities.

External dependencies

No effective campaign operates in a vacuum. Projects often have external dependencies, such as collaboration with non-engineering teams (communications, finance, PR, customer service), other engineering teams, or even the end users themselves. Coordinating these external dependencies is usually the responsibility of the manager, PM, or CEO. This means that the people most qualified to do time estimates (engineers) are not the people most in need of the time information for the estimates. This asymmetry leads to a fundamental contradiction.

Priority

Time estimates are also key to prioritizing work. "Whether the money is worth the money" is an important indicator in the project. Without a real estimate, it is impossible to determine whether the money is worth the money. Even if the feature you're working on is the best in the world, if you take the time to do a thorough estimate, you may realize that it's going to take a long time to complete.

Suppose you are working on one project that will make the website 50% faster, but in the same amount of time, two projects can be completed that will each make the website 40% faster. If you don't take the time to make an initial estimate, you'll never know you can make a faster website!

Introduction to Time Estimation

Now that everyone agrees that time estimates are needed most of the time, let’s talk about techniques.

We underestimate time because we think about "How long will it take me to write this basic version?"

But what is delivered is more than just the basic version. Also take into account the time required to write, test, debug and polish. Don’t forget that things like meetings, interviews, doing code reviews, and sending emails also take time.

Another reason to underestimate time is that we almost always encounter "unknowns" during coding that are impossible to fully predict and consider. Maybe the IDE updates, breaks the project, and you spend the day fixing it. This cannot be taken into account in time estimates.

However, we can still do better than our initial intuition. Here’s how I do it:

Step one: Develop a technical plan

Before starting work, you should already have a technical planning or design document that can assist with any major project. You can use this to let others know what you are doing and get feedback. Developing a technical plan is an ideal stage for launching time estimates. When you complete the technical details of the design, unknown problems will be discovered and you will magically revise the estimated time. Perhaps you will realize that you may need to upgrade a library you are using to a new version, which may add a day to your work. You may even realize that the library you plan to use doesn't actually exist and you need to write it yourself.

Granularity is important here. If any step feels vague or unclear, maybe you skipped it (should learn more) or need to break it down into smaller steps. At the same time, if a step is too granular, it may be vulnerable in practice and render the entire plan ineffective.

For information on what aspects should be considered in technology planning, please refer to this article by Alicia Chen "What do you mean ‘we need more time’?". One of the key points is to eliminate any potential ambiguity with the PM or other stakeholders so that you don't end up having to start over because you did something wrong.

Step 2: Add time budget for each step

Estimate how long each step in the technical solution will take to execute. This usually involves digging into the details ("Has anyone already implemented what this library does?"). Depending on the nature of the project, laying out a simple prototype may help expose many potential future pain points.

Step 3: Add lots of extra time

Now you have a preliminary estimate, but all the points we mentioned before still need to be considered.

• Debug at any time: there are always bugs. Debugging largely depends on your experience with a specific codebase and the maturity of the codebase.
• Meetings, interviews, vacations, etc.: Maybe you won’t be coding at your workstation all the time. How many hours do you really have to code? You should at least look at your calendar when estimating.
• Final testing and bug cleaning: Usually you should be writing tests while coding, but many teams need to conduct a round of polishing work or integration testing before releasing. Allow adequate budget for these tasks in the estimate. If the rollout is carried out in stages, the initial 1% of the content may expose bugs that need to be fixed, so this needs to be taken into consideration.
• Code review: How many rounds of code review does the project need? How long does it usually take? Be sure to have enough reviewers available (and check their schedules, too). If this is a project with only one reviewer, they should be asked to agree in advance to have a standby in case the reviewer is on vacation or is too busy at a critical point.

Once you start adding all of this time overhead into your project, you'll start to see your time estimates match much better than when the project actually starts. Yes, it may actually take longer than estimated, and you may feel pressured to shorten the deadline. But people will appreciate your estimates when they know they can rely on you.

Step 4: After the project is released, review and summarize the time estimate

It sounds painful to look back at the work done after the project is completed. But this kind of review will let you learn a lot from it and do better next time.

Which process result is different from the expected time? If an integration test takes twice as long as expected, make a note of it and allow more time for testing next time. Or try to improve the integrated testing system.

You're bound to see your estimates improve over time. You might even come up with some great insights along the way that can help the entire team.

In the end, it’s all about communication

You should inform others of your schedule and other changes in advance. If you let your managers know a new security vulnerability exists in a library you're using a month before a release and you have to start from scratch, they'll have time to notify PR, finance, or users accordingly that the release needs to be postponed.

Important feedback gained from communicating with other collaborators will help adjust the time estimate. The designer might say, "Oh, if this fancy animation is going to take all week, we could cut it out entirely." The PM might add, "This is just a prototype experiment in user research. We don't need Too much bug cleaning for this iteration." The manager might say, "You spent half your time in meetings? I'll fix that!"

For engineers, don’t compromise on unrealistic timelines just to please your superiors. It's more professional to be upfront about your estimated time and changes.

For everyone else, respecting estimated time is difficult and requires a process. You can only shorten the estimated time by sitting down and cutting features or phases that don't actually need to be released, not by nagging you to shorten the time.

We can never perfectly estimate how long a project will take. The only way to do that is to be open, communicative, empathetic, and prioritize decisively.

The above is the detailed content of Essential for programmers: project time estimation skills. For more information, please follow other related articles on the PHP Chinese website!