接上篇https://www.jianshu.com/p/f5df07aa6d70
四、进入开发，这时候产品需要注意的点
当产品经理的需求真正进入开发的时候，很多产品经理会在此时松上一口气，觉得总算把大担子交到开发测试那里去了，这一块的进度就靠同事们了；
我也曾经这样想过；但是事实是，大部分情况下（除非你的PRD已经写到了完美无瑕地地步，同事也聪明且有经验到极致），开发同事会在你工作的时间段里时不时地找上你咨询一把，一你并没有太多可以放松的时间，二在与开发同事的沟通过程中，一些决策就会影响到项目的实际进度。
此时在项目开发的推进过程中，产品经理可能会遇到的影响进度的3种主要情况分别如下：
1. 【需求增量】：PRD当中没有考虑周全的逻辑，开发同事在撰写代码的过程中及时发现并提醒了你，开发询问需不需要额外增加逻辑
2. 【需求量不匹配开发量】：在开发周期快结束之前，开发评估一部分页面没有及时完成，大概率是需要增加开发时间，项目需要延期
3. 【需求减量】：开发在开发过程中由于个人疏忽导致遗漏了一部分你已经写入PRD的功能或者页面
针对情况1需求增量，此时你作为产品是需要评估这个逻辑点是不是在本次版本中必须做上的，如果不是，可以考虑放入后续迭代，否则可能改逻辑导致的开发周期拉长，延期原因追溯时可能会追到你增加需求这个事情上；如果是必须做上的，对产品核心流程会产生重要影响的，笔者认为这是产品经理必须要努力维护的功能点，必须向开发晓之以理地请求将逻辑加上，产生的新增的开发时间，需要后续看开发能否加速，或者按照情况2的处理方法来进行跟进。
针对情况2需求量不匹配开发量，产品经理的及时介入非常之重要，大概率的情况就是开发同事需要此时产品经理去判断目前哪些还没做的功能是可以接受放入后续迭代的，哪些功能是核心功能没做完就不能上线的；产品在对这两类需求做好判断之后，如果确实有必须在本期要做完的功能然而开发评估在正常工作时间内是做不完的，需要开发领导出面组织开发人员加班加点或者说增派人手进行功能开发，确保交付。如果在加班加点和增派人手等手段支持的情况下仍然确认项目是会有延期的，则需要及时向更上层上报情况，确认是否可以接受一定时间的延期和后续对策。而至于那些判断是可以放入第二期的迭代中的需求，如果确认本期实属做不完了，那么可以选择需求后置，放入后续的迭代计划中。
针对情况3需求减量，在中小型公司中本情况还是时有发生的，但是一般来说这种情况会在测试期间被测试人员发现，一般以bug问题进行处理，测试会要求开发人员及时补写代码。产品需要介入的情况比较少，所以这一块一般信任测试即可。
而如果以上3种主流情况都没有发生，或者说已经得到了较好的处理，那么恭喜你，项目的进度在开发环节已经得到了较好的把控，可以准备好进入下一环节也就是测试环节。
<关键词>：
维护核心需求，需求后置，迭代计划
五、进入测试，这时候产品需要注意的点
需求进入测试是一个重要节点，这时候项目推进的主人翁变换成了我们的测试同学们，同样的，与开发环节类似，这时候往往也有几种常见情况会发生需要产品介入，产品经理的不同决策往往会对需求进度产生影响。几种情况分别如下：
1. 【需求减量】：产品在PRD当中书写的需求，开发同事没有做完整，有遗漏，被测试测出
2. 【需求争议】：产品在PRD当中书写的需求不够明晰，导致开发的理解和测试的理解不同，开发的形态不被测试接受，出现争议，开发和测试要求产品经理出面进行补充说明和决策
3. 【需求增量】：开发在写代码的过程中充满了产品激情，自行给产品上增添了PRD上没有的功能，测试发现后通知产品过来判断
其实这三种情况的性质简单来讲就是产品经理的需求被做了减法、模糊化和做了加法。而在沟通和处理上的逻辑基本是一致的。
第一点【需求减量】，一般优先操作都是让开发及时补入代码即可，当然这个前提是不影响项目进度。一般来说这种情况发生错误的责任在开发，一般情况下即使加点班，开发人员还是会及时将需求补进去。
第二点【需求争议】，产品需求不够明晰的情况其实如果对于项目没有影响的话，直接对需求解释清楚即可，需要对文档进行补充的做好补充，并在项目任务中进行备注即可。
第三点【需求增量】，这显然是开发给你出了道产品题。产品经理可以评估开发自行加入的功能是否能够被产品经理接受。
而以上三点处理方式和过程所遵守的基本的原则即是评估是否需要对代码进行一定量的改动，改动的量是否会对项目产生延期影响。但是对于产品经理来说，需求进入测试阶段已经相对比较接近实际上线阶段，产品方面确保以不改动为基本原则，因为你一旦做出了需求改动，不仅带来的是额外的开发的工作量，也是测试的工作量，一些关联的测试用例可能需要测试同学全部重测，项目会冒极大的延期风险，因而此时应该以“收”为主。
产品经理尽量不要养成在测试阶段还有出现需求变更的情况，尽管有时候可能基于维护核心流程的目的或者出于公司高层的要求在本阶段作出需求变更，但请务必三思而后行。
<关键词>：
尽量不改，争议解决，收
六、产品验收，这时候产品需要注意的点
激动人心的时刻终于要到来，也是整个团队最具有成就感的时刻，不过此时仍然应该注意小心翻车。
特别需要注意的是，即便测试和预发环节已经自信做好了测试和验收工作，问题仍然可能在正式环境中爆发，原因是多个层面的，如果是技术层面的那么产品人员也很难协助解决问题。此时产品经理能够做好的就是将流程验收完整，确保在用户使用的核心流程当中不出现差错。
当然，如果产品经理在验收过程中确实出现问题了，此时应该及时沟通到测试和开发人员确认问题，如果问题较为严重，对产品影响面较广的，应该及时通知运维对新代码进行回滚，恢复至老版本，评估问题并确认是否最终延期，以及下一次发版的日期。如果问题并不严重，影响面小的，而且开发可以及时修补的，可以尽快当即撰写修补代码(一般这种代码极其少量，可能只有一行或者几行)予以上线修正。
这里值得一提的是，很多时候人都是会犯错的，大型项目里从开发到测试再到产品，还是可能会碰到有遗漏的没解决的问题发上正式环境，因而诞生了一些主流的科学上线方法，例如【灰度发布】方法，即一开始可能只是引入5%（百分比看实际情况而定，也要兼顾数量）的流量进入新版本，观察各项数据表现，在各项数据表现正常之后，再逐步放量至100%。
当然，上面描述的情况和处理做法是针对Web产品而言的，如果你是App发版，那么请务必做好测试工作，因为App并没有像Web这样如此快速的回滚方案（尤其针对原生代码），如果出现较大问题，App Store可以利用Expedited Review进入审核快速通道加速修复发版，而Google Play则在一开始就可以利用Staged Rollout灰度发布的方法对问题进行提早曝光，方便控制bug影响范围，及时补救。
如果产品验收过程完全正常，那么恭喜，这个项目就算正式上线啦~
<关键词>：
Bug评估，代码回滚，加急发版，灰度发布
七、正式上线，才是一种开始
不过即便需求己经完整测试验收了，项目也准时上线了，产品工作还远未结束哦。
要记得，产品经理所设计功能的有效于否，刚上线之后仍处于待验证的阶段，此时产品经理需要格外注意每天的埋点数据的变化，如果数据表现不够理想，尽早着手准备后续工作，功能改进是常态，新功能予以下线都是有发生的（一个经典案例就是Facebook当年完整下线了筹备了大半年的界面改版，就是因为用户反馈和数据表现欠佳，导致灰度发布到一部分的时候便决策予以完全下线，回滚至老版本界面）。而后续工作中，也可以将下一版本的迭代和预估的开发周期计划放入议程。
因而产品经理一定要在心理上做好平常心的准备，不能因为项目一时的上线就以为可以缓下工作，大功能的成功迭代或许可以庆祝庆祝，但心态上要保持一种持续输出的准备，才能在产品路上越走越远。
<关键词>：
数据验证，后续迭代
结语
相信大家在看完本篇之后，对于需求全生命周期的推进过程和进度把控方法有一个较完整的感知了。希望这一份分享，能够给大家的产品实战工作带来实质助力。码字真辛苦啊