‍项目进度把控肯定是每个PM的必修课，但大多数产品经理都没有足够的重视和经验。文章通过将结合笔者经验，概述项目延期的原因及解决方法。

首先，谈一谈项目，大家对这个字眼应该熟悉吧，不管是具体实操还是面试过程中，都会有项目这个词汇出现。

那什么是项目呢？

其实很简单，项目是为了创造独特（或符合公司/市场需求）的产品、服务或成果，而进行的临时性工作。项目有清晰明确的开始和结束时间，在目标时间内，启动→计划→执行→控制——收尾，就是一个项目的生命周期。

你是否有这样的经历？

安身于一家中高型企业，毕竟不是大型或职能岗位建设很齐全的企业，职能并没有那么细化，作为一个小小的PM，担着分配到自己的业务线，涉及具体项目领导找你对接询问。

但是碰上项目屡屡预期的话，那种对上无奈，对下的无语且愤懑，中间对自己的小委屈， 真是闻者呵呵，听者心累——明明是开发过程中或测试过程中bug多或者各种非PM原因问题导致项目延期，但还是免不了领导一顿bb。

不过也难免，毕竟在这样的环境下，PM是项目的发起同时也是领头人，以结果为导向看待问题。

那…我们该如何高效地交付项目呢？

1. 明确协同职责
2. 统一迭代节奏
3. 过程有效透明
4. 站会三讲：完结的内容，存在的问题，怎么解决或需要哪些帮助
5. 过程高效决策

回归文章主题，该如何有效防止项目延期，首先需要明确可能造成项目延期的原因：

01 UI图未经过评审或成品界面不达标，造成返工导致延期

实际生产中存在这些问题，UI图输出后没有经过评审直接转到技术进行开发，过程中或成品后发觉此时再做调整修改，难免延误时间导致延期。

这类操作一般出现于首次带队的产品小白，前期别埋坑，UI评审的意义不容小觑，助于团队成员加深需求理解，沟通交流，同时也能给设计提供更多不同思维的灵感源泉。

当然，也可根据产品或公司领导对于项目流程的看法，不把UI出图及评审调整的时间算在项目内，单独计算时间，正常流程是设计图完成后是进行UI评审，没问题后转接产品及开发测试团队，因UI图的问题导致延期，解决方案如下：

1. 提高设计团队的专业度，UI图产出后即时进行评审

注：上图的项目初期、中期、后期可译为”第一感觉、相对来说、细节挑刺儿”

2. 明确设计图可交付的时间

产品需要跟每个需要合作的部门或同事沟通好，如果项目包含UI设计出图的流程，明确开始及最后的完成时间（即评审后调整完毕可交付的时间）

3. UI评审时明确重点，不必太过纠结细节

标题概述很明了，如果单单因为页面留白或者按钮大小圆角与否之类相对无关紧要的问题争辩不休迟迟敲定不下，此为因小失大，小问题后期优化迭代，不占用团队时间；

4. 项目开发过程中按时间节点查阅UI效果，如有问题及时跟进调整，避免成品不达标导致最后返工

02 实际开发过程中前松后紧，没hold住导致延期

工作中这个点比较常复现，例如公司待久的一些技术员工难免轻视公司制度，尤其是在制度并不完善或者自认为早已对公司业务轻车熟路的情况下，实际开发过程中如遇跨项目联调受阻…临近预计完结时间，加班加点熟悉其他项目组代码寻求解决方案，或团队整体氛围松散，导致项目延期。

况且前期轻松后期加班换调休 or money的类似行为，久而久之这种行为形成习惯，这也是很多企业定期换血，老员工数量占比较大的原因之一吧。

那么怎么解决呢：

1. 使用燃尽图节点设置，关注成员每个人的进度

燃尽图的纵轴可以是整个项目的剩余的任务，也可以是个人剩余的全部任务，用来观察项目过程中完成的实际工作量与剩余时间的关系，关注节点进度，如有异常及时沟通解决。

2. 需求优先级划分

需求优先级一经确定，将贯穿项目需求的整个生命周期，所有的资源将根据优先级被安排。分享几个划分需求优先级的方法如下：

（1）核心价值需求，影响主流程的需求，优化需求

例如本期项目核心就是优化下单流程，那么即买即付这个功能就是核心，登录注册即为主流程需求，如果添加oauth，则属于优化需求，评审项目时间，如果优化需求占用时间较多，即可迭代下一版。

（2）从开发及效果角度分析划分

（3）从使用频次和用户量分析划分

（4）根据业务或市场情况划分

（5）根据KANO模型划分

• 必备型：如电商类App，购物车、下单及订单管理流程则是必备型需求，最高优先；
• 希望型：如oauth，便捷登录注册的方式，符合大众用户简易使用操作的心理，属二级优先；
• 兴奋型：如百度地图语音功能，能触发用户感叹的点即为兴奋型需求；当然，创新的需求点需投入大量的构思、试验、研发成本，不鸣则已一鸣惊人，属三级需求（视具体情景而定）；
• 无差异型：不论提供与否，对用户体验无影响。针对这类需求，要避免投入，转战其他更有价值的需求。

3. 晨会

也称为早会、站会等，说法不一罢了，及时汇报项目进度，如有问题(产品逻辑or技术开发)及时抛出调整解决。

03 需求下发后只关注自己的模块，协接故障导致延期

如果仅仅关注自身的业务，那对自己来说不管是技术能力或项目全局的把控能力都不会有太大的提升，只有成长了才会有更大更好的平台发光发热。

再者，毕竟是大家一个团队，在同一家公司共事，共同努力做好一件事不香嘛~，期间的过程酸甜苦辣不都是一份经历一份成长嘛~，同时作为带队者：

1. 需求拆解

PM前期开需求评审会议的时候，就做好需求的拆分，按具体模块、功能划分，每一部分事无巨细讲述，逻辑清晰易懂、循序渐进贯穿本期需求/项目，如有与别的项目耦合关系或逻辑判断，着重讲述，让团队成员明白整体流程，以及最后需实现的成果，而后技术负责人按模块/功能安排具体开发人员。

2. 各自评估，集中讨论

开发人员拿到自己所需模块后，进行集中讨论（类似头脑风暴），毕竟业务/功能相互之间难免存在耦合，规定时间内理清业务，寻找与之前后是否存在相关联性，避免后期埋雷。

当然，需要开发人员熟练业务、自身能力及表达顺畅，相互之间较快得出估期结论。

3. 促进组内成员相互之间多交流沟通

大家一起讨论需求难点时，适当回应、多聆听、不打断、不做任何个人感情色彩评价，全程采取开放性的提问，让成员去思考，讲出自己的想法。

遇到逻辑问题或理解不通畅时不要争论，尽量把说话和表现的机会让给对方，聆听中抓取问题，设身处地站在开发或测试的角度去想他们提出来的问题，善于运用肯定式问句，引导对方思考，让对方不断认同。

如“你把这个逻辑想的有些复杂了，其实很简单，XXXX，你看这样是不是好理解一些或者更顺一些了呢？倒是你之前想的很不错，可以作为下期的优化点迭代一版”，如有好的想法加以肯定，每个人都需要被肯定。

04 估期时间偏差，导致延期

这是最重点的一个问题，百分之六十以上的项目延期就是因为预估时间出现问题，从而造成项目延期。

需求评审往往只预估了理想状态下的开发时间、联调时间、测试时间，忽略了一些开发上可能存在的一些难点，攻克、联调，再到测试或者测试出bug，修复半天找不到原因所在或修复所需的时间。

如涉及到B端产品，B端一般涉及到的数据流转非常复杂，有时候还需要与其他项目进行对接或接口的联调。

针对这种问题比较好的解决方法：

1. 采用Excel甘特图表

可采用Excel甘特图表记录时间节点以及具体每人按时间段需完成的需求点。

清晰展现估期时间段，一但发现某个需求在既定时间内延期，及时找出问题解决并判断后面的需求是否可能遇到类似的问题；

2. 需熟悉业务流程及逻辑

项目完结后，每人提交一份输出报告（类型可以是文档、版本代码、原型等），目的是让团队成员明确每个部分/需求/项目之间的关联，对现有逻辑有较清楚的认识。

3. 不可忽略联调及测试改bug时间

技术难点不可控，so 适当预留时间，便于及时调整解决。

4. 适当”留一些余地”，或可替代性方案

适当的预留一些时间，如上所说遇到一时难以攻克的问题，需要时间或及时寻求一些帮助去解决。

对PM来说也是如此，作为带队者，应准备可替代性方案，防止因技术难点或其他原因可能造成的逾期及风险预警。

05 深入后发现对现有业务耦合或造成改动过大，开发时间不够导致延期

这个问题跟上一个问题差不太多，前期尽量做好相应的一些准备，埋头吭哧吭哧开发了半天，才发现和现有XX模块对接不上！这个接口/方法导致现有H5页面出问题等等情况！于是乎，又得重新搞，此时延期的警报即将吹响……

1. 用鱼骨图分析潜在问题

项目前期可用鱼骨图分析一波，对项目正常完成可能产生威胁的因素进行评估，以便逐个击破解决问题。

2. PM需要足够熟悉项目

PM对项目的熟悉程度，一定程度上决定项目是否能够顺利进行，不了解的状态盲目规划制定需求，不是事倍功半就是夭折，延期还算轻的…

如果是新接手的项目，查阅PRD文档及原型，或跟测试人员沟通，尽快熟悉项目内容。

需求评审时应及时提出相关的逻辑关联辅助开发进行判断。

3. 做好需求拆分规划，根据公司或市场情况，及时调整稳步迭代

可根据上文需求优先级划分的方式进行后续版本迭代规划。

针对每期需求，拟可替代性方案，如一个连环相扣的判断逻辑略复杂，实现较为繁琐，占用时间较多，此时有一个简化的方案可替代，既满足使用，又不会导致延期，记录当前问题后期迭代调整也不失为一种解决方案。

06 需求变更或新增，导致延期

需求临时变更或者新增应该是最常见的情况了吧。

案例情景：

项目1期的整个周期为1个月，有3轮环境及功能测试。

当第3轮测试结束时，即将进入灰度发版阶段，领导此时给出大客户反馈并要求按客户的反馈意见修改。

技术了解后给出改动的地方涉及App端、H5及后端校验逻辑等方面，调整的话3个端均得做相应改动，再投入时间及测试成本……

首先需PM进行一波尽量带动领导思维的冷静分析，明确解决该问题所需要的成本及时间，是否属于重要且紧急的bug，是否必须解决。

如果仅仅是一个优化并不影响大面积使用不会造成系统崩溃，可否延后到下版迭代。

一波苦口婆心的劝说无果，那就转身深呼吸，低喃一句佛曰：“阿米豆腐”，再来一波面向开发大佬们的演说~

1. 冷静判断需求优先级（上文第2点有具体阐述）

• 核心价值需求，影响主流程的需求，优化需求
• 从开发及效果角度分析划分
• 从使用频次和用户量分析划分
• 根据业务或市场情况划分
• 根据KANO模型划分

2. 主要跟开发做好沟通

主动找开发沟通，产品岗在项目或团队中起的带头作用，做事态度积极，处好人际关系利于工作，当然对自身做事也有益处。

与开发沟通心态平和，站在对方的角度给予一定程度的理解，但如果是紧急且必须修复的问题需合并上线，商讨解决方案，尽量将延期时间压到最低。

07 开发/测试对需求理解有偏差，返工导致延期

可能你的成员是有不同小组或项目组临时抽调出来组建的团队，团队成员之间也不熟悉，同样，新同事进入团队也需要一个熟悉的过程，此时，沟通显得尤为重要！

沟通在任何团队任何项目中都是重大问题，自认为一个小的逻辑上的理解偏差可能就会造成实现的成果截然不同——开发记得是这样的，测试记得好像是那样的，造成项目在成品的时候出现偏差。

情况好的是测试理解不准确，不好的话那就得返工重新投入开发、测试时间成本。

同时也会造成团队成员之间相处的矛盾障碍，对之后的交流沟通埋雷。so~

1. 仔细讲明需求，保证团队对需求认知一致

需求讲述清晰明了，目的明确，评审时带动团队成员，从核心出发，按模块，逻辑，细节逐步讲述。

只有团队所有成员对需求认知一致时，才能保证工作高效的完成，达到事半功倍的效果，同时也有助于团队协作氛围提升。

PRD文档整理详细，逻辑清晰易懂，流程/结构图准确无误，应包含的内容：项目名称、版本历史、目录、文档介绍、需求目的、需求模块概述、需求明细、相关结构图、逻辑说明、全局功能说明、详细功能说明、影响范围说明、非功能性需求、注意事项、上线流程等。

2. 沟通

沟通 —— 沟通能增进团队彼此的感情，消除误解，增进团队彼此之间的了解，同时也让我们学会换位思考。

人与人的交往，就是一个反复沟通的过程——

沟通好了，就容易建立起良好的团队氛围，积极上进；沟通不好，闹点笑话倒没什么，但因此得罪人，导致工作处处受阻，就得不偿失了。

沟通的几种方式如下：

• 项目组成员位置就近，降低沟通成本；
• 项目管理工具：如Jira、企业微信TAPD等，便于及时查阅文档、问题，沟通及处理；
• 邮件的方式通知到项目每个成员及领导，也是一个查证依据；
• 站会及周会，汇报成果及问题，问题及时抛出及时处理；
• 建群，便于每天通报进度。

总结

个人感悟，只要做好项目管理、需求排期、对应功能时间节点、功能开发状态、进度达到多少时要开始预警、警报解除 、评估风险、延期影响评估、是否存在可替代性方案，一波操作下来，大程度不会出现延期的情况。

前辈大大们曾说过产品要有节奏感，这句话我十分认同。现在业内比较推崇的方式是敏捷开发，小步快跑，快速迭代的模式，把项目分成足够细的粒度并设置时间截点可以有效避免项目受到大的影响或经常性延期。

但在项目过程中随着进度的调整去做出一些需求上的调整也是很有必要的，人挪活树挪死，仍需不断努力。‍

‍

本文由 @时间怎么量 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议