数字化时代的产品能力建设

[摘要] 产品能力是数字化企业的核心能力之一。无论是传统企业、新型企业,还是政府或公益组织,都在着手打造这一能力。然而,缺乏目标规划、盲从粗浅的外部认证、沿用传统思维来分角色分职能做培养、想一举通过全面流程推进来获得高响应力,都让赋能过程陷入泥沼。如何避免这些误区,有策略地高效赋能?

ThoughtWorks结合过去5年的咨询实践,发布了《数字化时代的产品团队赋能》白皮书,给出数字化时代产品能力的框架定义、每项能力的具体介绍、不同类型组织、不同聚焦职能的赋能策略,及五个不同类型组织的实施案例。

互联网企业给传统企业带来了极大的冲击,第四次工业革命的轰轰到来,更是让传统企业如履薄冰。一位从普通啤酒企业员工做起,打拼20年成就企业辉煌的老总,面对各种新式互联网玩法黯然喟叹:“一夜之间,我发现自己完全不知道怎么做啤酒了……”。

无论是出于内忧还是外患,传统企业纷纷开始转型,希望学会互联网的新式打法,紧紧扣上科技进步的脉搏。原来没有IT的企业开始通过收购、兼并或自建方式,构建IT团队以期望获得“数字化能力”;原来有自己IT团队的,也纷纷开始进行“敏捷”转型,期望组织插上创新的翅膀。

战略方向上,这自然没有错,但在现实的每一天中,管理者们却难免迷茫和困惑:

  • 请了若干敏捷教练,进行了大半年的辅导,教练在,产品流程稳步前进;但教练一走,流程和实践又回到了原型;
  • 构建了创新中心,想要业务创新,缺乏创新机会探索和实验的能力,创新想法难以落地实施、行动迟缓;
  • 全新的产品团队,不知如何运作,看了几本书后跟着感觉走,但全不能快速验证商业想法、上线产品,更别说带领产品进入扩张期;
  • 由传统IT转型过来的产品团队,缺乏产品端到端交付能力,不知如何充分融合业务,由成本中心转变为价值中心;
  • ……

甚至,有时候都开始怀疑自己: “是不是我手下这帮人彻底没救了?是不是应该全开了,到外面买一个新团队?”

图1 不同组织的典型痛点和问题

到底什么是数字化能力?产品能力又意味着什么?又该如何有策略地高效地为组织赋能?

产品能力,是数字化企业的一项核心能力

互联网思维给传统IT的思维冲击体现在三个方面:

  • “用户思维” over “工程思维”:互联网思维一切从用户出发;而传统IT思维则是“工程师最大”,谁有技术谁最牛;
  • “产品思维” over “项目思维”:互联网思维以产品为中心,围绕价值成效进行管理;而传统IT的项目思维则是以计划、预算和职能为中心;
  • “价值创造(颠覆式创新)” over “效率优化(渐进式创新)”:互联网思维的组织,更注重价值创造,即使颠覆自己的现有模式;而传统IT则是注重效率优化和规模增长。

数字化时代的组织,向互联网学习,是这三个思维的彻底转变,并且践行。同时,这三个思维又是紧密联结在一起的,在实践中集中体现为以用户思维为核心,高响应力为目标的产品能力。这是数字化企业的一项基础的核心能力。

“数字化企业是以客户中心为基础,以科技为引领,在统一愿景下建立了实时战略机制和敏捷生态的生机型组织。” ——肖然《数字化转型改变了什么?》

“产品能力是每个人的底层能力。” ——梁宁 《产品思维30讲》

产品能力建设的四个误区

图2 产品能力建设的4个误区

然而,因为缺乏对产品能力的清晰理解,又迫切想获得这一能力,很容易就走入几个误区:

误区1:盲目地、无目的性的学习

组织也患上了“数字化知识焦虑症”,一切新鲜的“数字化的、互联网的”都要学习,精益创业、服务设计、用户研究、体验设计、数字平台技术、设计思维等等,不分主次、没有聚焦、没有系统,抓到什么就学什么。自己最需要什么,最欠缺什么?没有进行深入分析;能力建设想达到什么目标?没有想过。

误区2:缺乏能力漏斗,盲从外部“认证”

组织特别需要懂敏捷的10个ScrumMaster,或者需要能有复杂产品分析和规划能力的PO/BA,怎么办?自己培养?太慢。“XX认证——组团参加培训,就能获得认证!太好了!”。但事实是,尽管组织里已经有XX%的人具备了认证,但组织实践却并没有发生什么变化,更别说相应的业务成效产出了。

图3 产品能力漏斗

根据学习金字塔,一般的培训,如果在很好结合实践练习的情况下,最多能获得内容的30-40%,连100%自我理解都达不到,更不用提行为改变和知识传递和影响力。 而真正的产品能力,尤其是达成相应的业务成效产出,其根本在于产品能力漏斗中的第三层“个体行为改变”到第五层“团队行为改变”。

如果仅仅是让大家解决认知问题,从“Unknown Unknowns”到“Known Unknowns”,那么培训和证书是有效的;那如果是真正想构建“以用户思维为核心、高响应力为目标”的产品能力,寄希望于粗浅的外部认证,只是得个心理安慰罢了。

误区3:分角色、分职能进行能力培养

作为咨询师,我们被问到最多的是:“PO(Product Owner, 敏捷团队的一个角色)应具有什么样的能力要求?业界标杆是什么?”,只不过问题中的PO会换成BA、产品经理、体验设计师、运营经理、业务架构师、测试经理、ScrumMaster等等。 在赋能执行上,依然是传统的“以职能为中心”的思维,分角色、分职能来组织培训、设计人才发展,进行能力培养。

诚然,一定程度的分角色、分职能是必要的,但这种过早、过于强调“职能”的能力培养模式有三大弊端:

  1. 低效缓慢。互联网思维的团队,“人人都是产品经理”,强调人人都具有产品思维、产品能力。这种分角色、分职能的方式,大家在基础认知上达不成一致,成效缓慢就不足为怪了。
  2. 存在大量浪费。想要让团队“高响应力”,多个角色都必须学习多项能力,比如设计思维、敏捷精益方法、数字化技术等是无论管理、设计、需求、技术还是运营都要掌握的。没必要分别、重复组织培训。
  3. 限制人才发展和创造性。以“职能”为中心,传递出来给所有组织成员的就是“一个萝卜一个坑、各人自扫门前雪”,自主性和创造性也无从谈起。

误区4:忽略实践能力,强推流程改进

传统的产品管理流程​基本上还是层层传递的瀑布式:业务收集用户需求,定义产品传给研发,研发中的产品经理、项目经理进行分析以后,写成需求规格说明书给开发。在这个流程中,严重存在“响应力不足”的问题。当组织在进行流程改进时,很容易识别出自己的一些“缺失”,如:

  • 在产品创新时的探索流程:对不同切入点进行业务成效评估,基于业务成效找出MVP,找到尽可能小的一个切入点来启动;
  • 产品探索期或起步期,没有流程和管理机制保证尽早进行用户验证和市场验证;
  • 在产品探索方向确定以后,经过冗长的过程才能进行稳定交付;
  • 产品迭代交付周期过长等。

所以很多组织一上来,不管团队是否具备相应的实践能力,先要求咨询师带领着做“流程转型”:​制定一套流程,流程中有哪些环节,分别需要哪些活动、哪些角色参与、输入输出是什么,然后要求团队按流程执行。这种情况下,无非两种后果:

  • 第一种,“教练在,流程稳步前进;教练走,一切回归原样”。如文章开头所提到的“管理者的烦恼”。如果缺乏实践能力基础,只是照猫画猫,那有教练及时干预和反馈,自然能提供像样的输出;教练一走,不具备实践能力,人的天性就会逃避,回归到旧习惯。
  • 第二种,“流程对了,但输出成果更糟糕了,甚至还不如从前”。比如流程里要求用户访谈验证,列出了用户访谈的具体流程和问的问题,团队成员一丝不苟、非常认真地问每个问题、记录用户的每个细节反应、疑问、各种建议,但最后让总结出验证完的结论,却一句也说不出,白白花了一天时间,还不如原来没这个流程。

实践能力是流程落地的基础,通过强化实践让流程落地。比如流程中,如果缺少早期反馈和验证,那实际上应该先聚焦于培养“原型构建和测试”的能力,并让能力在更多的成员、团队中复制生长,那么以后在产品启动时,自然会有人自主自发地出来说,“基于大家提的想法,我们做了一个纸面原型,要不先找用户测试一下看?”,变成很自然地工作中的一个环节。然后再“显式”地告诉大家,这叫做“产品概念验证”实践,以后每个产品启动时都要经过这个环节。

产品能力建设的实施建议

那如何避免这些误区呢?我们有四条建议:

建议1:认知数字化时代产品能力框架,识别能力鸿沟,明确能力建设目标和路线

图4 数字化时代产品能力框架

一个产品,从概念、战略到落地,是一个完整的端到端的过程:最初产品机会的发现、启动、从0到1上线、运营增长、并不断演化为新的产品和服务形态。数字化时代,从面向业务的角度,这需要数字化能力基石、产品设计和需求、产品规划和管理三个层次16个板块的能力。组织首先需要理解并认知这个能力框架,以及其中的每个层次、每个板块对自己的组织来说意味着什么。

对于不同类型的组织,或者是处于不同发展阶段的组织,痛点和问题是不同的。根据自己组织战略,对照产品能力框架,识别自己的能力鸿沟,形成目标明确的能力建设路线,有重点、有步骤、系统地进行赋能。下图对比了一个大型企业的数字化创新中心和一个大型企业的IT研发组织的赋能重点。(扫描文末二维码下载白皮书,可获得数字化能力每个板块的详细解读,及不同组织的赋能策略建议)

图5 赋能重点不同:大型组织的创新中心 vs. 大型企业的IT研发组织

建议2:认知能力漏斗,建立“以实践能力为核心”的能力建设机制

结合图3的产品能力漏斗,我们知道能力的获取有5个层次,不同层次需要通过不同的方式,而不同的方式、周期、成本和效果不同。那我们的建议是:

  • 初期做“导入培训”,引入基础理论知识体系,来做思维和认知转变基础理论知识体系的引入,主要是让组织在基本的产品运作理念、原则、组织协作等达成共识;并明确当前的基线在哪里,核心的欠缺点是什么,应该达到的目标是什么。​这属于解决认知的问题,可以通过培训来解决。但建议在这类培训中,一定要引入模拟演练和体验,让参与者有更多的“浸入式体验”,能够触动大家,启发思考,促进认知转变。
  • 结合提升目标和重点,建立实践工具采纳路线图,逐步采纳相应的实践和工具每个能力板块,都有一组对应的实践工具。根据能力提升的目标和重点,建立实践工具采纳路线图,在教练辅导下,先逐步采纳相应实践工具,从能力漏斗的第一层升级到第二层。这个可先从部分重点团队做起。
  • 在工作中实战辅导,通过强化实践,让流程在落地从能力漏斗的第二层升级到第三层,往往是能力建设的分水岭。在基础的导入培训和实践路线图建立之后,就是需要在实际产品工作环境中,在教练指导下,经过一段时间反复可以练习某个工具比如低保真原型及用户测试,让团队完全具备在不同上下文中进行构建原型和用户测试的能力,从而促使“概念原型构建和验证”流程落地。
  • 先小范围试点,再稳步推广在大组织下面,团队众多,大家的基础认知和能力是不同的;组织赋予的战略重点也是不同的。建议先从小范围、重点团队开始,把这个团队打造成“榜样团队”,然后再逐步由点及面推广。

图6 建立“以实践能力为核心”的能力建设机制

建议3:采用种子教练模式,培育影响力,促进团队行为改变

我们经常观察到一个现象是,有的产品团队里,派出了产品经理或是BA,参与了培训和辅导,他/她个人是完全理解如何做用户访谈、从场景触发分析用户体验、找出痛点和机会点。但在他/她的团队中,就是无论如何做不起来。这里面究其原因,就是影响力和杠杆力:自己知道以后,如何把理念、方法传递给团队,在团队中形成影响力,撬动团队来做出改变,进行这一实践。所以,“赋能”,不但要赋能展业能力,也要赋能“影响力”、“教练力”。

在组织能力提升的时候,如果只是针对小规模,见效是比较快的;但往往很快就进入了一个能力提升瓶颈。单点上可以快速突破,但在面上则需要找到持续动能(Momentum)。

因此,我们建议:从不同的团队中筛选出“种子教练”,对种子教练做先期重点投入,给于培训和辅导,然后督导这些种子教练在自己的团队里面分享、传播和引领实践,一方面让种子教练自身能从漏斗的第2层跨越到第4层,也促进团队中的成员从第1层走到第3层。

图7 种子教练培养模式,促进从个人行为改变到团队行为转变

建议4:建立人才多元化成长和培养机制

传统观念上,明确分工、职责清晰是被倡导的;而不同角色中存在“Overlap”被认为是低效的。然而,正是“模糊的”边界和“跨界”的思维,才是创新力的源泉,也是产品长青的持久动量。

在业务和IT融合的产品化团队里面,会有多种角色:产品总监、产品经理PM、业务架构师、产品负责人PO、业务分析师BA、体验设计师UX、运营经理、项目经理、ScrumMaster,甚至技术方案架构师等,要鼓励这些角色交叉成长,互相学习增长各个角度的技能,是整个产品团队迅速达到预期能力的“捷径”。

“As always, we value poly-skilled TWer (one of the core concept of Lean) and encourage everyone to nurture different skills to take on multiple roles. 与往常一样,我们重视多面手TWer(精益的核心概念之一),并鼓励每个人培养不同的技能以承担多种角色。” ——ThoughtWorks CEO 郭晓

“永远没有完美的个人,但我们可以拥有完美的团队。”每个人都是有一定专长的多面手,那组合在一起就能构成“超强”战斗力的团队。我们建议,在赋能机制设计中,要鼓励这样的多层次、多元化的人才发展机制;弱化职能和角色、强调“能力积木”,在选拔人才时,“能力积木” over 角色资历。这样,必定会使组织充满活力。

 

图8 产品角色的多元成长机制

最后,让我们一起成为卓越的组织!

可能有人会说,组织中真地需要所有人达到能力漏斗的第三、第四层吗?显然不是。但是,所谓卓越组织和平庸组织的差异,也就在于此:卓越组织中,80%的人达到第四级;优秀的组织中,可能是60%;而平庸的组织可能就是30%。如果仅仅止步于平庸组织,那可以满足于说“80%的人参加了XX培训,拿到了XX证书”。如果真想做到优秀或卓越组织,就不得不更努力、下苦功,让更多人进入到漏斗的第四层。这是最坏的时代,但也是最好的时代,让我们一起努力,成为“卓越的组织”!

点击这里免费下载《数字化时代-产品团队赋能》白皮书!

Share

智能银行(中)

上篇文章中我们提到,人工智能和机器学习等新兴技术是银行业变革的催化剂,会让传统银行以一个全新的运营模式实现新的可持续增长,成为“智能银行”。本篇文章,我们谈谈“智能银行”的实施路径。

组织增长的三种策略

组织能否实现指数级增长,有三种策略。

1. 流程驱动

  • 提升价值链的每个独立环节的效率
  • 通过增强人力资源展开大规模运营
  • 强调专业化、按照专业技能形成职责分明的职能部门
  • 在部门层面定义成功标准
  • IT的角色是协助每一个职能部门变得更高效
  • IT的度量主要依据是否按范围、预定时间、在预算内交付

2. 数字化驱动

  • 通过自动化核心流程实现效率最大化
  • 消除组织和技术的阻力,进入新市场
  • 引入设计思维,践行以客户为中心的理念
  • 围绕核心业务能力,引入产品思维和跨职能团队
  • 通过实验学习,培育更强的创新能力
  • 构建微服务减少相互依赖,建立更敏捷的平台,促进无缝化集成
  • 通过DevOps实践,激发更深层次的协作和自动化,缩短产品的发布周期

3. 智能驱动

  • 构建自动化能力,以服务更广泛的客户群体或满足更深层次的客户需求
  • 通过实时访问整个企业的数据资产,推进算法智能,释放数字驱动服务的潜能
  • 利用企业和生态系统的数据实现动态监控,自动化、精细化决策
  • 从更广泛的生态系统中集成功能和数据,为客户提供整合的解决方案
  • 基于客户需求和可以承受的风险,提供个性化产品和灵活的定价
  • 减少组织和技术层面的摩擦,形成飞轮效应

需要明确的是,数字转型是非常有必要的重要一环。但实现了数字转型并不是就万事大吉了。注重成长性的银行必须不断去解决问题,发现新机遇。不仅要把自己已经熟悉的事情做好,还要有更高的目标、尝试不同的事情。

智能企业的战略核心:平台思维

成功转型智能企业的公司并不仅是使用技术“赋能”当前业务流程。他们的重心是把客户关系、业务线、核心能力和运营转化到软件端,成为一个数据驱动的组织。这就是智能企业的战略核心。籍此,实现指数级增长,并不满足于增量增长。

增长要么来源于新客户收入,要么来源于存量客户更多的收入贡献。这就需要企业对客户市场更为细分,或提供更贴合的服务,或切入一个细分市场,或创建一个新的细分市场。

高效增长战略的核心要义恒古不变——成功的公司并不仰仗他们的“产品组合 ”。他们关注的是客户“亟待解决的问题”,通过帮助客户解决问题来创造价值。在高效增长战略中,产品和服务完全可以针对个体客户的问题来定制,甚至是与生态伙伴的服务打包在一起,为客户提供更有吸引力的解决方案。

既然以客户为中心是高效增长的核心,那实施路径只能是通过平台思维,来实现规模化增长。原因何在?大部分金融机构创新时,面临的挑战多是成本和复杂性的问题,而平台思维就是解决之道。

平台思维是什么?

平台思维将技术与解决客户“亟待解决的问题”所需的敏捷性联系起来。ThoughtWorks数字平台战略展示了建立一个这种数字化基石的蓝图。

智能银行需要在自己的数字平台上,打造三个核心业务能力,以为实现指数级增长创造条件。

  • 全方位的客户洞察,即了解客户使用服务和产品的环境。例如综合了市场营销、风险管理和运营管理等内部数据,以及地域、设备、渠道和交互方式等外部数据的统一客户视图。这样才能对客户真实的需求形成更深刻的洞察,了解客户真正面对的风险是什么,进而形成一个清晰、风险加权的客户价值定位。
  • 企业数据的充分共享。在法律允许的范围内,能够帮助银行内部所有业务线和职能部门实现数据近乎实时的流动。目的是更好地理解业务,发现有用的模式和洞察,创造更多的机会,在运营的各个环节提升决策的自动化程度。例如,在综合考虑风险、合规和市场数据后,零售银行业务可能会发现针对某个细分市场中提供按揭首付的市场营销活动存在着极大潜力。
  • 敏捷的生态系统。生态系统敏捷度是优化客户解决方案的战略侧重点,需要外部合作伙伴提供数据和服务,以API为实现方式。这种方法与传统合作伙伴关系不同的一点是银行此时谋求向客户提供全面集成的解决方案,该方案既包括银行自己的产品组合(例如,贷款产品),也包括外部供应商提供的产品组合(例如,Zillow提供的住房市场趋势)。

初创企业如何利用平台思维推动公司快速发展?

Stripe一直坚持自我创新,秉承以客户需求为导向的原则。他们的核心业务是为数字企业提供银行业务的技术基础设施,保证互联网付款的安全性。Stripe意识到企业家在建立电子商务企业时会面临各种困难。公司不断扩展其套件功能,如欺诈保护、合规及核算等,帮助客户化繁为简。公司的新产品Atlas继续延伸这一理念,不仅仅局限于电子商务平台,而是让成立一家企业所需的所有服务都可以通过Atlas实现,如注册、银行开户和虚拟主机托管等。Stripe敏锐地意识到“客户面临的难题”后,对自己的业务模式再次洗牌,从数字支付基础设施供应商变成了一个电子商务平台提供商。

根据客户面临的难题重新对组织定位绝非易事。客户希望其合作伙伴能够简化复杂的运营流程,便于使用。这就需要组织重新架构整个业务领域,识别影响行业发展的难点和资源限制,并提供解决方案。

再举个例子,客户出门在外旅行,晚上需要有个睡觉的地方,他们甚至可能想寻求一些别样的体验,或体会融入社区的自在感。万豪和希尔顿的解决之道是与那些买了地盖了酒店的投资者合作,Airbnb(爱彼迎)则另辟蹊径使用平台思维把每一幢房子或者每一间公寓变成潜在的酒店客房。资源限制(土地)困难没有了,采用平台策略后,客户的选项大大增加。借由平台,Airbnb可以提供新产品组合“Experiences”(体验之旅),满足客户体验和融入社区的需求,例如房东可以提供诸多向导体验,在东京创作街头艺术,组织私人音乐会、采摘松露,或者规划一次酒窖之旅。

科技驱动的企业,平台思维是其核心能力。这些企业可以在平台基础上不断自我进化 ,实现持续创新。平台作为企业构建数字业务能力的基石,可以随企业发展不断更新和演进。比如,Uber对自己平台功能进行了不断革新,通过UberEATS提供送餐服务。与此同时,Youtube也利用自己的基础设施进行自我革新,通过DVR和流媒体功能向客户提供数字电视服务。建立平台减少了基础设施上技术改进的难度和限制,有利于实现快速部署、数据驱动的客户分析和全渠道体验。

平台吸引的内容和消费者越多,其价值就越大。苹果的iPhone能够成功,很大程度上要归功于应用程序开发人员营建的生态系统以及iOS平台上的App。如果要创建网络效应,平台必须调动内容创造人员和消费者进行公平交易的积极性,同时也能随平台价值而获益。

金融组织如何应用平台思维?

这种逻辑在金融服务行业怎么运用?下面是一些应用样例:

平台类公司比传统架构的公司能够更快发布新产品、服务和客户体验的主要原因是公司技术基础的逻辑不同。从本质上来讲,平台类公司就是一个服务库和业务功能库,并以API形式为彼此提供服务。这就是他们无需复杂磨合就能够实现增长的秘诀。做新产品的成本并不意味着一定要承担改变现有产品的成本。新功能应该像是在产品上新搭的一块乐高积木,而不是一大碗意大利面中的又一根面条。

把组织架构为一组自治的、由软件界定的业务能力的集合,对企业来说至关重要,能够帮助企业解除组织复杂性的障碍,提升组织响应速度,真正实现以客户为中心,发挥组织创新潜力。平台思维是智能银行的基石——着手打造智能银行赖以发展的数字平台吧!

点击这里深入了解ThoughtWorks数字平台战略。下篇我们将探讨如何把智能技术嵌入到银行的平台思维中,形成飞轮效应。


文/Aneesh Lele, ThoughtWorks 金融科技 规划主管 、Prashant Gandhi 金融科技 总监咨询师

译/亢江妹 ThoughtWorks 首席咨询师

Share

智能银行(上)

摘要:

人工智能和机器学习等新兴技术是银行业变革的催化剂,会让传统银行以一个全新的运营模式实现新的可持续增长,成为“智能银行”。

新科技并不会摧毁传统金融服务公司,新兴金融科技公司也没有这个能量。打败传统金融服务公司的是其内部那些不易察觉的业务模式缺陷,以及对过时流程的过度依赖,这些过时的流程会拖慢变革的步调,进而让组织背负高额的成本。技术则是变革的催化剂。

成功转型的金融企业可以通过一个真正划时代的方法实现新一轮增长。借助技术,他们可以更好地理解和服务客户、化解风险、打造出扩展性极强的自适应平台,并能够充分发挥生态系统的巨大潜力。

颠覆不仅仅是一个被滥用的时髦术语,如果使用得当,它依然拥有在人们眼皮底下点石成金的魔力。

2004-2010: Blockbuster陨落,Netflix腾飞

举个简单的例子,我们都知道Netflix“颠覆”了Blockbuster,后者因此破产。但是很少人意识到Netflix是怎么做到的,以及其成功的缘由。

Netflix成立于1998年,Reed Hastings因为忘了还借来的影碟,被Blockbuster罚了40美元,一气之下他创建了Netflix。次年,Viacom让Blockbuster重新回归资本市场,当时估值是48亿美元。一个人所皆知的花絮是,Blockbuster曾在2000年放弃了以5000万美元收购Netflix的机会;当时Blockbuster认定Netflix的邮件订购发货模式只是一个小众市场。

Blockbuster直到2004年才重回鼎盛时期的9000家开店数,到了2010年,它就破产了,三年后,该公司的店铺也都被清算了。

图 2004-2010: Netflix腾飞, Blockbuster陨落(by Augustine Foo

就Blockbuster衰败的轨迹而言,Netflix可能是催化剂,却不是诱因。导致Blockbuster关门的根本原因是该公司的经营模式。租赁费一般可以覆盖到公司的成本,公司的盈利大部分仰仗逾期罚金。2000年的时候,Blockbuster超过18%的收入,亦即将近40%的净利润来源是逾期罚金。鉴于Netflix咄咄逼人的气势,Blockbuster于2005年取消了逾期罚金,然而2010年的时候又不得不再次征收,因为公司创收乏力,营收缺口已经高达3亿美元。

对客户而言,这类逾期罚金是最烦恼的事,也是对Blockbuster不满的深层次缘由。这是Blockbuster与生俱来的缺陷。Blockbuster的运营模式决定了要与自己的客户产生利益冲突。因此,当人们有更好的选项时,Blockbuster就会丧失对客户的吸引力,进而导致了它的破产。

类似的情形也在金融业上演。以技术为导向的金融机构,也会抓住金融服务机构类似的天然缺陷,打败以传统方式运营的银行,为客户提供更好的价值和体验。

但是找到缺口只是第一步,要能真正颠覆旧秩序,需要不断进化,持续满足客户、监管和股东方的需求,才能成功。

Netflix很明白,公司的成功取决于公司的适应能力,而不是自己现有的分销模式。公司起步时的邮件订购体验远称不上完美,但是它的订阅收入模式,免去了客户被迫缴纳逾期费的烦恼,满足了客户最迫切的需求。从一开始,Netflix就围绕业务能力做文章,而不是流程。在技术革新时,Netflix就得以迅速切入。当业务覆盖到大部分美国家庭后,Netflix革了自己的命,砍掉了DVD邮件订购业务,开始专心经营流媒体业务。

随后,Netflix在设计和打造每项核心能力时,都致力于实现高度自动化,并挖掘积累数据的价值,驱动增长。Netflix的构架,能快速进入新市场领域、提供新产品,并且为新客户群体提供服务,同时又很少给组织带来负担,形成技术欠债。

这个故事对传统金融机构有什么启示?

技术不会颠覆传统金融行业商业模式,新兴金融科技公司也不会。这些都是催化剂。

现有业务模式如果与客户最关切的利益之间存在根本性冲突,这种业务模式将很快被淘汰。

以技术为导向的金融机构将会充分利用这些利益冲突带来的商机,瓦解现有业务模式。他们还可以通过打造高度智能化、自动化的业务能力维持这种优势,让公司快速适应不断变化的客户预期、市场状况,或者切入临近市场中存在的新业务机会。

举个简单的例子就可以清晰展示零售银行业的现状,仅仅是透支利息和ATM机取现这一项就为全球零售银行业带来了超过110亿美元的收入。CFPB预计61%的零售账户利润都来自此类收费。在银行业、投资管理和投资银行业,类似案例更是不胜枚举。

一个以技术为核心的银行,会怎样利用这些缺口?我们在接下来的两到三年内将见证下列三种形态:

  1. 以技术为导向的银行配备了高度自动化的运营设施和系统,以更低的价差赚取更高的利润。这将会激励他们在交易和租赁市场实现完全透明化,颠覆依赖价格暗箱的交易模式。
  2. 随着资产和投资管理行业收费迅速向零靠拢,投资经理需要在资产管理收费模式之外创造新的价值增长点。智能和半智能投顾产品,将赋予投资者更明晰的价格、绩效和目标定位,甚至可以创造新的价值定位。它们要么会与人工理财顾问一较高下,要么会将他们取而代之。这个趋势不断深化后,自动化智能投顾也将覆盖到更加挑战、更加复杂的产品,如保险、养老金和其它精算产品。
  3. 在一个高度自动化的世界中,资产服务和保管服务的边际成本将会趋近于零,中间商和清算服务提供商证明自己收费合理性的压力也越来越大。最终笑到最后的是那些实现端到端价值流量转化的公司,仅仅对现有流程进行自动化的公司只能在旁垂涎。

智能银行思维:“需要的是汽车,再快的马也枉然”

我们不可能用制造问题的思路去解决这些问题。 ——爱因斯坦

历史数据证明,金融服务行业的韧性是非常强的。最新数据显示,全球经济危机过去还不到十个年头,金融行业已经取得了史上最高的利润。然而,数据也清晰地表明,行业的主要收入和盈利引擎面临诸多层面的压力。传统上,金融行业赖以生存的盈利模式,“以收入和利润为单一导向”,将无法支撑金融机构实现有机的、风险加权式的增长。亚马逊、谷歌、阿里巴巴和苹果等数字巨头已经进入类金融市场,他们随时都可能成为传统金融企业的直接竞争对手。传统金融机构的领袖亟需改变对人、流程和技术的认知心态,要想不被这些数字巨头超越,必须让企业实现指数级发展。

零售和机构客户转向青睐如高收益储蓄工具、低费率投资基金、更低咨询费产品和低价差交易,而这些对银行来说边际利润更低。金融服务公司曾经拥有的信息不对称优势已经丧失殆尽,透明的定价将会进一步压低利润率。要实现盈利增长,规模效应变得愈发重要;但是要想获得规模效应,传统企业必须能够满足客户愈发挑剔的预期,以更快的速度向客户交付新的价值。

一种战略可能是,创造条件为新型进入者(比如智能金融机构)带来新的交易或投资用户流量。另一种战略,可以是将产品、资产和功能以全新的方式打包,开拓新的目标市场或提供新品类。但有一点是明确的——银行想要在新领域实现增长,需要不断快速测试新的商业模式、新的市场。

股东们会刺激组织去实现有机增长,导致组织无时无刻不面临着增长压力,而且这种压力与日俱增。与其他行业相比,金融机构堪称其中之最。固然,实现增长目标是重要的,但同时,我们也建议金融机构,要为实现指数级增长打下良好的基础。

Netflix在过去20年中,稳定实现指数级增长的秘诀是什么?Netflix从来没把自己当成是一家邮件订购公司,或是邮递DVD的公司。它一直以来对自己的定位都是科技公司。

虽然这种委婉的说法如今在金融行业已经变成了陈词滥调,但真成为一家科技公司,不是那么简单。这意味着公司要不断投资数字化驱动的业务能力开发,消除依赖、通过挖掘数据价值持续自动化,以机器智能为架构核心。与亚马逊一样,Netflix并没有依赖业务流程集成,而是通过不断加强以API驱动的数字平台,使公司拥有快速发布新业务的能力。适应业务需求的动态流程是他们的核心关注点。这样,他们就不会像现实中的运河那样,难以改变航道。

银行和投资管理行业的圈内人士,对这种思维已经形成了自动的条件反射。

“说起来轻松,给他们一个有50年历史的大型机系统,再甩2000个修修补补乱成一锅粥的系统试试。”

“等他们进入一个严厉监管的行业就现回原形了。”

“我们当然明白这个道理,可是我们的合规部门和安全团队肯定会反对。”

这些反应表明,人们对深层次原因存在根本性的误解。采取传统方式运营的银行并没有技术局限。他们面临的是文化、组织和心态层面的限制。在这种心态的作用下,他们对自动化和机器学习采取嫁接的方法,将它看作一种支持现有流程的系统。

最终结果可能是“效果更好,速度更快,成本更低”,但是很难带来持久的创新。他们给组织养了一匹跑得更快的马,而组织真正需要的却是一辆汽车。

下篇我们深入谈谈“智能银行”的实施路径。

文/Aneesh Lele, ThoughtWorks 金融科技 规划主管 、Prashant Gandhi 金融科技 总监咨询师

译/亢江妹 ThoughtWorks 首席咨询师

Share

数字化平台中的客户触点技术

什么是客户触点技术

图1 企业的线上线下多样化触点

随着科技的发展,客户与企业的互动过程中产生了线上线下非常多样化的触点。图1展示了一个啤酒企业在客户生命周期的获知、考虑、购买、留存、传播不同阶段的线上线下触点。不仅仅是啤酒,家电、汽车企业,甚至金融也都类似。全渠道成为新常态,企业需要通过多样化的触点技术向顾客提供随时随地、连贯一致的用户体验。

以亚马逊书店为例,线下也能提供与线上一致的体验,如“一进门的推荐货架”,“每本实体书配有评论卡(Review Card),可以看到读者评论”,“相似图书的推荐(If you like…, you’ll Love)”,“以及与线上的同一价格”。而做到线上线下书店拥有几乎完全一致体验的前提是整个企业需要:

  • 建立对其顾客和目标顾客的唯一、连贯、准确、整体的视图,从而更好地了解和服务顾客;
  • 结合顾客的特征和不同数字渠道的特征建立连贯的内容策略;
  • 在多种渠道之间引导顾客的消费旅程,与顾客产生正确时间、正确地点、正确方式的交互;
  • 基于从各种渠道获得的顾客本人及其行为的数据分析,向顾客提供定制化的内容、服务和产品推荐;
  • 作为必要的技术保障,所有数字渠道的软件应用(尤其是原生的Android和iOS应用)都应该实践持续交付,提供全渠道地快速响应。

客户触点技术解读

单一客户视图和个性化营销

单一客户视图(SCV)是组织对其顾客和目标顾客绘制的唯一、连贯、准确、整体的视图。客户在不同的生命周期中,在不同触点产生不同类型、不同结构的各类数据:人口/家庭特征及联系数据、社交媒体数据、市场活动互动数据、交易数据、用户行为数据,以及其他非结构化的各种数据,如社交媒体上的评价,各类服务请求等。只有当这些异源异构的数据有机的组合在一起,形成“单一客户视图”,才能准确衡量客户的客户终身价值(CLV)、在各个渠道上提供一致的用户体验、更有效地进行交叉销售(Cross-sell)和追加销售(upsell),进而留存客户。

图2 异源异构的客户数据有机组装成“单一客户视图”

一个典型的建立单一客户视图并实现个性化营销的方案,包括:

  • 采用数据流如Kafka、Flume、Flink技术来采集数据进入数据湖;
  • 利用Spark Streaming进行实时数据分析;
  • 数据的清洗、过滤、整合、身份关联,建立单一客户视图;
  • 同时,将相关的产品、销售、订单、渠道触点等信息也通过数据集市展示出来;
  • BI及Analytics分析系统建立智能分析模型如“客户终身价值”、“下一步最佳行动”等;
  • 营销活动系统发起“客户留存”、“交叉销售”、“追加销售”、“最佳渠道”、“潜力客户转化(Most Look Alike)”等营销活动行程进行智能个性化营销。

图3 基于数据湖的单一客户视图和个性化营销的架构方案

内容策略

当多样化的触点形成以后,内容的推送和服务也要相应地在正确的时间、在正确的渠道、推送给准确的目标群体。图4展示了这个逻辑流程:

图4 基于单一客户视图,建立细分客户群体,设计不同内容,在合适的渠道进行推送

比如一个在线购物平台,针对孕妈妈做内容策略:数据显示82%的孕妈妈每周做一次线上咨询,内容类型是可以互 动的、图文结合展示不同孕期内的信息资讯,通过电脑、手机、售货亭、社交网站推送;有67%的孕妈妈则是订阅每周的邮件,内容则是针对性的最新孕期知识;78%的孕妈妈们会经常浏览孕期及产前产后的博客,推送的内容则是不同年龄段孕妈妈写的各种博客。基于单一客户视图,对客户群的细分管理可以采用Adobe Audience Manager;在内容端用Adobe Experience Manager来管理;用Adobe Target和数字化营销系统完成内容定向推送。

跨渠道引流

全渠道时代,用户可以在任一环节便利地切换到最舒服的渠道和触点来继续服务。用户在整个服务过程中得到的信息是透明的、一致的。

图5 一个零售服装企业的跨渠道引流、决策、购买、交付、留存和传播

图6 一个汽车企业的跨渠道引流、决策、购买、交付、留存和传播

在图6展示的汽车企业的例子中,通过移动端营销活动和展示,用户可以继续在移动端、经销商、直营店对钟爱的车型,通过VR看车对车进行深入了解,然后在4S店预约试驾,完成购买。其中,二维码扫描、拍照购物(图片搜索)、虚拟现实/混合现实、在线个性定制等技术是跨渠道引流的支点。

移动应用持续交付

移动应用仍是当前全渠道中的一个核心触点。如果移动应用不能加快交付周期,与Web端做到同步持续交付,就会导致用户在Web端和移动端体验不一致,进而导致客户流失。

事实上,现在应用商店的审核速度已经有了非常大的提升。作为开发者,移动应用可以通过持续集成和自动化测试加快提交审核的速度;当然,我们也有一些技术能够绕过应用商店,直接更新,但是这样有app被下架的风险。

相关的技术方案有:

  • Fastlane是常用的iOS及Android自动构建工具集,功能覆盖了移动应用从创建、证书管理、构建、运行测试、打包到发布整个流程,配置简单、功能完善;
  • 单元测试框架成熟;
  • 使用截图测试来保证我们的UI正确性;
  • 用Appium / Calabash编写运行移动验收测试;

小结

全渠道已是新常态。获取便利舒服的体验、个性化的服务,是消费者的一贯需求。然而现实中所谓的“个性化推送”往往变成了“垃圾信息轰炸”。麦肯锡报告显示,98%的受访社交媒体用户都在社交媒体上收到过广告,但只有18%的人认为收到的推荐“投其所好”。对于线下购物体验,只有10%的消费者表示在店铺得到了个性化的服务或建议。究其原因,重点还是在于客户数据的完整性、连贯性、准确性和统一性。在英国,只有16%的企业拥有有效的单一客户视图。扎实做好单一客户视图这个数据基础,应用合适的内容策略,通过创新的服务设计支持用户在不同触点之间便利流转,移动端持续交付提供透明一致的信息和服务,才能把触点技术发挥到极致,塑造真正的数字化平台消费者体验。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


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

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