微信号:ThoughtWorks

介绍:最新技术雷达/各类技术干货/精选职位招聘/精彩活动预告/经典案例故事,就在ThoughtWorks.

精益产品需求的定义|TW洞见

2016-07-28 21:23 亢江妹

今日洞见

文章作者/配图来自ThoughtWorks:亢江妹。

本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站,在使用时必须注明"内容来源:ThoughtWorks洞见",并指定原文链接,违者本网将依法追究责任


1. 需求的新定义

我们这里说的“需求”,是沿循计算机技术诞生而来的“软件需求”,所以可以先稍稍回溯一下历史。下图是Michael Porter的“IT变革的三次变革”。

作者的本意在于看待技术在时代变迁中扮演的角色和地位,我们这里则去看看商业市场需求的变化特点。  


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

  • 信息技术时代,技术主要被用于实现业务、流程自动化。人们期望利用技术来提高“效率”,相对而言,因为工业时代的业务流程相对固化、掌握计算机技术资源的稀少,商业市场对软件的需求变化并没有那么大;

  • Internet时代,行业互联网化。市场对技术的期望不单是自动化固有流程,而是延展业务,所以外部需求的不确定性、变化越来越多;同时因为技术渗透更广,竞争程度也更加激烈;

  • 数字时代,技术渗透到生活方方面面,引领着消费、生活、商业生态的革新。市场变化日新月异,高度竞争,企业都在追求创新,市场对企业的期望是“高响应力”,甚至是引领力。

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

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


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

  • 软件工程时代,对应于上图的“信息技术时代”。市场需求聚焦在现有业务流程的自动化,大工业时代下固化的业务流程并不会天天变,所以对需求的定义是“软件功能的规范说明”。

    工作方式是瀑布式的:先花大量的时间模型化业务流程,制作出详细的“需求规格说明”,然后才进行开发实现。

  • 敏捷转型时代,对应于上图的“互联网时代”。随着互联网的出现,信息技术不再是自动化固有流程,而开始延展业务,如进行网上展示、销售和营销。

    这时,我们发现需求的不确定性变大了,用传统的“瀑布”方法不能适应外部市场的需求变化,软件项目失败率非常高,于是开始寻找更轻量的、迭代试错、小步前进的轻量级敏捷方法,来提升软件团队的响应力。

    这时,对需求的定义也演绎为“代表着业务价值的一个单元”。但是,此时的变化范围仅限于IT,已有的需求相关的实践和方法大多是面向技术团队的,如小步发布(Small Release),产品负责人(Product Owner)要和技术团队在一起,来制定团队的迭代计划、排优先级、澄清需求问题等等。虽然开始关注价值,但却仍只度量IT团队的效率和产能。

  • 精益企业时代,对应于上图的“数字经济时代”。面对高度不确定、激烈竞争的市场,发现需求和定义需求的过程,变成一个不断试错、然后逼近“正确结果”的过程,这已逐渐成为大家的共识;

    同时,面对市场对高响应力、引领力的要求,对需求的验证环路必然要穿越IT、销售、运营、市场等所有职能部门,才能形成端到端的闭环,持续创造市场价值,即“整个组织的更广阔精益变革”[^2]。 因此,在当前高度不确定的市场环境下,有必要重新定义一下“需求”:

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

2. 需求问题的多重挑战

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


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

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


图4 需求的多重挑战

挑战之一: 需求产生时的“不确定性”。

产品需求的本质都变成了“有价值的假说”,而不是传统意义上的“一开始就能能明确定义出来”。市场用户需要的是“一匹更快、永不疲倦的马”,是一个“有价值的假说”,最终“汽车”则是不断转向、学习的结果。

人们善于解决确定性的问题,但面对不确定性的时候,往往束手无策。连接商业、技术和人,方向那么多,从哪个点开始?如何在首次提出产品想法时,就能(比竞争对手)找出“更靠谱的假设”?这是前所有未有的挑战。

挑战之二: 需求经过层层分解可能完全失去原有意图。

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

挑战之三: 需求实现所必须的社会化协作导致的需求失真、或被“污染”。

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

挑战之四:需求的时效性。

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

下面的列表是常常听到大家反映的关于需求的问题。如果仔细去分析这些问题,本质上还是来源于上面4层挑战。如优先级排序中的来源太多、需求提出人的角色等都是第三类,“需求实现的所必须的社会化协作导致需求失真、或被污染”;需求变更频繁实质上体现的是第四类“需求时效性”的挑战。

3. 这么多挑战,有解吗?

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

  • 转变思维——我们的所有工作过程,不再是一个对确定问题求解的线性过程,而是一个构建(Build)- 度量(Measure)- 学习(Learn)的螺旋前进过程,我们会认为“不确定”是常态,积极主动地调整计划以适应变化;

  • 步子迈得更小一点——每次定的“需求目标和范围”会更小一点,这样尽可能让错误的弯路更短一些,验证的成本也更低一些;

  • 尽量缩短验证、反馈周期——因为这样试错成本更低,所以我们就要拼命靠近客户和用户,与他们对话,花精力研究他们、了解他们;

  • 迫切想知道验证结果——所以在产生需求想法时,就确定好度量指标和验证方法;

  • 为了一开始找到更接近的假设,我们需要对用户、领域问题、行业生态有更为深刻的洞察;

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

  • 需求目标定小一点,尽量避免不必要的分解;

  • 简化组织结构,层级少一点,减少层层分解;

  • 建立跨职能部门,减少分解;

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

  • 统一需求接口,减少沟通节点;

  • 按照产品职责来设置团队,让市场、技术和消费者直接沟通,减少中间环节;

  • 建立跨职能团队,避免部门政治给需求带来的污染;

  • 采用更直接、更简洁、更高效的方式去沟通,减少信息失真;

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

  • 需求目标定得尽可能小,因为目标越大、验证学习周期就会越长,失效的可能性更大;

  • 时刻关注市场变化,随时做好调整转向准备;

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

4. 精益产品需求是什么

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


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

如果回头检视,我们会发现通过图上这些方法、实践和工具,效果主要体现在改善了IT交付团队内部的“需求沟通和传递”,通过“小步发布”少量地改善了“时效性”的问题,其他挑战似乎没怎么改变。

因此,也出现了类似这样的疑问:“实施敏捷需求分析的效果,也就是团队内合作和沟通更流畅了,从业务来看也没啥影响啊?”

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

……

阅读下半部分内容请点击【阅读原文】




- 小编推荐 -
总额20W软妹币,全城通缉极客颠覆汽车行业!HOT!!!

如何走出死锁的十字路口——肖然《精益企业》分享

精益企业原则之:以产品为中心,而非交付项目| TW洞见


回复201501-201606,获取当月精彩洞见合辑
如:想看6月精彩洞见合辑,请回复 201606 
若你想去 TW洞见网站阅读所有洞见文章,复制网址在浏览器打开:insights.thoughtworkers.org



ThoughtWorks

❶ 新版技术雷达
❷ 各类干货洞见
❸ 精选职位信息
❹ 活动预告总结
置顶我们,天天给你好看!


阅读下半部分内容请点击【阅读原文】

 
ThoughtWorks 更多文章 虚位以待就等你来,最后五天还不赶紧抢座位? 精益产品需求的要义|TW洞见 敏捷QA,从入门到放弃|TW洞见 深圳活动 | 8月20日Office Warming Party .NET Core:面向未来的开源跨平台开发技术|TW洞见
猜您喜欢 Swift 如何优雅的实现 异步顺序任务 API 调用次数限制实现 Awk课程系列 【第55期】即使别人是码农,你却不该是 采取行动应对大数据