>

奥门新萄京娱乐场精益产品需求的要义,产品经

- 编辑:奥门新萄京娱乐场 -

奥门新萄京娱乐场精益产品需求的要义,产品经

原标题:产品经理的新利器——体验画布

1. 需求的新定义

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

1-three-waves.jpg

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

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

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

图2 软件开发方法的沿革和需求定义的演绎

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

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

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

原作者:Alastair Simpson

本篇文章内容来自2016年TOP100summit用友集团开发管理部总经理罗涛的案例分享。

编辑:Cynthia

2017年11月9-12日北京国家会议中心第六届TOP100summit,点击进入有机会获得免费体验票。

〇.引言

奥门新萄京娱乐场 1

奥门新萄京娱乐场 2

《人人都是产品经理》里说到:

因为生活中存在太多的问题,从而产生了不满意,而问题就是“理想与现实的差距”。那么人类会很自然的产生“减少甚至消除这个差距”的愿望,这就产生了需求

体验画布是由Atlassian这家公司实践一种团队协作工具,了解到体验画布其实是一件非常偶然的事情,但是在网上关于体验画布的资料非常少,所以我仔细研究了一阵,也在团队中做了一些小范围的实践,借此将这块的经验做一个记录,希望后续能够更好地应用,提升团队协作效率。

2. 需求问题的多重挑战

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

3-Common-Requirements-Problems.jpg

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

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

图4 需求的多重挑战

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

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

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

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

译者:励定洲

导读:在面对需求的变化无常、人员的变动和技术的更新时,对客户价值的识别尤其重要,这是产品成败的关键。如何在产品研发过程中精准定位用户价值,并针对用户价值分析用户场景、划分场景迭代计划,从而优化研发产品管理、研发项目管理、激发团队战斗力、提升客户满意度,建立新的研发模式,不断改进个体的沟通模式,启发大家的思路,形成了团队新的工作风格?

一.IT发展的三个阶段

奥门新萄京娱乐场 3

IT发展的三个阶段

奥门新萄京娱乐场 4

软件开发方法的沿革和需求定义的演绎

奥门新萄京娱乐场 5

开发方法

=

奥门新萄京娱乐场 6

3. 这么多挑战,有解吗

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

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

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

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

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

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

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

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

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

这周我同二十五位毕业生分享了一些设计经验,他们也向我抛来了许多问题,其中大多数都是关于如何构建面试用的作品集、在Atalssian做设计的工作内容,以及如何入门用户体验和设计相关行业。

通过实践我们在产品需求管理中形成了一套符合团队实际的工作方法论,教练出一支可以持续交付的高绩效团队,培养一批敏捷改进的骨干和积极分子,对完成新产品的研发起到了关键作用。

二.精益产品的需求

什么是体验画布?

4. 精益产品需求是什么

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

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

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

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

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

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

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

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

精益产品需求的目标:

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

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

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

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

“精益产品需求”方法:

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

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

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

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

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

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

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

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

应用实践

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

其中有一个问题让我记忆犹新:

本案例从集团某行业研发中心产品研发团队的实际情况出发,主要分享该团队在产品需求、开发管理等方面,以及客户价值的定位、场景的分析、迭代的规划、方案的验证等方面所做的创新,深度介绍新产品研发的POA、MVP、影响地图和故事地图的实际应用和具体效果。每个部分都会分享项目真实的体验,希望读者能从本中获得启发和灵感。

2.1.重新定义下“需求”

需求“建立在商业、技术和人之间的一组动态的、待验证的假设”

挖掘和定义需求的过程,是一个不断验证假设、在试错中学习、逐步逼近直至找到与市场的“契合点”的过程。

体验画布是什么?下面就是一张体验画布的示意图:

5. 写在最后

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

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

  • 一是“产品思维”,“人人都是产品经理”,认识负责产品的生命期,根据不同的生命期取舍不同的需求实践,全面掌握不同生命期的实践方法;

  • 二是“精益思维”,以业务成效来度量,对需求要有效做减法。

“作为设计师,你解决过的最困难的问题是什么?”

一、案例启示

2.2.精益产品需求的目标:

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

奥门新萄京娱乐场 7

我认为我的回答或许并不是学生们期望听到的答案:

基于价值的产品发掘、定义、分析和交付是打造高绩效团队的前提和基础。

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

1.对业务领域、市场、用户需要有洞见,来主动驱动业务变化,而不是仅仅理解跟随业务变化;

2.真正以客户/用户为中心,像客户/用户一样思考,由客户/用户价值来驱动决策,而不是利用组织政治来决策;

3.共同一致的需求愿景和目标,高度透明、可视化、协同地、高质量地需求沟通,而不是不写文档、频繁但低效地沟通

4.去中心化的产品体系架构和产品团队,负责产品的整个生命周期,而不是项目团队,只注重交付的速率不注重交付的价值;

5.以业务成效来度量和验证价值,形成价值闭环,而不是单单衡量IT团队的交付效率和产能;

6.产品的需求,少就是多(Less is More),做减法。

阅读原文,戳这里:《精益产品需求的要义|TW洞见》

体验画布包含以下几个部分:

“对于所有设计师来说最困难的就是如何让公司的其他成员相信在用户体验和设计上的投入是值得的”

价值是产品成败的关键,做项目之前首先要确定能给客户提供什么价值;

2.4.需求的三层次

就是能够把业务需求和用户需求转化为软件需求,保证最终的软件能满足用户需求,并带来业务价值。举个例子:

奥门新萄京娱乐场 8

需求的三层次

阅读原文,戳这里:《TW洞见〡在ThoughtWorks做BA是怎样一种体验?》

(1)假设(Hypothesis)

尽管用户体验设计在这几年掀起了热潮,如何真正介入仍然是个议题,并且我相信这是许多设计师都匮乏的一项技能。

需求是在场景中的需求;

2.5.需求的四步骤

奥门新萄京娱乐场 9

需求的四步骤

团队认为这个项目可以给客户带来的改变,一般会表述为:“我们觉得……会带来以下这些效果……”

让利益相关者确信改进用户体验的重要性是件难事。比如告诉一位CEO界面设计如何如何并不能获得实在的成效。同样地,去说服一个琐事缠身的产品经理也不易。

快速验证帮助产品实现客户价值的最佳方法。

(2)问题(Problem)

作为设计师,说服他们、使他们信服同样是你的责任,讲述一个值得信服的故事来帮助团队中的其他组员理解用户在使用产品时候的体验,并明白改进这种体验的重要性。

二、案例背景

是什么出发了假设?清晰地列出挑战问题和根本原因

如果你不能讲述一个好的故事,那就可能会陷入糟糕的境地,当前很多团队雇佣用户体验人员,却只期望分配一个不合理的时间和不成正比的投入就能让他们对用户体验做出改善。以我过去作为设计顾问的经验来看,很多时候客户会对调研的需求或者设计流程产生质疑。

一年以前,XX研发部刚和原来的部门分开,过去的一年半里团队没有发布过任何版本、人员流动非常频繁,这些原因导致整个团队士气低落。研发负责人和需求经理找到我,看能不能帮他们进行敏捷转型。

(3)用户角色(Customer Personas)

“我们雇用你,而且你是个用户体验专家,那么调研和这繁琐的流程对我们有什么意义呢?”

我首先做团队调研,发现相关方处于互相看不顺眼的状态:

谁有这个问题?他们的动机是什么?他们想要完成什么?

雇佣某人并不等同于拥有了一个正确的设计流程。

客户方典型没有建立信任感。客户常说“你做的东西根本不是我要的!”;“你不懂我啊!”,“要我等这么长时间!”,“根本没提供给我任何的价值呢!”;“要想上线,这个必须这么改一下!”;“你们都是按照我说的在做,业务水平不如我,那就听我的吧。”

(4)利益相关者(Stakeholders)

理解如何运用数据和定性反馈去明确用户体验的重要性,并考虑如何利用这些信息来讲述一个好的故事,以让那些利益相关者信服。这个过程是一门艺术,然而艺术从来都不是简单的玩意。

产品团队很痛苦。一方面被客户逼,被客户骂,一方面在开发面前,面对超出预期的交付周期,要面对“你说的这个需求到底是哪个客户会这么用?”;“你又不懂技术,这个没法实现,必须换方案。”等类似的质疑和争吵。

哪些人支持这项工作?哪些人有可能妨碍这个项目?哪些人也有一些要求?

三年前的Atlassian只有六位设计师,而如今我们的团队已经扩充到了六十人,并仍在快速成长,我们已经成为了用户体验行业的领军企业。我们与产品经理、开发人员以及客户协同打造属于我们的设计环境。

开发团队更痛苦。天天996、007加班加点做出来的产品,产品团队一句“这根本不是我要的”就退回了!说不清为什么加这个功能,手头工作还没做完新的变更又来了。好不容易做完了,用户不接受,说产品理解错了…

(5)团队(Team)

作为一个设计团队,我们在组织内分享这些故事。我们把人物角色重新定义在一系列卡片中,这样他们就能被很好地被作为故事的一部分粘在在的设计板子上。

以上问题造成产品需求与市场脱节,所做的产品客户方不认,并且由于薪酬和发展等原因,核心人员流动很大,而市场又存在更多的需求需要去满足。所以团队有强烈的诉求通过引入新的研发过程来改变现状,并希望能在年内推出新的产品在客户处实施上线。

建立这种成功经验需要什么经验和技能?

罗马不是一天建成的,我们当然没有解决所有的问题。Atlassian同样面对着其它软件团队会遇到的问题。比如我们是怎么样平衡改善体验和增加功能的?什么会对我们的用户产生影响?如何讲一个更好地故事,以让我们的产品经理和工程团队确确实实认识到客户的痛点和我们预期的解决方案?种种问题同样困扰着我们,值得庆幸的是至少我们的方向是正确的。

三、案例复现

(6)价值(Value)

3.1 策略与效果

什么是可能的用户利益和业务利益:

奥门新萄京娱乐场 10

  • 预期客户收益;
  • 商业上的利益;
  • 技术上的利益。

图1 打通产品研发的任督二脉

只列出可度量的内容,并根据顾客感知价值把他们视为一个集合。

为了敏捷改进更好地落地,并且发挥敏捷的真正意义,我根据了解到的现状和团队进行了深入沟通,确定了“从加强产品管理入手,发掘真正的用户价值,并快速研发产品,帮助用户实现价值改进目标,从而利用产品来吸引客户”的策略。我把准确发掘产品价值称为任脉、快速研发产品称为督脉,要想这个策略落地,必须打通产品研发的任督二脉(如图1)。

(7)创意(Ideas)

经过近一年的迭代尝试,目前团队基本上打通了研发的任督二脉。打通后团队的感觉主要有:

什么可以解决客户角色的问题并满足利益相关者的要求?

业务分析更为聚焦。整体构建后,大家全部聚焦在要完成的共同目标上,共同参与,为产品出力;

(8)最低可行经验(Minimum Viable Experience)

与客户的交流更为顺利。使用客户能听明白的语言,客户更容易理解,我们也更能控制产品发出的质量;

你的创意的最小、最简单、最速成版本,它能够可靠地证明该假设。

产品开发速度提升。产品开发的速度很快,每次的范围小了,也更聚焦了,演示时客户的参与度也更高,效果很好;

(9)衡量标准(Metrics)

开发更有动力。每次与客户交流后颇有成就感,客户有期待,我们有动力,项目有进展。

定义与该经验的期望值直接相关的成功指标,用于证明或反驳假设。指标常常被忽略或不被执行,早期确定衡量它们的时间、方式和人员。

打通后团队现状是:

另外,你希望具有指标不仅是为了最终价值,还是为了能提供早期成功或警告指标的里程碑。

大团队第一阶段敏捷改进已结束,目前正在进行第二轮改进——小的特性团队,端到端交付;

(10)端到端演示(End to end demo)

各环节目标一致,干劲十足;

从客户的视角讲述一个完整的故事,重点描述解决的问题、使用的解决方案以及获得的价值。把主要情节用角色扮演、略图或线稿的形式列出来,之后可以将这些改编成高保真的模拟旅程。

把其他部门的团队合入该部门一起管理。

一个从开始到结束的完整用户体验地图,会给整个团队一个可以期待的最终目标。

3.2 案例复现

以上就是Atlassian对体验画布10大板块的定义,图片中还给出了以航空公司低价航空旅行产品的示例。

下面具体说说案例的实践经过。

从体验画布这个名称及各个板块的设置上,我们其实会比较容易联想到另外两个工具——精益画布(lean canvas)和体验地图(Experience Map)。

首先,我们需要在团队建立产品的用户思维,即所有的产品或服务要对用户有用,也就是说一定是对用户有价值的。基于这个出发点去判断产品需求优先级。

精益画布来自《精益创业实战》这本书,作者是美国的Ash Maurya。在原书中,作者将精益画布定义为一个可以随身携带的商业模式单页图表,主要用于团队思考和讨论可能的商业模式,确定从哪里开始第一步,还可以用来记录持续的学习过程。

另外,建议产品经理要对用户思维辩证思考,用户思维不是盲目跟随用户看他需要什么我就做什么,而是深入共情用户,基于用户的场景,给出用户超预期的产品和服务。

精益画布的图示如下:

3.2.1 需求优先级排列

奥门新萄京娱乐场 11

之前团队进行产品需求分析和优先级排序的方法基本上有以下几种:

体验地图也是我们做产品设计时常用到的工具,下图是体验地图的图示:

谁腿粗、嗓门大谁说了算:典型的管控型团队,“职级高的”“会吵架的”“经验老的”拥有话语权,这时候产品长啥样就得听领导的了,用户,谁在意呢!

奥门新萄京娱乐场 12

技术先进代替客户需求:这是技术主导型团队经常出的状况,我们使用了最新最好的技术,用户就应该买单。

那么,体验画布跟精益画布、体验地图有什么区别和联系呢?

以上两种方法在语言上的典型表现是以“我认为”或“我想”开始发言,都是从自己出发,而不是从客户价值出发的思路。

从我的理解上来说,精益画布、体验画布、体验地图之间是一个从粗到细,从宏观到微观的递进关系,它们分别服务于不同的产品的不同环节:

那么该如何改进呢?

  • 精益画布主要用于确定产品的商业模式,基于精益画布,团队可以非常直观地看到产品的全貌,包括产品解决的问题、服务的客户、盈利的方式、竞争力所在等等;
  • 体验画布则主要用于帮助产品、设计、研发团队间协作一个具体的问题,弄清楚某个特定问题应该以何种方式验证和解决,让团队以最快的方式了解问题的全貌并达成一致;
  • 体验地图则服务于产品理念的最终落地,将产品与用户之间互动的方式放到显微镜下,探究在各个不同的场景下,产品是如何帮助用户最终解决问题,并创造良好的体验。

第一、引入用户画像(Persona),针对不同场景对用户进行分类,给每类用户建立用户画像(具体操作可参考相关书籍)。提醒一点:我们的用户画像是为特定场景服务的,所以不要脱离场景去制作它。

由此,我们可以很明确体验画布的价值:

第二、制作用户路径图。通过移情图发现用户实际的痛点和利益点,并基于此制作用户路径图。用户路径图是针对具体场景、根据不同职能描述各职能在不同时间在做什么。

  1. 体验画布以一种直观且简洁的方式,帮助团队理解产品规划人员提出的假设、问题、场景,以及对应解决方案的核心思路;
  2. 体验地图建立了清晰的用户场景,在后续的产品设计中,设计人员能够据此作出对用户诉求和预期更合理的推测;
  3. 奥门新萄京娱乐场精益产品需求的要义,产品经理的新利器。体验地图能够提前定义好针对问题解决的MVP和衡量标准,使得研发工作以更精益的方式推进,避免资源浪费。

到目前为止,我们都是在真实地描述用户的业务实际场景,并没有加入我们自己的主观意识。

体验画布怎么来做?

第三、绘制人性矩阵。我们分析用户的行为中暗含的基本人性,研究用户心理是喜欢还是厌恶这种感觉。针对不同的用户心理,思考我们提供的产品或服务是否可以为用户实现某种用户价值。

就和精益画布、体验地图一样,要实践好体验画布,在填充各个模块的内容之前,我们也需要提前做大量的实际调研、用户访谈等工作,确保我们获取的素材是真实的、符合产品与用户互动的实际情况的。我们提出的假设是可能成立的,用户的问题是确实存在的。

到此,我们还是在研究用户行为,因为要让用户习惯使用我们的产品和服务,第一步就是要发现他们在具体场景下的行为习惯,并研究这种行为背后的心理和人性,然后通过提供超预期的产品和服务,逐步改变他们在具体场景下的行为习惯。

根据Atlassian官方的指导,我们在做体验画布时可以分为以下步骤:

第四、确定业务需求优先级。完成了这些之后,我们就要基于客户价值确定业务需求的优先级。

  • 在准备阶段,我们可以先提出一个粗略的假设,而不一定要将所有模块都填满,并将体验画布呈现在白板上,以便于团队进行头脑风暴和及时记录。
  • 第一步,与团队一起建立讨论的规则与基调,引导大家重点关注用户、问题及更好的解决方案。需要注意的是:所有人都应当参与到讨论中,而不能以旁观者的心态参与,且大家要避免在这个阶段陷入到实现细节中。
  • 第二步,开始填充画布。在进行这一步时最好能有一个主持人来控场,管理好大家花费在各个模块上的讨论时间及会议的推进。我们应当尽量按照顺序标识来推进,并不时停下来询问团队成员的意见,看哪些地方可以优化,或有所遗漏。
  • 奥门新萄京娱乐场精益产品需求的要义,产品经理的新利器。第三步,在完成体验画布后,需要为MVE和假设的验证定制文档,并指定执行者,并确保项目推进的每一步都附带有截止日期,避免只是做一个看起来不错构想最终不能落地执行。

需要提醒的是:客户的优先级有可能是出于政治方面的考虑,这在平时经常容易被忽略,但是在企业级市场这一点很可能最后决定成败。所以,虽然有时我们觉得某些需求不是真正的业务需求,我们也得听从业务代表或客户的意见。

在我们的团队是如何来实践体验画布的呢?

同时我们发现:如果项目不按照客户的价值排优先级,我们很有可能无法识别关键的成功因素。因为产品需求从用户中来,我们必须明确用户到底需要什么,然后把不同需求都列出来再确定优先级,这样产品逻辑才会更清楚。

目前我们的团队基本上是按照Atlassian官方指导的流程来执行,在执行的过程中,我们也发现官方的指导及相关说明中有一些不够清晰的部分,或是我们认为可以优化的部分,我们在实践时做出了更细化的规定或进行调整,主要涉及的点包括:

基于客户价值进行优先级排序的常用方法主要有两种:

  • 用户角色的细化:因为我们主要做的是B端的产品,在我们实际的产品使用场景和设计的过程中,我们的用户天然存在多种角色。所以我们会要求产品人员将用户角色尽可能的细化,为其建立详细的角色名片,需要列举的信息包括但不限于名字(模拟)、行业、职位(模拟)、技术背景、日常工作的方式、与产品交互的能力等,有时还会附上真实客户的非常具体的反馈内容。这样的角色我们会尽量多列一些,以避免遗漏重要的用户。
  • 利益相关者的细化:从我们的理解上来说,利益相关者是指的非产品用户的第三方,可能不一定指具体某些人,例如:某些需求涉及的一些法规限制,我们也会视为利益相关者。在描述利益相关者时,我们不仅会像示例中一样列出利益相关者是谁,而且会更细化到他可能如何促进或者妨碍我们目标的达成。
  • 团队的细化:和利益相关者一样,我们不仅会列出有哪些相关的团队成员,并且会尽量写清楚要实现目标,团队成员应当具备哪些能力、了解哪方面的情况、完成哪些事情、以及做哪些预研等等。
  • 在填充价值模块时,我会直接要求团队成员提供一句话的文案,讲清楚解决当前问题的价值,来打动用户。
  • 端到端演示我们会先定义清楚多个用户角色的不同使用场景,然后基于这些细化的角色场景开始创建体验地图。当然,因为这些体验地图是基于未完成的服务流程,且对于我们的产品来说,涉及的场景和角色非常多,我们通常不会直接在体验画布的会议中完成,而只是列出场景与角色,待会后完善再组织单独的讨论。这期间也会根据实际需要进行用户调研,以便更准确地理解用户的预期,并在做体验地图时,对整个流程中相关的交互体验做出更合理的推测。

● MoSCoW方法

以上就是我们团队对于体验画布实践的总结,在此进行简单的记录与分享。

● Kano方法

未来我们也将基于团队实践的实际情况,结合团队的一些创意,不断进行完善和改进,以不断提升团队协作的效率。

以敏捷计划应用来说,敏捷团队和客户为开发协作选择用户故事,这些用户故事必须进行优先级处理。优先级处理常以价值和风险为基础,可运用MoSCoW 和Kano 方法和通过风险-价值、成本-价值指标执行。

本文由 @不知 原创发布于人人都是产品经理。未经许可,禁止转载

要提醒的是,虽然在计划期间用户故事会做优先级处理,但敏捷团队和客户应以逐步完善(即增加知识和观点)为基础定期迭代审查优先级。

题图来自Unsplash,基于CC0协议返回搜狐,查看更多

奥门新萄京娱乐场 13

责任编辑:

图2 Kano方法

Kano方法把需求分为以下四类(如图2所示):

奥门新萄京娱乐场,第一种 基础需求,是最基本、必须有的需求;

第二种 期望需求,满足这个需求用户会觉得你的产品还可以;

第三种 兴奋需求,这个很重要,它会让用户觉得你的产品太牛了,然后他们就会帮你传播,帮你制造好口碑;

第四种 反向需求,这是用户不想要的,也许你做了会挣到钱,但用户可能会骂你怎么搞这种东西出来。

基础需求肯定要做。否则产品就不成立。你能想象买个手机不提供通话功能吗?

期望需求尽量多做。期望需求的满足会带来用户满意度的线性增长,做得越多用户数越多。

兴奋需求最希望做。能够提升品牌度和口碑的兴奋需求投入较少,但带来的价值是呈指数型增长的,所以产品要时刻发掘这种需求。

反向需求尽量不做。

另外,对于企业级应用来说:

用户主路径上的关键需求必须做,并且必须按场景做全。也就是说,你提供的应用或服务的整个路径要跑得通,不能说采购下单了要付款的时候畅捷支付不能用、企业网银也不能用,这就有问题,至少要满足主流的支付方式。所以主场景路径一定要先做,分支场景路径可以到后面再做。

符合企业和项目目标的需求优先做。也就是立项时参照的企业目标是什么。这个根据企业的情况而定,如果是要保证现金流和利润,就满足挣钱;如果是让用户体验更好,就把用户体验放在第一位。这是团队自己根据企业目标设定的,和企业愿景、使命和战略息息相关。

用户覆盖面广的优先做。一般情况下参考2/8原则,有些功能可能只有20%的人在用,有些80%的人在用,这时候就优先做80%用户需要的功能。但如果你的目的是战略预研或树立某种品牌形象,那就要考虑让10%的愿意尝鲜的所谓内行和推销员去做口碑推广。

3.2.2 两大神器——影响地图、用户故事地图

下面介绍任督二脉打通的两大神器:

● 影响地图

● 用户故事地图

首先要明确产品设计的核心是什么?

关注给用户带来的价值,而非实现难度

关注给用户带来的便利,而非商业模式

关注你可以为用户做什么,而非有多少竞品

关注用户逻辑,而非运营手段,运营不是目的

没有脱离场景的用户需求,所以在定义需求的时候一定要明确用户的场景,以及用户需要获得的价值,如图3。

奥门新萄京娱乐场 14

图3 用户 场景 需求

打通任脉--影响地图

经过一个阶段的教练,团队就产品研发的目的达成共识:研发出好的产品,利用产品吸引用户。团队的所有活动都是围绕为用户创造价值而展开的。在团队内推动敏捷改进,其目的是为了更快和更高效地提供用户所需要的价值。

在产品分析阶段能够精准定位用户价值是非常重要的。所以我为团队引入了影响地图这个神兵利器。通过学习得知:对产品开发价值本质的认知是基础,只有把它们应用到实践中才有意义。而“影响地图”就是一个从产品开发本质出发的价值定义和价值发现的实践。

影响地图(图4所示)指出:产品是为人服务的,必须通过影响人的行为才能实现目标。这也是“影响地图”名称的由来。为完成从目标到功能的映射,影响地图要回答两个问题:

对什么人产生什么样的影响可以帮助目标的实现;

提供什么样的产品功能(或服务)才能产生这样的影响。

奥门新萄京娱乐场 15

图4 影响地图

这是一张模拟的影响地图,其逻辑结构如图5:

奥门新萄京娱乐场 16

图5 影响地图逻辑结构

从这张地图可以看出,目标、角色、影响都是从使用者的角度来进行定义的,而功能则是从系统提供者的角度来进行定义的。这样就在用户价值和系统功能之间进行了映射,明确了用户价值的实现依赖,并为开发实现功能给出了明确的价值定义,确保了团队对用户价值和功能的一致认可,避免了沟通上的浪费。

我和团队一起开发了很多套影响地图,因为每个干系人都有多个价值诉求,而其中很多都是我们系统的直接干系人,所以必须分析每一个价值,并绘制影响地图。如图6所示:

奥门新萄京娱乐场 17

图6: 团队绘制影响地图局部

要注意的是影响地图不应该专属于某个职能,也不应该是某一时刻的静态规划。开发过程中,团队持续交付功能、获得反馈及其它信息输入,深化对产品的认知。随着认知的深化,影响地图不断地被修正、拓展。这一过程需要各个职能共同参与,影响地图是管理人员、业务人员、开发和测试人员共享的完整图景。

对于业务人员,他们不再是简单地把需求列表扔给开发团队,并等着最后的结果。通过影响地图,业务人员和开发人员一同完成从目标到产品功能的映射,明确其中的假设,并在迭代交付中验证这些假设,当假设被证明或否定后,应该对影响地图做出调整,如继续加强或停止在某个方向上的投入,或调整投入的方式。

对于开发人员,他们的目标不再限定于交付功能,而是拓展至交付业务目标。开发者除了知道交付什么功能,也了解为谁开发、为什么要开发。这样就可以更加主动和创新地思考,有依据地做出决策和调整。

对于测试人员,除了参与上面的规划和验证活动外,测试的责任不再局限于检查产品是否符合预定的功能,而是验证产品是否产生了预期的影响。如果没有对用户产生期望的影响,即便完美符合功能定义,也不是高质量的产品。

通过使用影响地图,团队取得了如下效果:

开发团队共同确认需要提供的用户价值,有了共同的愿景;

统一了做事情的目的和原因;

厘清了客户业务和我们提供功能之间的差异和联系;

更高效地沟通;

没有了过去“抱大腿”“纯技术”的现象。

在这个过程中,可以同步和用户确认所需功能的价值体现,减少了团队在开发过程中的路径偏差。

打通督脉—用户故事地图

做到这一步,我们拥有了体现用户价值的用户故事列表(ProductBacklog),但还是以传统的条目化模块化列表呈现,团队在开发时还是不能尽快交付用户价值。这时团队的状况是:

传统的条目化模块化列表

无法明确用户场景

无法进行全景规划和讨论

需求无场景,讨论起来太复杂,非常费时

具体来说,当我带领团队完成影响地图之后,在使用敏捷开发的具体方法开展开发活动时,发现了一个问题:在2C的软件开发中使用用户故事基本没有问题,因为这些软件通常流程都不长,没有复杂的业务依赖和流程逻辑。而企业级应用流程通常较长,涉及多个角色和更多的环节,只使用用户故事会出现只见树木不见森林的问题,不能很好地确保backlog覆盖了最重要的用户体验路径,并且不能很好地按照场景进行优先级规划。

这就不得不说说用户故事的问题了,根据相关书籍资料,主要如下:

只见树木不见森林,重要的待办项容易淹没在各种细节中看不到全貌,因而难以排列优先;

不能方便地了解系统提供功能的完整性;

不能方便地了解系统提供的工作流以及价值流;

不能方便地利用递增和迭代的方式确定发布计划以及发布目标。

也就是说,用用户故事在我们开始进行产品或项目规划的时候,首先需要梳理出一个backlog,在其中按照优先级列出要实现的场景和具体功能。这时我们遇到的问题是:如何确保backlog覆盖了最重要的用户体验路径?是否我们当前所规划的场景确实可以为用户提供价值?这些问题单纯使用用户故事不能很好地得到解决。

所以必须要打通督脉,我采用的工具是用户故事地图。用户故事地图聚焦于需求梳理阶段,帮助我们解决这些问题。

为了让团队更好地使用这个工具,我增加了场景说明并且将用户活动定位为用户的业务活动,而将task定位为系统提供的功能,根据具体场景将在场景中的用户需求用对应于task的用户故事来表现。发布可以包含多个场景,但一个场景不能被分到多个发布。如图7所示。

奥门新萄京娱乐场 18

图7 用户故事地图

我们规划发布时要先进行场景的优先级排序,用户故事的优先级由所属场景决定,当我们规划迭代时,场景及其故事会被整个放入迭代,而不能单独放入。

我们进行一段时间的试验,获得的改进效果如下

按照场景进行需求阐述,统一了团队语言,提高了研发效率;

场景化的优先级排序,交付客户更有价值;

多层次计划,有了高层次视图;

开发、咨询、实施有了统一的表现形式;

每次开发迭代都能提供有价值的产品,提供了团队自信度、动力和效率;

提高了客户满意度。

周天循环方法-快速验证

使用用户故事地图解决了场景规划和迭代规划问题,但是在具体的实现方案上,还存在如下问题:

同一场景不同角色会有不同的解决方案,大家开会讨论,谁也不服谁,变成了吵架大会;

用户对产品不满意;

Sponsor也不满意。

这时团队已经有了很好的敏捷思维,为了提升发布质量、避免不必要的浪费,我们引入了进行周天循环的方法-快速验证,即无代码客户验证。该方法指在需求分析阶段,根据发布计划、需求和设计,将下一发布需要做的场景使用线框图进行绘制,如果可能,将核心功能制作成纸板模型,带着这些模型,在发布计划开始之前和客户进行面对面的确认和沟通,确保我们所做的设计是符合或超过用户需求的,如图8所示。

通过这种方式加快了用户反馈的频率,提升了客户满意度,降低了需求变更数,提升了生产率和产品质量。同时,当产品需求和产品开发意见不一致时,双方各自按照自己的设想,制作线框图原型,拿到客户和相关干系人处进行PK,以确定最符合客户预期的方案,增强了产品和开发的理解,化解了双方的对立,强化了沟通交流的效率。

奥门新萄京娱乐场 19

图8 某项目线框图原型

通过这次改进,我们取得了如下效果:

快速编制原型,快速和客户确认;

开发和产品各自出方案,以客户价值和客户认可为依据;

快速开发;

促进对客户价值和客户体验的深度挖掘和实现;

促进了人员技术和业务能力的提升。

11月9-12日,北京国家会议中心,第六届TOP100全球软件案例研究峰会,罗涛将分享《企业级服务和产品的产品管理》。

TOP100全球软件案例研究峰会已举办六届,甄选全球软件研发优秀案例,每年参会者达2000人次。包含产品、团队、架构、运维、大数据、人工智能等多个技术专场,现场学习谷歌、微软、腾讯、阿里、百度等一线互联网企业的最新研发实践。

奥门新萄京娱乐场 20

更多TOP100案例信息及日程请前往[官网]查阅。4天时间集中分享2017年最值得学习的100个研发案例实践。本平台共送出10张开幕式单天免费体验票,数量有限,先到先得。

本文由国际新闻发布,转载请注明来源:奥门新萄京娱乐场精益产品需求的要义,产品经