产品开发无疑是一件复杂的事情，在其“不可知”的过程，到底哪些是最为关键的阶段，管理好那些核心过程能够有助于提高产品的竞争力？本文中，笔者为我们揭晓了这些问题的答案。

01

据说，软件开发领域有一个数据，50%以上的项目都会出现进度延期，多数新产品开发项目都像是“脚踩西瓜皮，滑到哪里是哪里”，真正能够按照计划完成的研发项目少之又少。

上文《产品经理怎么规划产品发展路径》解答了我们为什么总是发布不对路的产品，下一步我们要解决的问题就是研发过程管理的问题，特别是新产品的研发项目。

• 第一个问题是：如何把握哪些关键性节点能有效管理进度？
• 第二个问题是：研发过程中存在那些坑，以及如何解决这些坑？

第一个问题的答案，看上去非常明显——无非是对关键节点的管理，在PMP的管理理念中就是对关键里程碑的输入、输出的管理。

著名软件工程专家B.Boehm在1983年提出了软件工程的七条基本原理，其中三条分别是：

1. 用分阶段的生存周期计划进行严格的管理。
2. 坚持进行阶段评审。
3. 实行严格的产品控制。

第四条则是——结果应能清楚地审查。

把软件的开发过程拆分成多个阶段，使得每个阶段的任务相对独立，就可以实现不同职责和岗位的角色进行协作，从而降低了整个软件开发过程的困难度和复杂度。

每个阶段都可以采用科学的管理技术和良好的技术方法，而且在每个阶段结束之前都可以从技术和管理两个维度进行审查，合格之后才正式进入下一阶段的工作（事实上部分工作存在并行性，而非僵死的串行机制，但下游成果是否符合设定的目标取决于上游的设计），这就保证了整个过程有条不紊地进行，既保证了质量，也提供了软件产品的可维护性。

但关键是如何进行阶段性划分呢？

我的观点是：4个评审点和一个验收点。

（1）需求评审

对需求的评审，回答的“我们要解决的问题是什么？”这个关键问题。如果不知道问题是什么，就试图去解决这个问题，只能是白白的浪费时间，最终的结果也很可能毫无意义。

这个阶段，必须要提出关于问题性质、来源、目标和规模的系统性解释，澄清含糊不精的地方，改正理解不正确的地方，确保用户（客户）与研发团队的理解一致性。

（2）交互评审

对“交互”的评审，回答的关键问题是：“概括地说，应该如何解决这个问题？”

之所以用“交互”这个词来表述是因为只有交互才更让人可觉察、感受针对问题的具体解决方案。

这个阶段，通常会用到流程图、原型图、状态图等工具来描述整个产品的各种可能性，估算每一种方案的成本、效益以及体验，充分权衡更重方案的利弊。

事实上，隐藏在交互背后是接口、数据层的复杂逻辑，这也是最容易被轻视的问题，因为它不可见。

（3）视觉评审

对视觉的评审，则是考虑如何建议规范性和一致性设计语言。

“美丑”是一个个体的主观感受，我们往往容易陷入“太丑”的泥潭中而不能自拔。在软件开发过程中，视觉设计需要建立一套专业的规范和机制，不能单纯依赖直觉。

（4）用例评审

用例评审是针对产出成果设定其度量的标准，如何检验交付物与用户需求的满足程度。

这个阶段的关键任务是写出正确的容易理解、容易维护的场景检测逻辑，包括各种正常和异常的数据状态，逻辑状态，正向和逆向的场景状态等。研发团队应该在产品开发过程中达成对用例的覆盖度和颗粒度的评审，而且整个过程越早越好。

同时，用例本身是动态维护的，要及时更新维护并在团队内达成一致。

（5）验收发布

产品验收是为了最终交付而进行的成果验证和归档，包括收集项目完整的记录，确保产品满足用户和商业需求，并将相关文档进行归档，还包括项目的审计。

这个是最终的环节，它是一种集中审核的过程，它包括合同的收尾和管理的收尾，事实上也非常复杂的一个过程。一定有不少人想要控诉验收环节的血泪史，往往是以为已经干完了“该干的事情”，结果不是新增需求，就是没有达成合同目标，根本就不可能验收。

产品开发过程的每一个阶段，都存在着重大风险，PM们一定要有清醒的认识，也要努力在项目管理的专业领域上有所建树。

不管是2B还是2C的项目，不管是内部项目还是外包项目，不管你的组织采用何种开发模式，必须牢牢监控产品开发过程的关键节点和关键交付成果。

需求评审，是针对目前已收集的来自各个渠道的想法、意见、需求和建议等，通过恰当的工具进行汇总、梳理、分析和排序后，所最终得出的当下或未来需要完成的产品工作。

输入

新产品或产品迭代过程中的需求来源渠道，通常包括用户、竞争对手、供应商、销售终端。也包括上一个迭代有计划遗留或者临时被裁剪的问题、功能，以及bug。

另外还有一个重要的渠道，就是产品本身驱动的新的设计理念，新的技术框架。

产品经理应该建立一个便于维护的需求池，及时收集和处理来自多个渠道的“需求”。

评审

需求评审阶段通常都有产品经理或项目经理发起，主要是针对”可行性“评审，确保团队在某一个时期内有能力完成具体的需求，而不是提出不切实际的行动方案。

整个过程用到的工具包括需求池、KANO模型、四象限法则、交集分析法、思维导图、泳道图、原型图、里程碑。

输出

需求评审最终输出包括4个文档：

1. 更新的产品需求池：需求评审后必须更新产品的需求池清单，有些需求会被拒绝，有的需求会被纳入迭代计划，有的需求会调整优先级，产品经理必须确保维护了一个完整清晰的需求列表。

2. 用户故事板：用场景故事的方式管理用户需求，有助于激发团队的创造力，从而找到更优的解决方案。

3. 业务流程框架：在低保真阶段，产品经理需要快速的呈现问题的解决方案，不要过早的的陷入细节性问题，而应该尝试寻找更多的解决方案。

4、产品迭代路径：任何一次需求的评审，都可能对产品的迭代路径发送改变，要及时在团队中同步产品路径的更新，它设计从市场到品牌、到运营到售后的全过程。

需求评审，是定义问题的过程，交互评审则是针对问题的具体解，强调是针对明确问题的产品功能性实现。经过产品功能的交互评审后，我们已经正式进入这一迭代过程的开发阶段。

我们更为常见的做法是两个评审点结合在一起，这并没有苛刻的区分标志，但两个阶段有本质的差异。

输入

1. 用户故事板：清晰的用户场景可帮助团队还原真实的场景，从而反思产品的解决方案，提升产品体验。

2. 流程图：包括业务流程、数据逻辑和状态转换关系。

3. 产品PRD：PRD文档不要过于在意“四种写法茴香”，原型+备注的方式的效率非常高，如果你需要一份模板，可以在这篇文章里面找到：彻底抛弃WORD！教你用Axure快速输出高质量的PRD。

4. 迭代路径：要及时在团队中同步产品路径的更新。

评审

交互的评审，是针对解决方案的完整性检查，包括场景、逻辑、用户、内容的完整性，也包括交互的闭环体验检查。

同时，在这个应该，还需要分解完整的工作任务，评估整个迭代过程的资源需要和进度可行性。

事实上，进度的评估在需求阶段就已经开始，之所以需要反复评审是基于需求变更和解决方案优化的考虑。

输出

1、产品PRD：经过评审的PRD，仍然可能存在细节性的补充和完善，产品经理有责任维护一份完整清晰的在线PRD。

2、版本里程碑：团队应当用”PBS“的思路取代”WBS“，明确各项任务具体的资源复盘和时间节点。

3、产品需求池：任何阶段的评审，都可能带来新的问题和需求，它们可能来自团队本身的创造力，有助于提升团队的使命感和责任心，有些情况下，由评审而带来的需求可能极大的改善产品。

视觉和交互应该分开两个不同的阶段考虑，有助于团队专注解决具体的问题。

输入

见交互评审的”PRD“。

评审

视觉设计的评审，更容易陷入主观直觉判断，”太丑“是最容易想到的词汇，它往往取决于第一感官感受，而往往忽略实际用户的使用场景。

所以，在视觉设计过程中更需要明确产品的调性，如何建立一致性和规范性的设计思路，这更多取决于设计师本身的技能和美学素养。

输出

视觉设计可能带来迭代进度的影响，特别是复杂的动画设计往往需要更多的研发资源和时间，产品经理需要考虑资源和时间的投入产出比。

在某些情况下，过于复杂的设计容易得不偿失。

要使最终用户对产品感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。

测试用例反映了要核实的需求。然而事实上，我们通常都难以确保核实所有的需求（测试用例可能无法覆盖全部的需求范围），如何找到对关键性的需求关系到项目的成败。

测试的深度和广度，都对项目产生影响，随着测试用例数量的增加，团队对产品质量和测试流程也就越有信心。这把双刃剑的另外一面是，意味这需要投入更多的资源和时间，测试工作量与测试用例的数量成比例。

输入

见交互评审的PRD、视觉文档。

评审

1. 业务层：包括本次迭代过程中所涉及的全部场景、流程、数据、内容的完整以及异常情况的处理，相比于正向流程的用例，逆向流程的测试往往更为关键。

业务层的测试覆盖度是产品的核心，直接决定产品是否满足用户的需求。

2. 交互层：主要针对产品操作体验的测试，包括文案引导、操作跳转、导航布局等等，交互层是体验的核心。

3. 视觉层：用例通常只能检测完整性，这个环节更考验设计师而不是测试员。

输出

1. 测试用例：用例是评估测试结果的度量基准和分析缺陷的标准，编写测试用例应有规范的文档模板，且应当符合团队的规范要求。测试工程师必须基于用例在产品验收阶段输出完整的测试报告。

作为产品迭代的珍贵文档，测试用例需要更新完善，要及时发现和补充用例编写的不全面，尽可能的减少漏测的可能性。

然而，现实中的情况是测试用例常常被忽视，甚至被随意丢弃。

2. 版本里程碑：测试用例的评审极可能带来里程碑的变更，用例本身不仅仅是对交付成果的测试，实际上也是产品设计的检测，用例编写和评审的阶段就应该尽可能的发现设计本身的缺陷和漏洞，而不是只能对交付物。

产品验收是核查项目计划规定范围内各项工作或活动是否已经全部完成，可交付成果是否令人满意，并将核查结果记录在验收文件中的一系列活动。

输入

见”评审的PRD“、”评审的视觉文档“、”评审的测试用例“。

评审

产品的验收需要通过多次完成，从debug版本到beta版在到release版是一个复杂的过程。

产品经理必须主导整个完成，从产品的功能到交互的体验，以及视觉都必须细致进行评审，这个阶段应当组织开发、设计、测试对bug影响的范围、严重程度进行多轮评估，并给出具体的解决和改善方案。

输出

验收发布阶段的最重要文档包括3份：

1. 版本更新日志：阐述具体的功能更新。

2. 更新的产品需求池：产品经理必须重视对问题和bug的处理措施，在评估和平衡资源、进度和质量以后，在团队内部同步更新产品需求清单，确保对遗留的问题有清晰的备案和计划措施，而不是试图掩盖可能存在的问题。

3. 迭代总结：对本次迭代做一个小结，即可凝聚团队，也是提升团队技能水平的措施。

对软件产品开发过程的管理，是对整个过程“完成了什么，如何完成的，结果如何成功，是好还是坏”的系统性描述，整个领域有很多的理论体系帮助我们优化和改善我们的工作，但软件开发在某种程度上存在一些重大的挑战，从而使其变得与众不同。

这个过程需要不断的迭代和完善，不要幻想有一种方法可以一蹴而就打造一个“理想国”，而是随机应变，审时度势，慢慢的规范、调整，使之符合现实的各种制约条件——你所在组织的资源、策略和文化。

产品经理在面对不同的产品，不同的组织下，需要充分考虑到环境的特殊性，过程管理的方法随之千差万别，在有些时候还存在大量的偶发性事件，你需要时刻准备适应由于未知和不确定的原因所带来的额外工作。

不同的组织，甚至有完全不同的产品成功的定义标准，是按时并在预算内完成算是成功吗？未必如此。或许是客户满意度？对你个人而言，如何把手上的项目达成目标，确保这个项目给企业带来的效益比花费多，就是一种成功。

#专栏作家#

杜松，公众号：产品微言，人人都是产品经理专栏作家。专注于人工智能方向，擅长产品规划和架构设计。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议