一、需求阶段
1、产品也不知道自己想要的是什么
2、产品即使知道自己想要的是什么，也没法给出具体的业务细节，如用户输入应该限制在多少位，是否进行存在性或唯一性校验等。
3、即使产品知道自己想要的，也知道业务细节，但是也没法跟开发人员衔接上，往往都是会有误差。
4、即使有幸，产品跟技术衔接上了，也很难在以后能记住这些当时的共识。
5、即使为了防止以后的遗忘，增加了文档说明，也难以保证文档能够记录的准确，想起我的第一个Boss说的话：一句中国话，100个人都100个人的理解。
二、开发阶段
1、只有Team Leader自己知道产品想要的是什么，手底下的兄弟们并不知道
2、即使通过分析需求，讲解需求，让兄弟们了解了需求，每个人也只是最关心自己负责的系统以及周边的模块
3、即使让大家知道我们的目标是什么，也难以保证在每天的项目推进中，每个人的开发方向不会跑偏。
4、即使是通过站会的形式让大家知道当前的进度并调整方向，也难以保证大家的理解都是一致的。
5、即使大家的理解是一致的，并且通过规范模块间的接口，也难以保证每个人的代码不是偶在重复造轮子
6、即使是每次使用到的轮子，将杂质尽可能去除了，只剩下一个最小公因子模块，也往往是因为不符合case场景被忽略。
三、集成阶段
1、经常经历的事情是第一轮的集成实际上就是各个模块的单元测试。
2、即使单元测试通过了，也会因为接口职责的不清晰，导致了功能的缺失。
3、即使是经过几轮的集成测试，把职责划清了，理顺了，也会因为部署环境的问题导致时间损耗。
四、发布阶段
1、发布当天往往是跟过年一样，有的人激情澎湃，有的人心惊胆战。
2、往往会因为生产环境跟测试环境不一致，导致发布失败。
3、即使环境一致了，也会因为配置参数不一致导致发布失败。
4、即使配置参数一致了，也会因为依赖系统跟测试环境不一致，导致出现一些莫名其妙的Bug
5、即使是发布成功了，没有什么异常，也会在运行几天后，出现一些发布当前没有覆盖到的bug，比如说第三方调用失败。
五、迭代过程
1、如果是产品第一次发布，那么恭喜你，你很幸运，第一次做想怎么做就怎么做，能实现功能就行。
2、即使不是第一次发布，如果从第一次发布到现在这次迭代发布都是你参与过的，那么也恭喜你，你也很幸运。
3、如果你是半路杀出来的程咬金，开始接收这次发布，那么我也恭喜你，你中奖了。
4、半路接手的系统，甭管交接工作做的怎么到位，都不会细致到每一句代码的处理逻辑，特别是条件表达式判断的逻辑。
5、经常是你觉得你按照新的需求修改了代码，进行了版本更新，却不行踩到了另外一个雷。
6、如果这个雷是在发布的时候，或者发布之前爆炸，那么你也很幸运，你还有能力捂住这个雷。
7、如果你以为你这次版本迭代是成功的，美滋滋的准备等待老板的奖励时，却等来了老板的电话：系统被领导发现Bug了。结果你查了半天，才查到问题原因是你踩了一个雷，那么恭喜你，你躺枪了。