首次揭示！传统管理是如何在数字化IT时代延续混乱的？

现状

尽管敏捷工作方式、持续交付和产品导向已经得到广泛应用，但仍有许多公司仍然采用项目管理的方式进行工作。实际上，项目管理永远不会完全消失。

在很多大型企业中，跨团队的协调工作始终是必要的。项目的进展与RAG（红、黄、绿）状态保持一致，就像繁忙路口的交通随着红绿灯的节奏运行一样。绿灯表示一切顺利。黄灯表示需要关注，也许可以要求团队提供额外的每周状态报告（就像额外的官僚手续能够帮助团队一样）。红灯表示情况不妙，内部审计要求采取行动，管理层派人介入协调危机。

困境

大多数企业组织只在出现问题时才关注IT交付，而数字化领导力则强调持续改进。这种模式反复出现。管理层太忙，无法关注绿灯时的状态问题。团队找到了改进方向，但因为没有专注于交付更多功能而备受指责。团队也发现了系统性挑战的微弱信号，但被忽视，直到错过了里程碑。一旦状态变为红色，才全员动员起来解决危机。

我多次站出来，因为我知道系统性问题不会得到关注。最近，我与一位正在进行敏捷转型的高级项目经理讨论了这个问题。他告诉我，最近他们经历了一些意外事件，危机模式下的协作非常有效。我感叹道：“良好的敏捷领导力应该让这种协作在日常工作中解决混乱的问题，而不需要费太多力气”。

混乱中的领导与敏捷组织的挑战

尽管全世界都喜欢英雄，但敏捷组织并不需要他们！

通常，领导者在混乱中扮演前线指挥官的角色，强调命令与控制的风格。带领团队从混乱中恢复是令人满足的，但这种模式不可持续。组织喜欢英雄，但那些能够保持项目状态为绿色的人往往被认为缺乏战斗经验。这种情况会持续下去，并深入到企业文化中。

业务部门在数字化转型中必须认真对待这种情况，否则会加剧混乱。在混乱的循环中前进是不可持续的，这样的企业面临风险，会经历一个又一个的危机，耗尽人才。

我们如何扭转这种文化？

我们可以很容易批评一些人的行为和对问题的贡献，但责备并没有任何建设性。

那么，我们来思考：应该如何解决？如果真运作一个绿色RAG状态的更高效的IT团队会带来什么回报呢？

开始向改变并拥有以上这种状态，实际上是成功的数字化变革的起点：

1.系统性管理

2.持续改进的文化

3.追求卓越

团队的系统性管理

敏捷思维强调良好协作的必要性，这是非常正确的。数字化组织也努力复制互联网独角兽公司的组织模式，采用更扁平化的结构和自主的团队，以加快决策速度。然而，许多人仍然将团队视为个人的集合，并专注于任务。我们难道看不出其中的矛盾吗？

如果我们从个人层面进行管理，我们就需要微观管理者来组织和协调任务。领导者为自己的价值辩护，坚持站在每个决策的十字路口，并成为前进的瓶颈。团队成员在一朝被蛇咬，十年怕井绳的基础上，放弃了自主性和协作性，倾向于盲从领导者的指示。如果没有系统性管理的方法，团队就无法达到期望的自主和协作水平。

系统性管理始于管理者与团队在工作现场的连接（例如，在团队所在的空间，而不是在管理者的玻璃办公室）。这个概念从丰田生产系统中的“Gemba”开始已经存在了几十年。“Gemba”的意思是去到工作发生的地方。

在制造业中，由于生产流水线的物质性，这一点非常明显，但在数字化团队中就不那么明显了，因为数字化团队中的一切都是虚拟的。在IT团队中使用“Gemba”，强调了在可视化管理的支持下进行信息辐射的需求。过程流程和质量进展可以张贴在墙上（或在线可视化板上），团队可以基于此展开改进的讨论。

管理者还需要具备与整个团队合作的技能和技巧。倾听系统的声音（VoS）可以产生透明性，并能够及早发现系统性挑战。此外，对问题的预期可以促进更好的工作流程。通过采用这些实践，团队变得更加自治，领导者与团队融为一体，从而大大减少了对中间过程微观管理的需求。

持续改进

为了避免自满并推动持续的绩效，丰田生产系统采用了Kaizen，这是一个持续改进的流程。每个人的工作不仅仅是完成自己的任务，还要思考如何改进工作方式，提高工作成果。这种持续努力是一种非常好的刺激大脑的方法，尤其是在生产流水线上的工作可能非常枯燥。

新技术Kaizen的创始人中尾千寻（Chihiro Nakao）坚持推动不需要投资的简单改进。他的目标之一就是激励人们，以防止自满。好的Kaizen还可以在领导层和团队之间创造出一种不同的动态。团队不断发展自主、自立和协作的能力，而管理层变得更注重引导和教练，以及激发创造性思维。我们今天在IT行业中追求的目标，难道不正是40年前丰田公司发明的吗？

许多人很快指出，制造业的生产和IT行业不同。这是事实。然而，在IT的虚拟环境中进行持续改进实际上更容易。与生产流水线上的工人相比，IT人员更自然地扮演知识工作者的角色。真的没有什么可以找的借口。

问题在于，公司的IT部门一直忙于跟踪处于红色RAG状态的问题，而我们忘记了对绿色RAG状态进行持续改进的锻炼。现在是时候重新启动了。让我们重新关注持续改进，为IT行业带来更大的进步。

追求卓越

有组织会反对追求卓越，但很少有组织真正在IT领域做到这一点。DevOps运动在推动这个主题上做出了贡献，但这种努力仍然局限在IT范围内。质量是每个人的责任，从业务需求的启动开始。

在实体商品上，缺乏质量很容易被发现，但在虚拟软件上却很难被发现。你可以从前端的可用性或测试一些边缘情况中得到一些关于质量的想法，但这只是冰山一角。隐藏在表面之下的代码质量是什么？它什么时候会回来咬你一口？RAG状态并不能解决这个问题，事实上，它通常会使问题恶化。

我曾经参与过一个项目，在黄色和红色之间徘徊。业务部门和管理部门不断向团队施压，要求按时完成项目。他们唯一能牺牲的就是质量。有人在意吗？团队在意，但没有人听得进去。

因此，对于任何不符合团队期望的工作标准的东西，我们让团队开始捕获产生浪费的实践，并记录技术债。团队感觉好多了，信息得到了传播，它变得不容易被忽视。然而，我们不应该走到这一步。

IT领导者和产品经理应该高度关注质量。通过项目的方式组织工作并不会促进这种行为。项目本质上是短暂的，交付项目的人很少会成为维护项目的人。质量、可持续性和可维护性在日常决策中很少被高度优先考虑。

关注项目所带来的只关注短期结果的态度，并不支持为公司的数字化打下坚实的IT基础。有效的Kaizen也不太可能发生，除非团队和领导层有长期的承诺。

除了更好地与客户保持一致外，基于产品/服务的一致性还可以维持长期存在的团队和领导力。这促使对人员进行投资，让他们理解工程，并在决策中考虑质量的优先级。然而，这种一致性与传统组织的建立方式在很大程度上是相违背的（这是由规模经济而非流动经济继承而来），这构成了在数字化绩效方面取得进展的重大系统性挑战。

许多公司的IT功能障碍是由基于项目的工作和错误的激励所导致的。这促使了与建立成功的数字化业务基础不相容的行为。为了解决这种情况，需要领导者迈出一小步，领导力才能迈出一大步（借用了这句话…:-)）。

数字化变革始于与团队合作，以理解如何让明天比昨天更好：更智能的流程、更大的自主权、更好的产品/服务、更强的技术能力。这是一个根本性的转变，转变为促进产品和工程性能的IT领导力，其中包括系统性管理、产品/服务和流程的持续改进、卓越的工程能力以及解决阻碍我们的系统性障碍。