文章目录 我们可以按照如下步骤进行开发周期的评估：1、当他们提交了需求变更后，首先要做的就是确认需求2、把需求整理成接口3、由初步合计时间，得出最终时间4、把最终时间合理分配到各个接口的开发时间中
一般情况下，开发一个产品，可以分解为：①需求确认；②原型设计；③UI设计；④程序开发；⑤测试&验收；⑥上线，这几个步骤。
我目前讨论的项目开发周期，仅仅是站在一枚程序猿的角度，也仅仅只是评估第四步骤（程序开发）。
由于我在公司接手了一个半外包的项目，给xx保险公司做saas系统，这是一个已经运行了两年的系统，但是他们不时就提需求变更，我目前已经做了四五次需求变更。每次需求变更最让我头疼的首先就是开发周期的评估。评估时间短了吧，开发就会非常赶，而且我们就会吃亏；评估时间长了吧，他们公司也有开发人员，会说我们坑人。那如何才能做到一个好的开发周期的评估呢？
谨记：开发周期并不是拍脑袋想出来的，必须是有理有据计算出来的。
我们可以按照如下步骤进行开发周期的评估： 1、当他们提交了需求变更后，首先要做的就是确认需求把概念不清楚的、逻辑业务不清楚的都要理清，这对我们开发而言非常重要。这个步骤可以和公司的需求人员，以及第三方的业务人员（客户方）一起讨论。理清需求后，还有一点很重要，就是标记哪些需求是难点；
2、把需求整理成接口我们现在的服务都是提供的RESTful接口，服务与服务之间都是通过接口进行关联，前后端也是通过接口进行数据交互的。例如我们可以做成如下的表格：
注意：每个接口的开发时间，应该是正常情况下可以做完的时间。个人建议为大于等于1的整数。千万不要说，这个小功能很简单，我10分钟就搞定了，要知道“世界上没有什么需求是简单的”，虽说你真的可能只要10分钟，但是也请写一天。万一别人问，你就说我要上线、打包、发布、测试，这都是时间啊。
情况1： 如果你觉得此次开发难度不是特别大，初步合计时间已经足够了，那请把初步合计时间 乘以1.2得出最终时间，不要问我为什么，最少必须乘以1.2，这是机动时间，这是“救命的时间”，万一你出现一个你意想不到的问题、万一开发过程中你负责的别的服务出了点小问题耽误了时间、万一你开发周期内生病了2天…
千万不要说没有这些万一，如果你开发截至时间到了，你去找理由，你说我生病耽误了两天，你觉得合适吗？别人公司领导已经和下面的人说了，xx日期后就会增加这个功能。然后时间到了，领导去和员工说，“我们外包的开发这几天肚子疼，耽误了两天，上线推迟两天”，你觉得合适吗？更何况，这些需求变更都是要签订合同的，违约可是要罚钱的。
情况2： 如果你觉得此次开发有些难度，可能会出现未知的问题，那请把初步合计时间 乘以1.5
情况3： 如果我们的客户是那种类似银行企业的大客户，这些大客户对开发周期要求特别严格，一旦违约将面临巨大的罚款，而且他们不缺钱，那请把初步合计时间 乘以2
4、把最终时间合理分配到各个接口的开发时间中下面以乘以1.5为例：
编号接口名称描述状态难点开发时间（人天）1xxxxxxxxx新开发是52xxxxxxxxx修改否33xxxxxxxxx新开发否2初步合计10最终时间15但是我们不要把中间步骤告诉客户，更不要把初步合计告诉客户，我们给客户的时间统计如下：
编号接口名称描述状态难点开发时间（人天）1xxxxxxxxx新开发是72xxxxxxxxx修改否43xxxxxxxxx新开发否4合计15在上面的过程中，如果得出的最终时间比较大，很难做到“神不知鬼不觉”，我们还可以多想一想，看看除了上述接口还有什么是可以考虑，这些东西可能不是接口，只是要做一些小小的改动。都可以写出来，并且加上开发时间，例如连写个sql脚本，都可以写“调整数据库表结构，2天”。总之，一定要让人看起来觉得还算是合理。
如果最终的开发周期提交上去，别人说，你这时间太长了吧，这么简单的功能也要做4天？你不用说太多话，直接丢一句“你行你上啊”。他肯定不会说他来的，因为他熟悉项目也是需要时间的。
我们程序员其实是弱势群体，一旦在自己写的开发周期内没有完成，客户、产品经理、上司，都只会去责怪我们程序员，才不会去理解我们的“借口”，“自己规定的时间，自己都完不成！”。但是我们程序员在开发的时候，不可能只做你那一件事啊，我们可能同时负责好几个项目，例如我就同时负责7件事，任何一个服务出了问题，我都要去检查：问题重现、测试是否是bug、检查日志、分析问题、甚至是上hotfix版本，这些看似简单的操作，通常一耽误就是大半天。
在预估计时间上乘以1.2或者乘以1.5，绝对是有必要的。如果产品经理、或者程序员的上司看到这篇文章，也请理解我们。