作为产品经理，如何主导团队敏捷开发？

敏捷的概念在互联网公司越来越流行开来，一些传统的大型公司也逐步地向敏捷转型，甚至在产品经理面试的时候，面试官最常询问的就是你参与过敏捷开发团队么？作为一个产品经理，如果你现在还不了解敏捷是什么，可能几乎无法融入团队的工作。但是当我们打算阅读一些敏捷相关的材料时，却总是被一些拗口的翻译词汇搞得很不明所以。

本文以一个产品经理的角度，以多年主导敏捷团队的经验，深入浅出的带你掌握主导团队敏捷开发的方法。

今时今地，为何需要敏捷开发？

让大象跳舞，是所有大公司追求的目标。

迅速的响应市场变化，用最低的管理成本创造最好的产品，源源不断的创新能力——多少管理学家和实战领袖都在追索这三个问题的终极解法。对于产品研发团队，敏捷方法也许给这三个问题找到了答案。

简单介绍敏捷开发

你可能已经阅读了一些关于敏捷的资料，接触到例如“宣言”、“价值观”这些大词儿，还会看到“迭代”、“看板”、“User Story” 这些方法论。但是没有经历过实操，觉得迷迷糊糊的。

没关系，我们来重新梳理一下：

“敏捷”（Agile）一词，来源于“敏捷软件开发宣言”（Manifesto for agile software development）：

个体和互动：高于流程和工具。

工作的软件：高于详尽的文档。

客户合作：高于合同谈判。 

响应变化：高于遵循计划。这个宣言所表达的是：自驱力、协作力、应对变化的能力，相较于工业时代的流程、制度、规范而言，更适合互联网研发团队。

我们拿麦当劳和海底捞举个例子，麦当劳是典型的大工业标准化管理方式，你在全世界每一个门店尝到的味道和感受的服务都是一样的；海底捞是一种以人为本的管理方式，最大限度的发挥服务员的主观能动性，不断给你惊喜。

理解到这一层我们就会知道，所谓敏捷，是一种团队竞争力，这种竞争力能迅速的响应变化，激发创造力潜能。

但是理想很丰满，现实很骨感可是不行的。产品经理或项目经理如果只会带着团队喊口号，画大饼，研发小哥哥也只能给你个白眼自行体会。

所以，掌握一些能驱动团队的方法和关键节点非常重要。

敏捷本土化变迁

敏捷的发源于美国，也因为一些硅谷公司在中国的大力推动而生根发芽。但是中美文化有巨大的差异，导致我们在理解和执行敏捷开发方法的时候，会觉得无法执行下去。这就造成了书本上和“别人家”的敏捷方法，与中国公司实际可落地的敏捷方法有很大的不同：

变化一：产品经理面对的需求来源更多，话语权更强，不确定性更大（没错我说的是大佬们）。团队的资源情况，任务优先级和进度透明化展示变得非常重要。我们常看到国外用便利贴的方式管理进度，然而更符合中国国情的方案是：线上看板工具。

变化二：迭代一旦开始就不要安排新的工作，这一点几乎没有办法做到。如果代码管理和自动化运维能力不足，研发团队会为上线问题耗费惊人的时间成本。而很多公司对此重视严重不够。

变化三：激情和自驱的工程师是珍贵而且稀缺的，所以里程碑和工时管理在本土企业中变得非常重要。

以上只是说了我在项目中常见的一些变化，相信每个公司都有自身的痛点。而敏捷的核心就是以人为本，拥抱变化。所以我们在执行的时候也不要固守书本里的方法论，那样只会纸上谈兵，无法真正为团队赋能。

产品经理的敏捷方法论

所以对于产品经理而言，什么是敏捷的核心方法，我们一定要贯彻、推动跟执行的呢？

我认为有以下三点：

对团队和用户的即时反馈

换言之，就是唯快不破。虽然每个产品经理心中都有大大的梦想，但是你一定得想办法把他们拆到最小尺度上。让开发团队在很短的时间内就可以交付，看到成果，也能让用户不断地感受的产品的升级和变化，并做出反应和调整。

从目标到代码的拆解

产品经理设想的功能，到开发实现的功能，失之千里是太常见的事情。产品经理必须能自始至终掌控交付质量，而不是仅仅在上线前进行验收。产品经理必须要通过不断地磨合，和研发团队建立一种有效的将需求精准明确的转化为代码的机制。

代码逆向可控性

光从目标拆解到代码是不够的，还需要能反向的知道一段代码究竟关联着什么样的需求。当团队成员变化频率较高，或者是系统变得复杂以后，你会发现知道这至关重要。可以节约大量的阅读代码、熟悉业务、整理文档的时间。

主导敏捷开发的关键节点

接下来，我将介绍一个完整的迭代流程中的关键节点。这些关键节点是我在长期的工作中总结出来的百试不爽的方案。希望能对你有所帮助。

我们拿一个常见的电商网站来举例，在实战中掌握方法。

第一步，确定一个大目标（产品长期目标）

如果你是一个初级产品经理或是产品助理，不要求你能够独立的设定产品战略，但是必须能够理解和传达目标。

制定战略目标又是一个大学问，此处就不展开了。

案例：传统的水果公司成立了软件开发部门，希望以此扩大收益，降低成本。通过调研和分析，确定了本年度目标是建立线上商城，并将供应链进行数据化管理。线上商城目标覆盖北上广深4个一线城市，达到年销售额 100 万；提升供应链团队 40% 的人效。

第二步，拆分多个小目标（产品短期目标）

面对不具有可实施性的年度目标，需要拆解成具体的季度、月度目标。包括制定产品路线图，组建团队，立项。当团队规模比较大时，按照项目划分团队是个好习惯。当一个研发团队的成员超过一定规模时，协同成本就会急剧上升，很有必要进行项目划分。项目团队是一个为了某个特定目的而组成的临时组织。我们可以利用项目管理工具便捷的创建项目、管理团队。让多线程的项目管理变得轻松。

案例：细化年度目标，拆解 3 个项目组：供应链基础版、商城 H5 版、管理后台基础版。

第三步，用户故事（UserStory）

我见过一些团队，强行的要求用户故事按照以下的格式进行：

“作为一个『角色』，我需要一个『功能』，以实现一个『目的』”。

无可厚非的是，设计每个功能时都需要定义清楚它的用户角色、功能详情以及目的。但一定要照本宣科的照搬格式，我认为也没有太大必要。产品经理按照自己和团队都能接受的最高效的方式，通过原型、标注、流程等形式将所需要的功能描述清楚即可。我们一定要将用户故事拆成能独立上线，实现一个完整功能的最小单位，并给他们清楚地定义好优先级（可能需要多方意见的综合）。保证在一堆用户故事中，最高优先级的不超过三个。只要产品经理做到这三点（清晰明白的原型和标注、最小独立功能、公认的优先级），就可以为迭代开一个好头。案例：对于商城 H5 这个项目，我们可以建一些用户故事，并不断地大胆的向里面增加新的用户故事：

第四步，设定迭代目标

迭代是敏捷开发最核心的概念之一。

一个迭代即为团队所约定一个交付时间，通常在2周，可以更长也可以更短。这个看上去有点不合情理的要求其实非常有益：通过交付时间的明确规定，使得产品经理在规划功能时尽可能的做到最小功能，研发团队在持续的交付过程中，能越来越熟悉自己的能力，培养按期交付的习惯。

实际操作时，需要在迭代开始前，组织核心开发人员按照优先级的从高到低了解用户故事，并评估所需要的时间，决定下一个迭代完成掉哪些用户故事。案例：经过评审，团队决定将两个最关键的独立功能作为下一次迭代的交付内容。在2周后达成上线，建立一个里程碑，作为一个承诺。

这样的承诺对于产品上线宣传和运营非常有帮助，能很好地计划推广素材准备时间。

第五步，交给研发

接下来，研发负责人要将产品需求转换为开发设计文档，将用户故事拆解为具体执行的任务卡片。拆解的标准也是以最细粒度为佳，单张任务卡片的开发工作量不要大于一天。并落实到人上。这样，我们就可以建立一套『目标-任务-用户故事-研发卡片』的完整链条，不论是正向还是逆向，都可以追溯，找到每一个代码的源头需求，也能为每个需求关联完整的代码。这个从用户故事到研发卡片的过程，最好能抽一个全员都能参加的时间，认真的开会评审讨论。产品经理营造轻松自由的氛围，让大家把能想到的问题都抛出来，并得到最佳解法。

在开始开发前，尽可能的将需求讨论清楚，才能避免后面的遗漏、信息不对称。研发需要每天及时的变更任务状态，这样团队所有成员都可以一目了然的利用任务看板了解迭代进度。案例：将刚刚的商品列表拆分为更细粒度的研发任务，指派到开发，并及时更改进度。

第六步，上线观测与目标调整

不少产品经理会觉得，功能上线后的用户反馈和运营数据与敏捷研发团队关系不大了。其实恰恰相反，因为敏捷的核心要素就是即时反馈，对于研发团队而言，上线后的效果就是最重要的反馈，可以激励、鞭策、凝聚团队更好的发展。通常，上线后，我们需要去做这两件事：

上帝说，要有数据：

如果上线的功能会直接产生可观察数据，那么一定要利用监测工具将他们记录下来，并有效的传递给研发团队。例如停留时长、下单转化率等。

聆听核心用户：

数据不是万能的，有时你掌握不了准确的数据，有时数据会迷惑你。所以需要建立与核心用户的反馈通道。收集他们对新上线功能的评价。通过以上两点，我们不断地去调整用户故事的优先级、建立新的用户故事、淘汰不合时宜的故事、改变小目标，使得产品可以永远符合市场的需求。

欲善其事，必利其器

经过短暂的阅读，你大概对于一个产品经理如何主导团队敏捷开发建立了认知。接下来，你需要实践、宣导，与你的团队一起磨合出最适合你们的迭代流程。这时候，你需要一个项目管理的工具。

用工具推动执行力

一个优秀的工具，自己就会宣导和贯彻高效的方法论，也能驱动成员去执行。这就像我们学习时利用笔记类工具；提升效率时用时间管理类工具。如果团队没有一个称心的项目管理工具，敏捷开发的推动也只能事倍功半。

推荐几款敏捷开发工具

在不同的团队里，我尝试过几款不错的项目管理工具。例如，

JIRA：可用于文档管理、进度管理、测试 bug 管理。适合于大型公司进行本地化部署，功能很强大。不过由于是国外软件，在交互方式、界面、语言上都稍微有些适应和学习门槛，感觉用了半年还是用不顺手。

WorkLess：可量化的团队协作软件，通过积分来衡量每个任务的任务量、难度和完成质量，最终合理量化每个协作创造的价值是WorkLess的核心思想，诠释了精准协作创造价值的理念，软件免费使用，适合中小企业或者初创型企业使用。项目或者任务讨论的内容及反馈信息不会被淹没掉，关键的项目讨论留痕，提升参与者对项目的信息对称程度。

功能如下：

一、任务管理

1、任务分为四个优先级，其中A优先级的任务有时效性考核要求，如超时会根据扣分配置产生连带（连带上级）扣分；

2、一个任务的角色包括发布人、执行人、验收人，其中执行人可以是多人，也可以在任务执行过程中指派新的执行人协作

3、预估任务量是最终验收获得积分的重要依据，发布任务时需要客观评估该任务的任务量，并尽可能精准。

4、任务执行获得的积分=日基础分*难度系数*完成质量*任务量，其中难度系数、完成质量由验收人根据沟通和经验主观评定

二、任务的量化评分

1、执行人需要对A类任务特别关注，A类任务超时扣分=扣分日基础分*超时天数，并产生连带扣分，扣分日基础分和连带层级可设置；

2、执行人交付任务时提交执行任务的耗时，耗时是单独做该任务所花费的时间，不是时间流逝的长度。耗时是验收人最终核准任务量的参考；

3、验收人主观评定难度系数和完成质量，并根据执行人提交的耗时和发布人填写的预估任务量最终评定核准任务量，核准任务量应倾向预估任务量，适当参考执行人耗时，此后分数将自动计算出。

三、项目全局管理

1、项目进度的全局管控，清晰显示项目包含的任务、动态、文档、文件和进展；

2、在线创建项目文档，多人协作编辑查看；

3、共享项目文档，并进行动态管理

4、关键的项目讨论留痕，提升参与者对项目的信息对称程度

四、通过积分量化任务

1、积分是执行任务产生成果的量化体现，WorkLess提供积分管理工具，对任务、汇报等成果进行统计，形成积分排名，为团队管理者提供数据依据。WorkLess适应不同的行业，30+行业在使用，解决工作中的团队协作问题、任务管理问题、项目协作问题。

好了，文章就到这里。希望能帮助大家。