PM设备维护及保养,pm项目管理

　　# #二。珠三角写作 　　

　　集中精神！这份工作会给你带来颅内高潮(*) 　　

　　撰写PRD可以说是产品经理的工作核心。所以这一块工作的进度，也是你自己最好把控的，因为主输出就是你自己（或者说你的产品团队，如果你阶级稍高一些能组织几个产品人写PRD） 　　

　　在BRD/MRD文档的情况下，可以根据BRD/MRD中带带的一些基本描述，开始绘制相关的基本框架，如流程图(如果还没有或者不够详细的话)和功能结构图。 　　

　　在很多公司的中后台产品经理手中，这个过程很可能涉及到业务流程的设计。如果公司没有专门的业务架构师(或类似的职能人员)，这项工作很可能会交给产品经理，产品经理需要与业务部门协调，整理流程。 　　

　　然后根据流程图、功能结构图等基本框架设计产品原型。你会花更多的时间和精力去思考很多细节。在产品原型的每一页的右边，通常会附上这一页的需求描述(如果你是用Axure设计的话)。 　　

　　至于如何写好珠三角，这个网站上有很多Sample(珠三角门户)，但实际操作和演练很重要。只有反复打磨和积累你的原型设计技巧(不仅仅是如何使用Axure等软件，你需要开始了解一些基本的交互/开发原则，以利于输出更高质量的需求)，才能把所谓的PRD。 　　

　　样本真正内化为你自己的知识和技能。 　　

　　在制作流程图、功能结构图和原型图的过程中，产品经理绘制的每个功能点代表开发量；因此，你需要特别注意。如果项目时间短，可以考虑在后续迭代中实现很多非核心功能，从而为项目实现一个MVP (Minimum)。 　　

　　可行的产品)设计，所需的开发周期会被压到一个相对较短的时期，这是不容易延迟的。 　　

　　这里说起来容易做起来难，功能拆分迭代需要产品对需求有深刻的理解，产品经理需要在这个板块反复打磨心智方法和技巧。如果不特别关注这一块，在需求提升的后续过程中会有更多的困难，也会有在评审中质疑开发，在后续开发过程中强行黑需求的情况。 　　

关键词： 业务架构、业务流程、MVP、功能拆分迭代、交互原理、开发原理

## 三、评审推进/评审涉及人员范围

对于很多产品来说，PRD的评审会议最为刺激 。当然这同时也可能是最容易让初级产品经理心里紧张的一项活动。

在进度把控上，尽量做好前期与各相关部门领导的前期单独沟通和调研，避免后续会议反复，而评审会议则要保持会议的高效不偏题，决策的迅速，重点的文字记录，最终及时将FPRD输出。

评审的次数、人员范围会根据需求大小、每个公司的实际情况、评审确认度而发生变化，甚至于评审的专有名词都在不同公司有所不同。我这里先讲一下两种基本的类型即【业务评审】和【技术评审】。

【业务评审】顾名思义，一般都是以业务人员为主要参与人员进行的评审，但同时也会让设计进行参与（除非你的项目仅仅涉及后台系统，同时后台系统的设计规范都已经定好）先行开始了解项目。由于你的原型一般来说是低保真原型，不对视觉进行定义，此时在后续进入开发之前，开发还需要设计交付一份设计稿，才能算是真正意义上的可以开始开发。

在业务评审完毕且相关方基本确认之后，你的PRD可以开始进入【技术评审】，此时往往是开发同事和测试同事开始进入到会议当中的场合。研发和测试阅读你的PRD时，他们往往对业务流程和项目目标、数据等层面关心不如业务部门，一般知道个大概，理解项目一些基本属性即可，但是他们会对你的PRD的技术实现方案和研发测试周期更为关心，也会在评审上对此进行讨论。

而在正式开【业务评审】和【技术评审】之前，对于产品经理来说一个很关键的步骤就是提前单独接触业务领导和技术领导进行调研，与他们沟通和讨论需求的大致方案，能将业务流程和技术实施的整体方案打磨出一个可行框架出来，这样一个步骤能大概率消掉后续会议中发生扯皮和争论导致的时间浪费、项目拖延的问题。

当然，即便在两种会议开始之前找各方领导做过单独的征询和调研，在会上你仍然很可能会遇见一些对需求点有关的 意见冲突

的地方，可能之前觉得可以的点，在会议上再多思考了一下又发现新的问题；

那么此时需要注意的是，如果争论点你在之前已经有所考虑，可以直接提出你的考虑看对方是否接受，如果对方的考虑更加全面或者这个点无法定论的话，你都需要做好会议笔记，方便会后及时跟进，并考虑对PRD做出合适的调整，方便后续给出最终版的FPRD（Final

PRD，作为进入开发前的PRD终稿）。

注意，如果意见冲突较多，PRD改动较大的话，此时是要考虑举行二次评审的。评审结束的判断条件就是一份大家都基本满意的FPRD的产出，后续的开发和测试都会以此FPRD为准开展工作。

当然，还有一种需求情况和流程是，当你接受到的需求体量较小时，或者需求对接部门单一时，很多时候【业务评审】会议可能略过，这样会节省大家大量的时间，可能你将PRD或者需求描述直接与对应部门的负责人对过即可；

有时候，一些情况下（多数为需求小且需求十分清晰），甚至【技术评审】会议也可以免除，交付开发负责人直接配给程序员开发也是可以的。这些情况在每个不同大小不同规矩的公司里，实际开展情况不同，灵活多变。产品经理应该根据实际需求情况进行会议的开展推动。

关键词 ：业务评审、技术评审、前期调研、会议记录、FPRD

## 四、进入开发，这时候产品需要注意的点

当产品经理的需求真正进入开发的时候，很多产品经理会在此时松上一口气，觉得总算把大担子交到开发测试那里去了，这一块的进度就靠同事们了；

我也曾经这样想过；但是事实是，大部分情况下（除非你的PRD已经写到了完美无瑕地地步，同事也聪明且有经验到极致），开发同事会在你工作的时间段里时不时地找上你咨询一把，一你并没有太多可以放松的时间，二在与开发同事的沟通过程中，一些决策就会影响到项目的实际进度。

此时在项目开发的推进过程中，产品经理可能会遇到的影响进度的3种主要情况分别如下：

1. 需求增量 ：PRD当中没有考虑周全的逻辑，开发同事在撰写代码的过程中及时发现并提醒了你，开发询问需不需要额外增加逻辑

2. 需求量不匹配开发量 ：在开发周期快结束之前，开发评估一部分页面没有及时完成，大概率是需要增加开发时间，项目需要延期

3. 需求减量 ：开发在开发过程中由于个人疏忽导致遗漏了一部分你已经写入PRD的功能或者页面

针对情况1需求增量，

此时你作为产品是需要评估这个逻辑点是不是在本次版本中必须做上的，如果不是，可以考虑放入后续迭代，否则可能改逻辑导致的开发周期拉长，延期原因追溯时可能会追到你增加需求这个事情上；如果是必须做上的，对产品核心流程会产生重要影响的；

笔者认为这是产品经理必须要努力维护的功能点，必须向开发晓之以理地请求将逻辑加上，产生的新增的开发时间，需要后续看开发能否加速，或者按照情况2的处理方法来进行跟进。

针对情况2需求量不匹配开发量

，产品经理的及时介入非常之重要，大概率的情况就是开发同事需要此时产品经理去判断目前哪些还没做的功能是可以接受放入后续迭代的，哪些功能是核心功能没做完就不能上线的；

产品在对这两类需求做好判断之后，如果确实有必须在本期要做完的功能然而开发评估在正常工作时间内是做不完的，需要开发领导出面组织开发人员加班加点或者说增派人手进行功能开发，确保交付。

如果在加班加点和增派人手等手段支持的情况下仍然确认项目是会有延期的，则需要及时向更上层上报情况，确认是否可以接受一定时间的延期和后续对策。而至于那些判断是可以放入第二期的迭代中的需求，如果确认本期实属做不完了，那么可以选择需求后置，放入后续的迭代计划中。

针对情况3需求减量，

在中小型公司中本情况还是时有发生的，但是一般来说这种情况会在测试期间被测试人员发现，一般以bug问题进行处理，测试会要求开发人员及时补写代码。产品需要介入的情况比较少，所以这一块一般信任测试即可。

而如果以上3种主流情况都没有发生，或者说已经得到了较好的处理，那么恭喜你，项目的进度在开发环节已经得到了较好的把控，可以准备好进入下一环节也就是测试环节。

关键词： 维护核心需求，需求后置，迭代计划

## 五、进入测试，这时候产品需要注意的点

需求进入测试是一个重要节点，这时候项目推进的主人翁变换成了我们的测试同学们，同样的，与开发环节类似，这时候往往也有几种常见情况会发生需要产品介入，产品经理的不同决策往往会对需求进度产生影响。

几种情况分别如下：

1. 需求减量： 产品在PRD当中书写的需求，开发同事没有做完整，有遗漏，被测试测出

2. 需求争议： 产品在PRD当中书写的需求不够明晰，导致开发的理解和测试的理解不同，开发的形态不被测试接受，出现争议，开发和测试要求产品经理出面进行补充说明和决策

3. 需求增量： 开发在写代码的过程中充满了产品激情，自行给产品上增添了PRD上没有的功能，测试发现后通知产品过来判断

其实这三种情况的性质简单来讲就是产品经理的需求被做了减法、模糊化和做了加法。而在沟通和处理上的逻辑基本是一致的。

1. 需求减量 ，一般优先操作都是让开发及时补入代码即可，当然这个前提是不影响项目进度。一般来说这种情况发生错误的责任在开发，一般情况下即使加点班，开发人员还是会及时将需求补进去。

2. 需求争议 ，产品需求不够明晰的情况其实如果对于项目没有影响的话，直接对需求解释清楚即可，需要对文档进行补充的做好补充，并在项目任务中进行备注即可。

3. 需求增量 ，这显然是开发给你出了道产品题。产品经理可以评估开发自行加入的功能是否能够被产品经理接受。

而以上三点处理方式和过程所遵守的基本的原则即是评估是否需要对代码进行一定量的改动，改动的量是否会对项目产生延期影响。但是对于产品经理来说，需求进入测试阶段已经相对比较接近实际上线阶段，产品方面确保以不改动为基本原则，因为你一旦做出了需求改动，不仅带来的是额外的开发的工作量，也是测试的工作量，一些关联的测试用例可能需要测试同学全部重测，项目会冒极大的延期风险，因而此时应该以“收”为主。

产品经理尽量不要养成在测试阶段还有出现需求变更的情况，尽管有时候可能基于维护核心流程的目的或者出于公司高层的要求在本阶段作出需求变更，但请务必三思而后行。

关键词： 尽量不改，争议解决，收

## 六、产品验收，这时候产品需要注意的点

激动人心的时刻终于要到来，也是整个团队最具有成就感的时刻，不过此时仍然应该注意小心翻车。

特别需要注意的是，即便测试和预发环节已经自信做好了测试和验收工作，问题仍然可能在正式环境中爆发，原因是多个层面的，如果是技术层面的那么产品人员也很难协助解决问题。

此时产品经理能够做好的就是将流程验收完整，确保在用户使用的核心流程当中不出现差错。

当然，如果产品经理在验收过程中确实出现问题了，此时应该及时沟通到测试和开发人员确认问题，如果问题较为严重，对产品影响面较广的，应该及时通知运维对新代码进行回滚，恢复至老版本，评估问题并确认是否最终延期，以及下一次发版的日期。

如果问题并不严重，影响面小的，而且开发可以及时修补的，可以尽快当即撰写修补代码(一般这种代码极其少量，可能只有一行或者几行)予以上线修正。

这里值得一提的是，很多时候人都是会犯错的，大型项目里从开发到测试再到产品，还是可能会碰到有遗漏的没解决的问题发上正式环境，因而诞生了一些主流的科学上线方法，例如

【灰度发布】

方法，即一开始可能只是引入5%（百分比看实际情况而定，也要兼顾数量）的流量进入新版本，观察各项数据表现，在各项数据表现正常之后，再逐步放量至100%。

当然，上面描述的情况和处理做法是针对Web产品而言的，如果你是App发版，那么请务必做好测试工作，因为App并没有像Web这样如此快速的回滚方案（尤其针对原生代码）；

如果出现较大问题，App Store可以利用Expedited Review进入审核快速通道加速修复发版，而Google

Play则在一开始就可以利用Staged Rollout灰度发布的方法对问题进行提早曝光，方便控制bug影响范围，及时补救。

如果产品验收过程完全正常，那么恭喜，这个项目就算正式上线啦~

关键词： Bug评估，代码回滚，加急发版，灰度发布

## 七、正式上线，才是一种开始

不过即便需求己经完整测试验收了，项目也准时上线了，产品工作还远未结束哦。

要记得，产品经理所设计功能的有效于否，刚上线之后仍处于待验证的阶段，此时产品经理需要格外注意每天的埋点数据的变化，如果数据表现不够理想，尽早着手准备后续工作，功能改进是常态；

新功能予以下线都是有发生的（一个经典案例就是Facebook当年完整下线了筹备了大半年的界面改版，就是因为用户反馈和数据表现欠佳，导致灰度发布到一部分的时候便决策予以完全下线，回滚至老版本界面）。而后续工作中，也可以将下一版本的迭代和预估的开发周期计划放入议程。

因而产品经理一定要在心理上做好平常心的准备，不能因为项目一时的上线就以为可以缓下工作，大功能的成功迭代或许可以庆祝庆祝，但心态上要保持一种持续输出的准备，才能在产品路上越走越远。

关键词： 数据验证，后续迭代

## 结语

相信大家在看完本篇之后，对于需求全生命周期的推进过程和进度把控方法有一个较完整的感知了。希望这一份分享，能够给大家的产品工作实战带来实质助力。码字是真的辛苦啊~

本文由 @菠萝饭 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。