从持续交付中获得商业优势

最新推荐文章于 2024-11-09 14:02:21 发布

weixin_33725126

最新推荐文章于 2024-11-09 14:02:21 发布

阅读量135

点赞数

文章标签： ux ui

本文链接：https://blog.csdn.net/weixin_33725126/article/details/89157414

版权

Gojko Adzic在 Agile Tour London 2015上发表了主旨演讲，关于“如何将持续交付转变成商业竞争优势”。InfoQ采访了 Adzic，主要关于向持续交付要效益、Gojko的三条持续交付规则、可能出现的问题和风险、以及在持续交付中使用多版本控制。

InfoQ：您谈论了企业如何才能从持续交付中获得效益。您能给出一些案例吗？

\
Adzic：我觉得企业正从持续交付中获得利益，比如降低发布的技术风险，和加快产品上市时间，但是他们可以从持续交付中获得更多的效益——通过从技术角度解锁持续交付的关键问题和解锁一些非常有趣的商业优势，从而使解决方案更加有效。例如，通过整理车辆的持续交付管道，Tesla（汽车制造商）能够比竞争对手更加便宜地处理产品缺陷和召回缺陷产品（参考 Tesla’s over-the-air fix: Best example yet of the internet of things?）。
\\
此外，人们很少考虑持续交付对产品体验中非技术部分的影响——比如市场营销和用户期望。例如，当在 MindMup工作时，我们使用持续交付从发布中消除可能导致意外发生的因素（take away the drama），让事情发展顺利并可预测。但是，消除意外因素的同时我们也远离了令人兴奋的事情。几乎不可能让媒体报道一连串持续的小改进——因为没有一个单一的更新具备报道的新闻价值。
\\
同样，没有软件版本和主要更新，客户往往会感受到更多的权益。每年一个版本，用户往往会付费升级。当换成一连串持续的小改进时，用户则希望永远免费试用新产品。许多移动应用开发人员一直被这个问题困扰着，几乎不可能让现有客户为了一个重要更新付费，但是仅仅开发和发布免费产品并不能带来很大的商业意义。
\

InfoQ：您提出了 Gojko的三条持续交付规则。它们是什么？

\
Adzic：与一套严肃的规则相比，更多的是类似 Asimov著名的机器人三定律的文字游戏，我试图捕捉团队在技术因素之外对持续交付管道产生误解的三个关键问题。技术因素已经被现有的实践和文献覆盖并解决，但是迈出更大的一步，看看一连串的小改变是如何把技术之外的事情搞糟的也非常的有趣。
\\
持续交付可能不会……
\\
使用户混乱\\
中断用户的工作或会议\\
扰乱或者阻止营销活动\

InfoQ：您在演讲中提到持续交付中可能会有一些问题和风险。一个可能是提高效率可能会伤害客户。您能给出一些案例吗？

\
Adzic：当有一连串持续的更新时，许多团队不会考虑在整个更新过程中会对客户的会议和工作产生什么影响。我看到过团队要求他们的客户在繁忙的工作日注销并重新登录，仅仅是因为软件有一个新的版本发布，人们彻底被新增的UI/UX混乱了。对于较大的改变，很容易在整个产品中保持UX的一致性。但是对于一连串的小改变，常常是在较长时间内更新和发布产品的一部分，所以用户常常必须处理不一致性。这方面的一个案例是，Paypal去年实施的“新的业务面板”。我的公司在 Paypal账户有两种货币余额，某天早上我登录上去后，总余额让我以为账户上少了数千英镑。我花了一个小时，试图弄明白是否其他人获得了账户访问权限并转走这笔钱，或者我被骗了，但是我没有找到任何明显的错误。实际上，这笔钱还在那儿——有人重新设计了面板，使其只显示一种货币，我认为应该为多货币客户推迟这种设计。这不是我想要的最佳客户体验，但是我可以理解他们为什么那么做。同时，在新的业务面板准备好之前，不应该强迫客户使用新的业务面板。
\

InfoQ：您还提到，通过交付小的功能增量，你不再有大的发布版本可以向你的客户推销。对此，你有什么解决方案？

\
Adzic：我现在的想法是解耦部署和发布。在我们行业中，部署和发布常常被看成一件事，但是一个是发布代码到产品的技术事件，另一个是让客户可用的市场事件。通过解耦这两件事情，我们可以从中获利，将意外因素从部署中消除，同时仍然保持其具有新闻报道价值，从而产品特征可以发布出去，制造最大的营销卖点。
\\
这是一个需要解决的困难的技术难题，尤其是因为部署软件的一些版本需要对某些人开放访问，从而对其验证和确认，但是它也需要对外面大多数用户是隐藏的，从而制造营销热点。
\

InfoQ：在您的演讲中你说“没有多版本控制的持续交付是不负责任的”。您能否解释一下？您能解释一下为什么？

\
Adzic：能够运行不同组件的多个版本是一个很好的解决方案，或者是我上文列出的问题——将部署软件的一些版本对用户的一个子集可见，但是其他用户看的却是不同的版本。我说的不是网络重新路由或者功能切换——而是一种系统性解决方案，多种版本可以并行运行，而不会中断。如果解决了这个问题，就没有必要中断会议或者忙于部署——人们可以继续使用当前版本，直到会议结束。同时也可能可以逐步发布产品——在 Paypal面板案例中，他们可以向拥有一个货币账户的用户发布面板，并解决整个 UX一致性/迭代的问题。这同样允许将部署从发布中解耦。这就是为什么多版本作为一个架构概念如此强大的原因。
\\
与此同时，多版本开辟了一些惊人的业务功能，比如高风险或实验性功能的温和/逐步发布；基于1%的活跃用户运行产品试验，从而证明高昂的假设；对高端用户提供预览版；紧急修复和比以前更廉价地预防问题；围绕营销事件而不是技术部署能力运行营销活动。
\

InfoQ：对于那些希望有效应用持续交付的组织，您有没有什么建议？