产品战术可以简化，但要保持顺畅

导语：如果产品战略是为产品发展指明方向，那么产品战术就是有效地实现既定产品战略的原则和方法。产品战略与产品战术关系紧密，相辅相成，缺一不可；本文作者分享了关于产品战术的分析，我们一起来了解一下。

产品战略包含产品用户选择、产品定位以及产品路线，而产品战术管理主要有五大方面的内容：范围管理（需求管理）、进度管理、质量管理、技术管理、文档管理。

一、需求管理

用户所有的需求都是合理的，但我们的资源是有限的，所以我们需要对用户提出的需求进行管理，能够弄明白哪些是不应该做的，哪些是应该优先做的，而还有些是要提前创造条件去做的。需求管理有一套完整的全生命周期，大概可以分为以下6个关键点：

• 需求收集：产品经理和公司领导及业务方对业务目标达成统一；
• 需求分析：产品经理和业务方及技术经理对技术目标达成统一；
• 需求确定：产品经理和研发人员及测试人员对细节交互达成统一；
• 需求评审：所有相关方对产品需求的五个共识达成统一；
• 需求推进：研发团队和测试团队按期完成产品功能的研发和交付；
• 需求变更：产品经理按照业务方及公司领导的变化要求协调研发团队达成需求变化的调整。

在这里重点讨论一下需求分析、需求评审和需求变更这三个主要环节。

需求分析：

产品跑得快，全靠需求带，可见需求的重要性。甚至可以说产品其实就是需求被满足的外在表现，需求是因，产品是果。需求收集，不论是来自用户真实反馈，还是客户的极度要求，更或是老板的个人愿望，这些需求真实存在，但却不能直接构成指导产品开发的需求定义，因为我们需要对需求进行分析，辨其真伪，去其糟粕，需要升华。

我曾经写过一篇文章：《他们是提需求的，不是做产品的》，也分析过我们做产品，特别是需求分析过程中的一些问题，很多产品人员不清楚需求分析到底分析什么！下图是需求分析的维度，希望给大家一点启示。

参考文章：《需求分析，需要有层次的分析》

需求评审：

需求评审是各方对需求进行确认的过程，达成统一认知和共识，使需求能够推进实现落地。在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。

广义的需求评审是让相关方对产品需求的业务目标、技术方案、交互细节、需求责任人、排期计划的五个层面达成共识。一般情况下，在我们内部我们会把这五个层面的共识拆分成需求评审和技术评审两个阶段完成，技术方案和排期计划放到技术评审环节，以保证在确定的需求范围下得出更合理的结论。

对于新项目或者大版本升级，设计需求范围广，功能比较多，建议需求评审多次沟通，已达到全面正确无误了解，如下图所示：

对于小范围的需求评审，可以合并简化过程，以提升效率。如果产品需求在方向和价值上存在巨大争议和分歧，转入到产品决策流程！

需求变更：

我常常在团队内强调：我们拥抱变化，但又要控制变化。有变化才有活力，才有生命力，所以拥抱变化，拥抱创新。但是作为产品研发的过程我们有需要控制风险，而不确定性是风险的一种主要来源，所以需求变化不加以控制就会存在不确定性的风险。

需求变更制度是产品研发过程中不可缺少的制度，首先我们要定义需求变更的原因（比如新需求的加塞、业务不稳定导致、需求本身出现偏差等），同时对需求变更类型进行定义（比如功能需求变更、体验需求变更、数据需求变更、业务规则变更等），这些会造成需求变更的成本不同，影响程度不同，同时是指导我们决定要不要变更，如何变更的重要依据。

建立好这些需求变更的规则和逻辑，最后确定需求变更的流程（如下图），通过友好的协商、评估将需求变化进行控制，以保证产品研发过程的顺利推进。

二、进度管理

大部分的情况下，需要产品经理具备项目管理的能力。也就是要把每一条产品线的每一个版本的整体进度都把控起来，让版本能够在计划的时间段内顺利上线。那是不是产品经理其实就充当了项目经理的角色了呢？

在一个敏捷的产品开发团队，产品经理完全可以承担项目经理的角色，因为敏捷团队的项目管理相对比较简单，而且团队已经形成了固定的迭代节奏，工作的开展就像已经设计好的程序一样自动的执行。这个时候只需要一个技术经理与其配合，一个把控产品进度，一个把控产品质量。老谭在之前负责一个互联网产品团队时，基本上是这样的状态。

但是在一个没有迭代节奏的研发团队，或者产品0-1的过程中，或者完全基于客户需求导向的项目开发团队，产品经理就不适宜承担项目经理角色，因为项目周期长，需要投入项目管理的精力太多；而且项目的干系人也更多更复杂，需要有协调能力的人来处理；最主要的是项目的主要目标是交付，而产品的主要目标是产出，有时候二者存在难以调和的矛盾，过于产品化就可能会影响交付，过于考虑客户交付，产品化程度就会被削弱，或者被延迟。

六大过程：

在一个以外部项目为主的公司，可能会有专职的项目经理的角色来主要承担项目经理角色。而内部的项目团队，一般由研发团队或者开发团队委派项目经理来负责。

在一个复杂的项目中，项目管理特别是进度管理是一件非常有技术含量的管理工作，需要很多的方法和工具，同时又需要人文和情商，有时候在一些大型项目中会看到双项目经理存在，一个主外（偏商务），一个主内（偏工程）。以下列举了项目进度管理的六个核心过程以及用到的方法和工具。

• 活动定义： 分解、模板、滚动波式计划、专家判断、规划组成部分；
• 活动排序： 前导图法（单代号）、箭线图法（双代号）、计划网络模板、确定依赖关系、提前与滞后；
• 活动资源估算：专家判断、多方案分析、出版的估算数据、项目管理软件、自下而上估算；
• 活动历时估算： 专家判断、类比估算、参数估算、三点估算、后备分析；
• 制定进度表： 进度网络分析、关键路径法、进度压缩、假设情景分析、资源平衡、关键链法、项目管理软件、应用日历、提前与滞后、进度模型；
• 进度控制： 进度报告、进度变更控制系统、绩效衡量、项目管理软件、偏差分析、进度比较横道图、资源平衡、进度压缩、假设情景分析、制定进度的工具。

计划变更：

在笔者的从业经历中发现，项目没有按照最初始的计划执行的十有八九，延期的项目更是远多于提前完成的项目，我相信这对于很多做过项目管理的人来说也是司空见惯的。

究其原因主要有以下几个方面：

自身评估有偏差。

网络上流行一个计划评估的段子，一个刚入行的程序员评估需要1天，一个三年工作经验的程序员评估需要3天，一个架构师评估需要1周，这个评估结果不应该倒过来吗？NO!一般是实际结果倒过来，是不是很有意思。因为自己主观原因导致项目计划需要变更，在领导或客户那里往往通不过，实在完成不了需要变更，那就等着扣绩效、扣项目款吧。-_-||
领导或客户要求和资源不匹配。

领导和客户往往对于项目进度是有期望或者有要求的，但是对于项目组来说，在项目范围、时间不变的情况下，只能通过增加资源和成本才能保证。解决不了资源问题，计划就很难按时完成。
项目范围有变化。

般来讲指假设其他要素不变，项目范围越大，项目所要完成的任务越多，项目耗时越长；反过来，项目范围越少，项目所要完成的任务越少，项目耗时越短。如果过程中扩大了项目范围，如果可以同步增加资源，可以保持进度不变，如果解决不了资源问题，就只能变更项目计划。
项目需求有变化。

虽然在项目前期我们采取了需求用户确认和原型法等办法控制系统范围和客户需求。但还是在系统开发过程中甚至是测试工作完成即将上线时，客户还是提出了新的需求或者对原有需求进行调整，虽然没有显性的扩大项目范围，但新需求以及需求变更都会带来相应的工作量，甚至有的需求变化对于底层都有严重的影响，这也导致项目计划需要变更。

在项目实施过程中，项目组要经常关注与项目相关的主客观因素，及时发现和把握变化，认真分析变化的性质，确定变化的影响，适时进行变化描述。当变化了的各种因素影响到了项目的顺利实施时，项目组织必须及时进行计划变更，以确保项目目标的实现。

项目计划的变更应征得项目主体的同意，项目组织还应及时向其反馈变更及变更执行情况。‍下图是我们研发团队内部的变更申请单，只要合理的变更我们基本上都不设障碍，但需要让相关人员都要知晓，避免项目的混乱。

三、技术和质量

一个好的产品经理能够成就一个好产品，但是一个使用不当的技术也可以毁掉一个产品，所以在产品战术管理中，我们要重视技术管理和质量管理，一个攻一个防，共同把产品具体落地。

1. 技术管理

一般情况下，技术管理主要是组织级的，由CTO等同类岗位的人来负责，但是对于产品研发来说，不同的产品对于技术的需求也是不同的，企业级的产品和互联网的产品对技术的选择存在很大的差异。产品管理人员有很多是不懂技术的，而产品的成功又依赖技术，所以产品一定要和技术团队紧密协同，更好的为产品的发展负责。那么技术管理主要包含哪些内容呢？

• 技术选型。
• 架构设计。
• 开发规范。
• 代码审查。
• 技术攻关（特别是对于具有技术壁垒的产品）。

2. 质量管理

每个企业都“重视”质量，但很多企业都在测试环节、质量管理方面投入不够，毕竟测试团队和质量团队无法直接产生生产力，往往我们在质量和成本之间平衡的时候，一不小心就变成了牺牲品。

真正做好质量管理，希望团队要从以下几个方面进行重视：

要将质量意识渗入到骨子里。

海尔张瑞敏砸冰箱砸醒海尔人的质量意识，三星李键熙焚毁三星产品烧出一个三星帝国。所以企业领导人、产品负责人要从意识和行动上重视质量，而不是喊着口号，打着算盘。
重视测试团队、建立测试流程。

质量不仅仅是测试团队的责任，是产品研发团队所有人的责任，每个人都要参与到产品的质量和测试中来。

建立质量管理体系。

*后面我会针对产品研发过程中的技术管理和质量管理部分再详细介绍，在此不再赘述！

四、文档管理

产品研发过程很重要，但这个过程进展的程度，产生的成果如何体现呢？

• 产品本身即是最大的成果物；
• 产品的代码是真正的资产；
• 过程中产生的必要的文档是支撑产品长期发展的知识积累。

由于生产文档并不是产品的目标，而是管理的行为，而生产文档本身也会带来额外的成本，很多公司特别是小公司是不太重视文档的编写和管理的。但是站在一个长生命周期来看的话，没有文档的积累，到了后期对于产品研发就是一场噩梦。

哪些文档：

产品研发过程中的文档主要包含产品文档（PD）、技术文档（TD）和管理文档（MD）三大类，包括：

• PD.市场/业务需求文档–新产品初期（业务分析、市场调研、产品规划）
• PD.产品需求文档（需求分析文档、产品原型）

• TD.技术方案文档（概要设计，详细设计）
• MD.测试用例文档
• MD.WBS工作计划
• MD.各种评审文档（需求评审单、技术评审单、发布评审单等）

协作>存储

过去我们写了很多的文档，但是回过头来想想，这些文档一旦进入到文档库中，我们还会再去翻看它吗？对于后来人，这些文档是否又真的能派上用场？

过去我是反对把文档单独存放在离我们开发太远的地方，更提倡文档在git上，或者研发管理系统上都可以，这是我们经常用的工具，只有放在这些地方我们才能像看代码一样去翻看他们。另外，文档尽量不要碎片化，一个技术文档由于阶段不同，参与的人不同，结果写了十几个文档，不仅重复内容多，而且内容关联性差，很难让人去阅读理解，逐步的就变成了摆设。

去年公司购买了石墨文档，石墨文档的核心精神不是存储而是协作，而产品研发恰恰就是一个高度协作的活动，这样就方便产品研发团队共同的编写的方案，有利于知识的共享和体系化。

所以让文档活起来，而不是死掉是文档管理的核心思维！

通过上图可以看出产品研发是一个复杂的、多组织多岗位高度协作的企业活动；不论是大团队还是小团队，是大项目还是小项目，没有规矩不成方圆，大有IPD的研发体系，小也有敏捷的研发体系，但不论是哪个研发体系，都没必要照搬照抄。

只要保证过程的完整性，我们都可以根据自身实际情况裁剪简化，既能指导我们产品研发有序进行，又不会成为过程中的累赘。

#专栏作家#

菜根老谭，微信公众号：CGLT_TAN，人人都是产品经理专栏作家。经历程序员、技术Leader、产品经理、研发Leader等多种岗位。现负责某科技公司整体产品研发，擅长企业IT架构及互联网产品架构。

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

题图来自Unsplash，基于CC0协议