How to evaluate the timing?

Question

Project management

I read articles on Habré of leads/managers. What is not TC, then the genius of planning. And everyone expects the same from employees. And with such a hint that otherwise you are a gouging, a swindler, your ten years of experience is a profanity, and generally get out of the profession.
How do I know how long it will take to fix a bug if I haven't found it yet?
How do I know how long it will take to implement a feature if I haven't done it yet?
Yes, even if I did it a hundred times, but did not do it in this project, and somewhere something will definitely come out.
Especially if I don't even know how long it will take me, why the hell would the manager want me to give an estimate of my colleague's work time?
When I rattled in a web studio on standard projects, it's not a question, everything is clear, but with a full-fledged development?

Answer 1

If you are familiar with the project and figured out what the bug is, then estimating the time to fix it is not a problem.
If you don’t know what kind of bug this is, then this is not a bug yet, but a production issue, and it is being investigated until you come up with a temporary workaround so that users can work, then you will find a root issue, start a bug and even then evaluate time to fix it.
In general, for any senior developer, these questions should be clear and understandable. The manager is not a programmer and should not be, but the development of a large product must be regulated in some way. Otherwise, why pay a programmer a salary, if he does not know the year, will he fix a bug or a day? How can someone who pays you money be able to understand if he has enough money for you to write a product for him at all, if you cannot estimate the duration of the work?
Therefore, you need not be indignant, but learn to plan your work.
In most cases, an experienced developer gives fairly accurate deadlines. Well, for non-standard cases, a certain percentage of the time is always laid. There are cases that cannot be resolved for months and years - this is being discussed, a workaround is found and they live like that.
Agile in this regard is convenient not only because you can give yourself tasks for 2-3 weeks and solve them, but because every 2-3 weeks you can look back and understand how well you assessed your estimates, and whether you need to sprint to increase or vice versa to reduce time. And so every sprint - you watch and improve your planning skills and work efficiency.

Answer 2

Everything is simple here. There are laws of statistics and large (and not so) numbers. They require estimates, i.e. approximate (with an error of no more than 30 percent) terms.
Firstly, a full-fledged development is also quite typical .. actually) If you have not understood this yet, then this means that you have quite a bit of experience.
Secondly, if you have fixed 100 such bugs, you will notice that the time required for fixing falls into a certain range, which you need to voice, clarifying it with the help of additional information that you know. If it is not known (for example, a new unknown freelance project, and the customer asks for terms and price), then it is quite possible to name the entire range. i.e. from and to (from an hour to a week), and then, as the project is studied and information is obtained, it should be refined.
The fact that it will come out somewhere can also be taken into account in the timing .. Often there are predictable things that can come out. Or make a reservation that these deadlines take into account only a good scenario, but then you will need to name the deadlines when you find out if there are problems or not.

Answer 3

I meet the deadlines only if the task is chewed from and to. Those. task level "do without thinking". And the deadline for such a task is within a day.
In other cases, this results either in a failure to meet deadlines, or in noodle code at the exit, or in editing bugs and retroactive improvements. And the larger the approximate estimate, the more side effects.
Perhaps this is due to little experience (~2 years of commercial development), insufficient knowledge of OOP, lack of tests and a base of proven solutions.

Answer 4

How do I know how long it will take to fix a bug if I haven't found it yet?

Finding a bug in your own program takes up to a week on average. In someone else's can take three months.
Make a detailed plan of what needs to be done to implement it. Point by point sum and scale in real terms.
For example, half a day - in two days, a day - in three, a week - in a month, a month - in three, six months - in three and a half years. Etc.
You don't just need to get a job in such projects. This is a waste of time and health.
Offer to insert this work into the plan, and say that it will take you a week. He will run away to evaluate.
Especially when a small team of real specialists is working on a project.

Answer 5

Books and articles have been written about it. For example, here .
Evaluation is not a commitment, but an assumption. It has a probabilistic character ("most likely it will take a week, at least 3 days but not more than a year").
The grade expresses your knowledge of the problem, some time can be spent on the grade itself to improve this knowledge ("I can say more precisely if you give me an hour to study module x and discuss with Pasha").
I would advise you to write a plan for completing the task and testing, think about what else can break and test it (regression testing) and get the opinion of colleagues (they can tell you what is missing). In SCRUM, for example, the whole team is involved in planning.
I would also advise you to google in English before asking such general questions - most likely you will find better content than you yourself will answer here. For example, look for approaches for software estimation.

Answer 6

I do this: I present a scale of percentages and time. Those. with a probability of 80% I will do it in a week. Rush faster? In three days I will do it with a probability of 20%. Where do these numbers come from? From experience, confirmed by tasks from the task setting system.

Answer 7

What are the methods and guidelines for calculating the number of program hours per project?

Answer 8

How do I know how long it will take to fix a bug if I haven't found it yet?
How do I know how long it will take to implement a feature if I haven't done it yet?

In order to give an estimate, time is given, and not immediately asked to evaluate.
The task of the developer is to understand the logic of the product, understand the essence of the problem, find the place where the problem occurs, evaluate the quality of the code, the cause of the problem. This usually takes up to an hour. And then it becomes approximately clear what needs to be done and in what volumes.

Answer 9

It seems to me that you have very experienced managers and you behave like little children.
Estimating a task is also a task and it also has an estimate.
And yes, sometimes evaluating tasks is much more difficult than actually implementing them, the temptation is very great to say something and not even start to delve into it.
Over time, you will develop your own wind correction factor.
Rating not ripe? - Don't speak up.
Not sure how to rate? - Decompose, evaluate separately and then summarize.
Started to do and realized that fucked up? - Report it right away, not an hour before the deadline.
Asked to evaluate for another person? - focus on how much you would do this task.
Again, there is an activity in Scrum - grooming. It's like planning, only without ratings. Superficial (or not so) analysis of estimates and clarification of all the details and nuances.