客户需求|开发人员解决不了管理烂的问题管理|底特律|福特|管理层|解决

本文最初发布于 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 锤子下的一个钉子——每个人都有一个甘特图、一个项目经理和一个项目代码！