您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

程序员如何合理预估自己的项目开发时间？

时间,项目,代码程序员如何合理预估自己的项目开发时间？

发布时间：2020-12-06加入收藏来源：互联网点击：

程序员如何合理预估自己的项目开发时间？

回答于 2019-09-11 08:43:50

回答于 2019-09-11 08:43:50

我把程序员的工作从某种难易程度上分为两种情况，一种是重复以往的有经验的工作，另外一种是需要深入研究的创新型工作，前者因为有过往研发及调试经验比较容易预估时间，后者相对复杂一点，会经常遇到所谓的‘’坑‘，为了填这些坑，时间往往很随机，我个人经验都是快速评估项目难点，通过预览学习资料（通常都是网上获取），评估技术可行性以及预估项目研发时间。因行业差异，实际方法可能有所差异，个人经验，仅供参考。

回答于 2019-09-11 08:43:50

初级时间估算

假设我们达成了时间估算非常重要这个共识，那么我们继续看一下如何估算。通常情况下，我们低估所需时间是因为我们想的是「写出一个原型需要多长时间？」。

但是，交付的东西往往要比原型大多了，你还需要考虑测试、调试、优化所花费的时间。还有开会、访谈、代码评审，甚至发邮件都是需要花费时间的。

低估所需时间的另一个原因是意外的问题，这些问题往往不能被充分考虑到，比如 IDE 更新而让你多花了一天去配置环境等等。

基于此，我们最好不要太相信所谓的经验和直觉。

Step 1：制定技术方案

在开始任何一个重要项目之前，你都应该有一份技术计划或者设计文档。这个文档的目的在于让别人知道你在做的事情，并能获得反馈。当你注意到其中的技术细节时，你就会更清晰知道具体所耗费的时间，比如把某个库更新到新版本，可能会多花一天的时间。你甚至还得自己写一个库。

颗粒度在这里是很重要的。如果有哪一部分让人觉得不清楚，要么是你应该了解更多相关知识，要么得把它分解为更细致的步骤。与此同时，如果一个步骤太细的话，又可能会太脆弱导致整个计划无效，所以要把握好这个度。

想要知道你的文档里应该考虑哪些东西，可以看看AliciaChen 的 这篇文章。关键在于跟 PM 沟通清楚，消除有歧义的地方，这样才不会导致最后要推翻重来。

Step 2：为每一步添加时间估算

文档里的每一步实现需要多少时间，这往往牵涉到对细节的研究（这个是不是已经有库了？）。因此视项目性质而言，先做一个简单的原型可以帮助揭示许多潜在的痛点。

Step 3：追加容错时间

现在你已经有了初步的时间估算，不过还有许多其他需要考虑的因素。

随时调试：Bug 难以避免，这取决于开发者对特定代码库的经验以及代码库的成熟度。会议和假期：开会或者放假时一般来说是不会敲代码的，所以真正敲代码有多长时间？因此时间估算时要好好看看日程表。最终测试：通常应该一边编码一边测试，但很多团队在发布前还需要做集成测试，因此在你的估算中留出这部分的时间。代码评审：在这个代码库中你一般需要进行几轮？每轮需要多少时间？要经过多少评审人？留意评审人的日程安排确保代码评审的时间。

当你把交付时间的开销也考虑进去，你就能看到自己的时间估算和项目的实际发布时间要匹配得多。尽管实际情况可能还会更长，你也可能会因压力而需要缩短工期。但当大家明白你的估算更准确时，也会更信任你。

Step 4：发布后评审上期时间估算

复盘还挺痛苦的，但是回顾能让你在下一次做得更好。每一个实际与预期时间不匹配的项目都发生了什么，找到原因并改进它。

总而言之一切在于沟通。提前沟通、经常沟通，了解彼此的日程和需求变更。

跟 PM 等相关参与者的沟通也能让对方提供可能会影响你估算的重要信息。一位设计师可能会说这个动画需要一周工期，干脆砍掉不要了。另一位 PM 也可能补充说这个原型只是对用户进行研究的而已，这次迭代不用处理太多 bug。

对于工程师来说，不要做不切实际的更短工期的妥协，开诚布公更显专业。对于 PM 和其他人来说，尊重这一估算可能需要一个过程，但要知道光靠唠叨是不可能缩短工期的。

项目时间估算不容易，唯有善于沟通、有同理心以及确定功能优先级才可以。

回答于 2019-09-11 08:43:50

程序员一定要懂得写烂代码，一定不能把项目写得太好，要留下坑，一直有bug改，不然做完项目你就失业了。

回答于 2019-09-11 08:43:50

这个要跟项目的目的和范围有关，其次是项目在需求阶段的规划和分解，如果好的项目经理和主程基本就已经可以预估开发时间了，偶尔有延后，稍微加个班都能解决，永远delay的原因是没有分解到位，开发的点不明确，缺乏技术认知，缺乏对关键流程或者需求的明确说明，缺乏关键用例或者故事