没有实践的理论是纸上谈兵，没有理论的实践是瞎搞。作为产品经理应该要有一些具体的理论指导实践，市面上的书很多，讲项目管理、产品管理、交互体验、商业模式等等。今天我们首先来讲讲产品实现过程。

一、五大过程的简介

根据PMP的理论体系，项目管理总体来说可以 划分为5大过程：启动过程、计划过程、实施过程、执行过程、收尾过程。在互联网公司基本不太可能走完完整的5大过程，但PMP中的项目管理体系任然有很多值得我们借鉴的地方。借鉴之前我们首先总结下互联网产品研发和传统的项目开发的差异，一般的项目都是有明确的范围、质量、进度、成本标准的，而互联网产品往往在事先不会有明确的这种定义，互联网产品研发讲究小步快跑、快速迭代，讲究敏捷、解决核心问题，也不会有太多的成本考量，只对产品质量和进度会有较高的要求，但这种要求往往也是动态变化的（10年前的产品和现在的产品质量区别天差地别）。总体来说项目管理讲究确定性，而互联网天生就是不确定的。尽管这两者本质有着巨大的差异，但互联网产品研发还是能够从项目管理中借鉴很多经验。以下我们来详细分解下互联网产品的项目管理过程。

首先我们对应着PMP的五大过程也对互联网公司的产品实现过程进行了阶段划分：启动阶段、产品设计阶段、技术开发阶段、测试验收阶段、上线部署及收尾阶段。这几个阶段没有严格意义上面的先后顺序，会有交叉、重叠、循环。划分阶段的意义在于形成工作流，能够让复杂的工作有据可依，有理可循并尽可能少的出错。

二、让我们做正确的事吧

在启动阶段，我们首先需要做大量的需求调研工作，竞品分析、用户访谈、问卷调查等等都是我们开展工作的手段。我们需要接触大量的用户、收集大量的资料、使用大量的类似产品，尽可能多的挖掘需求和发现问题。我们所有的拜访和试用都不应该时盲目的，需要带有一定的的目的进行，一开始可能目的并不明确，但在不断的探索的过程中目标逐渐清晰，我们能够发现不同需求背后的相同动机，也能够找到我们正真的客户或者是能够决定我们产品最终成果的干系人，我们能够找到充足的资料支持我们定义产品最终的目标，能够保证我们在做正确的事。而在这个阶段收集到资料都是我们宝贵的资源，能够为我们后期做产品方案输出提供必要的判断标准，那在这个阶段我们需要输出的文档又有哪些呢？首先我们可能需要设计符合逻辑的调查问卷，如果试用了相似的产品闹我们还需要输出竞品分析，在拜访用户时，我们还需要记录用户所有的需求描述，形成最原始的需求记录清单，在拜访客户的过程中我们需要把各个客户的基本资料记录，形成干系人清单，方便我们在后续阶段与其能够直接进行沟通交流。在把以上的内容进行简单的分析和归类后我们要产出需求跟踪矩阵，而这份需求跟踪矩阵是管理我们能够达成目标的各个需求最核心的文档，他会伴随我们直到产品上线。

三、确保团队正确的做事

在产出了需求跟踪矩阵后，标志着产品的工作可以进入下一个阶段了，即进行产品设计阶段。对于这个阶段我们可以细分为三个子阶段：需求分析、功能设计、原型或PRD输出，其核心目的是保证我们的团队正确的做事。

需求分析的目的，就是要把描述性的文字记录转换成有逻辑的定义性说明。我们需要把需求中涉及的人物、事件、步骤一一抽象出来，把相同的人物、事件、步骤进行整合，把不同的进行合理的分类。在系统中我们需要用具体的单据来满足一件事件的完成，把事件的过程按一定的顺序进行梳理形成步骤。

单据既是操作人员和系统之间交互的载体，为了完成某一件事情我们需要把能够描述这件事情的相关信息按照系统规定的规范进行输入，而系统根据我们输入的信息通过既定的步骤进行处理后再呈现给其他人员，而单据就是承载这种信息输入和输出的重用载体之一。一张合理的单据要有记录操作单据人员、具体事项描述、事件发生或是有变更的时间等信息，而这些信息即使我们需要定义的核心字段。

需求分析阶段最重要的目的就是抽象出来能够完成某项事件的所有单据和单据中的核心字段。在有了单据和核心字段后，我们需要设计详细的流程让单据流动起来，只有让单据流动起来才能达成解决事件的目的。要流动就必须要有推动信息流动的动力，而这个动力就来自于我们为流程中不同角色设计的操作，这种操作包括字段的输入和修改，对单据的审批，而为了标识以作的操作我们需要用一种特殊的字段进行记录，一般称之为状态，状态与操作普遍情况下要具有对应关系。而整个对单据的状态和流程的设计过程我称之为功能设计。这一阶段我们需要借助大量的流程分析方法，状态机、业务流程图、数据流程图等等都是我们能够使用的方法。

在设计单据状态时需要把握一定的原则：状态需要能够贯穿单据的整个生命周期；各状态之间不能重叠。在完成以上两个阶段的工作后，我们即可以进入产品设计的最后一个阶段：原型或PRD输出。原型以一种“粗糙”的方式展现产品的核心功能，是一种最简单和直白的需求表现形式；是需求从抽象到具象的输出。原型和PRD只是我们表达需求的一种手段，是为了能够让团队中的人或者是产品的后来者能够准确的理解产品的定位、功能的实现原理、各种异常的处理方式，如果原型和PRD不能达到这个目的那就没有存在的意义。很多产品在输出原型和PRD注重表面的信息，例如功能简单的操作步骤、页面呈现的字段的第一、页面的交互逻辑等等，这些内容肯定是原型和PRD 的一部分，但更重要的是能够描述系统模块之间的关联性、页面中没有完全呈现的字段、产品和功能设计的扩展性的说明等这种隐性的信息。

其次，一份核心文档其结构的条理性也是十分重要的，文档写出来看不懂那是纯粹的浪费资源，要想文档具有易读性一定要符合一定的文档逻辑，从背景开始交代，引出需要解决的具体问题，针对与问题做出详细的分析，既可以得出解决问题的方案，再对方案中的内容进行详细的介绍，最后进行总结或是常见问题和回答。这是一个通用的产品文档的内容结构，在本文中就不对文档结构这一部分内容进行详细的讲解，如需了解如何创建一份可读性良好的文档可以阅读《金字塔原理》一书。

四、做好后援，保障按图纸实施

在完成产品原型和PRD文档后，即可进入技术开发阶段、测试验收阶段，这两个阶段不属于产品主导，主要是辅助开发和测试并解答在开发和测试的过程中遇到的一些逻辑或者是文档上说的不够清晰的功能点。

需要注意，往往在这两个阶段我们可能会产生新的需求。毕竟，再详细的文档和讨论在具体落地执行时都有可能发生意料之外的事情，在工期和范围之间我们要做出痛苦的先选择，范围妥协时我们就需要把未完成的需求进行等级，进入下一阶段的需求池。这个阶段我们还需要特别注意的就是与技术和测试的沟通方式，要分清什么情况下要威逼技术、什么情况下要利诱，所有的这些方式的目的只有一个：让我们的产品能够在计划的周期内按方案实现，并能够尽可能的提高完成度。

五、宣传、总结才能让产品更好

在最后的一个阶段，既是上线部署及收尾阶段，最核心的事项只有两个：宣传和总结。产品发布会、新闻稿和软文、站内banner和通知、公司内部的邮件通知等等，针对不同的群体我们需要有不同的宣传方式，付出了时间和心血一定要通过宣传让客户、需求方、公司内部人员了解我们艰辛实现的过程，也要让其明白我们所实现产品的价值和意义。而总结也是必须的，每一次项目都有其特殊性，在项目的过程中使用的一些好的管理方法、解决方案或者是沟通方式我们都是需要进行整理讨论，形成团队的公用知识库，能够为后续的产品实现过程提供便利，同时公用知识库的建设也是一个团队是否成熟的重要标志之一。

以上既是一次完整的产品实现过程，希望能够对两到三年的产品经理有所帮助。在产品的工作中，最重要的是要保证我们在整个过程中一定要有输出物，输出物是推动我们产品实现过程往前的重要动力，我们希望通过这篇文章能够给你们提供一个合理的产品实现过程的划分，也能够知道在各个阶段需要有哪些输出物，以推动自己所在的团队稳步向前推进。

若产品老鸟对本文中的内容有建议，也欢迎随时与我沟通讨论。

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

题图来自 unsplash，基于 CC0 协议