为什么企业敏捷团队会失败

原文地址：
https://medium.com/startup-pa...
翻译君：敏杰小王子

上周，我站在一家市值 200 亿美元的公司的会议室里，推动了一个关于敏捷的研讨会。出席会议的小组由这家大公司的一个产品线中的每个职能部门的董事和部门经理组成。从 UX、工程和产品管理的岗位中挑选出来的十几位领导者组成了一支团队，他们代表着约 150 人的产品线。作为一个团队，他们踏上了“敏捷”的旅程。

这不是我们平时认为的企业转型。他们的高层既没有明确支持也没有明确阻挠这次转型，这家公司对敏捷的官方态度最准确的描述是“良性冷漠”。因此，这个团队基本上只能靠自己来尝试，无论最终结果是成功还是失败。

我在那里的唯一原因，是因为到目前为止敏捷旅程还不顺利，我的任务是帮助他们找出症结并解决它。好巧不巧，他们出现的问题与我在过去 5 年中遇到其他团队的原因相同。为简单起见，以下都是直言不讳的事实陈述，但也并非都适用于您的情况。

不明确的愿景

如果你在办公室走廊拦住任何团队成员，问他：“同学，我们产品的长期愿景是什么？”他们能否用一两句话来回答？八成不行。他们可能对目标客户有所了解，也可以明确地知道解决方案的功能。但是，他们真的可以说出客户想要解决的痛点吗？我猜不会。

一些高级管理人员在权利更迭期间，以临别顿悟为基础传达了自己的“突发奇想”。这个“想法”被投入了预算计划角逐会议中，这位特别的高管最终赢得了影响力战，并得到了 12 个月的项目资助。紧接着这一消息的所有内容通过一个既成事实的 PPT 传递给你，功能和时间表提前计划好了，你被正式告知“请实现它”。现在你正试图完成那个不可能完成的任务，并希望敏捷能帮到你。

解决方案：花一些时间阐明产品的清晰愿景，使用业务模型或精简图片表达您的设想，邀请团队中的每个人参与，将这些设想反馈给高层管理人员（如果他们拒绝参加），并确保你的相关信息出现在同一页面上。

PS：如果他们找你麻烦，给我打个电话。

被混淆的业务指标

该团队不会考虑日常的成本和收入。事实上，团队可能不知道公司要让他们赚多少钱，他们也不知道他们需要拓展多少客户，每个时间段需要支付多少钱，以便他们在这个疯狂的想法上实现收支平衡。他们基本上不太关心自己的工资来自何处。

但如果你问大多数初创公司，他们对自己整体燃烧率和销售业绩会有更好的了解，因为收入和盈利能力对于他们来说始终是最重要的。

其实这个成本在任何情况下都不难计算。直线经理（Line Manager）通常可以在几分钟内得出工程团队燃烧率的准确数字。然后当我们将这个数字（实际成本）与我们当前的销售数据（我们作为一个团队实际产生的收入）进行比较时，这就会是一个全新的业务竞赛。
译者注：直线经理（Line Manager）是指诸如财务、生产、销售等职能部门经理，每一个直线经理肩负着完成部门目标和对部门进行管理的职责。

解决方案：计算您的产品成功所需的团队收入和成本，并确保每个人都知晓。它很有可能会让人大开眼界。您应该在下一次业务规划会议上与您的团队一起尝试。

持续不断的干涉

由于方向上的某些紧急变化，您最后一次中断正常工作流是什么时候？它可以是最近的客户投诉或请求，也可以是来自首席执行官措辞强烈的电子邮件——邮件涉及团队在上周产品演示中使用的配色方案。

无论如何，如果你总是打破团队的正常工作流，会给团队带来巨大的压力。这种压力转化为吞吐量降低、士气低落、人员流动率增加、航运延误、工艺粗劣、以及对团队绩效的普遍拖累。所以把这个坏习惯丢弃掉吧，您并没有因为在组织中的管理地位而拥有在事务优先级排序方案中的特权。

解决方案：每周为计划外工作分配一些容量，比如总容量的 20％，只安排 80％ 的团队时间，而不计划其余的时间。可以在发生“紧急情况”时使用此容量，而不会影响原来的正常计划。无人认领的话可以用它来偿还技术债务。您可以轮换团队成员来执行此操作。

不够专注的团队

我工作过的每个大公司都有这个问题。项目中的大多数人被分配到多个其他项目当中。当我问团队中都有谁时，我得到的答案一般是某位工程师分配了 50％ 在这个项目上，而某位工程师与我们在一起的时间占 20％，超过一半的项目人员将一半以上的时间花在其他项目上。难怪项目的最终结果往往是事故，因为这种工作方式不管用。

产品开发是一项团队活动，团队成员之间需要极大的关注和大量的沟通和协调。您团队中的每个人在部分时间内被分配到其他项目，这会使交付日期常常延迟数周或数月。

关于这一点我从企业管理者那里得到了更多的案例，举一个具体的例子，你也许会问：“我们真的需要在团队中设置专门的产品体验人员吗？如果他们一半闲着怎么办？我们不是在浪费钱吗？”

让我们思考一下：

假设你有十个工程师和一个交互设计师（本来不应该是这个 1/10 的比例，但你可能会这样做，所以我们姑且先这么选着）。设计师为工程师构建了 100 个线框，现在你有 10 名工程师开始工作，设计师又回到了其他项目。

工程师几乎立即向设计师提出了要求，但设计师此时被其他项目束缚，所以工程师必须等待（延迟）。也许工程师选择打开另一项任务并开始工作。当设计师重新上线时，工程师必须暂时放下第二个任务以重新打开第一个任务（延迟）。

现在，第二位工程师需要帮助，可能还有第三个工程师，他们都在等待（延迟）。设计师再次有空并开始与第一位工程师合作，而其他两位排队等候（延迟），后两者的任务未完成（延迟）。所有三位工程师都失去了他们正在研究的一些事情的背景（延迟）。

在与第一位工程师合作时，设计师发现了设计中的错误，需要更新所有 100 个线框（大延迟）。现在，每个工程师都必须停止并重新检查他们的工作以应对新设计（大延迟），已经完成的一些工作必须废弃并重新开始（更大的延迟）。

所以你是选择固执己见还是有所改变？您可以试试把上面的示例中替换成后端 API 开发人员，事情的结果会变得更糟。

解决方案：请组织小型、跨职能、专注的团队，将一小组作为一个单元一起工作，并不断获得双方关于事务进展的反馈与澄清。

分散各地的团队

大型企业团队往往由一个地理位置分散的大型池的“资源”组成（原谅我用“资源”这个词）。因此，企业产品团队的成员处于不同的时区和地区，这使得沟通协调效率低下且成本昂贵，结果就会发生很多延迟等待和错误传达。远程通信的保真度绝对不如面对面沟通，视频通话确实让沟通变得更容易一些，但它与能够一起走到白板前讨论出来的东西并不相同。

解决方案：将所有团队成员放在同一个房间，或至少在同一建筑物的同一楼层。如果您必须与远程人员一起工作，请根据康威定律分解任务，按地理划分（具有明确定义的接口的模块）而不是按功能划分（设计、工程）。

太过臃肿的团队

通常情况下，在企业中找到大型团队来构建产品不是那么复杂的事情。但由于各种原因，团队规模常常大得惊人，这主要与高管倾向于通过指挥大群人来建立自我的事实有关。

100 名工程师构建一个 SaaS 产品？你确定？较大的团队效率更慢，因为协调成本是巨大的。您需要更多层次的管理，更多会议和更多文档。大型团队对其速度的负面影响随着其增长而渐渐变得更强烈。

解决方案：您应该使用尽可能小的团队在企业中构建产品。如果你可以把它减少到几十个，甚至一打，那就更好。

太重的技术债务

企业往往有很多旧的代码库。然而这并不是企业敏捷团队积累技术债务的真正原因。我敢打赌，您当前项目中的大部分技术债务是从您当前项目开始以来由您的团队创建的，而不是通过来自较旧的遗留系统的继承。

这是因为，尽管敏捷社区重复了 15 年：
（1）结对编程技术实践的重要性
（2）测试驱动开发
（3）对代码的持续集成
但非常少的企业团队真正去做这些事情。出于各种原因（主要是因为那些专注于流程而非卓越技术的大型咨询公司向高管出售的所谓“敏捷”），企业敏捷团队很少接受：核心技术实践使得敏捷出色。结果大型的工程团队开始设计和执行有缺陷的系统，然后在漫长而痛苦的发布周期中相互折磨。

解决方案：考虑采用“极限编程”，使用敏捷的技术实践。此外还要考虑使用敏捷构建的现代技术工具和语言。

太多的并发事务

拥有专门团队的关键是一次只做一部分事情并且把它做得非常好。大多数企业团队可能因为他们的人员太多而倾向于同时处理数十种特性。

将迭代限制为几个关键功能会好很多。在看板语言中，我们称之为“在制品”（WIP）限制。实际上您可以通过强制许多人在相同的项目上一起工作来创建更加协作的环境。由于 WIP 限制，不允许任何人在未完成目前事务前开始新事务。它可以使事务一次做得越来越少，越来越好。减少返工和减少错误，会带来更多团队合作、更高的品质和更高的士气。

方案：立即实施 WIP 限制。如果您有一个 10 人团队，请将 WIP 限制设置为 5 个项目，以便每个人都被迫与其他人结对工作。相信我，效果会让你感到惊讶。

更长的部署软件时间

大多数企业所处的遗留系统的问题是部署时间过长。企业通常由一个运维团队负责将代码引导到生产环境。这些人员经过培训，需要确保代码被批准在公司服务器上运行之前是安全，高效和可用的。

当你迫不及待让凡人工程师将他们自己的代码手动部署到生产中时，像亚马逊这样的公司已经迅速抢占你的市场份额。您可能依然在权衡开放生产环境访问权限的风险以及在市场中灭绝的风险，这是因为您对竞争威胁的反应太慢。

解决方案：DevOps。任何工程师都应该能够随时启动新的开发和测试基础架构。软件推送到生产环境应该通过一个自动化过程，并具备所有必要的测试和标准。

被忽视的企业其他成员

最后，在您的敏捷“实验”中，对您和团队来说非常重要的成员，那些不需要完成任何关键特性但是你不得不合作的团队：采购、法律、营销、人力资源等这些岗位人员。如果您必须及时与组织中这些非敏捷团队进行协调，那么您会很容易心累。需要有一种方式与团队外的团队合作，这种方式不会完全搞砸你的努力。

我们在敏捷社区中注意到，由高层管理者提供自上而下的命令，敏捷转型往往并不会真正起作用。除非被雇佣的执行层人员对转型十分兴奋，否则敏捷转型这事就不会被坚持下去。没有执行支持，也不会自下而上。

解决方案：基本上您有三种策略可以处理转型问题，需要同时完成所有操作：

• 在您的组织内进行持续影响力的活动，以赢得关键的高层支持者。我保证您的企业中还有其他高管和经理也在尝试或考虑在某个范围或规模上尝试敏捷，去寻找他们并结成联盟。毕竟，在大型人类社会中变化是如何发生的，在大公司也不例外。
• 找出你需要从非敏捷特性团队得到的东西，并确保提前与这些团队交谈。告诉他们你正在做什么，事情是如何运作的，最重要的是如何让他们更容易地与你一起工作。
• 无情地削减你的依赖。这部分或多或少在你的控制之下。推动使用工具、基础设施、营销材料、法律语言等，您和您的团队可以自己构建、借阅或购买。要做到这一点需要时间，所以你应该马上开始行动。

敏捷，做得对的话，效果惊人

尝试敏捷并不疯狂，事实上，我认为这是让你的公司进入下一代所需的竞争斗罗场的唯一途径。另一种选择是缓慢地或快速地倒在更小、更灵活的竞争对手石榴裙下。CODING 敏捷模块助你轻松搞定敏捷转型