Jan Bosch 是瑞典哥德堡查尔姆斯理工大学的软件工程系教授和软件中心主管。在 Bits\u0026amp;Chips Software Engineering大会上&＃xff0c;他做了一场题为“从意见到事实&＃xff0c;构建客户真正使用的产品”的主旨演讲&＃xff0c;并举办了“通往天堂的阶梯&＃xff1a;用于商业成功的持续集成和部署”定期讲座。InfoQ将报道本次会议的新闻和文章。
\\
InfoQ就如下内容对 Bosch进行了采访&＃xff1a;企业能够从提高交付速度中得到的好处&＃xff0c;导入敏捷和 DevOps后&＃xff0c;组织的下一步措施&＃xff0c;使用试验进行创新&＃xff0c;用于试验的实践和组织如何更具创新性。
\\
InfoQ&＃xff1a;你能解释企业如何从提高交付速度中获益&＃xff1f;它为什么重要&＃xff1f;
\\
\Bosch&＃xff1a;尽管许多企业花费了很多时间专注战略&＃xff0c;并多次尝试对行业“预测未来”&＃xff0c;但事实上行业中许多现有企业都错过了发展。无疑&＃xff0c;特别在欧洲许多人将诺基亚作为错失良机&＃xff0c;被新进入者淘汰的典型例子。诺基亚通常被视为例外和异常值。然而&＃xff0c;对财富500强名单研究显示2000年52%入榜企业如今都从名单上消失了。所有的企业都有战略和长期预测&＃xff0c;但是仍未能错过市场的潮汐变化。通过对多家企业的研究&＃xff0c;和我在行业生涯中的主动经历&＃xff0c;我意识到企业的关键区别在于减少识别客户需求和在市场上拥有可用的能够解决该需求的解决方案之间的时间。应对快速变化的客户需求的敏捷和响应能力需要“速度需求”。
\
\\
InfoQ&＃xff1a;许多企业都采用了敏捷&＃xff0c;而现在 DevOps很热门。你觉得下一个是什么&＃xff1f;
\\
\Bosch&＃xff1a;基于我们的研究&＃xff0c;我们开发了一个模型&＃xff0c;叫做“通往天堂的阶梯”&＃xff08;参见 Continuous Software Engineering一书&＃xff09;。这个模型基于较长一段时间内跟数十家企业的合作和跟踪随着时间推移开发实践在这些企业的演进。在模型中&＃xff0c;组织从传统典型的瀑布式或者迭代开发方法开始。下一步&＃xff0c;企业在 R\u0026amp;D团队中采用敏捷开发实践&＃xff0c;但是其它组织保持不变。敏捷团队通常会表达缺乏对所写软件验证能力的不满&＃xff0c;并走向第三阶段&＃xff1a;持续集成。一旦持续集成成功&＃xff0c;企业总会有一个该软件的生产质量版本&＃xff0c;然后企业会进展到下一步骤&＃xff0c;持续部署步骤。在这个阶段&＃xff0c;因为新软件的频繁部署不允许 R\u0026amp;D和运营组织之间传统、缓慢的交接&＃xff0c;所以DevOps成为重要的组织原则。这就要求同一团队负责开发和运营职责。
\\然而&＃xff0c;很少有人意识到持续部署是达到目的的手段&＃xff0c;其本身并不是目标。真实目标是它允许企业接近不同的开发模型&＃xff1a;持续部署能够实现A/B和分割测试的使用&＃xff0c;也能够实现其他定量测试方法&＃xff0c;向客户展示新功能的相关性。这允许企业与客户采用通过假设驱动试验驱动的开发模型&＃xff0c;而不是传统需求驱动的开发方法。其如此重要的原因是因为我们和其他研究表明典型软件系统中超过一半的特性从来未被使用过。这些特性可以认为是浪费&＃xff0c;一开始就不应该开发。我们需要一个开发模型在构建这些特性时完整的开发工作被提交前清除这些特性。我们已经开发了一些模型且适用这一开发阶段&＃xff0c;比如“R\u0026amp;D作为创新试验系统”。
\
\\
InfoQ&＃xff1a;你如何组织 R\u0026amp;D作为创新试验系统&＃xff1f;
\\
\Bosch&＃xff1a;在迈向 R\u0026amp;D作为创新试验系统这一阶段的过程中&＃xff0c;与之相关联的重点区域是产品管理与产品开发之间的关系。传统上来讲&＃xff0c;产品管理侧重于构建什么&＃xff0c;产品开发侧重于如何构建。这种分割能够满足可预测和变化缓慢市场中的组织。但不幸的是&＃xff0c;越来越少的市场能够满足这一要求。此外&＃xff0c;使用这一传统模型的企业其运行模式是&＃xff1a;只有客户明确要求新特性或者产品的时候&＃xff0c;新特性和产品才能得到充分的优先级。有时这会在客户需求出现和客户能够口头表述需求之间出现严重的时间滞后。客户需求出现跟客户能够表达出需求之间的时间就是市场新进入者扰乱现有企业的最佳时机。
\\所以我们不能坐等客户上门要特性或者产品&＃xff0c;我们不能在“如果我们构建此特性或者产品&＃xff0c;他们就会使用”的假设下构建特性或者产品。那么我们如何发现最有价值的特性或者产品提供给客户&＃xff1f;答案是要么与客户基于领域中已经部署的产品这一背景不断地试验&＃xff0c;要么通过其它试验方法不断试验。组织方法是将产品管理和产品开发聚集到同一个团队。虽然这是基本敏捷方法的规范&＃xff0c;但是许多企业中产品负责人是一名技术人员&＃xff0c;例如架构师或者高级工程师&＃xff0c;而不是真正面对客户的人员。每个敏捷开发团队&＃xff08;满足亚马逊2-pizza规则&＃xff09;同样包含肩负产品经理角色的人。同时&＃xff0c;团队提出假设与客户一起测试&＃xff0c;然后开发和执行这些试验。这可能会导致特性从产品中撤回&＃xff0c;因为客户反馈不温不火。或者&＃xff0c;基于客户使用产品的数据&＃xff0c;与产品管理的需求规范相比&＃xff0c;可能特性仅仅需要部分实现&＃xff0c;但是特性已经充分开发了。此外&＃xff0c;可能导致特性的实现与团队原假设非常不同&＃xff0c;因为客户反馈显示需要这一特性。最后&＃xff0c;当然一些特性的实现可能完全按照说明&＃xff0c;因为团队正确预测了客户最迫切的需求。
\\这种工作方式的重点在于&＃xff08;1&＃xff09;产品管理和开发参与团队&＃xff0c;&＃xff08;2&＃xff09;产品管理和开发都要拥抱此工作方式带来的不确定性并且&＃xff08;3&＃xff09;建立一种数据胜过意见的文化。
\
\\
InfoQ&＃xff1a;你能举例说明使用数据来决定构建或者不构建什么&＃xff1f;
\\
\Bosch&＃xff1a;在 Web 2.0/SaaS领域&＃xff0c;这是规范&＃xff0c;并且数家企业在 SaaS领域花费了更多的精力重新实现已经开发了的特性&＃xff0c;从而弄清楚替代实现方案能不能带来更好的商业成果。例如&＃xff0c;对于电子商务网站&＃xff0c;就是客户进入网站完成事务的汇率。一些我共事的企业如今开始在实现阶段和实现后更加严格地评估特性&＃xff0c;从而决定该特性是否应该保留在产品中还是应该去除。此外&＃xff0c;在嵌入式系统领域&＃xff0c;有很多企业在特性已经开发后去除特性的案例&＃xff0c;因为其增加的复杂性超过了特性提供的价值。不幸的是&＃xff0c;由于保密约束&＃xff0c;我不能分享这些特性细节。
\
\\
InfoQ&＃xff1a;在产品开发中使用这种方法&＃xff0c;你能获得什么好处&＃xff1f;
\\
\Bosch&＃xff1a;正如我之前提到的&＃xff0c;在典型软件系统中有一半到三分之二的特性从未或很少被使用。试想一下&＃xff0c;我们可以腾出 R\u0026amp;D资源的50%&＃xff0c;因为我们只构建客户真正、真正想要的功能&＃xff0c;这些功能会为客户产品增加价值。再想一下&＃xff0c;这50%的 R\u0026amp;D资源可以分配给现有产品新特性和全新产品的创新和试验。这对任何组织竞争地位的影响将是惊人的。这给采用这种方法的企业带来的关键好处是&＃xff1a;在投资回报率方面&＃xff0c;极大地提升了R\u0026amp;D投资的精度。在软件中心&＃xff08;www.software-center.se&＃xff09;&＃xff0c;我们积极地与伙伴公司合作研究这一机会&＃xff0c;包括爱立信&＃xff0c;沃尔沃&＃xff0c;Saab&＃xff0c;杰普逊&＃xff08;波音&＃xff09;和众多其他的公司。例如&＃xff0c;在一些研究中&＃xff0c;我们确实与哥德堡的一家企业合作&＃xff0c;我们度量“服务启动”的频率&＃xff0c;即特性使用的次数。如下图所示&＃xff0c;只有很少的特性使用非常频繁。许多特性从未或者很少使用&＃xff0c;并可能被认为是浪费。
\\
\
\\
InfoQ&＃xff1a;组织可以部署哪种实践用于试验&＃xff1f;你能举例说明吗&＃xff1f;
\\
\Bosch&＃xff1a;有很多实践组织可以采用并从中获益&＃xff0c;但是这里我将重点介绍三种实践。首先&＃xff0c;组织面向客户的交流被显著拓展。传统上来讲&＃xff0c;R\u0026amp;D人员从来不会面对客户&＃xff0c;除非在客户现场出现意想不到的问题。如果 R\u0026amp;D团队被认为应该对有价值的、新客户功能提出有见地的假设&＃xff0c;那么他们需要理解客户的实际情况和产品的部署。这需要 R\u0026amp;D人员在客户和客户现场花费时间。不仅仅是一些人&＃xff0c;而是每个人每年至少要在客户身上花费一些时间。这似乎是一个昂贵的运动&＃xff0c;但增进理解和客户同理心的价值远远超过其成本。例如&＃xff0c;我以前的一个雇主&＃xff0c;要求企业所有员工每年至少在客户那花费一天时间&＃xff0c;在他或者她的工作日跟踪客户。
\\其次&＃xff0c;企业需要适应数据驱动的工作方式。这需要测量现有的和新的产品&＃xff0c;以便确定特性使用情况。我们的研究表明所有我们合作的企业收集了大量的数据&＃xff0c;但是这些数据主要用于故障排除。R\u0026amp;D不具备访问权&＃xff0c;即使 R\u0026amp;D具备&＃xff0c;团队也没有使用可用的数据。用 Edwards Deming话说&＃xff0c;我们需要“我们信仰上帝&＃xff1b;其他所有人请用数据说话”的文化。
\\第三&＃xff0c;大多数组织工作在功能筒仓&＃xff08;functional silo&＃xff09;的环境下&＃xff0c;跨筒仓的协作是缓慢、令人沮丧和充满失败的。对于渴望敏捷和数据驱动的企业而言&＃xff0c;产品管理和开发有效地一起工作是不够的。整个组织&＃xff0c;从销售和市场到发布和交付团队都需要有效地一起工作。这需要摆脱传统的官僚组织机构&＃xff0c;转向授权、自我管理的团队&＃xff0c;并提供前所未有的自治。在管理文献中&＃xff0c;有一连串新奇的出版物在探索个体自我管理和自我导向的组织&＃xff0c;和没有层级、老板、强制性内部决策过程情况下组织的运营。相反&＃xff0c;这些组织已经发现了新的机制&＃xff0c;用于协调组织内的工作&＃xff0c;并且被大众视为结构化组织的下一阶段。一个众所周知的例子是 Valve&＃xff0c;一家负责 Dota&＃xff0c;Portal和Half-Life的游戏公司&＃xff0c;一路心甘情愿地建立自我管理。
\
\\
InfoQ&＃xff1a;如果组织希望变得更具备创新性&＃xff0c;你能提供一些建议吗&＃xff1f;
\\
\Bosch&＃xff1a;有三件事我想解释清楚。
\\首先&＃xff0c;创新需要个体有时间专注创新。因此&＃xff0c;100%甚至更多地分配你的员工&＃xff0c;然后告诉他们去创新仅仅是一种假象。一些硅谷公司已经制度化了员工可以自由支配自己10-20%的时间。如果你想利用组织内每个人的创新能量&＃xff0c;你需要给他们这样做的空间。
\\其次&＃xff0c;许多创新思想都扼杀于内部反馈和典型的高层领导驱动的选择过程。原则应该是创新思想只有在拥有足够大的客户反馈样本表明缺乏该思想的支持的情况下才应该放弃。测试棒应该是客户&＃xff0c;而不是组织内 HIPPOs&＃xff08;薪水最高人的意见&＃xff09;的意见。
\\最后&＃xff0c;建立一种文化&＃xff1a;尝试创新思想并接受不符合最初假设的可能性。我不喜欢关注失败&＃xff0c;有人觉得领导喜欢&＃xff0c;但是因为尝试没有成功的事情而在组织内惩罚员工是扼杀创新文化最快速的方法。当然&＃xff0c;我们喜欢能够给企业带来重大好处的创新&＃xff0c;但是得到这一成果的唯一方法是尝试更多的想法和创新&＃xff0c;并基于客户的反馈选择其中的想法和创新。
\
\\
关于受访者
\\
Jan Bosch是瑞典哥德堡查尔姆斯理工大学的软件工程系教授和软件中心主管。此前&＃xff0c;他是硅谷 Intuit和芬兰诺基亚的副总裁。他还积极担任领头企业的顾问和创业领域的董事会成员。更多有关他背景的信息可以参考他的网站&＃xff1a;www.janbosch.com。
\\\\
查看英文原文&＃xff1a;Using Experiments and Data to Innovate and Build Products Customers Actually Use
京公网安备 11010802041100号