最近在读《人月神话》这本书。
发现大部分task延期和研发关系不是很大，技术为业务服务，但是偿还不了业务债。
焦油坑的概念源自于挖掘坑井时的一种不幸状况。当挖掘坑井时，首先会进入表土层，进展颇快。但接下来遇到了沥青或泥浆，这种材料比较粘稠，导致进展明显减慢。在开采坑井时，无论是多么小的焦油坑，都会导致进展受阻。
在软件开发中也存在类似的问题。开发项目的初期，团队可能会进展迅速，但随着项目的推进，可能会遇到一些没有预料到的问题，如技术难题、人员调整或需求变更等，导致开发进度的延误。
那么最近实际工作中，确实遇见了"焦油坑"。
在做”消息定时发送“功能的初期，我快速地完成一些基础功能的开发，如定时任务配置，消息模板等。但在开发过程中，我遇到需求描述不清的问题，这就需要投入大量时间和资源来解决。这个问题就像是一个焦油坑，阻碍了项目进度的进展。
回顾一下我接手这个task的过程:
1. 初期，我知道是个什么样的功能，快速的了解了相关的技术栈
2. 下一步，架构抽象 -- 实现接口
3. 业务需求不清楚 和 需求变更 导致功能延期
4. 和测试，产品沟通，整理需求文档，达成一致性
5. 回到step2去重构相关功能
很明显，假设我的预估成本是 程序*编程系统=3n，我给出的假设成本是 6n ，但是实际花费的成本是 n*3*3 = 9n
主要的问题，可能是出现在需求的传递上，或者换句话说，需求文档的缺失。
需要什么样的文档？
不同对象需要不同级别的文档，以下总结仅针对 产品 -- 研发 这种传递来说。
使用程序：对功能的一段描述性文字，大部分需求描述只是描绘树叶和树皮，没有描述森林的图景。
- 1. 目的：功能是什么? 开发此功能的原因？
- 2. 范围：有效的输入范围，有效的输出范围
- 3. 输入-输出格式：保证确切和完整
- 4. 操作流程：此功能的正常操作流程和异常操作的处理
- 5. 精度和校验： 预期的结果，如何进行结果校验？
注：流程图不是必要的，如果总结性文字足够精炼。
或者更实际一点, 我给出一份通俗的文档描述的案例
- 1. 用户想获得定时提醒的功能，工作流中，完成A节点后，通知B节点相关的人继续处理
- 2. B节点相关的人是 X,Y和Z类型的角色，消息通知将会告诉X，Y角色要做什么
- 3. 通知的输出是：时间，内容，节点A的若干信息
- 4. 功能操作中，由任意类型的角色配置。每一个列选项的输入范围是（）
- 5. 当用户在APP上收到消息通知后，此功能完成。
- 6. 若出现程序集宕机或者升级导致当前时间点无法推送消息，处理方式为（）
- 7. 附：流程图（包括异常分支处理）
- 8. 附：歧义名词的注解
- 9. 附：此模块相关功能可能出现的影响