遇到这种问题，首先寻找根因，才能有的放矢。笔者经历过的项目通常都有以下几类情形：

 1 、需求层面

- 产品PRD质量不高

- 产研前期沟通确认不清晰或有遗漏

- 需求变更

- 隐藏信息需要显性化，即你以为大家都知道的，其实大家不知道（比如有的人只能看到当前需求点，有的人可以看到需求点背后的影响面）

 2 、任务拆解层面

- 任务拆分粒度粗，常见的是按照需求粒度去拆解，但是需求粒度不代表实现粒度，一般实现粒度比需求粒度要细

- 任务依赖方未确认，主要表现在实际的情况和你以为的不一致，未确认开发环境是否支持

- 任务工时预估不准，低估需求复杂度，高估自己的处理能力

 3 、技术方案层面

- 没方案，研发直接开干，黑盒测试

- 有方案，但方案很粗，看不出来服务具体逻辑，全靠脑补，但是每个人脑补的结果根据对需求理解的不同，结果也不同

- 方案评审质量不高

 4 、开发实现层面

- 主开发深陷技术细节，对整体实现内容把控力弱（一般主开发=PM，除非是很大项目的PM不参与开发，主要做统筹）

- 风险未识别，到了截止日期，未完成的事项未及时同步

- 开发周期内其他临时紧急事项占用时间高，导致整体进度延后

- 冒烟不细致

 5 、测试层面

- 冒烟用例比例不够，对到不同成熟度的团队，冒烟用例是不同的

- 测试用例的细致度不够

- 测试环境不稳定等

对到以上问题，逐个拆解破局，是事没做到位，那就抓事，定节点，追过程，是人没做到位，那就辅导人，把能力提升上去。

作为项目参与方，过程中需要协同其他人一起去完成任务，信息透明化是一项很重要的能力。只有将你的需求透明化，别人能很清晰地感知到，才能更好地去配合你成事。如果事情都说不清楚，配合你的人需要不断地去猜你的语意，效率产出就会很低。