There's no other way to know how long something will take. You should be thankful, really, that your PM is even consulting you -- too many managers get together with the customer and promise impossible timelines, then expect the devs to live up to their outrageous promises.
Certainly. Without getting estimates for development time no-one has a clue what is going on. You need to be able manage stakeholders expectations, in this case your clients. And better the estimate comes from the horses mouth (in this case the developer) rather than the PM promising impossible time-frames!
Developers sometimes get funny about doing estimates of this nature (I know I do), but it is critical to running a business. The easiest way to approach it is to understand that the PM just wants information. Be open and honest - don't say things will be done when they won't, and explain when and why things might be unknown, or why there might be an element of risk around your estimate.
Yes, you can't get away from PMs wanting an exact figure of how long something will take.
My approach has been to give estimates with +/- values. I'm 60% sure I'll finish this in a week, there's 30% chance it will be longer, and 10% chance it'll be 2 days. Takes a while for a PM to get used to that idea, but it's the reality of the situation. As someone wise once said, only [insert deity here] can change reality, regardless of how much the PM would like it to be different.
We know that Dev is an in-exact science, the tension of traditional project management, meeting creativity and best guess estimation is probably the single biggest headache of professional development. A really good learning from Agile is just how bad we are at estimating, most Dev's will underestimate 80% of time - that's my estimate anyway.
Then it is makes perfect sense that your manager asks you "How much time will this take" because it translates perfecty into "How much will this cost".
Someone must pay that cost, it will either be a customer, or your company.
The PM will use your estimates to ensure the project comes in on time and with in budget. If you say something will take 10 days, and thats 5 days more than he'd like, then it's up to him to either a) cut some other functionality to get this in or b) extend the deadline.
So thats the PMs job, to get estimates from you, and juggle the balance between deliver times and functionality delivered.
YOUR JOB is to provide the best, most honest estimates you can. Like someone else said, always give a confidence prcentage. "2 days, 30% confident" "Possibly 1 day, could be 3 worst case" etc.
It can be annoying to be constantly asked, but it's his job.
P.S. Sometimes the answer "I don't know" is perfectly acceptable, however you should phrase it as "I don't know, I need to look at it a little more and I'll have a better idea then".
You have obviously never worked for a manager that does not ask for an estimate from you. Otherwise you would know better than to question whether they should do it. :-)
Seriously, very few managers can make realistic estimates on the time needed to provide particular feature, mostly because it's not their job to really undersand all the technical intricacies. A good manager will realize this and will always involve the developers to get good estimates of the work that can be fit in when creating the schedule.
I think it's sounds pretty good. It seems better that he asks for an estimate by the people that are going to do it than just promise something to the client that can turn up to be unrealistic.
A project manager should always ask developers how long something will take. What the project manager does with those estimates will vary considerably depending on their own experience and skill.
If the PM has lots of development experience, they should be able to assist more junior developers in determining whether or not the developers estimate is valid - and hopefully point out why they think there estimate is wrong. Also, a PM should be able to add in other factors that the developers tend to forget - meeting time, sickness, time on SO etc, that all impact on their time.
If the PM has little development experience then the most accurate estimate will come from the developers.
如果您对这些事情更感兴趣，我推荐这本书“死亡March”和极限编程网站（特别是此页面）。 对 XP 持保留态度：规则永远不会解决你的问题；规则永远不会解决你的问题。 他们只是告诉你什么对其他人有效。 您将始终明智地使用它们。
One of the main advantages of this is that it helps you to find out early in the game that you are overwhelmed by a task: If you can't time it, you probably don't know how to tackle it.
Also, if your estimate more than a week, then it is probably off by 100-1'000'000% (a.k.a "pure speculation"). If you come up with "several weeks", I suggest that start breaking up the task and estimate the pieces. This will help you notice danger zones (where you really have no idea how long it is going to take).
This process will allow your manager to get you the help/tools you need to complete your assignments in time (instead of noticing something important missing two days before the deadline).
If you're interested more in these things, I suggest the book "Death March" and the Extreme Programming site (especially this page). Take XP with a grain of salt: Rules are never going to solve your problems; they just tell you what worked for other people. You will always use them judiciously.
We had a business manager recently mention in a all-hands staff meeting that a bunch of new features were on the way and they shouldn't take too much effort to implement. This was news to the development team!!
Yes. It is better the manager consults the team on the time required. And the team has to come up with the actual time line taking into considerations all the factors. The onus is on the team to justify the time required for giving quality output. If the Manager is good enough, he/she would appreciate it and agree with the team.
Its a fair question, just don't ever reply with an off the cuff estimate. Always derive estimates from some sort of specification, that way your both on level ground, thats my advice anyway.
发布评论
评论（12）
没有其他方法可以知道某件事需要多长时间。 你真的应该庆幸的是，你的产品经理甚至还在向你咨询——太多的经理与客户聚在一起并承诺不可能的时间表，然后期望开发人员兑现他们的无耻承诺。
There's no other way to know how long something will take. You should be thankful, really, that your PM is even consulting you -- too many managers get together with the customer and promise impossible timelines, then expect the devs to live up to their outrageous promises.
当然。 如果没有对开发时间的估计，没有人知道发生了什么。 您需要能够管理利益相关者的期望，在本例中是您的客户。 更好的是，估计来自马口（在本例中是开发商），而不是 PM 承诺不可能的时间框架！
开发人员有时会因为进行这种性质的估计而感到有趣（我知道我确实如此），但这对于经营业务至关重要。 最简单的方法是了解 PM 只是想要信息。 开诚布公——不要在事情不会做的时候就说会做，并解释事情何时以及为什么可能是未知的，或者为什么你的估计可能存在风险因素。
Certainly. Without getting estimates for development time no-one has a clue what is going on. You need to be able manage stakeholders expectations, in this case your clients. And better the estimate comes from the horses mouth (in this case the developer) rather than the PM promising impossible time-frames!
Developers sometimes get funny about doing estimates of this nature (I know I do), but it is critical to running a business. The easiest way to approach it is to understand that the PM just wants information. Be open and honest - don't say things will be done when they won't, and explain when and why things might be unknown, or why there might be an element of risk around your estimate.
是的，你无法摆脱项目经理想要知道某件事需要多长时间的确切数字。
我的方法是用+/-值给出估计值。 我有 60% 的把握会在一周内完成这个任务，有 30% 的可能会更长，有 10% 的可能会需要 2 天。 产品经理需要一段时间才能适应这个想法，但这就是现实。 正如某个智者曾经说过的那样，只有[此处插入神灵]才能改变现实，无论首相多么希望情况有所不同。
我们知道开发是一门不精确的科学，传统项目管理、满足创造力和最佳猜测估计的紧张可能是专业开发中最令人头痛的问题。 从敏捷中学到的一个真正好的教训是我们在估计方面有多糟糕，大多数开发人员会低估 80% 的时间 - 无论如何，这是我的估计。
Yes, you can't get away from PMs wanting an exact figure of how long something will take.
My approach has been to give estimates with +/- values. I'm 60% sure I'll finish this in a week, there's 30% chance it will be longer, and 10% chance it'll be 2 days. Takes a while for a PM to get used to that idea, but it's the reality of the situation. As someone wise once said, only [insert deity here] can change reality, regardless of how much the PM would like it to be different.
We know that Dev is an in-exact science, the tension of traditional project management, meeting creativity and best guess estimation is probably the single biggest headache of professional development. A really good learning from Agile is just how bad we are at estimating, most Dev's will underestimate 80% of time - that's my estimate anyway.
是的，这是他的工作，因为时间=金钱
如果您考虑到
赚钱
那么，您的经理问您“这需要多少时间”是完全有道理的，因为它完美地翻译为“这将花费多少”。
必须有人支付该费用，要么是客户，要么是您的公司。
项目经理将使用您的估算来确保项目按时完成且不超出预算。 如果你说某件事需要 10 天，而这比他想要的多了 5 天，那么他就可以 a) 削减一些其他功能来完成这项工作，或者 b) 延长截止日期。
这就是产品经理的工作，从您那里获得估算，并平衡交付时间和交付的功能之间的平衡。
您的工作是提供最好、最诚实的估计。 正如其他人所说，始终给予信心百分比。 “2天，30%的信心”“可能1天，可能是3天最坏的情况”等等。
不断被问到可能很烦人，但这是他的工作。
PS 有时，“我不知道”的答案是完全可以接受的，但是你应该将其表达为“我不知道，我需要多看一下，然后我会有更好的想法”。
希望这可以帮助。
Yes, it's his job, because time = money
If you consider the fact that
to make money
Then it is makes perfect sense that your manager asks you "How much time will this take" because it translates perfecty into "How much will this cost".
Someone must pay that cost, it will either be a customer, or your company.
The PM will use your estimates to ensure the project comes in on time and with in budget. If you say something will take 10 days, and thats 5 days more than he'd like, then it's up to him to either a) cut some other functionality to get this in or b) extend the deadline.
So thats the PMs job, to get estimates from you, and juggle the balance between deliver times and functionality delivered.
YOUR JOB is to provide the best, most honest estimates you can. Like someone else said, always give a confidence prcentage. "2 days, 30% confident" "Possibly 1 day, could be 3 worst case" etc.
It can be annoying to be constantly asked, but it's his job.
P.S. Sometimes the answer "I don't know" is perfectly acceptable, however you should phrase it as "I don't know, I need to look at it a little more and I'll have a better idea then".
Hope this helps.
显然，你从来没有为一个不要求你估价的经理工作过。 否则你会知道最好不要质疑他们是否应该这样做。 :-)
说真的，很少有经理能够对提供特定功能所需的时间做出现实的估计，主要是因为真正理解所有技术复杂性并不是他们的工作。 优秀的经理会意识到这一点，并始终让开发人员参与进来，以便在创建进度表时对适合的工作进行良好的估计。
You have obviously never worked for a manager that does not ask for an estimate from you. Otherwise you would know better than to question whether they should do it. :-)
Seriously, very few managers can make realistic estimates on the time needed to provide particular feature, mostly because it's not their job to really undersand all the technical intricacies. A good manager will realize this and will always involve the developers to get good estimates of the work that can be fit in when creating the schedule.
我觉得听起来还不错。 他最好要求将要做这件事的人做出估计，而不是仅仅向客户承诺一些可能不切实际的事情。
I think it's sounds pretty good. It seems better that he asks for an estimate by the people that are going to do it than just promise something to the client that can turn up to be unrealistic.
条件是他接受你的回答。
如果产品经理在问你这个问题时心里有一个数字，他就不会对他的结果感到惊讶。
On the condition that he accepts your answer.
If a PM has a number in mind when he asks you the question he shouldn't be surprised by his results.
项目经理应该总是询问开发人员某件事需要多长时间。 项目经理如何处理这些估算将根据他们自己的经验和技能而有很大差异。
如果 PM 有丰富的开发经验，他们应该能够帮助更多初级开发人员确定开发人员的估计是否有效 - 并希望指出为什么他们认为估计是错误的。 此外，PM 应该能够添加开发人员容易忘记的其他因素 - 会议时间、生病、SO 时间等，这些都会影响他们的时间。
如果 PM 缺乏开发经验，那么最准确的估计将来自开发人员。
A project manager should always ask developers how long something will take. What the project manager does with those estimates will vary considerably depending on their own experience and skill.
If the PM has lots of development experience, they should be able to assist more junior developers in determining whether or not the developers estimate is valid - and hopefully point out why they think there estimate is wrong. Also, a PM should be able to add in other factors that the developers tend to forget - meeting time, sickness, time on SO etc, that all impact on their time.
If the PM has little development experience then the most accurate estimate will come from the developers.
这样做的主要优点之一是，它可以帮助您在游戏早期发现您被任务压垮了：如果您无法计算时间，您可能不知道如何解决它。
另外，如果您的估计时间超过一周，则可能会偏差 100-1'000'000%（又名“纯粹猜测”）。 如果您提出“几周”，我建议开始分解任务并估计各个部分。 这将帮助您注意到危险区域（您真的不知道需要多长时间）。
这个过程将使您的经理能够为您提供及时完成作业所需的帮助/工具（而不是在截止日期前两天注意到重要的事情丢失）。
如果您对这些事情更感兴趣，我推荐这本书“死亡March”和极限编程网站（特别是此页面）。 对 XP 持保留态度：规则永远不会解决你的问题；规则永远不会解决你的问题。 他们只是告诉你什么对其他人有效。 您将始终明智地使用它们。
One of the main advantages of this is that it helps you to find out early in the game that you are overwhelmed by a task: If you can't time it, you probably don't know how to tackle it.
Also, if your estimate more than a week, then it is probably off by 100-1'000'000% (a.k.a "pure speculation"). If you come up with "several weeks", I suggest that start breaking up the task and estimate the pieces. This will help you notice danger zones (where you really have no idea how long it is going to take).
This process will allow your manager to get you the help/tools you need to complete your assignments in time (instead of noticing something important missing two days before the deadline).
If you're interested more in these things, I suggest the book "Death March" and the Extreme Programming site (especially this page). Take XP with a grain of salt: Rules are never going to solve your problems; they just tell you what worked for other people. You will always use them judiciously.
询问比假设要好得多。
我们的一位业务经理最近在一次全体员工会议上提到，一系列新功能即将推出，他们不应该花费太多精力来实施。 这对开发团队来说是个新闻！
Asking is much better than assuming.
We had a business manager recently mention in a all-hands staff meeting that a bunch of new features were on the way and they shouldn't take too much effort to implement. This was news to the development team!!
是的。 经理最好与团队协商所需的时间。 团队必须考虑所有因素来制定实际的时间表。 团队有责任证明提供高质量输出所需的时间是合理的。 如果经理足够好，他/她会很感激并同意团队的意见。
Yes. It is better the manager consults the team on the time required. And the team has to come up with the actual time line taking into considerations all the factors. The onus is on the team to justify the time required for giving quality output. If the Manager is good enough, he/she would appreciate it and agree with the team.
这是一个公平的问题，只是不要用即兴估计来回答。 总是从某种规格中得出估计，这样你们就都在水平面上，无论如何，这就是我的建议。
Its a fair question, just don't ever reply with an off the cuff estimate. Always derive estimates from some sort of specification, that way your both on level ground, thats my advice anyway.