不会摧毁企业的企业转型项目

霞多丽项目

霞多丽公司是一家知名制造商，生产昂贵的商品（我必须含糊其辞！）。他们越来越多的收入来自租赁这些商品，而不是出售它们。租赁是一项古老而复杂的业务。随着租赁业务的增长，他们的计算机系统也需要增长。这就是我们介入的地方——构建所谓的“前端租赁系统”。前端租赁系统处理所有在您签署（或用租赁术语来说，预订）租赁协议之前发生的事情。这包括对租赁人进行信用检查、报价、发放和制作文件。在我们开始之前，大多数这些操作充其量只能算是半自动化的。

我们构建的系统将满足许多技术人员的梦想。它使用了所有最新的企业 Java 技术——EJB、JSP 和其他缩略语。当然，重要的是它对业务的影响。它使霞多丽公司能够整合其办公室，从多个地区办事处搬迁到一个办事处，减少了人员数量（同时保持了处理的租赁数量），使流程更加一致，并缩短了周期时间——以前获得报价需要两天时间，现在只需要 45 分钟。此外，互联网的奇迹使霞多丽公司的经销商能够直接访问系统以获取报价，这有助于使霞多丽公司的产品对客户更具吸引力。

歌海娜项目

歌海娜公司是一家大型零售商，在美国每个无聊的购物中心都有分店，更不用说我曾经试图挤进去的每条时尚购物街了。像任何零售商一样，他们非常关心自己的供应链。他们必须将商品从不太富裕的供应商那里运送到富裕的客户手中。他们的仓储复杂性简直是一场噩梦。每个 SKU 都有多种不同的品种。

虽然我将歌海娜称为一个项目，但实际上它是一系列项目，每个项目持续 6-9 个月，在四年内完成。每个项目都针对一个特定问题，例如圣诞节前大量集装箱到达配送中心，却在那里停留了几天，人们才弄清楚集装箱中的物品与零售商实际期望的物品之间有什么关系（答案是“比你想象的要少”）。我们使用基于通用关系数据库的 Forte 技术构建了这些系统。

丹魄项目

丹魄公司出租集装箱——从普通的金属箱到复杂的、巨大的冷藏箱，应有尽有。一家航运公司租用集装箱，在世界各地运输一段时间，然后将其送回。计算机可以发挥重要作用，帮助跟踪集装箱的位置以及何时会被取走。丹魄公司现有的系统不符合 Y2K 标准，最初，新系统被视为解决此问题的最便宜方法。然而，很快，它就演变成一个企业转型系统。我们使用 Forte 开发了它（我们过去经常使用 Forte）。

圣埃美隆项目

圣埃美隆看起来很像霞多丽——至少项目是如此。大公司，前端租赁系统，企业 Java 加上各种功能，有很多重叠的地方。（是的，确实有一些重用。）不同之处在于，圣埃美隆公司的昂贵商品在技术上也非常先进，因此它们在开始生产的那一刻就过时了。因此，圣埃美隆的一个主要优势是能够更好地控制库存，我们通过将其与他们的 ERP 系统集成来实现这一点。此外，圣埃美隆公司的租赁业务不如霞多丽公司的成熟，因此，制定一致的报价方法带来的益处更大。让销售人员在电子表格上制定交易方案很灵活，但会导致会计和利润管理混乱。

频繁交付

如果说有一件事让我印象深刻，那就是这些项目中成功与失败之间的共同区别，那就是频繁交付。我经常遇到一些人谈论他们目前正在进行的重大企业转型计划。他们热情洋溢地谈论他们在五年计划进行两年后取得了多大的进展。虽然我不是一个统计上有效的样本，但我发现我还没有在五年计划进行五年后遇到过这种程度的热情。我通常得到的最好回应是“如果我们……我们就会成功”。

我们成功项目的共同主题是在整个项目生命周期中频繁交付可用的软件。事实上，越来越多的主题是，项目越新，我们尝试交付的频率就越高。歌海娜是其中最古老的项目，每六到九个月交付一次。虽然这是一个彻底改革供应链的宏伟计划，但每个项目都是一个独立的项目，旨在成为一个可行的商业提案。非正式的说法是，这些项目通常在一年内就能收回成本的两倍。霞多丽是一个更新的例子，突出了缩短周期的趋势。在这里，我们每两到三个月部署一次新软件。

为什么这很重要？首先，这是关于建立信誉。企业并不以在投入大量资金到一项计划时保持耐心而闻名。即使你确实找到了愿意为公司改革计划提供五年资金的人，这个人也不太可能坚持五年。通常，大型新计划会在第三年左右成为他们的负担。除非有人能够在那个阶段展示出可行性，否则要么项目被放弃，要么赞助人和项目都会失去立足之地。

另一方面，交付会建立信誉，尤其是在你看到效益时：降低成本、提高及时性——这些比预期效益更重要。当人们看到系统在实际运行时，他们就能看到它带来的价值，以及它带来的变化。这种可见性也有助于提高软件开发人员的信誉。没有什么比业务人员抱怨说，虽然他们听到了自信的项目简报，但他们实际上不知道项目是否按计划进行更糟糕的了。部署的软件是实实在在的，它清楚地表明了进度。有时，情况并非如此，如果进展比预期慢。但即使在这种情况下，我也发现它仍然是值得的。如果开发速度放缓，你只能隐藏它一段时间。最终，现实总会以一种令人不快的方式赶上你。但如果人们看到稳定的进展，他们要么更能理解延迟，要么会更早地取消项目。这两种情况都比拖延很长时间才失败对企业更有利。

频繁交付还允许你从开发中学习。这对许多人来说听起来像是一个奇怪的短语，但我们的经验是，在进行这种项目时，没有人真正知道整个情况。如果你以前走过这条路，你就会知道你要去哪里，但企业转型意味着进入一个全新的世界。一个对客户和承包商来说都是不可预测的世界。虽然我们在圣埃美隆能够利用我们在前端租赁软件方面的经验（这是我们第四个这样的系统），但事实是，在那个规模上，每个企业都有足够的不同变化，足以构成一次新的旅程。

这一点还因企业转型项目通常涉及非常新的技术而加剧（我将在后面讨论原因）。在这种情况下，早期的交付应侧重于让技术人员学习技术并探索一些高风险领域。这些发现既有好的，也有不好的，因此要尽早进行，以便你能够相应地调整计划。

探索新领域有一个替代方案。那就是在其他人先走过这条路之前，不要尝试企业转型项目。这样，你当然会对要去哪里有所了解。当然，问题是，当你到达派对时，所有的食物都吃光了。

正如我之前所说，交付是指向企业交付，即将软件投入生产。然而，这个概念可以进一步扩展。即使在一个为期几个月的部署周期内，软件开发人员也可以以更紧密的周期构建软件：最短可以是几周。虽然你可能不想将每个周期都投入生产，但你仍然可以通过这些开发迭代获得许多学习和跟踪的好处。在过去一年左右的时间里，我们在几个项目中使用了这种短期的内部周期，随着我们看到更多成功，我们也越来越多地使用它。

预期意外

正如我之前提到的，企业转型不是一个可预测的过程。新的业务流程意味着你正在进入一个只有模糊了解，甚至根本不了解的领域。在进行这些项目时，会遇到意外。其中一些可能是坏的意外，一些可能是好的意外。只有通过对它们做出反应，你才能避免坏的意外带来的损害，并最大限度地利用好的意外带来的收益。

Tempranillo 提供了两种情况的例子。在负面方面，有一个关于维修的不愉快发现。当项目最初计划时，预计对集装箱维修的跟踪将是项目的一小部分。随着项目的进行，我们发现大约一半的工作是在跟踪维修。这导致项目的成本和时间表大幅增加。在这种情况下，唯一要做的事情就是正视问题并重新制定计划。

我见过另一种情况，试图继续执行原始计划，以避免偏离计划而导致的失败。这会导致计划与现实之间的偏差。你可以维持一段时间，偶尔你甚至可能由于其他更令人愉快的意外而重回正轨。但更多时候，偏差会持续下去，直到差异如此之大，以至于现实无法再被忽视。结果通常非常痛苦。

对于更快乐的另一种情况，它们可以以多种方式出现。我们的 Tempranillo 项目经理 Greg 讲述了业务人员查看我们现在拥有用于跟踪集装箱的关系数据库的事实。他们突然意识到，他们只需要一个简单的 SQL 查询就可以找到所有在集装箱维修方面拖延和付费的公司。访问这些信息很简单，但为 Tempranillo-Corp 节省了相当多的钱。这种好处在项目计划中被简单地忽略了，但事实证明它是新系统的一个重大好处，值得花点时间去实现。

Tempranillo 也有一个更大的例子。Tempranillo-Corp 不仅仅是出租集装箱，新任执行管理层决定出售集装箱租赁业务的一部分。在他们这样做的时候，他们发现要出售的部分是非典型的集装箱，例如巨大的冰箱。新系统使这些业务线能够轻松分离，这在旧系统中将是一场噩梦。不仅如此，修改系统以使 Tempranillo-Corp 能够出售“罐”业务（运输化学品、食品等）并仍然使用该系统来管理买方的集装箱并不困难，从而在交易的双方都获得收益。任何深入的需求分析都无法预测这种变化，因为它是一项深刻的业务变革。

面对这种不可预测性，人们很容易得出结论，计划几乎不值得付出努力。毕竟，如果计划很可能在项目进行到一半时就被放弃，那么它们有什么价值呢？但实际上，我们发现计划在这些不可预测的项目中至关重要。只是计划的重点不同，特别是它变成了一个持续的计划过程，计划定期重新制定。在这种环境下，长期计划既不稳定又粗略，但仍然有助于设定方向。短期计划更稳定，尽管在需要时仍然可以进行调整。

Chardonnay 是这种过程的一个很好的例子。当团队正在为当前的两个月部署开发软件时，分析团队正在制定未来两个月需要完成的工作。我问 Chardonnay 的项目经理 Scott，他对六个月后的任务了解多少。“一个要点列表，我不知道其中大多数是什么意思，我认为客户也不知道。”然而，这个项目对 Thoughtworks 和 Chardonnay-Corp 来说一直都是成功的。

获得高层管理支持

这并不奇怪，或者至少不应该奇怪。业务流程的重大变化需要来自业务管理层顶层的承诺。没有它，什么都不会发生。转型变化很少受到欢迎，但人类天生更喜欢他们所知道的魔鬼，而不是未知的未来，无论人们告诉他们未来有多好。克服这种自然抵抗需要领导力，而且需要大量的领导力。

高层领导力也需要为未来提供愿景。这可能不是一个非常详细的愿景，但考虑到这些项目的性质，它不需要很详细。它需要的是一些东西来指导进展，即使计划正在发生变化。这包括设定优先级，对做什么和不做什么做出艰难的选择。我们还发现，保持我对之前提到的频繁交付的承诺很重要。通常人们会想推迟部署，以便为一些真正很棒的功能腾出时间。但一个很棒的功能会导致另一个功能，很快你就会陷入不交付的陷阱，从而失去信誉和学习优势。在这里，频繁部署会有所帮助。如果 Chardonnay 必须在当前部署中跳过一个功能，那么它只需要等待两个月才能进行下一个部署。有了这么短的时间间隔，更容易做出不做什么的艰难决定。

如果你无法获得所需的高层业务支持，会发生什么？我们的建议是：不要理会这个项目。这听起来可能有点苛刻，尤其是如果这个项目是你认为对公司有利的项目。然而，高管的注意力是有限的，如果没有高管的注意力，企业转型成功的可能性就像在拉斯维加斯把你的工资押在 15 号上一样渺茫。

即使一个项目获得了高管的支持，它也并不一定能一直得到支持。在 Grenache，最初的领导者转而追求新的目标。这并不奇怪——成功的人喜欢迎接新的挑战。新领导者喜欢不同的方法，依赖 ERP 系统而不是定制软件。这同样是一种自然的人类行为，新人通常更喜欢采取与前任不同的方法，即使当前的设置正在运行。因此，Grenache 计划在彻底改造整个供应链之前就结束了。频繁交付再次成为一项宝贵的技术。尽管 Grenache 的整个宏伟计划尚未实现，但由于所有组成项目都取得了成功，并且带来了极好的投资回报率，因此该业务从迄今为止的工作中受益匪浅。不仅钱没有浪费，而且投资也得到了很好的回报。

将业务和软件开发视为合作伙伴

也许在企业转型项目中最难做的事情之一是确保项目的技术方面和业务方面之间存在真正的伙伴关系。当然，我们注意到这一点，因为我们是一家与客户独立的公司，但你经常在内部项目中也发现这一点。业务人员和技术人员是不同的个性，有不同的目标和个性风格。

即使在内部技术团队中，也强烈希望将安排改为固定价格合同。这是我们需要的东西，继续构建它，告诉我们你什么时候完成。但正如我已经提到的，这些项目并不像那样——其中涉及太多意外。我完全同意固定价格合同会更好，如果它能奏效的话。但是固定价格合同取决于非常明确的一组需求。有一些软件项目具有这些需求，但你不会在企业转型项目中找到它们。因此，需要采用不同的计划方法——以及不同的业务/技术关系方法。

我所说的伙伴关系需要我之前提到的那种联合计划。一种预计会出现新需求，业务和技术方面都会出现问题的计划。一旦双方开始争论他们所同意的内容，项目就会陷入严重困境。在这种关系中，你必须依靠信任，如果这种信任破裂，那么项目也会随之破裂。现在，这种情况可能会发生，我确实见过一些技术供应商没有提供商品的情况。在这种情况下，项目需要终止，或者至少要搁置，直到找到新的供应商。

那么，如何找到一个值得信赖的供应商呢？（我会尽量克制住直接说“联系 Thoughtworks”的冲动。）显而易见的建议是尝试在内部完成项目。对于一家技术提供商公司来说，这是一种奇怪的建议，但冒着让我们的销售副总裁发怒的风险，我还是会给出这个建议。有了内部团队，你就可以消除商业拉锯战中的一大部分。事实上，我曾经认为，这类项目应该在内部完成，而不是与我们这样的技术公司合作。

是什么改变了我的想法？（除了每月的工资单。）问题是，许多公司根本没有资源在内部完成这项工作。技术公司可以为软件专业人员提供比大多数企业更广泛的有趣项目，这些项目使用的是领先的技术。他们还提供了一种更适合像我这样的极客的自由奔放的环境。因此，他们获得了更好的极客。在企业转型项目中，你通常需要你能找到的最好的极客，所以这是一件需要牢记的事情。这并不意味着你必须将项目完全交给技术公司。我们做了很多工作，这些工作使用的是 ThoughtWorkers 和客户员工组成的团队——Grenache 和 Tempranillo 都成功地采用了这种模式。

重要的是要意识到，你需要的不仅仅是一群聪明的极客。那些能够很好地合作的人比一群更聪明但不能合作的人要有效得多。所以不要寻找一群聪明的人，而是寻找一个拥有共同文化并且之前一起工作过的团队。找到同样属于这种文化并且习惯于与这种团队合作的经理和分析师也是一件好事。

那么，如果你需要在外部寻找，如何为这样的项目选择技术提供商呢？一个因素是他们人员的素质。确保他们确实有能力完成这项工作的人员。查看简历通常是不够的。通常，一个好方法是找到一个项目，让他们可以派一些人去工作几个月。在这段时间里，你可以评估他们的技能，并了解他们的文化。看看他们之前的项目。业务领域在这里不太重要，尽管如果他们之前做过这项业务，当然会有所帮助。关键是要看看他们是否成功地以这种伙伴关系的方式与客户合作。查看参考资料是显而易见且明智的步骤。看看他们对与来自其他技术提供商的人合作的反应。我发现，那些试图摆脱外部人员的公司通常这样做是因为他们缺乏应得的信心。

当然，一旦你选择了技术提供商，你必须监控事情的进展。罗纳德·里根的名言“信任但核实”浮现在脑海。你需要有形的进展迹象。一个明确的项目计划，其中包含你可以验证的里程碑，是这里的关键，当你重复我关于频繁交付的口头禅时，你不应该感到惊讶。没有什么比运行的软件更能衡量进度了。

还要预料到障碍，并期望技术提供商坦诚地对待它们。Tempranillo 提供了一个很好的例子，说明了为什么这一点很重要。正如我之前提到的，当我们距离交付还有四个月的时候，很明显 Tempranillo 的维修部分比任何人都意识到的要复杂得多。项目不得不推迟几个月。坦诚地对待这种情况很重要，一个评估情况并同意评估结果的客户项目经理也很重要。虽然这意味着项目比预期晚交付了完整的功能，但它仍然取得了成功，并且通过使用迭代交付，我们仍然能够交付部分但仍然有用的软件。

请注意，这个例子表明了拥有一个深度参与项目并因此能够理解出现的问题的业务项目经理的重要性。虽然这并不完全必要，我们经常没有业务项目经理，但它确实有所帮助。

当然，当事情出错时，有时是我们的错，毕竟我们并不完美。但关键是努力寻找解决方案。在圣埃美隆项目中，我们低估了工作复杂性，最初派出的团队经验不足。当我们发现这一点时，项目已经陷入困境。虽然我们派出了一支经验丰富的团队来采取紧急措施，但我们的客户也必须通过重新规划工作来提供帮助。从一开始，我们就非常坦诚地谈论了风险，这种坦诚帮助我们建立了必要的信任。最终，圣埃美隆项目取得了成功，但我们双方都做出了牺牲才得以实现。

选择面向未来的技术

为这类项目选择技术存在一个特殊问题。你不能仅仅根据现在最好的技术来做决定，而要评估几年后项目全面展开时最好的技术是什么。随着技术的不断变化，这是一个棘手的选择。

格纳什和霞多丽项目在这里形成了有趣的对比。格纳什项目始于 1990 年代中期，选择了 Forte 平台。在很多方面，Forte 都是一个绝佳的选择，因为它是一个成熟的多层信息系统平台。它拥有许多现在更流行的平台所没有的功能。然而，事实证明，Forte 被 Java 的滚滚浪潮所冲击，现在已经成为一种没有未来的技术。在 1995 年，这是无法预测的（Java 只是在那一年开始出现），所以这只是事后诸葛亮，一个糟糕的决定。

霞多丽项目则是一个正确选择的例子。在 1997 年，企业级 Java 技术是一个冒险的选择。工具和技术非常不成熟，远不如 Forte 或 Powerbuilder 和 VB 等成熟的客户端服务器工具。然而，事情最终进展顺利。工具和企业级 Java 知识的不成熟确实让事情进展得比预期慢，但现在企业级 Java 已经证明是一个稳定的平台，拥有一个拥有众多公司支持的未来。

平台选择不仅是长期工具的选择，还会影响你能找到的人才。软件开发人员往往很聪明，尤其是优秀的人才。因此，他们知道使用过时的技术会限制职业发展。所以他们会远离那些似乎没有未来的技术。在 Java 世界真正开始在技术上赶超之前，越来越难找到愿意在格纳什项目上工作的人。

面对这种情况，选择集成策略而不是完整的技术平台变得很重要。在格纳什项目中，这一点从一开始就很明显，因为构成项目的各个子项目是独立完成的。对于格纳什项目来说，这个平台是一个关系型数据库。每个项目都期望使用一个通用的关系型数据库作为共享数据的基础。因此，不同的项目可以以相当程度的独立性运行。这种方法也为格纳什项目提供了一种摆脱 Forte 问题的途径，未来的开发可以在 Java 中进行，尽管仍然需要 Forte 来修改现有系统。

在我们的企业级 Java 项目中，我们广泛使用 XML 进行处理单元之间的通信，并且越来越多地使用 Java 平台。除了 Java 的良好前景外，我们还认为 XML 也有可能长期存在。XML 受到很多炒作，但它在企业开发中占有重要地位。

虽然这与主题略有偏离，但现在是时候谈谈面向对象平台最常被吹嘘的优势之一：重用。多年来，我遇到了很多谈论构建可重用框架基础的人，他们打算在这些基础上构建下一代应用程序。我几乎没有遇到过成功的案例。这甚至没有考虑到技术平台消失时出现的问题。问题在于，从头开始构建框架非常困难。格纳什项目就是一个典型的例子：一个复杂的安全性框架，花费了很长时间构建，最终变得比需要复杂得多。

现在，我和许多其他框架开发者都认为，框架需要作为使用它们的应用程序的一部分来演化。构建几个应用程序，然后从共性中提取一个框架。由此产生的框架是为已知需求而设计的，而不是基于猜测。我需要提醒你，这并不容易，实际上并不比构建初始基础容易——唯一的区别是它更有可能成功。

人是关键成功因素

真正让这样的项目取得成功的，是参与其中的人以及他们如何协同工作。最终，这是最重要的因素。技术选择、方法论、业务波动，所有这些都排在第二位。一个优秀的团队，成员之间能够良好地协作，会找到克服不可克服问题的方法，而一个糟糕的团队甚至不会尝试越过六英尺高的墙。因此，如果你负责这样的项目，最重要的是找到优秀的人才，留住优秀的人才，并确保他们能够良好地协作。

找到并留住优秀的人才，主要取决于赋予他们正确执行工作职责的责任。我听到过很多关于赋能和管理人员的新方法的讨论，但实际上，这些方法很少能超越提供免费咖啡。

人们觉得困难的是，真正退一步，让团队做出他们所了解的决策，并确保做出决策的人是拥有相关知识的人。需要信任技术人员做出技术决策，需要信任业务专家做出业务决策。管理层的职责往往是确保合适的人做出正确的决策。

管理层的另一个关键职责是确保信息流动丰富且定期。寻找组织和物理上的沟通障碍，并消除它们。很多事情都取决于简单的事情。确保一起工作的人员坐在一起。确保有足够的会议室供团队协作。投资于团队建设活动。一个团结的团队值得付出很多努力去打造。

这里尤其重要的是业务专家和开发团队之间的定期联系。格纳什项目遵循的做法是，在项目持续期间，为团队分配一名全职的业务专家。霞多丽项目有一大批 Thoughtworks 租赁专家，他们与 Chardonnay-Corp 的业务专家合作，确定了解 Chardonnay-Corp 业务流程的来龙去脉的关键主管。需要的是定期面对面的交流，通常你会发现业务人员和开发人员每天都会互动。这经常被项目忽视，导致沟通和信任的破裂，最终损害项目。如果企业希望项目取得成功，就必须投入人员。

衡量这种安排是否有效的关键测试是应对坏消息的反应。不可避免地，现场的开发人员会遇到问题，通常是会影响进度的问题。如果管理层的反应是隐瞒情况或告诉每个人“加倍努力”，那么你就没有找到能够有效工作的管理层。对问题的诚实反应和对问题的坦诚态度，对于与开发人员有效合作以及成为企业的良好合作伙伴都至关重要。

持续学习

在一个复杂且开拓性的领域工作，不可避免地会带来发现。正如我在上面讨论的那样，对于意外情况，重要的是从中吸取教训。事实上，一个成功的长期项目的关键主题是持续学习的概念。这种学习是关于业务需求、我们使用的技术以及我们进行工作流程的学习。

软件开发中常见的发现之一是，人们在看到系统的早期版本后会改变对需求的想法。这是一个自然的结果，因为系统的存在为业务人员澄清了问题。因此，他们了解了自己的需求以及技术能够提供什么。频繁交付的优势之一是它加速了这个学习过程。业务人员应该利用这些交付以及他们在开发过程中的沉浸，作为学习更多关于软件开发过程中哪些有价值内容的工具。霞多丽项目和圣埃美隆项目都从短开发周期中获益匪浅，这帮助业务人员指导项目交付最有价值的功能。

持续学习也适用于技术。由于企业转型项目通常使用较新的技术，因此学习对于充分利用技术至关重要。当技术是新的或快速发展时（现在还有什么不是呢？），许多最佳的使用方法在早期并不明确。此外，必然会有一些隐藏的陷阱，这些陷阱在早期也不会出现。一个优秀的团队会观察它使用的技术，并在项目继续使用该技术的过程中调整其方法，以最佳方式使用该技术。圣埃美隆项目和霞多丽项目是使用企业级 Java 的最早的几个严肃项目。这两个团队都学到了很多关于如何使用企业级 Java 的知识，并对系统进行了改进，以利用这些知识，以及从其他 Thoughtworks 项目和大量关于使用 Java 的文章中吸取的知识。

最容易被忽视的学习形式之一是了解开发流程的重要性。定期检查团队的工作方式，并让团队思考如何改进。圣埃美隆项目进行了一些关键的回顾，开发团队和客户团队都回顾了流程，并决定如何改进。这些流程检查对于将项目从陷入困境转变为取得巨大成功至关重要。另一方面，格纳什项目成为了自身成功的受害者，后来的项目没有足够地发展，以利用自身的经验，这导致了最近一两年效率下降。