开发人员的客户思维

都说产品与开发之间的矛盾由来已久。在很多互联网企业,都发生过类似这样的一幕:

工程师日以继夜,终于在约定的时间里交付产品——虽然这在产品经理看来可能还只能算个高保真的原型。产品经理体验了这个原型之后,发现一些与期待不符的地方,提出了改进意见。工程师带着泛起充满自信的笑容,再次进入了封闭的开发阶段。

programmers-and-users

类似这样的过程持续往复下去,开发工程师和产品经理对对方的耐心都会受到挑战:

产品:新的方案也就是改了一种排列方式,数据都是一样的,再花点时间不就能搞定了么?

开发:你知道上次那个推荐算法,我花了多久才做出来的么?你说改就改?

产品:可我已经跟老板回复了,说咱们三天就能搞定!

开发:……

在互联网企业里,开发人员作为产品的直接生产者,地位受到优待;工程师作为“创客”所具有的自豪感及自信心也理所应当。直到随着项目的持续,业务越来越复杂,工程师终于不能在期待的时间里顺利交付功能,即使加班加点已在不知不觉中成为习惯。

开发人员与客户思维

在大量的团队里,大家表面看似春意盎然、合作愉快,实际却危机四伏。问题的原因可能很复杂,而从开发人员的角度来说,一个很重要的因素在于开发人员普遍缺乏客户思维。

2-mind

这样的开发人员也能交付能够工作的产品,但从产品设计人员的角度来说,要么他们交付的产品在细节上与需求有较大出入(或多或少,或错),要么就是花费了大量时间,却没人知道他们在做什么,也无法估计一项需求到底需要多久才能开发完成。

开发人员大多有相似的特性,他们擅长解决问题,却不擅长与人沟通。甚至一些人还有“技术至上”的自负心理,认为测试人员和业务分析师等其他角色可有可无。这或许与他们理工科的成长背景有一定的关系。“因为、所以、得证” 这是数学里常见的论证步骤,理工科的同学们擅长运用已有命题推理出一个个新的命题,这一特点在软件开发人员这里有着很好的体现。那些曾在算法练习中用过的代码片断就像一段段积木,当产品设计人员提出一个想法,开发人员就心生一计:这事儿没问题!似乎,接下来就缺时间了。

3-need-more-time

事实却不会那么简单。一个需求的提出,必然有其商业上的考量,其所在的业务场景、适用的范围和限制,以及要实现的可度量目标。在实现过程中,还需要考虑不同的解决方案,各个方案中可能存在的风险,以及需要投入的成本。在团队中,只有所有人都对业务有一致的理解,所有的努力都朝着一致的方向,才有可能获得成功。

有客户思维的开发人员,能够把工作当作为客户提供服务:自己是服务提供方,而同事、老板就是客户。他们积极地从客户角度思考需求的真正来源,在开发过程中与客户保持沟通,适时给出合理的建议。最终在更高效完成工作的同时,建立更顺畅的协作机制,培养出更健康友好的团队关系。客户思维也能够培养开发人员转变视角的习惯和能力,令其习惯于分析价值并作出决策,既而为职业和事业的发展带来更多可能。

思考并沟通

当接到一个新的需求,无论是初次提及,还是后续反馈,首先要思考的是为什么会有这个需求产生,它解决了什么问题、提供了什么价值。虽然开发人员很聪明,却很容易忽略这样一个其实很简单的部分。大部分开发人员的思维方式真的就如同数学证明那样,习惯于接受指令并醉心于实现一些看起来很酷的功能。

4-cool

然而,如果一开始不弄清楚需求的前因后果,就会出现在做了一半、甚至完成了之后,才发现最终得到了一个与设计人员的期待并不符合的产品。其他情况,由于开发团队内部理解不一致导致接口不兼容、由于前期没有沟通清楚而导致返工浪费等情况更是数不胜数。

举一个实际发生过的例子。

作为一个基于浏览器来管理的电商网站运营方,产品经理希望管理员能够在浏览器中即时收到网站用户下的新订单,而不再需要隔一段时间去刷新浏览器,以便做好发货准备。

在拿到这样的需求之后,工程师很兴奋。他开始着手研究服务器推送的各种技术,并深陷其中不可自拔,学习了长轮循、WebSocket等技术。三天过去了,他终于成功地完成了相关开发工作,急切地找产品经理要演示其进展。可没想到,产品经理却并不买账,没等工程师演示,就黑着脸向他回复,“这三天里,我两次向你询问进展,你都说‘快了’。可我一直没见什么动静。后来,我已经请旁边的阿哲搞定了,他只花了一小时!”

5-what

工程师转向阿哲,却发现阿哲用了一个每隔5秒向服务器再取一次数据的“笨方法”。工程师感到委屈不已,向产品经理解释自己的方案比阿哲的方案更有效率,也更先进……

在这个例子里,工程师自认为的高效和先进似乎并不是产品经理所关心的。产品经理作为功能设计者,自然更关心其功能价值,而不是技术方法是否先进。另外,对需求里的“即时收到新订单消息”里“即时”的理解,工程师一开始就将自己的臆测加了进去。

不妨考虑一下,需求的价值是使管理员更早知道新订单到来,但这个“即时性”要求有多高呢?显然没有达到秒级,大概,分钟级也是能接受的——毕竟之前管理员是手动刷新浏览器去完成这个需求的,这说明新订单并没有频繁到需要秒级通知。因此,不管是工程师提前想到了这个结论,还是与产品经理及时沟通了自己的技术方案计划,都可以提早防止浪费。

6-work-place

在工作中,如果只将产品经理视为规则制定者,将领导视为发号施令的老板,我们便会失去思考的机会。逐渐地,思考的能力也将失去。但如果将他们视为客户,那么就更容易理解客户与我们之间可能存在的误解,毕竟大家术业有专攻。这时,不少人便会考虑客户可能的隐藏的想法,耐心地沟通核对,态度也端正友好。

灵活地给出建议

对于一家IT公司来说,开发人员是当之无愧的宝贝,各企业为了招来优秀的工程师,都不惜重金。他们是那么的天才,似乎什么问题到了他们那儿都有解决方案。是的,其实一个用技术能够解决的问题,往往都有很多种解决方案,有些方案甚至不涉及技术。在拥有天才一面的同时,开发人员也相当的耿直,有时候甚至过于耿直,过早地将精力集中到技术方案上,而这时的方案往往还只是开发人员一厢情愿的期盼,不一定是客观上合适的方案。令人不安的是,与这些技术人员合作的业务分析人员和管理人员却没有办法预测或是验证其中的风险。

7-work

在手机支付的概念在技术圈风声水起时,有人正对“刷手机乘公交”的想法感到兴奋,在一边走一边与朋友分享的时候,正好有公交车到站。只见朋友伸出手机在刷卡机边轻轻一滑,“嘀”的一声,刷卡成功!他好奇地问朋友,你是怎么做到的?朋友淡定地翻开手机盖,从中缓缓抽出一张公交卡。

虽然这只是一个笑话,但现实中类似的情形却在真实的发生着,就像上一节中提到的例子一样。 如果开发人员拥有客户思维,就应该在真正行动之前,考虑多个可能的方案、权衡其中的优劣,及时向客户阐明这些方案的利弊;根据对需求的理解,以及客户提供的更多信息,给出具有可操作性的建议。对于一些经验丰富的开发人员来说,给出有价值的建议早就成为了他们的工作习惯,这也正是能体现他们更具专业性的行为之一。

不过,对于老油条们来说,也需要警惕:请注意保持对客户的尊重。作为客户,他们有时候显得不太专业,甚至不太友好。但开发人员,请一定尊重自己的客户。客户的最终目的是解决问题,而解决方案不一定要花哨炫酷,或是技术先进——开发人员应该在合适的时机,让客户知道他们可以做出选择,而不是由开发人员自行决定。即使开发人员自己有什么偏好,也不应该直接或间接地强加于客户,那样只会画蛇添足、招致反感。

《软技能》一书中指出了一个事实,虽然听起来有点残酷:当我们为了谋生而一头扎进代码的世界里时,其实与小时候老家镇上铁匠铺里的铁匠并没有什么区别。那样的我们,不用考虑顾客为何需要打造一件那么奇形怪状的铁器;在顾客一而再地提出挑剔意见时,我们一开始争辩,后来丧气,最后麻木了。那样的我们,数十年如一日,作为铁匠的技艺愈加纯熟。直到有一天,一种叫做“铸造机床”的远在天边的东西,夺去了我们的饭碗。

8-mechanic

如果养成了思考的习惯,拥有为客户提供专业服务的能力,随时都能换个地方另起炉灶。实际上,企业的价值正是体现在它为客户解决的问题上。习惯将工作视作服务客户,把自己当作一个企业去思考,也就具有更独立的人格,为今后真正做出良好的商业决策积累经验、奠定基础。 一旦拥有了这样的心态,开发人员也就不会只关注完成手头的工作,还知道要计划接下来的职业发展,关注自己和同事的成长;也不会因为觉得作为开发人员去帮老板实现梦想没有意义而烦燥不安。很快,开发人员这种聪明的人种就会成为有思路、有规划的进步青年。

 

更多精彩洞见,请关注微信公众号:ThoughtWorks

Share

需求风险的坏味道和对策

大部分项目上,我所承担的角色是帮助客户寻找到产品战略,并着手落地开始项目实施,在这个过程中,我需要强制自己迅速从发散思维中回到收敛思维、从机会导向回到风险导向,因为大部分的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