在移动互联网时代，除了确保产品质量之外，产品的时效性也很重要，需要有一种相对更优的产品开发模型可以确保产品质量的同时，提升产品投产效率。于是敏捷开发模型（Scrum）应运而生，产品经理如何做好敏捷管理呢？本文作者对此作出了分析，一起来看一下吧。

“敏捷”常用Agile英文单词来表示。Scrum英文原意为并列争球，常出现于橄榄球运动中。近些年网络对Scrum解释为迭代式增量软件开发过程。

Scrum和敏捷不是一回事，随着近些年在越来越多的JD（Job Description，工作说明）使用Scrum这个词汇来表示敏捷，Scrum也被赋予了敏捷的涵义。

在PC（Personal Computer，个人电脑）时代，产品开发过程模型常使用瀑布模型（Waterfall Model）、快速原型模型（Fast Prototype Model）、螺旋模型（Spiral model）或是喷泉模型（Fountain model）等。

在PC时代的产品需要通过应用软件的方式安装至PC上，因此为了确保产品质量，产品从构建到发布往往要经历较长的时间，产品开发模型的严谨性相对于高效性来讲更受重视。

在移动互联网时代，除了确保产品质量以外，产品的时效性也至关重要。需要有一种相对更优的产品开发模型可以确保产品质量的同时，提升产品投产效率。

敏捷开发模型（Scrum）应运而生，敏捷开发模型是产品经理做敏捷管理的指导理论。产品经理实现产品的敏捷管理，需要结合理论、经验、工具三个方面共同协作。

产品经理敏捷管理框架如图1所示。

图1 产品经理敏捷管理框架

本文先从产品经理敏捷管的价值为出发点，以银行社区产品为例子，由理论、经验和工具三个维度，讲解产品经理如何做敏捷管理。

一、敏捷管理价值

斯坦迪什集团（Standish Group）主席吉姆·约翰逊（Jim Johnson)曾指出：“产品中64%的功能是很少使用或从未使用过”。

对于产品而言，产品的功能越来越多，功能越来越复杂，来自管理层的需求、来自业务部门的需求以及来自用户的需求往往会夹杂在一起，使得产品经理对于产品的管理力不从心。

大多数情况下，产品研发团队为了确保产品按时上线，不得不加班加点进行产品赶工。产品开发时长的增加，人力投入的增多，产品质量却持续恶化，产品团队士气低迷。

市面上的大多数公司尽管投入了大量的人力和金钱，仍然未在产品的成功实现上有所突破，大部分产品以失败告终，成功投产上线并生存下的产品寥寥无几。

传统产品开发管理模式建立在多个假设的前提，诸如产品需求在开发过程中严格执行，不能变更，员工能力一定足够强并且足够可靠（不会离职）以及产品的市场环境一定不会发生变化等。

很显然这些前提条件在目前产品开发过程中大概率不会存在。

现实工作中，由于产品管理的缺失或缺陷，导致产品反复推倒重建，产品最终的失败，以及产品团队人才的流失等情况数不胜数。

由于互联网时代的产品具有非一即零的特点，产品失败后会导致前期所有的投入变为沉没成本，公司以及产品团队的努力付之东流，损失巨大。

马尔文·康威在1967年提出的康威定律中指出：“设计系统的架构受制于产生这些设计的组织的沟通结构。”

随着产品团队人员的增加，团队成员之间的沟通成本会呈指数增长：

沟通成本 = n(n-1)/2

大多数情况下产品团队会面临着需求的扩散与产品实现难度的不可控性。产品确定性越高，实现难度越简单，人员结构简单，产品达成目标较为容易。

产品复杂度矩阵，如图2所示。

图2 产品复杂度矩阵

由此可见，产品经理使用敏捷管理的价值在于面对产品开发的不确定性，最大可能地实现产品预期目标，降低产品失败的概率，节省产品实施成本。

二、敏捷管理理念

产品敏捷管理的理念是实现产品目标的同时确保产品质量，最终提升用户对产品的满意度，增加产品在市场上的竞争力。更多的是传递一种价值观。正如《敏捷宣言》描述得那样：

• 个体和互动高于流程和工具
• 工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划

敏捷宣言如图3所示：

图3 敏捷宣言

产品经理在对产品团队进行敏捷管理之前，首先需要在产品团队成员宣导敏捷管理的理念，使得产品团队成员认同敏捷管理模式和方法，齐心协力共同实现产品目标。真正符合敏捷精神的价值导向能让产品相关者满意，并得到公司的管理层的认可。

三、敏捷管理实战

1. 建立敏捷管理团队

产品敏捷管理的意义在于能在产品实施过程中的存在的各种不确定以及动荡的环境下，迎接和适应各种变化，最终实现产品目标。

产品经理实施敏捷管理，在其理念上推崇以人为本，通过建立统一愿景来打造一个响应力强的高效能产品组织。

好的敏捷团队中工作会使人感到兴奋，成员之间协作高效充满活力，具有较强的凝聚力。

在产品敏捷团队中，我们设定以下角色：

• 管理者：可以由产品负责人担任。对产品经理、研发或是测试录入的产品问题进行评估，分配缺陷。管理者还可通过系统报告了解项目进展及团队工作量和效率。
• 产品经理：细化产品功能说明，拆解所负责产品模块功能，细化产品开发任务。
• 研发人员：查看由管理者或是测试人员分配给自己的问题，及时处理、填写情况并提交工作量记录。
• 测试人员：及时记录问题并对开发人员处理之后的问题进行验证和追踪。

完成建立敏捷管理团队后，通过每日的站会方式完成成员之前的信息的同步更新，回顾之前的协作事项，暴露产品研发过程中存在的风险与问题，便于成员彼此之间共同解决问题，更好地协作。

2. 使用敏捷管理工具

本文借助于目前市面上敏捷管理软件Jira作为管理管理工具。

结合JIRA提供的产品功能，产品经理敏捷管理可以通过以下几个步骤实施。

第一步：创建Epic（史诗）

Epic是产品的总体目标，建立Epic的目的是为了使产品团队所有成员明确产品方向，彼此达成共识，共同努力。

第二步：制定Version Releases（版本发布）计划

产品经理根据产品上线目标，制定产品发布计划。一般成熟的产品团队会有固定的版本发布周期，例如可以指定为每个月最后一个星期的星期四。这样产品团队成员便于记忆和理解，也容易在脑海中形成稳固的上线目标。

第三步：创建Sprint（冲刺）

在Backlog（积压的工作）中可以创建Sprint，制定好Sprint后，可以将Backlog中的工作任务通过拖动的方式移入到相应的Sprint。非常方便。

第四步：创建Story（故事）或Task（任务）

在Jira中，Roadmap中的Epic下Task和Story是一个等级，可以在Epic下直接创建Story或是Task。Task下面可以建Sub-Task（子任务）。视具体产品情况，具体分析和操作。

产品经理可以进行任务分解，创建Sub-Task（子任务），创建子任务原则是一般能在一天内完成的任务，是对当前任务的进一步细化。

产品经理建立故事，需要遵循“INVEST”原则，即：

• Independent（独立），产品功能逻辑自洽。
• Negotiable（可协商），产品故事范围内的灵活。
• Valuable（有价值），完成产品故事是有意义的。
• Estimable（可估算），完成这个故事需要多长工时。
• Small（小），故事是经过细化的。
• Testable（可测试），根据输入有明确的输出可验证。

在所建立的任务中，可以选择将当前任务安排至哪个Sprint以及相当的版本计划，估算工作量以及设置任务的其他字段参数。

第五步：看板与报告

看板是常见的产品敏捷管理框架，有助于产品经理和团队成员透彻了解产品的工作进展和团队能力。

Jira的数据报告类型有很多种，可以满足大部分产品经理对敏捷管理过程中的数据进行分析。

比如常见的如Burndown Chart（燃尽图）,Burnup Chart（燃烧图）,Sprint Report（冲刺报告）以及Cumulative Flow Diagram（累积的流程图）等。

产品经理可以根据实际的工具需求，通过配置和查看相应的数据可视化图表进行敏捷管理效果评价。

四、小结

产品经理从实际的产品管理中发现，传统的“瀑布”已经干涸了，在VUCA（Volatility-易变性、Uncertainty-不确定性、Complexity-复杂性、Ambiguity模糊性）的产品环境中，产品管理面临的全新的挑战。

敏捷宣言自2001年开始实行，到目前为止已经有二十多年的时间了，敏捷管理的有效性得到了充分的验证。对于产品管理而言，最合适的就是最好的。在没有更为卓越的产品管理模式出现之前，产品敏捷管理是相对最优的管理方案。

产品经理的价值不仅在于“做”某些事情，更重要的是“做成”某些事情。做事情容易，做成事情太困难。在漫长的产品实现过程中，产品经理难免会遇到各种困难，要做好长时间坐“冷板凳”的准备。

谋无术则成事难，术无谋则必败。产品经理只要认定所做的产品的方向是对的，通过敏捷管理的理念与方法，快速验证产品模型，根据实际产品环境迅速调整产品策略，坚持不懈，一定能迎来产品成功的曙光。