易讯网络知道,产品经理最头痛的事情是项目延期，因为这就意味着产品没有如期投入市场，意味着要开始加班加点赶进度，意味着可能加班加点赶出来的产品存在大大小小的BUG，你原先设想的XX功能，XX体验没办法实现，你的KPI可能会有危险，你的年终奖可能泡汤...

为什么会延期呢？易讯网络来帮大家分析分析,除了那些我们无法改变的客观原因之外，还要关注哪几个问题：
1）前期需求讨论，UI评审时间过长，压缩了后续开发时间
有的时候我们会陷入对某个需求细节、UI细节的反复讨论。特别是在UI评审的时候，对于设计大家都有各自审美观，有的人喜欢留白，有的人喜欢紧凑一点，有的人觉得页面丰富一点好，有的人觉得简洁干净一点好。众说纷纭，好不容易确定下来了，时间也没有了。留给开发的时间自然就变少了，但是工作量可一点都没变。开发们也是人，再怎么加班加点也不可避免出现延期和代码质量下降的问题。
>>>面对这个问题，产品或者设计师应该要：
首先，提高自己的专业度。这是你的领域，你要展现你的专业说服他人，而不是被老板或者其他人带着走。你要有自己清晰的认识，为什么这样做？为什么不那样做？这样做的目的是什么？你的依据是什么？准备多套方案，说明你个人最推荐的方案是什么？次推荐的方案是什么？最不推荐的方案是什么？***要有理有据，如果有数据支持，就展示你的数据！
其次，要有严格的截止时间点。任何的讨论如果没有时间限制，那就不会有结果。你组织评审或讨论的时候，明确地告诉大家我们***要在某个时间点达成一致，如果没有达成一致，那就使用我的推荐方案；
第三，明确重点，不要在细节上过多纠结。有的功能或者设计点，并不是最重要的，对用户影响比较小，我们就不要在这个上面浪费时间。集中力量放在重点流程和核心页面上。有些时候，你留白多少，用户其实并没有感知。那为什么我们要在这样的事情上去纠结呢？我一直认为在这些问题上，只要不影响用户对产品的使用流程，不会让用户在使用过程中产生歧义或者误解，没有必要去纠结。如果你的老板***要这样改，那就改。我们的焦点应该始终放在产品的核心流程上。
2）实际开发过程中前松后紧
这个问题在实际工作中也经常碰到。在开发周期的评估时候，节奏安排不当。前面慢悠悠，后面发现哇靠时间没有了，拼命赶进度。
为什么会这样呢？我不是技术出身，但是开发同学交流下来，主要是对风险点评估不充分，需求理解程度不同。
对风险点评估不充分，这个和需求理解程度，个人能力都有关系。没有充分理解需求或个人经验能力没有达到***程度，是不会或者很难预见风险点的。我的建议是开发在评估开发周期的时候，可以：
将需求拆解成细化的用例。就是开发完成这一个需求，需要涉及到哪些开发工作，需要涉及哪些后端接口，需要涉及到哪些模块联调，需要测试如何测试等等。拆解成这样的用例，既可以把开发周期更细化，也可以发现一些风险点；
各自评估，集中讨论。将需求拆解成用例或故事要点之后，开发同学可以按照各自情况提出自己的预计时间。如果同一个功能，A的工期是1个工作日，而B可能觉得要5个工作日，两者之间相差较大。那这时候就要进行讨论，为什么会这样？是否有风险点没有发现？还是谁的技术方法有问题？这样一来，大家都可以了解彼此的想法，互相弥补自身的思考盲点；
3）需求变更
需求变更，不仅对于程序员来说是一种痛苦，对于产品经理来说也是。我们都希望需求确定之后不要再变更，但是现实总是很骨感。毕竟市场和需求可能是变动，毕竟前期调研再充分也可能存在误区，现在变更总比开发完成之后再改来的好。
但是变更需求极有可能影响原定的计划，我们又该怎么办呢？
***，冷静地判断变更需求的优先级。这和我们评估需求优先级一样，不重要不影响用户使用的就延期安排；重要的自然往前排。这点就不赘述了；
第二，寻找合适的解决方案；和开发同学充分讨论，实现新需求的方法有哪些？找到能解决问题同时时间成本***的方案，尽量将延期影响压到***；
4）只关注自己的任务
这其实是很要命的一点。只关注自己的任务，忽视了上下游相关业务模块的联系。吭哧吭哧开发完了，发现和XX模块对接不上啊！这个接口设计前端用起来很麻烦啊！于是乎，我们又一起重新写一遍。延期的红色警报又要响起来了。
解决这个问题，我们可以试试：
阅读需求文档时，请不要只看自己负责的模块，把所有需求都过一遍，理解需求的上下逻辑关系；提前和相应的同事沟通技术方案。这一点全靠自觉，毕竟不这样做***返工的肯定有自己。
开发负责人可以在正式开发之前组织大家集中花一个时间段，把需求疑难点，需要彼此配合的拿出来讨论。磨刀不误砍柴工，这会让大家后面工作的更有效率。