需求风险的坏味道和对策

大部分项目上,我所承担的角色是帮助客户寻找到产品战略,并着手落地开始项目实施,在这个过程中,我需要强制自己迅速从发散思维中回到收敛思维、从机会导向回到风险导向,因为大部分的IT项目都可能失败,成功对于IT项目而言很可能是「不失败」。

这说起来似乎有些「缺少志向」,但是在现实中IT项目所面对的,除了软件工程本身的巨大挑战、还有技术之外的需求、设计、沟通、政治、分工、计划等诸多变数,作为一个大型项目的负责人,一旦进入交付落地阶段,就应该进入「风险模式」。

而「控制需求」成为了「控制风险」中最重要的一环,换言之,对于一个失败的项目而言,需求未得到有效的控制,往往是最重要的原因。本文将讨论多年来我在需求控制方面的一些心得。

识别坏味道

要明白软件工程是一件专业度很强的事情,你必须教育客户明白,如何管理一个软件工程的「坏味道」,以下场景你是否似曾相识:

  • 「这个需求我们实现过,只需要一周时间就可以完成」;
  • 「关于这个需求你做一个方案给我选一选」、「这两个方案我都不喜欢,你们再想想?」;
  • 「这是领导要的,我也没办法」;
  • 「没有这个功能我们不能上线」。

当听到这些话的时候,作为工程管理者的你,就应该警惕可能在「需求控制」方面正在遇到挑战,让我们来分析一下每句话背后的挑战:

「这个需求我们实现过,只需要一周时间就可以完成」

你的客户正在插手你的工作量估计,这往往是最危险的。一个优秀的项目管理者首先需要做的是让客户完全了解你的工作量估计系统是如何工作的,并不断强调你的工作量估计是合理、公平和有效的。

「关于这个需求你做一个方案给我选一选」、「这两个方案我都不喜欢,你们再想想?」

这代表你的客户不理解在软件开发中,“需求分析”也是工作量的一部分,AB稿在设计界中广泛存在,在我看来是最低效的一种决策方式,这一问题在软件交付中也同样存在。你会尽可能做出一个更趋向于复杂的设计、以求得客户的决策,最终结果是需求被放大。

「这是领导要的,我也没办法」

这代表你的客户正在抛开自己的决策责任,尝试用最不负责任的方式逼迫你答应需求,一旦成功,这种行为就变成一个肆无忌惮的借口。

「没有这个功能我们不能上线」

必须据理力争,请坚信,没有阻止上线的功能,只有阻止上线的、不理智的、缺乏安全的客户。

上面的「坏味道」是我经常要遇到的情况,用什么方法对策呢?以下是我的一些总结:

尽可能靠近决策者

软件工程同样是一个「社会工程」,软件项目的失败往往是因为其社会性的复杂,导致身处其中的人无法处理所负责的合作、组织、政治、和职责关系。

而越是处于复杂社会网络的中间、越无法对整个复杂网络产生影响,最好的办法是尽可能地接近决策者。但往往你总是在跟你的直接客户合作,决策者也许是他的上级,你如何接近决策者呢?

我的建议是:尽可能帮助你的直接客户接近他的上级、也就是真正决策者,在上一个客户中我们做了以下几件事情:

  • 为客户包装向他上级汇报的PPT;
  • 总结他上级的想法,例如用可视化的方式概括他上级在说什么;
  • 将工作过程拍成视频,供他在组织内传播;
  • 每周一次的Newsletter,制作一些易于传播的图片、小视频等。

1-client-interview

(将项目过程拍摄成专业视频供组织内传播,以此接触高层决策者)

这些内容被我们的客户传播给了他的上级,甚至上级的上级,不一定要等到成功的项目,我们就已经将影响力传递到了决策者,这使得你和你的客户不再是甲乙方的关系,而是合作者,明确这个地位,才是接近决策者的重要意义。

做系统决策人

和你的直接客户建立合作关系之后,你还要努力将自己打造成系统的决策人之一。系统是各种概念建立关联关系的结果,一个优秀的系统决策人需要对以下决定产生影响:

  • 是否应该引入新的概念;
  • 是否应该将某一概念变复杂;
  • 是否应该建立新的关系;
  • 是否应该将某一关系变复杂。

2-system-evolvement

(用系统复杂度的增量方式,包括新增/加强概念和新增/加强关系来建立概念系统模型,用概念模型来讨论需求)

这套「概念系统」应该持续存在于你的脑海里,一旦新的需求出现,你就需要对这个需求做出以下决策:

  • 这是否引入新的概念?
  • 这是否在将现有概念变复杂?
  • 这是否建立了新的关系?
  • 这是否在将现有关系变复杂?

我们通常习惯于从「价值」的角度进行决策,而在真实场景中,对于任何一个没有上线的产品,谈论「价值」的意义都不大。因此谈系统复杂度会是一个更好的策略,因为你把客户与客户的讨论拖入了一个更偏向于系统工程的专业讨论,而非一个「非专业」的所谓价值讨论。

当然你必须给客户一个明确的优先级指导框架,例如在一个新系统里,建立新概念间的关系,优于对于一个已有概念或关系进行深入优化,达成一致后,决策效率会更高。

不要给选择

这个建议听起来很专断,它背后的含义是努力让客户认为你所给出的几乎是最优选择,就算再选,也应该是优、次优、最次选择这样的方式,而不应该是同等权值的盲目拍板。给选择的目的永远是让客户选择我们期待他选择的那一项,如果不给选择也是其中一个选项,那么尽量不给客户选择。

我所使用的策略有如下几种:

  • 采用完美的系统思维逻辑帮助客户认定我们选定的就是最优选择;
  • 对我们的方案给出完整的思考和选择过程、而不是最终方案而已;
  • 给出大量的假设让客户认为「反正都不知道最后结果是怎样,选什么其实都没那么重要」;
  • 最后才是给出多个方案,对优缺点进行分析。

这样的方式帮助我们强有力地抓住了需求的源头,阻止需求扩大、或朝错误的方向演进。

管理结果而非解决方案

管理需求的核心在于管理结果(Outcome),而不在于管理解决方案,结果和解决方案的区别是什么?假设一个简单的在线小额贷款的产品,也许有一长串功能需求,但核心的结果也许只有几个:

  • 借贷者能够借到合适利率的贷款;
  • 贷款者能够在合适风险下发放贷款并获得收益;
  • 平台能够管理逾期的风险,并从中获益。

把所有的需求讨论放在对于这一系列结果的影响上,而不过多讨论具体实现方式:有了它跟哪个核心结果有关?有了它会对这个核心结果有什么影响?没有它呢?

3-outcome-management

(一个用简单Outcome Dashboard来管理需求的例子,通过考察需求对业务结果的影响来规划需求)

切记一点,不是因为东西难就不做、也不是因为东西简单就做,而是思考一个需求对于整体结果的影响。换句话说,一个产品的上线,应该是一系列结果的上线,而不是一系列需求的上线,需求是结果的副产品,应该由产品经理、设计师、架构师来保证,你只需要和客户讨论「最终产品在多大程度上导致了所期待的结果」。

如果没有影响,无论有多简单,都不应该做,如果至关重要,无论多难,都应该完成。

建立游戏规则

就像之前所说的,游戏规则必须建立,这里的游戏规则,我推荐以下几条,你需要花长时间和客户进行讨论、强调、教育、再教育:

没有东西是免费的

所有东西都是有价格的,花时间的,这里包括需求的讨论、编码、改动、测试、调试、沟通等等;

讲不清楚的需求很可能是没价值的

如果讲都讲不清楚,今天讲不清楚、明天讲不清楚、你写100页文档也还是讲不清楚,大多数情况,都是没价值的需求,不如推迟决策;

这是系统思考

任何一个新概念的产生、或者一个新关系的出现,都意味着系统其他部分的成本、变动、甚至破坏,谨慎一切新概念、新关系的产生;

社交游戏

复杂问题最终都是复杂的社交游戏(Social Game),能通过政治或者社交解决的问题,尽可能不用技术解决,例如:当前项目上需要其他系统开发的配合解决,花大力气放在协商其他团队改变开发计划,而不是扩大本项目开发需求;

每个阶段都有该阶段专属的规则

特别在需求的前期,讨论越多需求,流入后期的需求范围就越大。在一开始就应该建立“需求规则”的概念,什么该谈、什么不该谈,而不是简单跳过(例如放入Parking Lot);

4-scope-principle

(在前期需求规划中我们就设定了严格准入标准,任何需求的讨论,如果不符合这些规则,都坚决不谈)

交付大于一切

永远不进行项目延期,目标是在交付期中保证交付既定的结果,而非之前约定的需求列表,可以容忍瑕疵、但不容忍延期;

尊重估算

不要尝试花时间质疑估算,你所有的怀疑会变成工程师巧妙的「套路」,他们会在另外的地方找补回来,反正你不懂,若相信、请深信。

写在最后

大型IT交付项目的巨大风险在于「需求管理」,真正的诀窍在于将管理需求上升到新的层次:

  • 决策者期待;
  • 系统概念和关系、以及产品路线图;
  • 业务结果;
  • 组织内协作和社交。

而不是着眼于需求本身,如果我们只懂得用需求列表中的工作量估算、功能排期、优先级排列,「需求失控」只是时间问题。

Share

精益产品需求的要义

1. 需求的新定义
2. 需求的多重挑战
3. 这么多挑战,有解吗?
4. 精益产品需求是什么
5. 写在最后

1. 需求的新定义

我们这里说的“需求“,是沿循计算机技术诞生以来的“软件需求”,所以可以稍稍先回溯一下历史。下图是Michael Porter的“IT变革的三次变革”[^1]。作者的本意在于看待技术在时代变迁中扮演的角色和地位,我们这里则去看看IT需求的变化特点。

1-three-waves

图1 Michael Porter IT发展的三个阶段

  • 信息技术时代:IT主要是用于实现业务、流程自动化,期望利用技术来提高“效率”,相对而言,因为工业时代的业务流程相对固化、计算机技术资源能力的相对稀少,商业市场对软件的需求变化并没有那么大;
  • Internet时代:互联网变成新的营销渠道,市场对技术的期望不单是自动化固有流程,而是延展业务,所以外部需求的不确定性、变化越来越多;同时也因为技术渗透更广,软件服务的竞争程度也更加激烈;
  • 数字时代:技术渗透到生活方方面面,引领着消费、生活、商业生态的革新,市场变化日新月异,高度竞争,企业都在追求创新,市场对企业的期望是“高响应力“,甚至是引领力。需求变得更加易变、不确定。

我想大家都深切感受到了这个突出的变化,那就是:普遍来讲,市场需求不确定性越来越高,竞争越来越激烈

与此同时,如果对比软件开发方法的发展,好像也对应有三个时代:

2-Software+3+Waves图2 软件开发方法的沿革和需求定义的演绎

  • 软件工程时代:对应于上图的“信息技术时代”。市场需求聚焦在现有业务流程的自动化,大工业时代固化下的业务流程并不会天天变,所以对需求的定义是“软件功能的规范说明”。工作方式是瀑布式的:先花大量的时间模型化业务流程,制作出详细的“需求规格说明”,然后才进行开发实现。
  • 敏捷转型时代:对应于上图的“互联网时代”。随着互联网的出现,信息技术不再是自动化固有流程,而开始延展业务,如进行网上展示、销售和营销。这时,发现需求的不确定性变大了,用传统的“瀑布”方法不能适应外部市场的需求变化,软件项目失败率非常高,于是开始寻找更轻量的、迭代试错、小步前进的轻量级敏捷方法,来提升软件团队的响应力。这时,对需求的定义也演绎为“代表着业务价值的一个单元”。但是,这种变化始于IT也仅限于IT,敏捷方法簇[^2]里需求相关的实践和方法大多是面向技术团队的,如小步发布(Small Release),产品负责人(Product Owner)要和技术团队在一起,来制定团队的迭代计划、排优先级、澄清需求问题等等。虽然开始关注业务价值,但却仍主要度量IT团队的效率和产能。
  • 精益企业时代:对应于上图的“数字经济时代”。面对高度不确定、激烈竞争的市场,发现需求和定义需求的过程,变成一个不断试错、然后逼近“正确结果”的过程,这已慢慢成为大家的共识;同时,面对市场的高响应力、引领力的要求,对需求的验证环路必然要穿越IT、销售、运营、市场等所有职能部门,才能形成端到端的闭环,持续创造市场价值,即“整个组织的更广阔精益变革”[^3]。

因此上,在当前高度不确定性的市场环境下,有必要重新定义下“需求是”:

需求“建立在商业、技术和人之间的一组动态的、待验证的假设”;挖掘和定义需求的过程,是一个不断验证假设、在试错中学习、逐步逼近直至找到与市场的“契合点”的过程。

2. 需求问题的多重挑战

下面是我们在提供咨询时收集到的一些常见的需求问题。看起来是不是很眼熟?

3-Common-Requirements-Problems

图3 组织中常见的需求问题

如果仔细去分析这些问题,本质上会归结为下面的挑战:

4-multiple+challenges

图4 需求的多重挑战

挑战之一: 需求产生时的“不确定性”。产品需求的本质都变成了“有价值的假说”,而不是传统意义上是确定的、一开始就能准确定义出来的。“市场用户需要一匹更快、永不疲倦的马”,是一个“有价值的假说”;“用户需要汽车”则是不断转向、学习的结果。人们善于解决确定性的问题,在面对不确定性的时候,往往束手无策。产品创新连接商业、技术和人,但方向有那么多,该从哪个点开始?如何在首次提出产品想法时,就能(比竞争对手)找出“更靠谱的假设”?这是前所有未有的挑战。

挑战之二: 需求经过层层分解可能完全失去原有意图。即使在最开始,我们独具慧眼,已经识别出更接近“正确结果”的假设,但在落地实现时,因为组织分工、政治、计划等约束,不可避免地会被拆解成零部件,然后再一一实现,组装完了再去验证。在这个过程中,拆解、组装之后的结果很可能让原始的意图面目全非。

挑战之三: 需求实现所必须的社会化协作导致的需求失真、或被“污染”。需求的交付是一个社会化协作的过程,所有参与其中的人背景、知识、能力、出发点、利益不同,在理解、表达、传递、接收、消化、再传播需求时,都会“解释过滤“一遍,这样的协作过程的产物极有可能让需求意图失真、或被“污染”成另外的样子。

挑战之四:需求的时效性。在验证假设的过程中,外部市场时刻发生着变化。可能就要上线验证了,市场上突然来了一个其他的产品横空出世,消费者行为因此而改变,“原有的可选项不再是可选项”。

3. 这么多挑战,有解吗

如果我们认识到,需求只是一组假设,那么我们就会:

  • 转变思维——我们的所有工作过程,不再是一个对确定问题求解的线性过程,而是一个构建(Build)- 度量(Measure)- 学习(Learn)的螺旋前进过程,我们会认为“不确定”是常态,积极主动地调整计划以适应变化;
  • 步子迈得更小一点——每次定的“需求目标和范围”会更小一点,这样尽可能让错误的弯路更短一些,验证的成本也更低一些;
  • 尽量缩减验证、反馈周期——因为这样试错成本更低,所以我们就要拼命靠近客户和用户,与他们对话,花精力研究他们、了解他们;
  • 迫切想知道验证结果——所以在在产生需求想法时,就确定好度量指标和验证方法;
  • 为了一开始找到更接近的假设,我们需要对用户、领域问题、行业生态有更为深刻的洞察;

如果我们认识到,需求层层分解会导致需求变形,那么我们就会:

  • 需求目标定小一点,尽量避免不必要的分解;
  • 简化组织结构,层级少一点,减少层层分解;
  • 建立跨职能部门,减少分解;

如果我们认识到,需求的社会化协作(沟通、传递、协调)会导致需求变形,那么我们就会:

  • 统一需求接口,减少沟通节点;
  • 按照产品职责来设置团队,让市场、技术和消费者直接沟通,减少中间环节;
  • 建立跨职能团队,避免部门政治给需求带来的污染;
  • 采用更直接、更简洁、更高效的方式去沟通,减少信息失真;

如果我们认识到,需求是具有时效性的,那么我们就会:

  • 需求目标定得尽可能小,因为目标越大、验证学习周期就会越长,失效的可能性更大;
  • 时刻关注市场变化,随时做好调整转向准备

所以,需求挑战的应对,不单单是IT团队负责需求的个人和团队的事,更是思维和文化、组织结构、管理流程、领域洞见、沟通和协作能力等各个维度在各个层面的事。

4. 精益产品需求是什么

当前,在诸多开始尝试或已经实施敏捷转型的企业里,应用最普遍的还是团队级的“敏捷开发方法“,有关需求的方法和实践,如果浓缩下来,大概像这张图:

5-agile-analysis

图5 当前常用的“敏捷需求分析“

回头检视,我们会发现通过图上这些方法、实践和工具,主要是改善了IT交付团队内部的“需求沟通和传递”,通过“小步发布“少量地改善了“时效性”的问题,而针对其他问题似乎没怎么改变。因此,也出现了类似这样的疑问:“实施敏捷需求分析的效果,也就是团队内合作和沟通更流畅了,对业务也没什么影响啊?”

如果想要全面应对这些需求挑战,则需要应用“精益企业”[^4]的指导方法——把敏捷、精益的理念思维应用在与需求有关的组织结构、管理流程、领域洞见、沟通和协作能力等各个维度、各个层面。

另外,“传统上,大多数企业秉承以范围、成本和进度为中心进行交付管理,这使得所有人都迷失了,似乎项目交付就是目的,而忽视了投资本身的初衷所要达到的用户和业务目标,更谈不上持续创新。现代科技企业所面对的竞争环境越加激烈,用户和市场的变化迅速,要能够快速适应变化,真正创造用户喜爱的,有竞争力的产品,并持续创新,需要告别以往多年“以项目为中心”的管理,建立一种以产品为中心的软件交付模式”[^5]。要根据面向业务的能力来建立产品团队,在看待需求时从产品的全生命周期——产品的机会发现、定义、启动上线、成长、成熟以及演化去看待和管理需求。

如果尝试给“精益产品需求”下个定义,就是以“精益企业”为指导,以产品为中心,把敏捷、精益的理念应用在产品全生命周期相关的组织结构、管理流程、需求沟通和协作中的方法和实践

结合第2部分的常见需求挑战,无非就是在组织层面应用精益的思想和原则:

需求挑战 精益产品需求的应对策略 方法和实践举例
市场是不确定和高度竞争的 通过设计思维去寻找有价值的需求假设;无论是在探索期和拓展期,构建(Build)-度量(Measure)-学习(Learn)的螺旋前进流程;建立产品团队,每个产品都直接与自己的客户/用户打交道;对业务领域、市场、用户需要洞察 设计思维MVP假设驱动开发验证板(Validation Board)可选性原则精益画布产品团队单一关键指标在线受控实验可视化运营,持续的领域研究和洞见,用户研究用户测试
需求层层分解会导致需求变形 去中心化组织架构、服务治理和数据存储;以业务为边界建立产品化团队;度量响应力而非效率 MVP微服务设计领域驱动设计产品团队跨职能团队
需求的社会化协作(沟通、传递、协调)会导致需求变形 协作需求分析;可视化需求;原型设计;轻量级文档;建立团队契约规则 故事墙看板墙用户故事敏捷快速启动协作式需求工作坊概念草图低保真原型行为驱动开发(BDD)实例化需求价值点分析优先级契约团队协作契约
需求的时效性 小步前进,精益创业实战流程,假设驱动开发, MVP假设驱动开发精益画布单一关键指标纵向切分在线受控实验可视化运营

精益产品需求的目标:

  • 通过在组织、团队、个人层面的精益需求发现、管理、沟通和协作实践,来提升组织的响应力和创新力。

“精益产品需求”的原则:

  • 对业务领域、市场、用户需要有洞见,来主动驱动业务变化,而不是仅仅理解跟随业务变化;
  • 真正以客户/用户为中心,像客户/用户一样思考,由客户/用户价值来驱动决策,而不是利用组织政治来决策;
  • 共同一致的需求愿景和目标,高度透明、可视化、协同地、高质量地需求沟通,而不是不写文档、频繁但低效地沟通
  • 去中心化的产品体系架构和产品团队,负责产品的整个生命周期,而不是项目团队,只注重交付的速率不注重交付的价值;
  • 业务成效来度量和验证价值,形成价值闭环,而不是单单衡量IT团队的交付效率和产能;
  • 产品的需求,少就是多(Less is More), 做减法

6-value-circle

图6 精益产品需求的价值闭环

“精益产品需求”方法:

  • 产品化方法,区分探索期和拓展期的工作方法
探索期 拓展期
基于可选性原则,快速对大量的“方案”(需求假设)逐一验证,期望其中大部分会是不匹配的,而少量的能真正解决问题;以科学方式进行一系列快速、低成本的实验,所有活动以验证假设和消除不确定性为目的,来找到产品市场匹配点; 以价值为核心要素并得到普遍共识的经济模型来进行优先级决策;将需求拆分为小粒度并限制在制品数量,以最快的流速持续为用户和客户创造价值,并收集反馈;将新的特性视为有待验证的假说,基于实际的用户和业务成效而非产出量来衡量取得的进展,并驱动产品的演进方向,甚至调整愿景;将质量内建到交付的每个环节,以高度的自动化和可视化来提高交付效率和降低风险,同时兼顾吞吐量与稳定性
  • 不同产品生命周期的关键方法:

7-lean-product-methods

图7 产品的生命周期及关键方法

“精益产品需求”实践和工具:

8-lean-requirements

图8 精益产品需求的实践和工具举例

我们在跟一家国外大型金融企业合作的过程中,他们实施了“以客户为中心”的组织架构重组,他们已实施敏捷转型5年,想借用此次架构重组来做到“精益产品化治理”,并解决“业务需求响应力慢”的问题。 他们面临的具体挑战是:

  • 经过了几十年的运营,IT系统非常复杂,仅客户平台这块新老系统超过200个,相互紧耦合。
  • 以项目团队进行工作,项目之间相互依赖,经常出现因为等待依赖而浪费大量的时间;
  • 项目启动基本上是瀑布方式,概念阶段和启动阶段长达数月;
  • 开发和运维分开,负责维护的团队觉得不被重视,长期士气低落;

他们的改进路线和应用实践如下:

9-improvement-plan

图9 XX金融企业的需求改进路线

应用实践

  • “以面向业务的能力来构建产品团队”,每个产品团队自己规划自己的项目,以持续交付、持续验证的方式来演进自己的“能力”(如发展新产品,退役旧产品);
  • 每个产品团队设立Product Owner和Product Architect,按照“业务能力职责”,共同规划自己产品体系的发展蓝图及运维支持;
  • 持续的产品需求技能提升训练和实践社区;
  • 产品团队建立后,运维放到产品团队做了之后,发现总体人员规模可以减少1/5 – 目前这1/5的人用来识别创新机会,在团队内开展创新项目。

5. 写在最后

很多企业当面临图4中列出的需求问题时,第一时间想到的就是组织需求分析人员的技能培训,给他们制定一个工作流程,发给他们一个有着“先进实践”的Handbook,然后就期望这些需求问题都能迎刃而解。但这样过了一年,发现好像没什么变化,那些存在的问题还依然存在。希望通过本文,大家能认识到:在新的数字经济时代下,需求不确定性更强,挑战来自于市场外部、组织内部的结构和管理、能力等多个方面。在实施转型或改进时,企业能以一个更系统的视角来看待,真正实现“精益的产品化治理”。

另一方面,从个人和团队来说,图5所展示的“敏捷需求分析”方法和实践依然适用,但应该有两个关键的转变:

  • 一是“产品思维”,“人人都是产品经理”,认识负责产品的生命期,根据不同的生命期取舍不同的需求实践,全面掌握不同生命期的实践方法;
  • 二是“精益思维”,以业务成效来度量,对需求要有效做减法。

参考资料:
[^1]:Michael Porter, http://www.faz-forum.com/scp/150121_SCP_Porter_Harvard_Heppelmann_PTC.pdf.
[^2]:“敏捷方法簇”,指代Scrum、XP等为代表的轻量迭代开发方法。 [^3]:肖然,”从敏捷转型到精益企业”, http://insights.thoughtworkers.org/from-agile-transformation-to-lean-enterprise
[^4]:《精益企业》. [^5]:姚安峰,“精益企业原则之:以产品为中心,而非交付项目”,http://www.infoq.com/cn/articles/the-principles-of-lean-enterprise-product-centric.

Share

精益的新产品启动与技术创业(下)

用真正对用户有价值的技术和产品去创业

接上篇,这篇咱们继续讨论精益创业的实战技法。

设计思维和精益画布是精益创业的有效技法,可以清晰方便的来帮助自己归纳分析已有的信息和资源。

设计思维

6

上图是使用设计思维来启动一个产品的过程,需要经过的过程:愿景(起点)->探索(发散)->定义(收敛)->创想(发散)->原型(收敛)->计划(落地)

愿景:理解客户的项目愿景,收集已有的关于目标用户的需求和痛点。

探索:走出办公室,倾听真实用户的声音,挖掘未知的用户需求。

定义:梳理全部已掌握的信息,定义出明确的目标用户和待解决问题。

创想:针对目标问题进行自由的发散思考,寻找任何有可能的解决方案,寻找创新的机会。

原型:将优秀的创意细化成原型,通过原型测试进一步收集用户反馈。

计划:根据产品原型拆分出产品功能清单,整个团队一起确定交付上线计划。

下面是一个实际的足球比赛产品落地计划:

7

精益画布

8

除了上面这些精益创业的办法,还需要进行一下竞争对手分析和详细的资金使用计划,来减少创业失败的情况。

分析竞争对手从而规避风险

知彼知己,百战不殆。分析竞争对手,从而规避不必要的风险。在进行竞争对手分析时,需要对那些现在或将来对自己产品可能产生重大影响的主要竞争对手进行认真分析。根据创业产品的独特卖点,分析竞争对手,下面是一个足球比赛产品的竞争对手分析:

9

制定资金使用计划

兵马未动粮草先行,初步规划好开发计划和资金使用计划,创业初期,设计良好的资金使用计划从而保证最终产品的交付。下图是一个产品6个月的常规资金使用计划:

10

在创业的路上有了这些策略和计划,会大大减少失败的情况。讨论了精益创业的技法,咱们看看一个实际落地的案例吧。

订餐应用的MVP落地实践

故事的开始: 美好一天从健康的早餐开始,可是每天买早餐都要排长队,这该怎么办?

用户:白领上班族

需求:买早餐不排队

方案:未知

11

根据调研,V0.1版只需要三个步骤:订餐, 选择取餐点,付款,(实体取餐柜入住写字楼)完成定早餐的需求,从而试图解决买早餐排队的问题。

12

(用户提前一天晚上订餐)

13

(选择取餐点)

最后结账付款。

15

(入住写字楼的取餐柜)

用户反馈数据收集:发布调查问卷,实地采访用户感受,假设新功能,验证新功能。

用户调研问题:

  1. 太晚取早餐,早餐冷掉了,这该怎么办?
  2. 我想预定面条,或者饺子,时间稍微长了,虽然是热的,但是粘在一起了?(早餐真的有人想订饺子和面条哦~)

V0.2版本改进:

  1. 带自动加热或者保温的小柜子(需要硬件支持);
  2. 细化取餐时间,更合理的配送时间。

14

原型设计时最后取餐时间可以到中午12点,但是根据实际调研情况,上线后调整到10点,每隔30分钟配送。(一般10点后就没人取早餐了。)

再次用户调研,用户需要定下午茶功能,等等其它新功能,满足不排队的需求。

16

最终通过,精益创业,MVP的方式,打磨抛光出用户由衷喜欢的精致产品!

Share

精益的新产品启动与技术创业(上)

用真正对用户有价值的技术和产品去创业

企业平均寿命从1920年的65年降到了2015年的15年,社会与科技飞速发展,大企业的既有竞争优势迅速弱化,甚至被颠覆。大企业对市场趋势和用户喜好的变化不敏感,错失机会,巨额投资产生不了预期收益。在这种大背景下,给技术创业和创新性的产品带来了更多机会。

借古比今,站在巨人的肩膀上好办事。近代历史上有那些成功的精益创业案例供我们参考呢?看看二战后的美国福特和日本丰田:

1

二战结束时,福特已经掌握了成熟的T型车生产线。但是在战后物资耗尽的日本,丰田必须白手起家,重新开始摸索。福特和丰田都是要制造一部车。

福特:稳定、大批量、执行计划:

2

丰田:灵活、单件流、需求拉动:

3

丰田这样做最终创业成功了吗?1993年,丰田汽车公司以 295 亿日元的纳税款额,荣登日本纳税榜首。”有路就有丰田车”也成为丰田车知名的广告语。

丰田的成功其实就是一次精益创业,技术创业的经典案例。丰田打破了原始的汽车制造方式,采用:灵活、单件流、需求拉动。精益的控制和度量生产汽车的每一个过程,先做出最小可用产品(MVP),尽早投入市场,收集市场反馈,然后根据反馈不断的迭代改进。

同样的,我们不想采用福特的方式制造产品,不想等产品全部做好了才投入市场,不想投入技术和时间做出来的新产品上线后无人使用。我们需要产品准确命中目标用户的真实需求,从而降低创业风险。

我们希望最终得到的不是一堆不知道未来会有多少人使用的代码,而是一件抛光已久、用户由衷喜欢的精致产品。所以需要先做出最小可用产品(MVP),尽早投入市场,收集市场反馈,然后根据反馈不断的迭代改进,不断抛光打磨产品,制造出用户由衷喜欢的精致产品,从而取得创业的成功,甚至像丰田一样伟大。

丰田是大企业,它做的是复杂的汽车,我们要做的是技术创业,一定需要借鉴丰田精益创业的办法吗?我们把功能都做完再上线,不用MVP,不行吗? 不着急一下子就回答这个问题,我们先分析一下技术创业要解决的问题,技术创业的风险,然后看看不用精益的方法是否可行?

技术创业一般要解决一个错综复杂的问题从而产生价值

实际的问题一般可以分为:简单问题,复杂问题,错综复杂的问题。创新型的产品,技术创业一般是解决错综复杂的问题,没有前人经验可以参考,从而产生价值取得成功。

简单问题:很容易理解,它的目标是明确的,达成的路径也是明确的,只要依照步骤来就一定能达成。(比如家里的灯泡坏了,如何修复?买一个新灯泡,卸下坏灯泡,换上新灯泡)

复杂问题:虽然有清晰的目标和路径,但是需要控制很多因素,每个因素都会影响最终的成败但可以通过大量实验来控制。(比如一个大水池,3个进水管,2个出水管,同时开,什么时候能把水池灌满?分析3个进水管的参数,2个出水管的参数,水池的容量,做实验,看放水的时候,水池是否有漏水或者别的损耗,放水时,水的自然蒸发,等等因素,列出公式,实验推算,最后得出实际正确的结果。)

错综复杂的问题:目标和路径都不明晰,需要根据不断遇到的问题去决策,没有现成的经验可以借鉴,创新是可以解决这类问题的。(比如每天早上买早餐要排队,我想每天早上不排队就能买上想吃的早餐。目标和路径都不明晰,需要根据不断遇到的问题去决策: 今天早餐摊位少了一个,买油条豆浆的休息了,导致排队时间更长了。今天周围园区里有一家企业放假了,买早餐的人少了,很快就买上早餐了,等等情况。)精益创业,最小可用产品(MVP)是解决这类问题的有效方法。

创新性产品(解决错综复杂问题)的特点

4

创新性产品,一般要解决一个错综复杂的问题,提供一种独特创新的解决方案,需要根据不断遇到的问题去决策,没有现成的经验可以借鉴,一般情况下,产品演进的道路是曲折往复的,最终要得到产品也是不明朗的,但是最终都要逐渐收敛逼近到可用的产品,产生价值从而取得成功。

在技术创业时您可能遇到下面的情况和风险

  1. 目标用户是否存在?想到了一个解决方案就直接想要做出来,顾不上做用户调研,不了解设想的目标用户是否真正存在、用户群有多大、生活的状态是怎样的。
  2. 目标用户是否有这个需求?思考从解决方案出发,想到或看到一个功能,觉得不错就想做。没有去验证目标用户是否真的有这样的需求,是否早就有了很好的产品解决了这个需求。
  3. 技术与解决方案是否有亮点?想到一个还可以的解决方案就不再继续探索了,一些创新的点子觉得它不可能就直接放弃了,没有掌握做创新的有效方法。
  4. 一开始就规划大而全的产品有用吗?想做个大平台,想要做精致的用户体验,想做精品,想到什么功能不错就想往产品上加,想要一下就做的很完美。但如果一开始方向就错了,再精致的产品,它的价值也是零。

再回到我们起初的问题:要做的是技术创业,一定需要借鉴丰田精益创业的办法吗?我们把功能都做完再上线,不用MVP,不行吗? 分析了技术创业要解决的错综复杂的问题,最终产品的不确定性,要面对的风险。由于这些因素,所以需要使用精益创业的方法来帮助解决这些问题,规避这些风险,这是实际实践过程中总结出的一套有效的应对办法,能有效的帮助技术创业取得成功。

精益创业的核心思想是:专注于学习未知,积极验证假设,尽早面向客户,持续演进。具体操作方针:

  1. 科学地做调查和实验:一开始创业者需要认识到对用户、需求、解决方案的猜想都是主观的,必须把它们视作“假设”。快速开发功能并上线给用户使用,通过数据追踪等方式进行用户研究,验证这些假设是否成立。
  2. 尽早上线并开始测试:不要等到所有功能开发完毕才上线,而是将核心功能开发完成,形成一个最小可用产品(MVP)就立刻上线,尽早开始对用户需求假设进行测试和验证。
  3. 追踪可帮助决策的指标:在决定追踪哪些指标时,不要只是追踪宏观的整体指标,如总的PV、UV,而是要找哪些能够直接验证功能价值,能够帮助我们形成判断的针对性指标。5
  4. 建立反馈环并持续测试和验证:建立“猜想->建构->验证”的反馈环,每个迭代都能持续地测试功能的价值假设是否成立。假设成立就追加投资,假设不成立就要尽快做减法,删减后续投入。借助这种方式,来推动产品的持续成长。

时常使用这4条来检查自己的创业产品,不断收敛逼近到真正可用的产品,规避风险。到这里咱们讨论了精益创业的方法,下篇咱们继续讨论实战的技法。

Share

实践中的精益产品设计

精益产品设计是一种软件开发流程,旨在开发出创新型的新产品。这种设计理念帮助企业尽快在市场上推出新产品、在与用户的沟通中进行产品验证,并持续地回应用户反馈。精益产品设计将轻便设计和用户调研贯通于整个敏捷开发过程,而不必事先做好大部分的设计和调研。

在精益产品设计中,从第一天起,产品经理、设计师和程序员就一起创造一个完整可用的产品。首先要有一个清晰的产品定位,团队可以根据这个定位集中开发一个核心功能,之后上市抢滩试水。通过连续的用户调研,共同设计和开发的迭送代,产品才可以基于最新的市场反馈不断更新。待达到用户愿意付费使用的版本时,这个产品已经具备了经过验证的需求,并且准备好推向市场了。鉴于当前各个行业的飞速创新,做一个可以满足当下需求的产品 (而不是六个月或一年前的需求 )是成功的关键。

精益过程:把精益产品设计带到团队中来

natalie-lpd1

小型团队可以通过各种跨职能角色的合作来展开精益产品开发。以下是ThoughtWorks团队使用的几种开发最简可行产品(MVP – minimum viable product) 的方法:

  • 合作紧密的小团队:小型团队的成员可同步共享最新状态,当问题出现时,在设计和技术上的决策也更快。
  • 跨职能搭档:不同职能角色的参与有利于对话和做决策,这意味着整个流程会更快、反应更灵敏。传统的从分析到设计,再到开发的流程其实更易变且随机。
  • 从草图到代码:当你的产品每周都需要很快更新的时候,从草图直接到代码是一个既加速又止损的好方法。设计师和程序员搭档,从画草图,码代码,不断迭代,直到建立起好的方案来创建界面,这保证了最终方案不仅可以迅速实施、而且具有较高的可用性。
  • 设计墙:随着产品功能的增加和更迭, 把最新的设计草图、线图在一个大的墙上展示出来,可以起到很好的可视化信息和交流产品方向的作用。这样做使整个团队对接下来的任务以及产品的组成部分一望而知。
  • 用户调研和测试: 新产品通过对很多影响因素的应变而逐步提升,其中最关键重要的是用户反馈。把现有的版本拿去给用户使用,频繁地收集用户反馈,是让产品更快适应用户需求的关键。

精益工具:跨团队实现精益

natalie-lpd2

在设计和开发中,将开发人员分成多个团队或者将设计、开发分成不同的小组,会大幅度减慢精益流程。为了更快地推进和有效应变,我们在ThoughtWorks使用以下设计开发工具:

  • 扁平化设计:扁平设计不单单是一个潮流,它也使程序员能更快的地改变风格设计并在代码中轻松实现,整个过程并不需要设计师切图并上传。
  • 图标字体:花些时间制作SVG图标并把它们含在CSS字体中是很值得的。这使改变图标大小和颜色变得无比快捷,并且不需要等设计师切图。
  • 风格图块:设计师创建图块或版来展现贯通于整个产品的公用界面元素设计和交互形式,而不是为每一个网页/应用页创建一个视觉包。这样,设计一个新的功能只需要少量的草图或线图,因为视觉风格已经建立了。
  • 实时的风格指南:这是一个大家共享(或放在本地)的网页,它显示当前网站的所有风格元素,程序员可以看到哪些元素已经完成,哪些元素还有待开发。实时的风格指南有效地防止了代码库有10种颜色有微妙差异的按钮,也减轻了改变这些颜色的痛苦。
  • 专门控制风格的Gem:如果你有多个Ruby应用,可以把公用的设计风格放到一个ruby gem中,这样它就可以被用到不同的产品中了。这使得多个产品可以有统一的视觉效果,并且需要更改设计风格时,只要更改一个地方即可。

精益理念:把精益产品设计带到你的整个组织

如果想要在整个组织中使用精益过程,但你们有多个产品或者多个办公地点,那在决策链中应该尽早采取精益思维。这可以防止没用的产品构想带来无效工作。把精益产品设计带到整个组织意味着团队结构、文化和工作流程的改变,比如:

  • 嵌入式用户体验设计师:孤立的设计团队会减慢整个开发过程。在团队中有一个设计师提供咨询,建议不同的实现方法,观察实时的更改,可以加快编程的速度,也可以提高设计质量。
  • 目标导向性的团队:当目标清晰时,团队便可迅速对想法进行探讨并检验,对反馈做出及时的反应。这使得团队可以尽早摒除不成功的想法,并且更快地为用户找到更有价值的解决方案。
  • 精益思维:把精益思维运用到整个产品策略中,而不是仅仅停滞于功能和任务的层面。这可以更早地减少没必要的工作。你可以在设计和开发开始前就检验想法。需要向别人展示以验证想法,可以使用纸上原型或仿制交互式原型。
  • 科学的方法: 在开始的阶段多花些时间去定义问题,采用科学的方法去验证解决方案是否有效,可以保证团队开发“正确的”功能。这可以大量减少在编程、测试、维护和产品研发中的浪费。
  • 信任,谦逊和勇气:在大型组织中实施精益开发方式是具有挑战性的,它需要持续的努力。作为产品负责人,虽然刚开始无法预测成型的产品,你也必须相信精益产品设计流程会成就优秀的产品。你还需要谦逊地意识到任何来自你自己,团队或组织的想法可能并不能正确满足客户需求。最终,保持信任和谦逊都是需要勇气的。

在有着不同规模的组织和不同经验的团队里,精益产品设计会面临不同的挑战。但是只要应用得当,便可将优秀的创新型产品迅速推向市场。

Share