《持续数字化》和《项目短视症》作者问答

本文要点

• 在当今现代化的时代中，每家企业都是数字化企业。
• 企业需要转变为技术发展和企业发展相互推进的持续性模型。
• 在软件开发中应用项目模型存在着诸多问题。由此，我们推出了“#NoProjects”运动。
• 产品是永存的，需要始终处于维护状态。项目是阶段性的，终有结束之时。
• 很大一部分 IT 项目会失败（30% 到 70% 不等）。失败并非由于能力或目标上的问题，而是因为采用了错误的模型。

如何在现代数字化企业中开展工作？近期， Allan Kelly 针对此问题推出了两本著作。Kelly 是一位作家、演说家、业界从业者和顾问。

第一本书是《持续数字化》（Continuous Digital）。该书解决了一个组织如何在“所有业务均已数字化”的现状下实现自身的构建问题。在该书中，Kelly 提出了“持续化模型，即一种技术发展和业务拓展相互驱动的模式”。

第二本书是《项目短视症》（Project Myopia）。作为上一本书的配套书，该书探讨了“#NoProjects”运动的各项基础理论，并解释了持续性文化的重要性。

两本书均提供节选章节下载。全书可从亚马逊购买，地址分别是《持续数据化》和《项目短视症》。

InfoQ 就这两本书与 Kelly 进行了一次问答。

InfoQ：您为什么要撰写这两本书？意在解决哪些根本问题，还是要指出存在着哪些机会？

Allan Kelly：我本来完全没有将撰写这两本书列入我的计划。长期以来，我一直在思考“项目”的开展是如何导致问题的。我依然记得早在 2011 年与 Mary Poppendieck 的一次谈话。

时间回到五年前，我和 Steve Smith 以及 Joshua Arnold 在推特上发起了一项“#NoProjects”运动。推特并不适合开展辩论，但是非常适合提出一些新的想法。我们很快就发现，项目模型及其在软件开发中的应用中存在着大量的问题。很显然，还有其他不少人也发现了这些问题。

Vasco Duarte（即#NoEstimates）希望我们能将所有观点汇总起来。由此形成了一篇长长的论文，进而汇总为《项目短视症》一书。该书提出了项目中存在的一些问题。

然而，光提出问题还不够，人们更希望得到更好的办法，即替代解决方案，但该书尚不足以满足人们的这一需求。在推特上，不少人一直在提问，“那么我们该换成什么做法呢？”

由此，我着手去给出一种替代解决方案。一开始，我的想法和我以前提出的 Xanpan 方法毫无二致（译注：Xanpan 是 Kelly 提出的一种组合了 XP 和 Kanban 的方法，并以此为书名撰写出版了“Xanpan”一书）。但是我们在解放思想后，项目中浮现出了两种真正强大的力量。

首先，我们身处的时代是一种持续化的时代。改进是持续的，集成是持续的，交付也是持续的，诸如此类。尽管企业痴迷于做出变革，但他们真正渴望的是自身能一直生存下去。没有人希望自己的雇主会破产，这不是什么好事。一个成功的软件也应该是持续发展的，使用者也需要不断做出改变。而不成功的软件则没有人使用，因此也不会发生改变，进而逐渐消亡。

第二，企业正日益数字化。技术不再甘居“后台”，已成为产品的前沿和中心。对于商务人士来说，这是一个大问题。现代企业和技术是密不可分的。在这种情况下，项目的暂期性本质不复存在。

InfoQ：这两本书面向哪些读者？您如何确保书中的内容对这些意向读者而言并非“老生常谈”？

Kelly：很可能《项目短视症》一书就是一些“老生常谈”，我知道有些开发人员喜欢它，因为书中的内容道出了这些人的挫折。不过我认为，那些认定了这种项目模型的开发人员应该读一读这本书，进而针对各种批评找出自己的答案。

《持续数字化》一书则不同。该书对持续数字化业务给出了一种全新的替代模型，它面向的是两类读者：

一类读者是担负着管理职责的人。我在书中还考虑到了未经正式授权的管理人员，比如 Scrum Master 和业务分析师。管理者可从中学习到大量的内容，因为书中介绍的正是很多管理人员应该掌握的思维模式，可用于为他们的决策提供信息。

另一类读者是未来的领导者和管理者。虽然他们当前任职开发人员、测试人员和分析师，但终将从这种全新的管理模型中受益。

这些意向读者之所以非常重要，另一个原因在于随着企业向更加自组织的方向发展，更少需要管理者做出管理决策并完成“管理”工作了。这样，更多人需要具备管理方面的知识。其中的相互矛盾之处在于，专职管理者的减少意味着更多的雇员需要参与到管理工作中。

InfoQ： 您为什么同期撰写了这两本书？这两本书之间有何差异？阅读的顺序如何？

Kelly：读者可按任意顺序依次阅读这两本书。如果只想读其中一本，推荐阅读《持续数字化》一书。不过这本书篇幅较长。

《项目短视症》一书介绍的是项目模型不适合软件开发的原因，以及项目模型是如何对软件造成破坏的。读者可将该书中的内容视为停止使用项目的一个推动力。

《持续数字化》一书提出了一种更好的工作方式，如果你喜欢，可以将其视为拉动力。这本书并没有从项目模式的失败中寻找论据，而是从现代、数字化、商业的本质中寻找论据。这类业务本质上是基于技术的。业务就是技术，技术就是业务。

人们常问，“Uber 究竟是一家技术企业，还是一家通讯公司”。但事实上，Uber 两者皆非。Uber 是一家技术与产品密不可分的数字化企业。 Spotify、JustEat、AirBnB 等多家二十一世纪的企业也都是如此。

InfoQ： 现代经济有何不同之处？为什么人们如此看重“数字化”？该理念是否只是另一个流行语罢了？

Kelly：我是在数字化世界中成长起来的。我的第一台计算机是我 12 岁时使用的 1KB 存储、Z80 处理器的 ZX81。在很长一段时期中，我都忽视了“数字化”的存在。模拟计算机从来就没有走得太远，因此“数字化”一词并未带来任何意义。

但对于那些不具有上述经历的人们而言，“数字化”是十分有意义的。一些人并非是伴随着 Facebook 甚至是 MySpace 成长起来的。对于这些人而言，“IT”曾意味着不人性化的界面、响应缓慢的终端、Word 的崩溃以及 IT 的集成。数字化世界对于这些人而言是完全不同的，它意味着 iPhones、Twitter、GPS、传感器，以及所有由于低代价 CPU 周期而得以实现的事物。

当然，它们也都是技术，并且是一些完全不同的技术。以亚马逊为例，从某种程度上看，该企业就是 Sears 或 Littlewood 商品目录服务的数字化版本。但是技术改变了客户体验，使得企业表现得完全不同。

InfoQ： 您强调指出团队是价值的来源和工作的重点。为什么是团队而不是个体贡献者？团队关注的重点是什么？

Kelly：这是一个关于缩放尺度的问题。有些情况下，个体可以发挥巨大的作用，这通常是技术发生改变时。想想那些通过编写 Commodore-64 游戏或早期 iPhone 应用而致富的青少年。

从总体上看，当前的系统对于个体而言过于庞大。系统所需的技术和技能也越来越多。人们仅知道 C 语言是不够的，还要掌握 JavaScript、CSS、Jenkins、流水线，并且具备设计、测试、联络利益相关者和做出分析的技能。此外，还需要具备一些非技术技能。例如市场营销、销售、产品支持等。

即便有些人可以自己编写出一个有价值的大型系统，但是依靠团队可以更快地产出系统、更快地实现价值。一旦我们开始将延迟代价考虑进来，那么很多事情就都不一样了。

InfoQ：您为什么会推出“#NoProjects”运动？难道没有成功使用了项目模型的企业吗？

Kelly：显然，技术发展带来了显著的成效。我们看到了 iPhone、无人驾驶汽车、Netflix 等。但这是因为这些项目都是成功运作的，还是因为它们没有使用项目模型？

我们常常会听到有人说 40％到 70％的 IT 项目是失败的。虽然我并不知道真实的数字，但既然存在这么多失败的项目，我必须考虑，这是因为模型本身就是失败的吗？

由此，我采纳了其中一些成功项目的建议做法，尽管项目模型并不建议如此做。这些项目之所以会取得成功，就是因为打破了原有的规则，并未循规蹈矩。

其次，我们还未考虑有一些代价，其中包括技术债务、软件缺陷、无偿加班、延迟交付所导致的价值损失等。由此，其中一些成功的项目看上去并非如此成功。

当然，这都是过去的情况。我们现在生活在一个不同的时代。我们需要的是一种在很多情况下可正常工作的模型。

InfoQ： 您对规模不经济（Diseconomies of Scale）提出了自己的观点，但该观点看上去有悖常理。在此您能给出一些解释和实例吗？

Kelly：有人在购买牛奶时，会希望两个 500 毫升的纸盒装牛奶要比一升纸盒装牛奶贵，一个两升纸盒装牛奶会比两个一升纸盒装牛奶便宜。这就是规模经济，亨利·福特正是据此制造了上百万台福特 T 型车。

虽然规模经济适用于牛奶及其它许多商品，但并不适用于软件开发。开发人员在开发软件时，起主要作用的是规模不经济。要提高开发效率，开发人员必须得擅于处理大量的细节。

修复一个一千行代码程序中软件缺陷，要比修复具有一万行代码程序中的软件缺陷轻易许多，更不用说十万行代码的程序。程序代码量越多，越难以维护。由此，人们提出了微服务运动。

小规模团队要比大型团队更加高效。在四个人组成的团队中，每个人的交付量要高于十四个人的团队，更不用说四十个人的团队了。随着团队规模的增长，交流的代价也随之增大，难点在于如何建立每个人对团队整体的共识。

另一个例子就是测试。企业往往会出于规模经济上的考虑，一次性将所有的软件修复一并打包，汇总到某个大版本中。相比起测试一百个每次做一处更改的版本，测试一个具有一百处更改的版本的难度增加了多个数量级。

假定某个程序版本每年发布一次，其中包括一百处更改，但却遗漏了一处可导致用户蓝屏的软件缺陷。那么在用户眼里，该程序版本是完全失败的。而如果该程序对一百处更改每次发布一个版本，其中依然遗漏了可导致蓝屏的缺陷。那么这时在用户眼里，软件版本只有 1% 失败了，而 99% 是成功的。

如果你就是修改软件缺陷的开发人员，你会选择哪种做法？

同样，如果再加入延迟成本上的考虑，你会发现一百个小版本的投资回报如火箭般攀升。

最后一点，在软件版本已完成发布、所有的更改已处于“完成”状态的情况下，一旦软件上线，规模经济就能得到最大化的体现。

InfoQ： 如何采用书中的方法在融资和监管领域攻坚克难？

Kelly：道理类似，我们需要着眼于细微之处的优化。停止大规模资金的操作，转而定期审核小额资金。

这大体上就是硅谷风险投资模型。固然风险投资也有其缺点，但其基本的融资模式是有效的。一旦团队获得一小笔投资，进而证明他们能够在可运作软件或经验证市场上取得推进，那么团队就会进一步获得更多的投资。这是一种投资组合模型，投资者可从中开展大量的小额投资，剔除一些表现不佳者。

同样，这需要投资者善于处理大量小规模投资。投资组合过程需要经常定期有效地运行。

InfoQ：您在《项目短视症》一书中对比了持续交付与基于项目的方法。这两种方法是否可以并存？

Kelly：是的。现在很多地方都在同时使用这两种方法，但是二者间的融合是磕磕绊绊的。我不得不质疑，为什么会这样？采用其中一种方法相比于采用另一种方法的优点在哪里？

一些小组在项目模型中采用了持续交付方法，但是最终导致了工作压力加大。如果我们认真思考一下，会发现这两种方法并不兼容。持续性意在持续开展，团队一直在寻求要做的事情和要交付的东西。项目只是一种暂时性结构，是为完成一些预知的事情而创建的。

如果同时使用这两种方法，那么团队会对项目进展和目标产生一些模糊不清的认识。这本身就是一个问题，尤其是对于项目监管。将项目成功的标准应用于一个连续性团队，这是不合乎逻辑的。

InfoQ： 为什么会出现“短视症”？也就是说，是什么导致了一个组织在自身的工作方式上产生短视问题？

Kelly：企业在运行项目时，总是认为这些工作终会结束。他们忽视了一个事实，技术和改进是永不停步的。新的机遇会不断出现，人们在运用技术时会发现新的运用方式，看到技术的新用途和发展机会。

如果这时说，“不，我们已经做完了这一项目”，那么我们就没有获取本应取得的价值。

如果我们说，“那好，让我们启动新的项目吧”，那么我们就会确认价值所在。但这样做会引入一些项目设立上的成本，也会损失一些时间（想想延迟成本问题），并需要假定项目需求是预先已知的。

InfoQ： 敏捷开发与思维业已存立近二十年。怎么让这些理念广为流行花了如此多的时间？它们目前是否已经足够流行了呢？

Kelly：这些想法一直潜伏在敏捷中，但即使在敏捷发展的同时，仍有太多的项目管理活动。我们这些敏捷人士中有许多人都在回避这个挑战，哪怕只是因为它可能会威胁到职业生涯。

现在推动这些变化的是向数字商务的转变。技术正在推动增长，固步自封于项目模型中，就会扼杀潜力。

InfoQ：这些理念无疑适用于 AirBnB 和 Uber 这样的新兴企业。那么对于多年来一直在交付项目的现有企业而言，这些理念是否适用？

Kelly：一些具有 IT 部门的传统企业，会将业务整体看成是一个“终将完工”的项目。但是大家是否能想象 AirBnB 宣称自身的系统已经完工。一旦一家数字化企业宣称自己已经“大功告成”，那么它无疑是放弃了领导权，将地位拱手让给竞争对手。

遗留企业不能保持这种短视，它带来的额外成本和目标的模糊性。这样做的企业正让自己面临挑战。数字化企业不能将技术视同为一些独立于业务而发生的、终有一天会实现的事情，错误地认为技术最好是低代价的，且和自己毫不相干。

以传统的银行为例。他们在各项措施中都将技术视为次要因素，三十年来一直保持贪图便宜走捷径、累积技术债务、盘剥雇员和自欺欺人的做法。现在，这些银行发现自身的技术和系统无法与金融科技（FinTech）分庭抗衡。

那些曾经取得成功的实践和过程，包括繁重的项目管理、扩大化的分析、外包、离岸外包、大批量工作等，现在都已成为取得成功的阻碍。从表面看，数字化类似于旧式 IT 方式（Java 变成了 JavaScript、测试变得自动化，等等），但是两者截然不同。

英国有一家 TSB 银行。六个月前，TSB 做了银行大系统的更新。就在 TSB 在推特上发出庆祝图片时，客户抱怨称无法访问自身账户和支付账单。六个月后，TSB 依然未得解决所有问题。虽然 TSB 声称自己是敏捷的，但显然他们并未做到，很明显，管理人员并不知道如何管理技术。这类银行事实上已经死亡，只是他们自身还懵然不知。

银行当然可以声称自己是一家“凑巧通过提供银行服务赚钱的技术企业”。但是，他们也给出了可怕的技术债务。违背康威定律（Conway's law）限制了他们的能力。尽管他们必须放手一搏，但是其中只有少数会成功，大多数都会失败。

面对金融科技，传统银行束手待毙（sitting ducks）。我认为很多资深人士深谙此道，这就是为什么很多人通过投资作为竞争对手的金融科技而降低风险。

书籍作者简介

Allan Kelly 是一位敏捷改进专家，他已帮助很多各种规模的公司强化自身的敏捷流程并改进自身的数字化产品，其中的成功案例包括维珍航空、高通、英格兰银行、Reed Elsevier，以及一些尚未为人熟知的小型创新企业。他发明了价值扑克（Value Poker）、时间 - 价值概览（Time-Value Profiler）和回顾对话表（Retrospective Dialogue Sheets）等工具。Kelly 也是多本书的作者，包括《亲爱的顾客，告诉你关于 IT 的一些真相》（“"Dear Customer, the truth about II”）、“Xanpan”、《软件开发人员的业务模式》（“Business Patterns for Software Developers”）、《持续数字化》、《项目短视症》等。Kelly 的博客地址是 https://www.allankellyassociates.co.uk/blog/ ，推特是 @allankellynet。

查看英文原文： Author Q&A Continuous Digital and Project Myopia

感谢冬雨对本文的审校。