当一个项目或产品规模大、需求多、利益相关者众，不知从何入手时；

当一个创新型项目或产品方向不明、参考不足、用户独特时，不知如何决策时；

当一个产品发布MVP版本后，反响平平、用户不爱用、老板不买账、研发催需求产品经理不知何去何从时；

你可以采用群体共创、群体决策的方式进行「快速启动」。

1

何为以及如何快速启动

「快速启动」（下文简称「快启」），就是当遇到产品方向不明，诸多利益相关方对于问题的定义、范围、优先级等不清晰时，盲目的计划并投入研发很可能造成延期返工风险，这时，可以通过工作坊的形式，邀请利益相关方基于一些讨论的框架，来对齐对于产品、计划的想法。

通过群体决策共同定义方向和主要路径，快速进行架构设计，分解业务、架构层面的复杂度，输出一个能够让研发开始工作的范围，制定短期内可评估、可执行的计划。

快启上承设计思维工作坊产生的经验证的产品/项目创意，下启敏捷迭代规划，所以快启一般以产品/项目愿景为起点，以用户故事地图&迭代计划为产出。

为了让大家更直观的理解快启与敏捷开发的关系，我们引用这张Gartner的图进行说明，并在原图的基础上进行了标注。

对于预算和时间都很充裕、利益相关比较重视的产品/项目，一般我们建议采用快启的全流程进行集体共识、共创再共识。当然，整个过程也可以按照产品/项目的类型、规模、阶段进行裁剪，这很多时候取决于范围的清晰程度（比如客户、目标、利益相关方的诉求是否充分对齐），推荐的完整流程、工具、方法如下：

在实际组织工作坊的时候，要特别强调的一点是，利益相关方的参与程度至关重要。我们在实地教辅过程中，也遇到过在工作坊前一天被告知业务方因有重要的会议不能参加的情况，没有业务参加的工作坊效果会大打折扣，后续需花费大量的时间来反复对齐。

下面，我们以一个DevOps平台产品为例，向大家介绍如何高效组织快启活动。

2

案例解析：产品创设阶段

1. 产品创设阶段-产品愿景

首先，我们要定义产品的愿景。产品愿景定义了产品业务价值的本质，向用户及团队伙伴反映出清晰且令人信服的信息，指导我们从创意到发布的整个过程中不忘初心，始终围绕着用户价值展开一些列活动。这里给大家推荐的工具是电梯演讲。

电梯演讲以如下结构性的句式，清晰明了的产品的用户、需求、产品特点及优势：

一般这个过程我们会这样组织：

• 将电梯演讲模板写在白板或白板纸上，让整个团队都能很容易地看到

• 将团队分成几个小组，让每个小组分别填写一个空白位置(如果团队较小，可以一组填多个）

• 收集每组的结果形成最后的陈述

以下是该DevOps平台产品，以电梯演讲的方式做的产品愿景：

2. 产品创设阶段-用户分析

明确了产品定位后，接下来我们就要对产品定位中阐述的最终用户进行深入分析。通过对用户进行多维度的分析，能帮助我们识别重要客户，为后续需求规划及优先级排定提供参考。这里给大家推荐的工具是价值矩阵。

价值矩阵提供了用户分析的多维视角，大家可根据自己项目/产品的用户属性自定义分析维度。

一般这个过程我们会这样组织：

• 每个人头脑风暴细化该产品的用户群体

• 集中讨论对产品的用户达成共识

• 团队成员分别依次对同一用户的不同维度进行打分（一般推荐0-5分），对于分值分歧较大的成员分别阐述理由，各抒己见帮助大家充分了解用户，视情况达成一致或保留意见

• 将同一用户的不同维度打分加总并在不同用户中对比，选出分值较高的三类用户

以下是该DevOps平台产品的用户分析价值矩阵实例：

在识别了高分值用户之后，我们要进一步对客户进行深度的共情及分析。这一点非常重要，因为我们要解决的不是「我」的问题，而是「用户」的问题。

在真正理解用户之前，我们并不知道要解决什么问题，所以要去观察、访谈甚至体验来发现人们表述出来的、隐含的需求，这样在设计解决方案时，才能满足真正的需要。但很多时候我们是很难触达到真正的客户的。这里，给大家推荐的工具是用户画像。

用户画像又称用户角色，是基于产品和市场构建出来的虚拟角色，代表产品的主要受众和目标群体。帮助我们从那些将与最终产品交互的人的角度来描述功能。

我们建议这样组织用户画像的活动：

• 把团队分成两人一组或三人一组。每组选一类用户

• 使用模板作为参考，要求每个组对其用户展开分析

• 每个小组向整个团队展示他们的用户画像

以下是该DevOps平台产品，对于「研发经理」这一角色做的用户画像示例：

3. 产品创设阶段-用户旅程

明确了用户角色后，我们对用户作进一步分析，通过用户旅程，描述用户为了达到目标而遵循的一系列步骤。在每一个步骤之下都有对应的触点，即我们通过借助什么工具、通过什么方式完成的这一步骤，演示用户如何与潜在产品交互。

建议这样组织用户旅程活动：

• 根据我们选定的角色，确定此角色的目标

• 将人物角色和她的目标写在便利贴上，并将其放在画布的左上方(A3纸或白板纸上是最好的，这样可以四处移动)

• 判断该用户针对其目标的起点，把这个起点写在便利贴上，然后把它贴在纸上

• 在便利贴上描述下面的每个步骤，依次将便利贴贴在白纸上，直到角色达到她的目标

• 在每个步骤下分析完成该步骤依赖的触点

• 分析每一步骤该用户的痛点

• 依序对痛点展开探讨，看是否能转化为产品/项目的机会点

• 结合机会点分析该用户使用我们的产品后的To -Be用户旅程

以下是该DevOps平台产品，对「研发经理」这一角色做的用户旅程举例：

梳理完用户旅程之后，我们可以获得足够的输入，进入「生成解决方案阶段」了。解决方案部分，我们同样带入一个咨询案例展开讲解。

3

案例解析：生成快启解决方案

1. 解决方案阶段的大型项目

首先需要说明的是，一些问题明确、整体范围清晰的产品/项目，如果只是因为难以定义优先级而导致「分析瘫痪」，造成项目迟迟不能开始，也可以省略产品创设阶段，直接通过「快启」活动进入生成解决方案阶段。

解决方案阶段主要的活动包括：

1. 用户故事地图（梳理需求全景）

2. 快速架构、技术设计

3. 划分迭代计划（定义优先级）

对于一些大型的项目，比如金融企业的核心系统替换项目，复杂程度很高，一般包含如下因素：

• 这类项目都是一把手工程，有很明确的里程碑时间要求

• 业务本身非常复杂，涉及到企业内部几乎所有的业务部门

• 众多的业务方、实施方，协作要求高

在这种类型的项目中，我们常常见到的一些模式包括：

• 用严格定义的需求文档来锁定范围，进而避免后续的需求变更

• 由一个或一群项目经理，收集、协调各个职能的计划后，整合制定整体计划

• 制定包括大量活动细节（比如WBS）的详细计划

• 计划更多是作为合约、承诺来严格执行和考评

但因为项目的复杂程度，往往我们会看到：

• 计划制定出那一刹那就已失效，只能不断延长早期的活动，按照截止时间不断倒排压缩后续活动的时间。比如需求调研延期，进而压缩开发和测试的时间。更有甚者，计划活动本身就开始导致其他后续活动的时间被压缩。

• 由于计划是一个合约、承诺，在管理层看到的纸面计划和实际的执行持续偏离，导致执行层对于计划完全失去信心，只是疲于应对，员工心累、领导累心，项目做的窝心窝火。

• 业务方和实施方针对需求范围、项目计划的持续博弈。

巴顿将军有句名言：「一个能立刻执行的好计划，远胜于一个在下周才能执行的完美计划。」这个理念，同样也可以用来指导我们对于复杂项目的计划。我们希望能够采用一种方法分解项目在业务和技术上的复杂度，通过有限的集体分析的时间投入，获得足够支撑计划决策的细节--刚刚好的细节！

依据这些刚好的细节，制定出短期（常见的周期为三个月）可行的计划。对于更长期的计划，我们可以通过不断执行，获得更多的信息后滚动制定。

2. 用户故事地图透视需求全貌

下面与大家分享一个XXTier-2 人寿保险公司的具体案例，在讨论细节前我们先来了解下该项目的背景，该项目具有如下特点：

• Tier-1 外包团队全职能+In-house团队做项目管理

• 三年X百人开发团队，per页面验收

• 固定范围和成本的合同

在咨询阶段，我们发现该项目面临着需求沟通频次少，项目验收困难的问题。

该项目的主要问题表现

首先，整个团队依赖大而全的需求文档来确认需求，以IT系统的流程视角来描述业务流程，其中包括了页面、字段解释、数据库表字段设计等。依赖文档的确认作为需求锁定，再开始开发活动。

其次，整个研发过程以文档为载体沟通需求，IT视角为主的需求文档，业务评审懵逼，需要多轮的评审讲解才能理解，业务「只判断看到的文档中的内容是都符合要求」，而并没有没有实际的确认（消极参与）。

此外，该项目每个里程碑约3个月~6个月，乙方提供了传统功能点+WBS活动粒度的项目计划，但因为需求沟通的冗长、业务的配合度低，项目计划频繁更改、延期。项目成员陷入了一般项目管理过程中常见的对立、挣扎圈：大而全的计划vs项目时间压力。

最后，验收过程业务不断提出新的问题、需求到验收的过程冗长，时间压力全部由乙方无奈承担。

针对以上现象，我们评估判断决定引入快启来帮助项目团队破局。

我们首先选取了一个业务流程、一个开发团队，说服甲方业务负责部门、乙方外包团队总体负责人投入资源试验迭代式开发模式。在内部事先演练，梳理完整的用户故事地图。

图 / 一种用户故事地图示例

然后，我们邀请客户的CEO参加，说明工作坊的目标是主要是为了探索新的业务、甲方IT、研发的协作模式。简单对日程进行介绍后，分成多个小组，每个小组有乙方研发团队的技术、产品角色、甲方的业务、IT人员组成，每个小组都由顾问负责引导。

在介绍具体流程之前，先跟各位对齐一下用户故事地图的概念。用户故事地图是以系统服务的多个用户的视角，时间线、阶段为框架，梳理用户活动、用户故事（用户视角描述的系统功能），过程中要关注的重点是：

• 优先识别所有相关角色，梳理出端到端的业务流程。

• 在一些关键的用户故事上进行澄清，但不要陷入「分析瘫痪」，该步骤的目标是确定复杂度，而不是具体的细节。

• 梳理出例外、扩展流程，同时确定总体的优先级，一般会把最短的那个流程作为优先级，首先完成。还有基于价值&风险矩阵进行优先级排序，值得强调的是只要业务&技术对于优先级达成一致就可以，不必引入过多的理论、方法。

• 业务输出为主，咨询顾问主要负责写卡、梳理流程，乙方研发同学和产品经理负责提问。

• 每个卡片是一个用户故事，用户故事简单来说就是一个以用户视角描述的需求，符合IVEST原则，但在工作坊中我们看重的更多是独立和大小适合（建议5人天以内），最终的结果可参考如下例图。

用户故事地图的好处是，可以利用叙事的时间建框架建立需求的全貌，分解业务的复杂度，优先梳理出的端到端完成流程就是复杂度最低的一个切片。

出于同样的考虑，我们要去分解技术上的复杂度，所以需要对架构做快速的设计，降低技术的复杂度。由于这个团队对于模块划分已经比较清晰，只需要基于梳理出的用户故事地图，把当前的各个系统之间交互的时序图、消息梳理清楚就可以了，这是我们经验中较为实用且有效的方法。

当然，对于那些领域划分等还不太清晰的项目，也可以尝试使用事件风暴做设计建模，这里不具体展开。下图是我们辅导团队进行快速架构、技术设计的过程实拍。

有了用户故事地图作为需求全貌，有了快速的架构设计，我们可以识别出主要的技术任务，这样我们对项目的业务、技术复杂度都有了一个充分的分解。分解用户故事过程中，也可以很容易梳理出这些任务之间的依赖关系，可以按照业务的优先级、必要的技术任务，以及初步的针对用户故事、技术任务的工作量评估做迭代计划了。下面将对该项目的迭代计划进行介绍。

3. 迭代计划

以下是该客户团队「快启」后输出的迭代计划：

从一开始，业务方就参与了整体范围、优先级、迭代计划的制定，需求沟通、验收的效果明显优于之前的模式。乙方的核心人员，架构师、产品总监对这种快启、迭代式开发的认可程度较高，认为这种方式对于和业务沟通的效率较原有的模式大大提高。

快启+迭代式开发为项目带来了很多好处，投入产出比极高：研发团队能够持续的交付业务所需的产品，给到一个不断明晰且可执行的计划发挥计划本身的作用，使工作有明确的目标和具体的步骤。同时，也能协调团队的行动，加强工作的主动性，使工作有序进行，给各方提供放心、安心的工作进展和质量。

如果项目团队不具备类似对投入产出的认知，不愿做出相应的投入，一个明显的结果，就是后续的很多其他的项目会出现一再延期，不愿验收的情况。

4

案例：用快启来重启产品研发

通过以上的案例分析，相信大家对于通过快启活动制定合理的计划、优先级的重要性及可行性有了一定的了解。下面，与大家分享另一个通过快启活动重启产品研发过程，解决由于产品定位不清晰导致上线后反响平平，产品经理不知何去何从的案例。

对于这个产品，我们在试点团队调研之初，获得的信息是团队有清晰的产品愿景及产品定位，但在方案设计的过程中，发现存在需求断流的风险。

因此，我们与各方干系人敲定，将需求全景梳理（用户故事地图）作为教辅的一个侧重点。但在实际进行中，我们发现经过几轮沟通和梳理，虽然业务负责人就Q1的需求规划予以肯定，但后续存在反复现象，虽然研发迭代走的越来越顺（主要是技术优化），但业务需求迟迟没有迭代更新，产品经理天天被cei。

研发催需求，领导要效果，产品经理夹在中间左右为难，进不得、退不了。虽然产品经理的痛点很清晰，需求很明确，但我们发现，产品经理的需求梳理工作很难进行。

为什么需求梳理不出来？原因是，经过MVP版本的验证，产品经理对该产品的主要用户有了新的思考，而这一思考，与之前业务老板所做的产品定位有偏差。在经过这轮分析和探讨之后，我们决定从MVP版本洞察出发，站在产品经理的视角梳理1.0 VS 2.0的产品定位，并基于2.0进行用户分析（价值矩阵->用户画像->用户旅程->用户故事地图）。

最后，在跟涉及战略、业务、研发负责人等角色对齐的过程中，业务老板给与了重要输入，重新调整了产品定位，补充了重要资源来进行产品底层模型设计。

基于以上内容，我们阐述的是，虽然快启一般以产品/项目愿景定位为起点，以用户故事地图&迭代计划为产出，但其实可以选择在任一环节出发，不必严格的背板。希望快启能够帮助大家的每一个项目/产品都能快速、高效启动。

快启是一个较为复杂且实践性很强的话题，为帮助大家更好的理解快启，我们与PMO前沿社区联合组织了两场直播，4月1日和4月2日两天晚上20:30，三位专家与大家见面，好好的聊一下快启。详情和直播预约，可见海报：