It always takes longer than you expect, even when you take Hofstadter's Law into account.
--Douglas Hofstadter
On a more serious note, take a look at Critical Chain Project Management. It recommends that you give two estimates for each step in your project. One is an optimistic estimate that you're about 50% sure you can meet if everything goes right. The other is a more realistic estimate that takes lost time and mistakes into account (my paraphrasing, don't blame the author). Over time and several projects you'll learn which estimate is more accurate, and by how much. It varies by developer, so you need to keep track.
The problem isn't so much poor time estimates as it is poor/impossible scope estimates.
Showing the result, or mockups of the results to the customer/manager as early as possible, while testing the codes validity, results in better understanding of the goals/requirements.
Remember: A project is a success if it "makes the customers happy" when it is done, not when it meets the requirements known to the analyst, when the project was originally started.
Naturally this means that "moving target" is the rule, not a bad thing, and nothing to be afraid of. It also means that I, as project lead/architect, must ensure that cost for the changes in scope can/will be communicated and covered .
How is this done?
Demo early, demo often (To users and their managers in the same room)
Change Requests Mentality. (So the customer knows what the changes are and what those changes cost, and so the customer can use them to re-scope his project a la carte)
Be honest, talk to customer and developers .. and make sure they also talk to each other.
I spend 20% of my time doing what I want and 80% refactoring it.
So, yeah, if you consider that it "works" in that first 20%. But, that last 80% makes it reusable, worth maintaining, and a pleasure (instead of a burden) to use in the future.
The Pereto Principle applies a lot to Developers. Some say that 80% of the work is done by 20% of the Developers. Also, 80% of the bugs are generated by 20% of the Developers. In addition, 80% of the features are used by 20% of the users. Those are the examples that I've heard of.
发布评论
评论（9）
我认为霍夫施塔特定律适用。
更严肃地说，请查看关键链项目管理。 它建议您为项目中的每个步骤给出两个估计。 一种是乐观估计，如果一切顺利，您大约有 50% 的把握可以见面。 另一种是更现实的估计，考虑了损失的时间和错误（我的解释，不要责怪作者）。 随着时间的推移和几个项目的进行，您将了解哪种估计更准确以及准确程度如何。 它因开发者而异，因此您需要跟踪。
I think Hofstadter's Law applies.
On a more serious note, take a look at Critical Chain Project Management. It recommends that you give two estimates for each step in your project. One is an optimistic estimate that you're about 50% sure you can meet if everything goes right. The other is a more realistic estimate that takes lost time and mistakes into account (my paraphrasing, don't blame the author). Over time and several projects you'll learn which estimate is more accurate, and by how much. It varies by developer, so you need to keep track.
绝对地！ 我 80% 的时间花在 stackoverflow.com 上，20% 的时间用于实际工作。
奇怪的是，我的生产力和以前一样…………
和以前一样！
;-)
absolutely! 80% of my time is spent on stackoverflow.com, and 20% actually working.
oddly enough, my productivity is the same as it ever was...
...same as it ever was!
;-)
提前 2 小时向客户编写单元测试和演示功能将为您节省 8 小时的调试和重写时间。
2 hours of writing unittests and demoing functionality to your clients early will save you 8 hours of debugging and rewriting.
在我看来，Kozyarchuk 说得对：
问题不在于糟糕的时间估计，而在于糟糕/不可能的范围估计。
在测试代码有效性的同时，尽早向客户/经理展示结果或结果模型，可以更好地理解目标/要求。
请记住：如果项目在完成时“让客户满意”，而不是在项目最初启动时满足分析师已知的要求，那么该项目就是成功的。
自然，这意味着“ 移动目标”是规则，不是坏事，也没什么好害怕的。 这也意味着我作为项目负责人/架构师，必须确保范围变更的成本能够/将会得到传达和涵盖。
这是怎么做到的？
这总是有效吗？ 否
In my opinion Kozyarchuk gets it right:
The problem isn't so much poor time estimates as it is poor/impossible scope estimates.
Showing the result, or mockups of the results to the customer/manager as early as possible, while testing the codes validity, results in better understanding of the goals/requirements.
Remember: A project is a success if it "makes the customers happy" when it is done, not when it meets the requirements known to the analyst, when the project was originally started.
Naturally this means that "moving target" is the rule, not a bad thing, and nothing to be afraid of. It also means that I, as project lead/architect, must ensure that cost for the changes in scope can/will be communicated and covered .
How is this done?
Does this always work? NO
你为什么还要问 80/20 规则？ 您正确引用了 90/90 规则。 您已经知道 90/90 规则适用于开发人员。
（抱歉，我用事实来回答，而不是开玩笑。）
Why do you even ask about the 80/20 rule? You quoted the 90/90 rule correctly. You already know that the 90/90 rules applies to developers.
(Sorry to respond with facts instead of a joke.)
我花 20% 的时间做我想做的事，80% 的时间重构它。
所以，是的，如果你认为它在前 20% 中“有效”。 但是，最后 80% 使其可重用、值得维护，并且在将来使用时会带来乐趣（而不是负担）。
I spend 20% of my time doing what I want and 80% refactoring it.
So, yeah, if you consider that it "works" in that first 20%. But, that last 80% makes it reusable, worth maintaining, and a pleasure (instead of a burden) to use in the future.
佩雷托原则对开发人员来说非常适用。 有人说 80% 的工作是由 20% 的开发人员完成的。 此外，80% 的错误是由 20% 的开发人员产生的。 此外，80%的功能被20%的用户使用。 这些是我听说过的例子。
The Pereto Principle applies a lot to Developers. Some say that 80% of the work is done by 20% of the Developers. Also, 80% of the bugs are generated by 20% of the Developers. In addition, 80% of the features are used by 20% of the users. Those are the examples that I've heard of.
我和蜥蜴比尔在一起。 由于非常意外的事情或可能没有考虑到的事情，它总是比预期花费更长的时间。
I am with Bill the Lizard. It ALWAYS takes longer than expected due to very unexpected things or probably things that weren't taken into account.
是的，80/20 法则适用于开发，但你必须以不同的方式解释它：
Yes, the 80/20 law applies to developing, but you have to interpret it differently: