高效的筒仓

有时候，我喜欢想象自己从高处俯视一家典型的现代公司的情形，我可以"看到"公司按照不同的职能分成了一个个封闭的圆筒仓库，筒仓上写着市场、运营、制造、IT、工程、设计，等等。各部门按部就班，有序运作。

想象一下，如果伸手下去，拿起一个筒仓，把顶盖掀开，朝里面看，你会看到什么？这是一家现代公司，你将看到，每个筒仓都是以追求最大效率为目标设计的。要想实现高效率，就必须找到一个高度迭代的、以客户为中心的方法来解决问题。对于制造部门来说，可能要采用传统的精益生产法；工程和IT部门可能会采用敏捷开发方法；市场部门会使用客户开发法；运营部门采用DevOps理念；设计部门则使用最新的设计思维、互动设计以及用户研究方法。

重新站回高处，我们可能会觉得："这家公司使用了各种方法。这些方法不仅严谨，而且是由假设驱动的，不仅以客户为中心，而且是迭代式的。所以，它肯定是一家非常敏捷的公司，可以对市场变化作出快速反应，并不断创新。"但是，凡是在现代公司中工作过的人都知道事实根本不是如此。

为什么每个部门都非常敏捷，但是整个公司却死板、缓慢呢？从高处看，我们必然会忽视一些重要的细节。虽然各个部门都注重敏捷，但是部门之间的联系却一成不变，还在走工业时代的老路子。

再举一个例子，也许你对它并不陌生。有一家公司觉得，要生存下去，就必须创新。所以，管理者指派了一个设计团队（内部或者外来的）来分析公司的行业前景，并推荐一些创新产品以确保公司能持续经营下去。公司上下都觉得特别兴奋。设计团队和客户面谈，观察并分析他们。各种实验、问卷调查、小组讨论、原型产品以及粗略测试一个接一个。各种理念迅速产生，然后验证、否决，继而改善。

结果是什么呢？设计师骄傲地用一大堆说明文档来展示他们的研究结果和推荐，业务人员则欢呼雀跃。然后迭代结束，实验和探索也随之终止。接着，管理者叫工程团队来落实这些设计。虽然工程流程是敏捷的，但说明文档是完全固定的。万一工程团队发现设计无法实施或者有问题，怎么办？要是这个设计在实验室里很有用，但是没有商业价值，怎么办？要是在初期的"研究调查"之后，市场形势发生了变化，又该怎么办？

我曾经跟一家公司的领导聊过。这家公司曾不惜高价聘请一家设计公司，对公司所在行业进行一项跨度长达数年的研究。最后，这些设计师在公司总部布置了一间名为"未来景象"的展示厅。在这个展示厅里，你可以看到他们对未来十年行业发展的一些预测，还包括各种可以操作的、颇具科幻风的概念产品。你可能已经猜到了这家公司在接下来的十年做了些什么——什么也没做。十年里，这家公司的高管、经理和员工来来去去换了成百上千人。实际上，十年过后，这个展厅已经不再那么科幻了。尽管当年迷雾重重，但是研究人员的预测居然大部分都成真了。不过，这家公司却连一个预测都没能实现。所以，我问管理者他们接下来准备怎么做。他们告诉我，想把之前那些设计师找回来，再做接下来十年的预测！这家公司认为，没能实现设计不是设计师的错，而是工程人员和管理者的问题。

当我把这些告诉设计师之外的人时，他们感到十分震惊，并且对我说都是那个自以为是的设计公司的责任。我告诉高层管理者（包括大公司和初创公司）这个故事时，他们会很无奈，因为不同的部门都说自己很高效，并且走在时代最前沿，都是其他部门拖了后腿。当公司无法找到新的增长点时，这样的指责就会满天飞。

不过，责任其实并不在设计师、工程师，甚至也不在高层管理者身上。真正的问题在于公司的体系。世界在不断变化，而我们仍然在使用这种一根筋的组织体系。这是一个必须全面合作才能成功的世界，而公司组织却依然严格区分职能和部门。这是一个必须不断做实验才能持续创新的世界，而我们却仍然在分析上浪费时间，为了说明文档而争执不休，拼命工作也只是为了完成交付任务。

我希望大家记住Jeff Gothelf提倡的"不要再谈交付"。让我们回归本源，让全公司都集中精力关注真正的问题——让客户满意。

是打破筒仓、团结一心、一起工作的时候了！

 

——节选自《精益设计》 - Jeff Gothelf