开发人员解决不了管理烂的问题

本文最初发布于 iiSM.org，由 InfoQ 中文站翻译并分享。

我经常看到一些文章指责开发人员不理解他们为什么要做改变，不理解背后的“为什么”就盲目地实现改变是错误的。“向上看，不要把太多精力放在写代码上！”在我看来，这些文章所面向的人群是错误的。在大多数公司中，实际上应该由管理层为故意把工程师隔离在发现客户需求之外的行为负责。实际上，开发人员喜欢发现需求，并用史诗级的软件解决方案满足需求，他们非常不愿意花时间创建没有客户想要的东西——我的意思是，我们喜欢创建软件，只要我们能这样做并因此获得报酬，如果没有更好的、更令人满意的机会，我们就会消磨时光。然而，如果有一个更令人满意的、可以获得报偿的机会，比如为汽车创造自动驾驶仪，或者一个闭环胰岛素泵，我们会立刻跳槽！

传统管理有详细的估算、甘特图、WBS、PMP 和所有其他的制造/订单执行/物流优化技术！

管理层是阻止开发人员创建满足迫切需求的产品的真正问题。事实上，这个问题一直延伸到CEO身上。因为发现真正的客户需求是在项目的生命周期中，而发现的这些需求必然会改变所涉及的工作范围，这意味着，为了避免项目范围的变化，一个 MBA 实践驱动的组织将避免发现真正的客户需求。相反，他们让工程团队在确定的日期之前把事情做完，而做完的是一个没有客户想要的产品，因为发现真正的客户需求的行为被抑制了。此外，由于团队一直专注于创建新特性，而不是描述他们自己的工作并消除混乱，产品可能会变得混乱不堪。项目完工唯一的好处是通常会有一个发布派对，有披萨和蛋糕——再好一点，他们获得了一点点职业发展，因为团队按约定日期完成了交付——我的意思是，交付的东西没有得到采用，但他们不在意，直到有人通知他们客户没有采用，通常，CFO 会应用4X Rule规则，削减集团预算。

我们有史以来一直这样

软件行业所处的这种管理状况在历史上也有类似的情况。大约在 1940 年，W. Edwards Deming 为底特律的汽车制造商带来了一种新的汽车制造方法。这个时候，底特律赚着大钱，他们占领了世界上最赚钱的市场，坦率地说，他们不觉得有必要做任何改变。遭到拒绝后，Deming 开始着手其他任务，参与战后日本的重建工作。他的方法非常成功，日本汽车开始侵蚀底特律的市场份额。当顾客等待并支付额外费用购买一辆配备丰田制造变速器的福特汽车时，福特得到了一个实际的教训。迷惑不解的福特工程师把变速器拆开，比较了各个部件；他们发现，日本的零部件具有两倍的均匀一致性，结果是更平滑的拟合和卓越的车辆可靠性。

只要简单地询问下他们的工人“如何才能做得更好”，倾听他们的意见，然后对制造过程做些新的、实用的改进，任务管理者就能显著地提高他们的质量。之前的方法是管理者通过抽象思考想出改进的方法——通常是他们老板的想法——然后把这些想法灌输给员工。如今，这种自顶向下的反模式反复出现在软件团队管理中。

1981 年，在日本蚕食福特的市场份额多年以后，福特管理层终于投降，让 Deming 加盟，整顿他们的制造业务。福特的管理层认为，他们有质量问题，或者更准确地说，他们的工人有质量问题，因为管理人员不干工人的活。当 Deming 告诉他们，在研发更好的汽车的过程中，管理措施要为 85%的问题负责时，他们感到震惊！福特花了 6 年的时间完成转型，最终推出了 Taurus-Sable 系列，这款汽车比他们之前生产的汽车都要好。

在致 Autoweek 的信中，时任福特董事长 Donald Petersen 说，“我们正努力在福特建立质量文化，这里发生的许多变化都直接源于 Deming 的教诲。”

福特管理层犯的一个关键错误是，他们没有从工人那里了解如何优化生产流程。只要简单地询问下他们的工人“如何才能做得更好”，倾听他们的意见，然后对制造过程做些新的、实用的改进，任务管理者就能显著地提高他们的质量。之前的方法是管理者通过抽象思考想出改进的方法——通常是他们老板的想法——然后把这些想法灌输给员工。

Deming 告诉福特，在研发更好的汽车的过程中，85%的问题都是由管理层的行为造成的！在如今的软件管理中，我们发现自己也面临着同样的情况。

我们出了管理问题！

现在，让我们回到那些“开发者需要做得更好”的文章。试想，如果这些文章是为汽车工人写的。那么标题会是：

• 美国的汽车工人真的需要专注于改进他们的制造过程，这就是丰田所做的！

• 汽车工人应该不断地与客户沟通，这样他们才能尽最大可能制造出最好的汽车

• 汽车工人把太多的时间花在了细节上，却没有花足够的时间去理解“为什么”

• 创造超凡的汽车而不仅仅是生产汽车

作者的意图是好的，从表面上看，他们的建议也很好，但是这些汽车工人如何改变他们的工作流程呢？他们是否要对公司管理层进行再培训？历史告诉我们，他们没有做到，我也不指望他们能做到。在大多数公司，软件工程师发现自己处于同样的情况。在我们大多数人工作的公司里，MBA 实践占据主导地位。在经过 MBA 训练的管理者那里，每个开发人员都是他们 PMP/WBS 锤子下的一个钉子——每个人都有一个甘特图、一个项目经理和一个项目代码！

甚至当一个采用传统方式管理的公司决定变得“敏捷”时，这一举措的常见结果是传统管理方式友好的Date Scrum反模式。Date Scrum 的出现让许多开发人员对敏捷实践产生了负面的看法，因为在变得“敏捷”之前，他们不得不忍受每隔几周就会有一次的状态会议。现在有了 Date Scrum，他们必须忍受每天一次的站立状态会议！

Date Scrum 是什么？Date Scrum是一种研发模式，它要求开发人员预先评估整个项目的软件项目需求。在项目获得批准，并基于最终的评估设置了预算之后，团队就会保持日常的 Scrum 状态，并在发布之前管理在解决方案“迭代”过程中的风险。在某些人看来，这种方法是在冲刺中进行瀑布式开发。

因此，我们需要更多的文章来鼓励高层和管理人员不要再导致软件项目失败了，呼吁放弃传统管理的估算、甘特图、WBS、PMP 和所有其他的制造/订单执行/物流优化技术。那东西很好，它是帮助我们赢得 WW2 的关键，如果我要开工厂，我会用它！但是在软件项目中，没有它的位置。

为什么这么多的软件项目失败了？软件开发更接近于创建一个新工厂，而不是经营一个现有的工厂。传统管理侧重于使用固定的、已知的最佳实践来安排持续时间已知的任务来经营工厂和执行订单。软件开发是由许多持续时间未知的任务组成，这种根本上的不可预测性使得传统管理的预测计划技术特别不适合软件项目。

传统管理如何造成了破坏

福特花了 40 年时间才接受了 Deming 的研究成果。在今天这个快节奏的世界里，一家公司如果要花 40 年的时间才能让有价值的软件工程师不再讨厌它，那它将永远不会成功，而且我预测，大多数不发展的公司将会在 10 年内灭亡。之所以做出这种可怕的预测，是因为这些传统企业一直徘徊在这样一种生产管理套路上，根据工作划分部门，然后使用一种刚性的、放之四海而皆准的最佳实践优化各部门——这些最佳实践往往是源于工厂运营工具包的预测规划技术！正是这些实践阻止了他们创造新的、有价值的软件产品，因为他们让开发团队专注于创造没有客户想要的解决方案，而不是发现和满足巨大的需求。这些实践导致组织主动忽略了软件项目偏离轨道的所有危险信号。危险信号被忽略了，因为组织中固有的 MBA 偏见会导致他们应用反模式，比如：

• 那些额外花费合理的时间去检查他们的工作并清除混乱的开发者被认为“有点慢”；

• 当开发者注意到产品/市场适配的问题时，他们会继续实现更多的功能，并承诺他们所关心的问题将会由Idea Silo处理；

• 快速实现特性以便于另一个筒仓能够进行“质量”检查，开发人员会因为能够快速完工而受到赞赏；

• 当开发者漫步到工作场所，并注意到客户在艰难地使用这个产品时，他们会小心翼翼地引导到 Idea Silo 的议程上；

• 当开发经理试图理解产品/市场适配性、打包和定价的总体情况时，他们会被鼓励回去让开发团队专注于实现项目范围之内但没有客户想要的特性；

• 尝试使用统计混沌控制技术来实现代表性负载混沌检测的开发人员会被引导至 Quality™筒仓，就好像不编写代码的人会做得更好一样！

Idea Silo 是什么？Idea Silo是公司内部的一个组织，负责为另一个筒仓实现新产品和新特性。在许多公司中，Idea Silo 是指产品管理组织。

开发人员没问题，管理层需要做出改变

传统管理需要发展；他们应该先听开发人员说说管理层应该做什么：

• 明确目标、愿景和使命感

• 帮助我成长，提供晋升机会

• 允许自治，授予权限

他们还应该听听管理层不应该做什么：

• 不要进行微观管理——开发人员设计和编写代码，而不是管理人员！

• 有技术背景——没有什么比开发人员回答他们的问题时项目经理目光呆滞更糟糕的了！

• 不要仅仅屈服于政治压力——公司政治是管理领域固有的，请努力代表团队！

在听取了开发人员的意见后，传统管理需要抛弃以下不适合于软件的实践：

• 基于详细评估的预测计划——预测计划用于组织内持续时间已知的制造和订单执行任务，而不是软件项目；

• 为开发人员分配任务时详细评估；

• 工作分解结构——同样，这非常适合持续时间已知的任务，而不是软件项目!

• 根据有缺陷的详细估计计算出的到期日
  

• 在未与精明的客户进行反复沟通的情况下应用敏捷Scrum
  

• 盲目接受Idea Silos的范围
  

在 iiSM.ORG，我们相信：

• 通过增强、自动化和娱乐性，软件改变了我们生活、工作和娱乐的方式；

• 世界顶级公司中的科技公司越来越多，而且这个数值还在呈指数级增长；

• 我们正处于一股变革洪流的开端，正如我们所知，这场变革正在大规模地颠覆行业，重塑社会。

如果上述情况属实（相信我，确实如此），那么，如果传统管理人员希望自己的公司在数字化转型的新世界中生存下去，他们就必须改变自己的方式。我们需要花点时间弄明白，将传统管理技术应用于软件开发团队非常糟糕，即使从短期看，也是完全不可持续的。

原文链接：

Developers can't fix bad management