跳到主要内容

Scrum，最常见的互联网产品研发流程

提示

Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。其最早起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

—— Scrum中文网

最常见的互联网产品研发方式毋庸置疑是敏捷化、迭代化的流程。大概在 2010 年之前，大部分软件研发还是传统的瀑布式研发，半年、1 年一个版本。比如 Office、Photoshop，那时候甚至要跑去电脑城买光盘回家安装。回看马化腾和雷军早期创业的相关书籍，有很多内容都描述过类似的情景。

瀑布式研发模式，要求在开发前要进行充分的调研、分析和论证，否则很可能浪费大量的资源。但随着国外迭代思维和工具的快速传入，时至今日，大部分互联网公司已经围绕着快速迭代的思维进行着研发流程管理，连 Office、iOS、Photoshop 具有如此繁杂功能的软件也可以通过网络随时更新。

发生这些转变背后的原因主要有 3 个，分别是研发流程的创新、功能验证的要求以及市场竞争的加剧：

1、研发流程的创新

瀑布式研发伴随着较大风险，如果产品有漏洞或者安装问题，往往面临着产品召回和成本巨大的线下修复。随着互联网接入服务，也就是我们过去常说的 “宽带办理”，门槛降低，以及无线网络（WiFi）的大量普及，通过快速迭代作为研发流程开始有了土壤。


2、功能验证的要求

快速迭代这种研发流程被验证可行，意味着互联网产品可以在更短的时间内进行频繁的增量更新（回想一下，是不是手机里的 App 好像无时不刻都在更新？），高频的增量更新提升了用户反馈的效率。可能这周的一个想法，在下周就能上线并得到用户反馈，而不必像过去那样过度谨慎。加上现在上线前需要经过的环境测试和灰度测试，试错成本比以往低很多。


3、市场竞争的加剧

只要有一家公司采用了快速迭代的方式并获得了成功，那么未来行业使用同一方法就只是时间问题。更快的版本更新可以更快地提升产品满意度，修补漏洞，提供用户迫切需要的功能。市场如战场，假如 A 公司采用快速迭代的方法，B 公司使用传统的瀑布式研发，即便两家公司旗鼓相当，但 A 公司的用户需求会被快速满足。倘若 A、B 公司产品都有重大的漏洞，响应速度在这里就起到了关键的作用。

01

不同研发流程的响应速度


那么，常见的选代方式（如：Scrum）是如何运作的呢？有哪些特点？网上有很多资料，这里就不再赘述了，更多的从我个人看法来介绍一下快速迭代的几个要点。

PS：为什么以 Scrum 作为例子？非安利，Scrum 只是一种工具，市面上有许多敏捷工具和敏捷方法，但 Scrum 相对来说具有代表性。


Scrum 的历史最早可以追溯到 1986 年，可以说，它作为一种工具已经诞生了很久。那为什么在近几年这种方法变得如此热门？究其原因是因为互联网公司的经营理念不断变化，更加注重响应快、MVP 理性试验、数据化决策。换种说法，现在公司更注重 “小而美”。过去追求宏观叙事，讲求 “大而全” 的产品理念已经很难实现，那不妨就做行业中的核心，践行精益创业的理念。也因此，传统的瀑布流研发模式并不能支撑这种理念，Scrum 自然就被推到了台前。

推荐一篇文章： flomo 团队做客得到直播间，聊聊小而美的产品及创业

Scrum 的特点​

Scrum，可以把这种产品研发流程想象为精益创业的具象化，特点是小而快。

团队规模小​

提示

亚马逊的两个披萨原则

在亚马逊早期，杰夫·贝佐斯制定了一个规则：每个内部团队都应该足够小，两个比萨饼就能解决伙食问题。这并不是要削减餐饮开支，就像亚马逊做的几乎所有事情一样，它专注于两个目标：效率和可扩展性。前者是显而易见的。一个较小的团队，花在管理和让员工了解最新情况的时间会更少，而花在需要做的事情上的时间就更多了。但对亚马逊来说真正重要的是后者。

把一件事向 N 个人说清楚的难度是指数级的。想象一下，告诉一个人提升学习效率的办法，和告诉不同教育阶段的学生这个办法，哪个难度更大？很显然前者更容易被说服，后者则需要花更多的精力和时间去实现。更别提在这个过程中还需要因材施教，让每一个人都能理解你的办法。

因此小规模团队的沟通效率是很高的，在磨合度较高的团队，同事能够更快地理解你的意图。对于大团队来说，需要 PMO 或者计划软件（比如 Jira、禅道）来管理进度。现在只需要一个在线看板就能够理清楚，或者在团队办公室的墙上贴上几张便签就足矣。但小团队也会受限于规模，产出的结果不如大团队，于是就有了以下第二、三个特点。

目标颗粒度小​

团队的人力有限，产出必然也有限。在不考虑人力成本的情况下，可以通过配置多个团队并行工作，解决总量不足的问题。每个团队只需要关注自己正在实现的目标，而这些目标叠加起来就形成了一个完整的产品。

02

多个团队并行工作


频率高、节奏快​

一种方式是耗时短，要求人数多。另一种方式则相反，耗时长，但是能够节约人力。单个团队可以交付大量结果，不过只需要更多的时间。

03

一个团队单线程工作


回到一开始讨论的话题，前文说 Scrum 作为一种常见的互联网研发流程，要求快速迭代，要求小而快。那么现在遇到的问题是：

  1. 如果采用多个团队并行，则会耗费较大的人力成本
  2. 如果采用单个团队开发，则会耗费较大的时间成本

过长的交付期会影响创业团队的市场响应速度，增加失败概率。初期的创业团队又不能要求过大的人力投入，那么应该怎么做？

Scrum 给了我们一种可行的产品发布思路，通过 2 周 1 次，甚至 1 周 1 次的快速迭代发布，来满足小而快的交付要求，尽快地得到用户反馈。

04

Scrum，快速迭代的理念


在即刻 App 上看到过这么一则数据，在各大厂开发的 AI 工具中，有一个独立团队开发的 AI 工具（AI帮个忙）日活遥遥领先。从侧面也反应出更快地迭代速度甚至能 “打败” 大厂开发的产品，毕竟许多大厂的研发流程已经高度复杂化，这给践行快速迭代的产品留下了宝贵的突破空间。天下武功，唯快不破。

运作方式​

Scrum 就像是一列火车​

企业需要有明确的目标（Goal 1、2、3...），为了实现目标需要做若干的准备（Sprint 1、2、3...），最终将目标和准备结合，就形成了一列完整功能的火车。目标就像是火车头，而若干的准备就像一节一节的车厢。

05

Sprint 的中文翻译为冲刺，为什么叫做 “冲刺”？放在这里其实很好理解。

产品团队一般会有需求池，即便团队没有，每一个产品经理多多少少也有一些想做或者用户反馈的功能。那么，当企业提出了一个目标，首先按照之前文章提到的方法，先拆解。将企业目标拆解为一个个 “用户故事（User Story）”，然后通过分析罗列支撑用户故事的产品功能（Feature），来匹配需求池中的功能。

06

举个例子，假如现在我是一个网红社区的老板，我要设立这么一个目标：

  • 让产品内的 KOL 能够与粉丝高频互动，以提升 App 的 DAU 和粘性。

那么，产品经理通过拆解，可以获得几个简单的用户故事（User Story）：

  • User Story 1：用户可以分享自己的邀请码，邀请粉丝加入社区；
  • User Story 2：用户可以发布视频内容；
  • User Story 3：用户可以给其他用户的内容打赏；
  • ...

以第一个 User Story 为例，可以再度拆分成几个具体的产品功能（Feature）：

  • User Story 1：用户可以分享自己的邀请码，邀请粉丝加入社区：
    • Feature A：用户可以在自己的主页生成邀请海报；
    • Feature B：用户可以将邀请海报保存到手机相册；
    • Feature C：用户可以将手机海报直接分享到微信朋友圈；
    • Feature D：用户可以使用微信扫码识别海报打开对应的用户主页并关注；
    • Feature E：用户可以自定义自己海报的背景图片；
    • ...

其中，一个个 User Story 就组成了 Sprint，为了实现企业目标（Goal），就需要完成 User Story，要 “冲刺”。这就是 Scrum 中提及 Sprint 的原因。

打造车厢的四道工序​

前文详细讲了 Scrum 的机制，是如何一步步拆分和组合的。那么放到实际的产品开发流程中，Scrum 是如何被组织起来的？这就要来聊聊产品经理的日常工作：开会。

07

Review Meeting 评审会议​

评审会议一般由产品经理主持，向团队介绍希望在这节车厢（这次 Sprint）实现的功能有哪些，分别是为了满足怎样的用户场景，产品设计文档（PRD）就是这时候被拿出来评审（Review）的。

PS：希望没有勾起大家过去被开发小哥哥们怼天怼地的惨痛经历...

但有时候有很多很简单的小功能需求，并不值得撰写结构严谨的 PRD，可以简单的将需求表述出来即可。又想起刚当产品经理的时候，非常喜欢把简单的需求写成一大段复杂的 PRD 文档，结果在需求评审时花了不到几分钟就讲完了。有时候简单的需求，一句话带过就可以。

在一些磨合得还不够好、或者产品极其复杂的团队，有时会多开一次叫做 Pre-review 的会议。简单来说就是先拿需求和技术团队碰一下，看看实现难度大不大，有没有简单的实现方案等等。避免在正式的需求评审中频繁出现 “做不了” 或者沉默的尴尬局面。

08

在进行评审会议，产品经理需要完成产品设计的工作。还记得上文提到的需求池吗？产品经理需要从目前的需求池（Backlog）中挑选优先级较高的需求（用户故事），并进行对应的产品设计。经常提到的 P0、P1、P2 就是对于优先级的表述，P0 级别意味着优先级最高。

09

Select Story to Sprint


Backlog，也即需求池。是产品经理日常接收到的需求，来自公司的各个团队或者客户（用户）反馈，需要定期对每一项需求进行价值判断和优先级排序，始终把最重要的需求放在顶端。然后根据产品经理对研发团队产出能力的预判，选择数个最重要的需求纳入到下一届车厢的功能目标，并同时进行产品设计、PRD 撰写。

Planning Meeting 计划会议​

在完成（预）评审会议，工程师团队理解了车厢（Sprint）功能设计后，便会在内部评估团队能力和功能的实现方式。他们会进一步将产品经理提出的功能（Feature）细化为具体的（Task），以便能够准确预估工期耗时和人力分配。最终，会给出这节车厢的最大容量和包含的功能。

10

工程师团队对于产品需求的计划


再回顾一下前面提到的目标：

  • Goal：让产品内的 KOL 能够与粉丝高频互动，以提升 App 的 DAU 和粘性。
    • User Story 1：用户可以分享自己的邀请码，邀请粉丝加入社区；
      • Feature A：用户可以在自己的主页生成邀请海报；

什么叫做 Task？即是对产品功能（Feature）的拆解，这个拆解会更偏技术性：

  • Feature A：用户可以在自己的主页生成邀请海报；总预估耗时：2.5 人日
    • Task a：在用户主页提供生成海报按钮。预估耗时: 0. 5人日，研发同学: 小王
    • Task b：服务器端提供用户信息接口，返回用户的邀请码。预估耗时: 0.5 人日，研发同学，小李;
    • Task c：用户端能够根据返回的数据生成海报图片。预估耗时: 1 人日，研发同学: 小王；
    • Task d：长按图片可以保存至手机相册。预估耗时: 0.5 人日，研发同学: 小王；
    • ...

当然，Task 还可以进行进一步细化，比如：

  • Task a：在用户主页提供生成海报按钮。预估耗时: 0. 5人日，研发同学: 小王
  • Task b：服务器端提供用户信息接口，返回用户的邀请码。预估耗时: 0.5 人日，研发同学，小李;
  • Task c：用户端能够根据返回的数据生成海报图片。预估耗时: 1 人日，研发同学: 小王；
  • Task d：长按图片可以保存至手机相册。预估耗时: 0.5 人日，研发同学: 小王；
    • Task d-1：支持 iOS 系统手机相册功能的保存。预估耗时: 0.25 人日，研发同学: 小王；
    • Task d-2：支持 Android 系统手机相册功能的保存。预估耗时: 02.5 人日，研发同学: 小王；
    • ...

至此，团队对 Sprint 结束后能够交付的功能基本达成一致。此时，产品经理便可以向运营团队告知结果，推动他们提前做好必要的运营准备以迎接即将上线的功能。

Daily Meeting 每日会议​

也称之为每日站会（Stand-up Meeting），顾名思义就是每天站着就能开完的会议，往往 10 来分钟。每个人介绍一下手中任务昨日的进展和今日的计划，以及需要协助和调整的部分。会议前，需要大家先将自己负责的 task 的状态进行更新，比如：to-do、doing、done之类的。

Daily Meeting 是非常有效的团队沟通方式，以"日”为维度复盘，避免进度风险。

Retro Meeting 回顾会议​

回顾会议，也可以称作复盘会议，一般很少出现在 Scrum 中。而是会在向上汇报时以文档或 PPT 的形式呈现。但在团队中，评估在打造车厢的过程中出现的优点和缺点相当重要。好事要发扬光大，坏事要避免重蹈覆辙。经过这样一次次的车厢打造，团队的信任感、效率和能力便得到了提升。在实际工作中，Retro Meeting 并不要每次都召开，相关负责人可以根据团队的状态动态安排。

另外，由于团队会由产品经理、交互设计师、UI设计师、研发工程师、测试工程师组成。他们的职能各不相同，当产品设计进入研发阶段后，设计团队便开始进入下一节车厢的设计周期。因此实际工作中，车厢是交替制作的。

11

以上运作方式在互联网行业已经应用非常广泛，大家也可以在网上找到很多资料，所服务的公司也定会有更细节的要求帮助大家提效。

Scrum 的工作流其实也很适合自己的成长路径规划，给自己定 1 个全年目标，然后拆解成 52 个周，每周实现一个小故事。之后我会分享如何利用 Scrum 理念打造自己的效率系统。

参见：如何保持高效