如何高效完成产品生命周期管理

作者介绍：

郭振宇，十年研发及技术管理经验，通过了CMMI5认证和PMP认证，擅长大数据集成、大数据治理、大数据安全、数据资产管理等领域的产品规划及技术研发。对技术团队管理和研发流程管理也有一定的研究及实践。

产品研发流程的发展经过了很多阶段的变化，不同企业使用的研发模型一般不一样，有些大企业注重规范会引入CMMI研发模型，有些企业可能因为传统项目的因素，还在使用瀑布式开发模型，而互联网企业更多倾向使用敏捷开发模型。

在研发投入方面，有些初创企业可能更注重价值产出，对研发流程管理投入较少，但事实上，如果一家企业没有研发流程，可能会导致产品研发效率极其低下。对于不同的企业想要管好产品，应该要根据自身的业务发展找到一个合适的研发流程。

本文会对几种不同的产品研发流程进行分析，结合自身的业务提出一套合适的产品研发生命周期管理流程。

项目管理方法论

CMMI

        对于项目的研发流程，CMMI是专门针对软件研发提出的管理方法论，在国内CMMI认证基本分为CMMI1~CMMI5，下面简单介绍一下：

        1级：默认级别这里不做介绍。

        2级：满足研发流程的基本条件，建立了基本的项目管理过程，有做就行。

        3级：是定义级别，即定义项目的目标、过程、研发规范、风险、组织过程定义等，在基本条件上定规范，文档化、标准化，使软件产品在整个软件过程是可见的，但没有量化。

        4级：软件过程和产品质量的详细度量数据，对软件过程有定量的理解与控制。每个过程有一个作出结论的客观依据，能够在定量的范围内预测进度和性能，量化管理过程，稳定运行。

        5级，持续优化，稳定运行基础下继续优化。分析过程性能数据，分析哪些数据影响了目标，分析哪些是关键点，针对于每个过程发生的事件的问题都有原因分析与解决方案，用了这个措施能达到什么效果，分析投资回报，继而实现并推广改进方案。

        CMMI优点：项目明确目标，明确研发过程（需求、设计、编码、测试、集成）的要求，注重每个环节的评审及性能分析，明确职责分工，有详细的过程文档，有决策指导及组织负责过程改进指导，有预测管理性能的算法，全过程持续优化流程，适合高质量的有明确需求的项目或跨项目管理。

        CMMI缺点：以整个项目为单位，有点类似瀑布式开发，但又不是完全瀑布式，文档太多，过于繁琐，如果实施不好会导致项目效率降低，维护成本增加，不适合一些需求经常变化，太多不确定问题，要不断探索市场迭代开发的项目。

敏捷开发

        在互联网的高速发展下，产生了敏捷开发流程，相信很多人都了解过，互联网行业用敏感开发来管控研发流程是最为常见的，而敏捷价值观体现在：

l        个体和交互高于流程与工具

l        工作的软件高于详尽的文档

l        客户合作高于合同谈判

l        响应变化高于遵循计划

        敏捷开发相对传统软件开发模式，它主要是针对快速变化的需求，是一种增量式的软件开发过程，早交付、频交付，会做一点点需求收集，一点点设计，编码和测试，最后交付一点点价值给客户，再重复此过程……周而复始，工作推进过程不断改善、调整流程，一直到项目完成为止。但这个东西并不是神器，不是实施了就可以解决所有软件公司的问题，而是要结合自己公司的特点和问题摸索出适合自己的一套模式。

        敏捷开发优点：快速适应市场的需求变化，快速试验市场，快速纠正错误，非常适合需求变化万千，需求不稳定的项目。

        敏捷开发缺点：因为在研发过程更关注变化迭代，对规范文档和知识库有点忽视，对技术人员的自律性、沟通、技术要求都比较高，敏捷在评审环节和预测性能方面也是比较弱的，如果需求、设计、评审都做得不足，容易出现返工和代码质量差。

PMP

在国内做过项目管理的基本都会知道PMP，而PMP已经成为国内各大公司招聘项目管理人员的基准或加分项，而且现在考个PMP证书也比较容易，虽然PMP现在含金量不高，但还是有他存在的价值，主要还是看学习之后怎样利用。PMP不是针对软件行业的管理方法论，它也可以应用到不同行业里，比较通用，主要分为五大过程组（启动过程组，规划过程组，执行过程组，监控过程组，收尾过程组），这里就不详细介绍了。

产品研发流程

        综合以上三种方法论，大家有没有发现都有一些共通点，有明确项目目标，有策划，有监控，有测试和验收。因此，我针对公司部门的环境提炼出合适的一套研发流程，主要以启动、策划、执行、监控、验收五个过程。这里我拿做过的一个产品作为例子说明：

        一、启动过程（产品概念阶段）

        所有的产品都必须要有启动过程，或者说是产品概念阶段，这阶段主要是收集市场用户需求进行分析，对产品进行可行性分析及竟争对手分析，形成概念性的产品，以制定一个商业目标。

        产品概念阶段计划：

        A1、收集市场用户需求及痛点：收集需求有很多种方式，常用的有用户访谈、媒体信息平台、与客户进行技术交流，参加行业交流峰会、与竞争对手交流、专家意见、公司内部交流，销售人员数据收集、政府政策方向等等，将各种途径收集的信息结合起来，了解现状及问题，深入分析用户的痛点在哪，需求的频次和价值。例如某某公司拥有用户数据，但数据安全没有做到位，没有治理方案和工具支撑，经常泄露数据，导致用户投诉，严重影响公司信誉及业务发展。

        A2、产品可行性分析：通过产品的市场前景，产品建设方案（核心价值），产品投资估算，产品财务评价，技术难度分析，团队及资源情况，竟争对手分析等方面去评估可行性，接下来总结一下竟争分析。

        竟争对手分析：

        1）第一步是收集这方面产品有多少对手，各对手在市场的占有率、规模、价格、有哪些客户、客户满意度、盈利水平，分析出谁是行业领导者、挑战者、有远见者和特定领域者。很好的例子就是参考魔力象限报告，Gartner作为全球最具权威的IT市场与顾问咨询公司，他的分析很有代表性，其次可以通过媒体数据（包括新闻报道、账务报告、行业报告、分析报告）来分析，再通过全国工商XX网或企XX的APP查询企业信息得到包括公司人数、融资情况、股权结构，账务报表等），如果是上市公司获取经营财务数据就最准确。比较出名的对手也会有官网和广告，从中可以获取一些产品信息及功能技术介绍，客户群等。百度指数有时也可以搜索到一些信息，而关键的产品满意度、质量、服务可以通过用户访谈及权威媒体新闻来获取。

        2）第二步是分析各对手产品，最终形成一份竟争分析表格（可以是Excel），就可以根据表格来制定产品定位及战略计划，具体表格指标如下：

        横向：对比层、对比大项、对比小项、对比内容、对比公司A、对比公司B、对比公司C......。

        纵向：战略层（产品定位、市场、客户群等）、范围层（产品架构、核心功能、亮点功能、怎样实现等）、框架层（界面、页面跳转、交互等）、表现层（视觉表现、布局、配色、排版）、（质量、性能）

        下面是一份表格例子，避免关键信息泄露，已经清除全部对比内容！单元格里会详细写上对比项的优劣势内容，为了方便对比出优劣势，这里我采用了5星来表示。

        输入：市场需求及用户痛点。

 

        输出：可行性分析报告及竟品分析报告。

        A3、制定商业计划（立项建议）

        有了上面的市场需求和用户痛点（为什么做）、可行性报告（凭什么做）、竟争分析数据（竟争分析），用户需求调研表，就可以制定一个商业目标（核心价值）。例如要开发一款帮助企业防止数据泄露的软件，目标是保障企业的数据安全，挖掘数据安全价值（这个产品是什么）。

        A4、产品成员任命和启动会：通常是创始人/高层指定产品经理，产品经理建议和协调项目的组成人员，召集相关干系人，在会议讲述产品背景、目标、宣布和明确产品范围，产品组成人员、职责等，让干系人都清楚为什么做产品，统一愿景，统一目标（团队思想）。

        输入：可行性分析报告及竟品分析报告。

        输出：产品立项建议书。

        二、策划过程

        这阶段主要是根据产品目标，制定版本迭代计划，干系人计划、人力资源及责任，风险，评审计划，进度定义，成本定义，质量定义。产品为一个大的迭代，里面包含了许多小迭代，如果产品规模大，将产品划分为多个子产品分派到名个开发小组中，每个子产品也按版本小迭代进行。

        B1、需求优先级排序

        因为经常会发生需求只有部分清晰或无法准确的说出全部需求，客户对需求的可视性要求较高，市场需求也会持续变化，必须采用敏捷迭代模型来研发产品，此模型由于能够在较短的时间内向用户提交一些有用的工作产品，因此能够解决用户的一些急用功能，每次只提交用户部分功能，用户有较充分的时间学习和适应新产品，同时产品的架构设计也要做到由一个个构件集成在一起，才能很好地配合敏捷模型，系统可维护性是一个极大的提高，当需求变更时只变更部分部件，而不必影响整个系统。

        将用户需求全部放入需求池，对需求排好优先级，选择市场/客户重点关注的及价值高的需求先实现，将需求划分为多个小版本迭代开发，快速跟进需求变化。

        需求可分为：核心需求、期望需求、兴奋需求、反面需求。

        1）核心需求是指产品必须要有的基本功能，没有的话用户基本使用不了产品。

        2）期望需求是指用户期望的，会增加用户好感的功能，如果没有也不影响基本使用，如果有了会大大增加用户体验。

        3）兴奋需求是指一些对产品影响不大，但有了会使用户觉得兴奋的功能，这类功能往往是一些很酷炫，很花哨的功能。

        4）反向需求是指有了这些功能可能只满足少数用户，但可能使产品更复杂，会对许多不需要此功能的用户产生不满。

        需求优先级按照重要性和紧急性来判断（重要且紧急、重要不紧急、紧急不重要、不重要也不紧急），定义：P1>P2>P3>P4。这时侯产品经理理解筛选、挖掘、匹配需求的能力也是很关键，也要有拒绝需求的决心，原则是要将一些不符合产品定位的需求过滤。

        制定需求池文档的字段有：需求编号、需求名称、需求背景、需求描述、优先级、状态、需求来源、版本。       

        输入：产品立项建议书、可行性分析报告，竟品分析报告。

        输出：用户需求池管理表。

        B2、定义产品迭代版本&估算版本需求规模

        这阶段要将产品分成很多个小版本（尽可能小），尽快输出可使用的产品，再迭代打磨，如果产品是从0到1，第一个版本就要先实现基本核心需求，产品基础流程要走通才能让用户用起来，所以开发时间相对会长一些，而之后的版本迭代时间就会短很多，每个版本要控制需求数和时间，迭代周期一般为1周~3周，如果有非常紧急的问题可以紧急发版。在确定了版本要做的需求后，就要将用户需求分解成面向开发人员的功能需求。

        1）需求分解（WBS）：例如用户的一个需求：要支持对数据库进行扫描，发现哪些字段是否敏感数据，是属于什么类型的敏感数据，帮助企业梳理敏感数据等级及管理。由此分析这是刚性需求，使用频率中等，价值非常大。客户想要的结果是敏感数据目录，而要达到目的，分解出几个关键功能及指标：

        第一，自发现，能全自动智能发现敏感数据位置和类别，不需要人工干预。

        第二，100%准确，必须百分百准确才能有效保障敏感数据。

        第三，覆盖范围广，敏感数据随处都有，可能在关系型数据库里，可能在HDFS里，可能在搜索引擎里，可能在文件里，可能在NoSQL数据库里等等。

        第四，性能，客户的数据已经是TB级别，在超大数据量下也要能保证扫描发现的性能。

        将需求分解为细粒度的功能和非功能，可以用思维导图先整理列出来。

        2）规模估算：用CMMI的PPM估算法将需求分解为可量化的功能点，将分解的功能分类归纳为模块、一级功能、二级功能、功能详细描述、功能点类型、复杂度、文件/库表/接口数量、字段数量，通过公式计算出每个功能的功能点数及全部需求的总功能点数。

        功能类型有EI、EO、EQ、ILF、EIF，解释如下：

        外部输入(EI)：通过界面等的输入，如插入、更新等操作都是典型外部输入。

        外部输出(EO)：仅仅输出，如导出、报表、打印等输出。

        外部查询(EQ)：先要输入数据，再根据输入数据计算输出，如查询。

        内部逻辑文件(ILF)：可以理解为业务对象，可能对应多个数据表。

        外部接口文件(EIF)：其它应用提供的接口数据。

        第一步，初步分解出每个功能及涉及的数据库表/文件/接口的数量，如下表：

        第二步，设置技术复杂度因子调节参数，如下表：

        第三步，通过公式得出规模估算统计，如下表：

        3）整体计划时间试算：有了上一步估算出来的版本总功能点数，可以把数据填入CMMI的试算表，得出估算例子如下：

 

        这些估算数据可作为参考，也会根据实际情况作微调，估算表里的最少值、最有可能值、最大值是根据模型基线得出的，这个基线会持续优化更新，在这里就不详细说明（有空可以再写另一篇文章来介绍这一块内容）。

        B3、制定产品版本目标&度量指标：

        根据客户/高层给定的质量要求和版本上线时间要求，进行产品版本度量模拟，维度包括进度、质量、成本，资源，如目标达成的置信度分析低于95%，纳入风险管理，这阶段就大概能知道这版本每个需求包含的功能点和所需用时，这版本需要多少资源才能按时完成，客户/高层要参与产品版本目标的评审。

        输入：产品立项建议书、可行性分析报告及竟品分析报告，用户需求池管理表。

        输出：版本需求分解管理及估算表（WBS）。

        B5、产品需求分析&原型设计

        根据需求定义业务流程、操作流程、逻辑关系、依赖关系、用户交互设计、显示内容、特征、业务约束、非功能性指标等，这阶段可以用Axure先画出个草稿的原型demo，用Visio来设计业务流程及逻辑关系，要尽早让开发负责人和测试负责人参与需求分析，一方面避免后续开发出现理解偏差，如能技术创新推动业务创新更好，二方面避免需求缺陷太多，负责人提早参与能更全面分析需求，为下一步需求评审做好准备，需求评审完成后再让美工制作更高保真的设计稿，同时开发人员就可以先并行进行架构设计和框架搭建。

        B6、需求评审&需求规格说明书

        需求评审：这环节非常关键，必须由产品经理、技术经理、测试、开发团队共同参与，最好是会议评审或电话会议，可以会议前先通过邮件将需求相关资料发送给内部相关干系人预先了解，再进行会议评审，确保相关的人都参与进来，确认每个人都是了解需求，及早发现需求缺陷问题，继而改进并全员一致确认。

        需求规格说明书：有人会问，敏捷第二条价值观表明态度“工作的软件”高于“详尽的文档”，那为什么还要写文档？本人观点认为不是不写文档，而是要阶段性轻文档，先沟通后存档是避免偏差的有效办法，如果产品规模很大，没有正式文档，当人员流动变化大就很难交接，需求评审通过后这份文档就是开发依据，涉及的内容有：文档编写目的，产品背景，产品描述，模块划分，整体流程图，功能需求（功能描述，业务流程、逻辑关系、业务规则和约束，前置条件，界面设计、非功能性指标等）。

        输入：产品立项建议书、可行性分析报告及竟品分析报告，用户需求池管理表。

        输出：原型设计，需求规格说明书。

        B7、完善综合计划&评审（进度计划、WBS、资源、日程时间）

        计划评审：这环节也是非常关键，在需求评审完毕后，就开始需求分配，可以让开发人员认领或者负责人指定，有前面的估算表数据，可以结合技术经理评估或团队投票来确认偏差，最后得出每个需求的开发、测试、部署时间及需求功能的活动顺序。

        综合计划：明确每个人的任务、计划、目标、识别风险。包括干系人计划、人力资源及责任、问题风险、产品交付计划、评审计划、软硬件资源计划，配置计划，QA计划，里程碑计划。

        开发计划：把WBS，进度计划，资源，日程时间结合在一起。很多敏捷书籍里都建议用看板，这里我用redmine，还有禅道也可以，都有甘特图和看板功能，可以搞个屏幕或投影出来，很方便监控进度，关键能把数据沉淀下来优化预测模型。

        输入：原型设计，需求规格说明书。

        输出：开发计划和综合计划->redmine。

        二、执行过程

        相信很多PM都曾经遇到资源不足问题，总结起来是“资源是永远不够的”，但一个合格的产品PM也需要在有限的资源下最大化利用并完成目标，如果产品是从0到1，还要管理招聘工作，如果是迭代阶段，资源的增加及调整也是会发生，这阶段要管理干系人参与及团队沟通，这里就先不详细介绍了。

        三、监控过程

        C1、概要设计（架构设计）&评审

        因为产品是从0开始，虽然加入敏捷模型，但对于大型规模的产品，概要设计（架构设计）一开始是不能省略的，可以根据需求来做多少设计多少，再逐步完善设计并记录文档，建议技术比业务超前设计1~2年较为合适，内容包括架构设计、设计约束、设计策略、技术框架、模块重用分析、软硬件规范及环境、功能架构、依赖关系、接口设计、容错处理设计等。

        架构设计评审：由技术经理、测试人员、开发团队共同参与。

        输入：产品需求规格说明书。

        输出：产品概要设计说明书。

        C2、代码设计->编码->代码走查->测试并行

        这阶段根据计划，以一个功能为单位并行进行，代码设计->编码->代码走查->测试，利用敏捷看板和甘特图跟踪进度。  

        1）代码设计及编码：敏捷强调的是前后端开发人员和测试人员的沟通，例如接口设计，前后端开发必须紧密沟通定义好接口方法，入参，出参等，编写好接口就可以直接利用如Swagger这些工具来管理接口，完成调试后再导出文档保存下来。

        2）代码走查：技术经理角色很重要，要负责起代码评审工作，辅以各种代码检测工具，工具负责检查规范性的代码，技术经理负责review代码逻辑，可重用，高扩展，可阅读，解耦，性能，成熟度模型评审及优化工作，原则是每完成一个功能要review代码，及早发现问题并指导开发人员修正，长期下来会形成一种良好的技术成长气氛。

        3）敏捷测试驱动：因为敏捷，测试人员必须提前介入测试，在需求评审通过后，就要开始测试用例的设计及评审，一旦系统某个层面可测，比如完成了某个模块功能，就要开始功能层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性，如果功能之间有依赖关系可先单个功能测试最后再集成测试。目的是尽早发现缺陷，尽早解决问题，对相关模块的测试影响会比较小。

         输入：产品需求规格说明书，概要设计说明书，代码规范。

        输出：代码设计或详细设计、测试用例，BUG管理->redmine。

        C3、团队要定规矩，例如举行每日早晨站立会议，每人轮流汇报昨天的工作、今天计划工作、问题，及早发现问题，会议控制在15分钟，我们在实行了每日晨会后，研发进度会控制得很好，问题都会得到很快响应，每周的个人周报及产品汇报也是必要的。  

         输入：开发计划，综合计划。

        输出：晨会，周报。  

        C4、原因分析&解决对策&风险管理

        原因分析：在发现问题后，利用鱼骨图进行原因分析，利用Pareto图识别问题影响重要性，再设计改进对策及计划，改进完成后要评价改进效果及记录。

        风险管理：每个阶段都要重新识别风险，做好风险评估、记录及监控。

        风险管理表：编号、描述、分类、行动措施、类别、风险级别、发生概率、风险值、优先级、状态、责任人、问题定位时间、计划关闭日期、实际关闭日期、跟踪人、跟踪日期、备注。

         输入：问题及风险。

        输出：CAR改进计划及方案表，风险管理表。  

        C4、里程碑&度量

        监控应该覆盖在整个产品生命周期内，在每个阶段结束时做里程碑报告，度量进度，质量，成本的偏差，及时做出对策调整，如果没有度量，产品可能会失控。

        经理对收集到的产品实际数据，进行偏差分析、质量目标分析及统计过程控制分析，完成《产品度量数据表》中度量数据的收集和分析。当产品到了所设定的里程碑时，经理负责组织里程碑评审工作。

         输入：开发计划，综合计划，度量数据。

        输出：里程碑报告。 

        三、验收过程

        1）成果评审，是在版本完成时举行，要向客户演示自己完成的软件产品，收集反馈，持续监控产品运行情况，上线一个月后提交功能指标、性能指标、监控指标等，上线三个月后提交运营指标。

        2）度量数据&回顾会议，每个人轮流发言，收集上一次版本中遇到的问题，继而洞察问题，确定改进方案，大家一起分享讨论，移交版本相关材料，包括软件，产品资料，里程碑报告，版本总结报告。

        3）结束：感谢团队，予以称赞。

        进入下一个小版本，回到策划过程，如此循环。（通常是在当前版本结束前就会根据市场反应提前策划下一个小版本）