作为产品经常会跟开发工程师一起估算项目进度。无论怎么前期估算时花费多少时间去沟通需求和进度，项目最终还是会遇到两种结果：1. 项目延期、2. 项目严重延期。

更绝望的是在你跑去质疑对方进度不靠谱的时候，对方总是能义正言辞地说：“你又不早说！”，“我怎么知道啊？！”

天啊，那我们到底什么问题没有早说？我们来聊一聊日常软件开发估算进度不靠谱的原因。

目标理解的不靠谱

节日临近，老板让小明开发一个节日活动，并且声明此次活动时间紧、任务重，是本月度是否能达成销售目标的关键。在听完老板的介绍后，小明对本次活动的需求胸有成竹，并承诺一定按时完成任务。

于是，小明找到了开发小程同学讨论项目进度问题。在经过一番需求讲解之后，小程表示已经完全了解需求。

小明：好了需求就是这样，那开发大概需要多长时间？
小程：3天搞定。

3天后。小明兴致勃勃的找到了小程。小程正在和其他同事讨论其他问题，显然是已经完成任务了。

小明：活动开发完成了吗？
小程：搞定了。
小明：让我看看效果怎么样？
小程：还没最终部署上线呢。
小明：不是说3天搞定的吗？
小程：是啊，开发3天就搞定了。只要测试部署一下就可以了。
小明：（有些急了）我们项目要3天内上线的啊！
小程：你又不早说！
小明：……

进度预估不准确的一个大原因是来源于彼此对任务目标理解的不一致。做为一个只负责开发环节的开发人员，往往只从一个环节去理解任务的目标。你理解的目标完成是功能上线，他理解的目标完成是开发这个环节完成。

解决这个问题，首先是作为产品，我们要理解项目开发的各个环节和步骤。开发完成后，还有测试、上线等环节。有必要时还需要跟测试、运维等部门沟通。给开发后续的各个环节预留足够的时间。

正常在项目上线前都应该设置一个标准，并以此作为上线的条件。例如规定功能上线必须具备下列要求：

• 关于测试验收：

1. 测试用例全部执行完毕。（如果有测试用例的话）
2. 缺陷值小于10，无遗留重大问题。（缺陷值计算不同公司不一样，在这里不展开）
3. 所有缺陷回归完成。

• 关于文档（如果有的话）：

1. 需求文档等必要文档更新完成。
2. 用户手册更新完毕。
3. 维护手册更新完毕。

还可能有其他不同的检查项，不同的公司有不同，将这些作为每个功能上线的checklist，并指定每项确认项的责任人跟踪完成，这样就不存在大家目标不一致的问题了。

在大型公司，重大功能的上线必须有产品负责人、开发负责人、测试负责人、运维负责人等会签后才能上线，也是为了保证避免某一个环节掉链子了。

需求范围的不靠谱

产品发展到了一定的阶段，需要加入用户体系。在征得老板同意后，小明决定在产品在加入注册登录的功能。小明又找到了小程，并讲解了功能的背景。吸取了上次的教训，小明这次决定换一种提问方式。

小明：这个功能要开发、测试到上线要多少时间？
小程：开发2天，测试2天，上线1天，总共5天。

5天后，小明又兴致勃勃的找到了小程。得知小程要演示功能时，小明很开心，这次功能终于可以上线了。

小明：功能完成测试完成了吗？
小程：搞定了。
小明：咦！怎么没做忘记密码功能？错误提示也没做？
小程：你不是做注册登录吗?
小明：（有些着急）是啊，注册登录功能包括了错误提示、忘记密码等功能啊！
小程：你又不早说！
小明：……

需求范围理解不一致是导致无法完成进度的一大原因。而对需求范围理解的不一致的高发地则是在一些所谓约定俗成的功能上面，特别是在非主要流程和异常流程上。就比如错误提示功能，小明觉得注册登录功能当然要包括错误提示，而小程觉得你没说我当然没做了。

解决这类问题首先是在讲解需求的时候全面的讲解。另外在提交文档时产品除了需要考虑正常流程以外，还需对异常流程或非主要流程进行说明。

在需求说明时，可以考虑增加验收标准。举个例子，登录功能的验收标准：

1. 点击登陆后，密码正确，跳转到主页。
2. 点击登录后，用户名或密码不正确，提示错误。
3. ……

对于整个产品约定俗称的功能，可以做成全局的说明。这样随着项目的推进，就不用反复对一些细节进行说明了。例如，加载时需要有加载动画，表单填写错误时需要错误提示等等，只需要做全局说明，并在整个项目达成共识就可以了。

外部依赖的不靠谱

随着业务的继续推进，在累计了一定的用户之后，老板决定在产品里面引入商业模块，首当其冲的是开发支付功能。小明综合了各种情况后，决定使用第三方支付。小明又找到了小程，并对支付功能的需求进行了讨论。

小明：这个功能要上线要多少时间？
小程：我看过API文档了，就几个接口调用而已。加上测试上线一共5天。

5天后，小明找到了小程。小程看到小明的到来，这次有点不淡定了。

小明：怎么了，是不是进度延期了？
小程：是啊，别提了。申请接口才刚刚提交，现在还下来呢。功能是开发完成了，没办法测试啊。
小明：你当时没有跟我说还需要申请接口的啊。
小程：我怎么知道啊？！
小明：……

对于外部依赖的识别是比较考验产品和开发经验的。而且项目经常在这种事情掉链子。万事俱备了，只缺一个外部审批就可以搞定了，就是这个审批拖了整个项目的进度。

在这种多个子任务，而且相互之间有依赖的情况下，可以使用甘特图来标识出子任务之间的依赖关系，并识别出关键路径。

类似这个项目支付接口的开通必须先认证账号，开通了接口才可以进行接口联调。而且子任务的完成时间和风险来看，账号认证这条路径是完成时间最久而且风险最大的路径。我们用甘特图表示如下：

通过甘特图我们基本上能看到，推动账号申请和接口联调是完成是这个任务关键的路径，一旦这个路径上的子任务出现了延期，整个项目就会延期。

难度预估的不靠谱

项目逐步累积了大量的用户，小明决定在产品中加入IM功能，方便用户和用户之间沟通。小明又一次找到了小程，考虑到产品进度比较急，双方决定直接使用第三方的IM接口。

小明：这个功能上线要多少时间？
小程：我看过他们的API文档了，总体5天，包括开发3天，测试2天，开发1天。
小明：接口需要额外申请吗？
小程：不需要，开通缴费后就直接可用了。

5天后，小明找到了正在愁眉苦脸的小程。

小明：怎么了，遇到问题啦？
小程：调用他们的API接口，各种报错，现在跟对方交流呢。
小明：你不是说只要简单调用API就可以了吗？
小程：我怎么知道啊？！文档是那么写的。可是一调用就出错。
小明：......

对项目难度的预估比较乐观是开发进度预估不靠谱的一大原因。当使用第三方系统时、当涉及多个系统模块对接的时候、当修改不熟悉模块的时候……总之，只要是开发工程师不熟悉的环节，却又说得十分肯定的时候，就是一个风险点。

对待这类有风险的环节，可以求助熟悉系统的工程师进行评估。对于第三方系统，也可以在系统开发前做预研究，先对接口进行摸底再进行评估。

后记

软件项目是个复杂的工程，其涉及到的环节比较多、涉及的岗位也比较多，无论哪个环节出了岔子，都有可能导致开发进度的延期。据不完全统计，80%的项目都存在着进度延期的问题。

小明和小程的故事会在各种项目里面持续的发生，这里并非需要分清谁对谁错。很多时候也并非程序员预估不准确，而是来源于需求方和执行方双方沟通上的问题导致。更多的还是来源于项目管理的不规范导致的。

软件开发经过这么多年的发展，也总结了很多先进的经验。从软件工程时代到现在的敏捷开发时代。首先要选择适合自身团队的开发模式。其次最重要的还是能否在一次次错误中吸取经验，能否建立一个自我改进的机制，在失败中不断完善开发流程。

最后，此文并不是为了调侃程序猿兄弟。只是将站在一个项目组织者的角度对软件开发的一些事情进行总结。更多的是想探讨进度估算不准确的原因和改进方法。

最最后说一句：文中如有冒犯，敬请谅解。