工时估不准的，往往不是哪个功能难，是那几个你说了不算的环节

工时表上每一行都估了，最后超的往往是那几行：设备联调、第三方系统对接、供应商对接。

不是开发慢，是这些环节不归你管。对方什么时候有空、接口什么时候给、设备什么时候调好，你说了不算。办法是把这三处单独列出来，不和功能混着估；对方要交什么、哪天交，写进计划。

这篇讲 4 件事：需求怎么从蓝图变成开发任务，工时怎么拆，测试分几轮，开发期间来了新需求谁来接。

一、开发需求从业务蓝图拆，讲完再开发

蓝图签了字，是业务的语言：流程、岗位、单据。开发看不懂业务语言，中间要有一个人翻译。

我们是这样走的：

1. 产品经理按业务蓝图设计功能逻辑：蓝图里的每一个流程节点，系统要怎么判断、怎么处理
2. 出产品设计文档：写清每个功能的逻辑、页面、字段、规则
3. 给开发讲一遍：产品经理当面讲解，开发听懂了、问清楚了
4. 再开发

第 3 步最容易省。文档发过去就算交接，开发按自己的理解做，做出来和蓝图对不上，到测试才发现，返工的时间比讲一遍长得多。

二、开发工时按功能点拆，再和项目经理排计划

工时由开发经理来拆。按功能点，拆成前端、后端、接口等几块，每一块评估：

• 开发时间：要几天
• 完成时间：哪天做完
• 开发人员：谁来做

拆完了，开发经理和项目经理一起商量开发计划和周期。项目经理手里有上线节点，开发经理手里有人和工时，两边对过才是能执行的计划。

立项那篇讲过，功能清单每一行标「复用」还是「改造」。复用的主要是配置，改造的才要这样拆到前端、后端、接口。

最常估不准的，是三处不受控的环节：

• 设备联调：设备方的现场调试进度，决定你什么时候能联调
• 第三方系统对接：对方系统的排期、接口文档、测试环境，都在别人手里
• 供应商对接：供应商那边的系统和人，配合节奏你管不了

功能本身再难，人和时间都在自己手里，估得出来。这三处要等别人，最后超的常常就是这几行。所以要单独列出来，别和功能混着估；对方要交什么、什么时候交，写进计划里，最好在立项那篇讲的「前提和假设」里也写一笔。

三、系统测试分四轮：内部先过，再交业务用户

我们的测试分四轮：

1. 单元测试：开发自己测，每个功能单独跑通
2. 集成测试：几个功能、几个系统连起来跑
3. 设备联调：和立库、AGV 这些设备一起跑
4. 用户测试：业务用户在测试环境，按真实业务做模拟测试

顺序上有一条规矩：内部测试人员先测完，没有阻塞问题了，再交给业务用户。 业务用户本职工作很满，抽时间来测，一上来就卡住、点不下去，下次就不愿意来了。内部先把路扫干净，业务用户进来的时候不会被卡住。

四、开发期间来了新需求：先过项目经理

开发做到一半，业务方又提了一个新需求，常见。我们的做法：

• 先交项目经理评估：接不接受，算不算变更
• 接受了，再谈排期：插在哪、挤掉什么、节点要不要动
• 开发人员不直接对接业务方

最后一条最要紧。开发直接接业务方的需求，一句「顺手加一下」就进了代码，没评估、没排期、没记录。加多了，工时表就不准了，节点也就跟着拖了。

---

你们的开发，会直接接业务方的需求吗？