有時候，我喜歡想象自己從高處俯視一家典型的現代公司的情形，我可以"看到"公司按照不同的職能分成了一個個封閉的圓筒倉庫，筒倉上寫著市場、運營、制造、IT、工程、設計，等等。各部門按部就班，有序運作。

想象一下，如果伸手下去，拿起一個筒倉，把頂蓋掀開，朝里面看，你會看到什么？這是一家現代公司，你將看到，每個筒倉都是以追求最大效率為目標設計的。要想實現高效率，就必須找到一個高度迭代的、以客戶為中心的方法來解決問題。對于制造部門來說，可能要采用傳統的精益生產法；工程和IT部門可能會采用敏捷開發方法；市場部門會使用客戶開發法；運營部門采用DevOps理念；設計部門則使用最新的設計思維、互動設計以及用戶研究方法。

重新站回高處，我們可能會覺得："這家公司使用了各種方法。這些方法不僅嚴謹，而且是由假設驅動的，不僅以客戶為中心，而且是迭代式的。所以，它肯定是一家非常敏捷的公司，可以對市場變化作出快速反應，并不斷創新。"但是，凡是在現代公司中工作過的人都知道事實根本不是如此。

為什么每個部門都非常敏捷，但是整個公司卻死板、緩慢呢？從高處看，我們必然會忽視一些重要的細節。雖然各個部門都注重敏捷，但是部門之間的聯系卻一成不變，還在走工業時代的老路子。

再舉一個例子，也許你對它并不陌生。有一家公司覺得，要生存下去，就必須創新。所以，管理者指派了一個設計團隊（內部或者外來的）來分析公司的行業前景，并推薦一些創新產品以確保公司能持續經營下去。公司上下都覺得特別興奮。設計團隊和客戶面談，觀察并分析他們。各種實驗、問卷調查、小組討論、原型產品以及粗略測試一個接一個。各種理念迅速產生，然后驗證、否決，繼而改善。

結果是什么呢？設計師驕傲地用一大堆說明文檔來展示他們的研究結果和推薦，業務人員則歡呼雀躍。然后迭代結束，實驗和探索也隨之終止。接著，管理者叫工程團隊來落實這些設計。雖然工程流程是敏捷的，但說明文檔是完全固定的。萬一工程團隊發現設計無法實施或者有問題，怎么辦？要是這個設計在實驗室里很有用，但是沒有商業價值，怎么辦？要是在初期的"研究調查"之后，市場形勢發生了變化，又該怎么辦？

我曾經跟一家公司的領導聊過。這家公司曾不惜高價聘請一家設計公司，對公司所在行業進行一項跨度長達數年的研究。最后，這些設計師在公司總部布置了一間名為"未來景象"的展示廳。在這個展示廳里，你可以看到他們對未來十年行業發展的一些預測，還包括各種可以操作的、頗具科幻風的概念產品。你可能已經猜到了這家公司在接下來的十年做了些什么——什么也沒做。十年里，這家公司的高管、經理和員工來來去去換了成百上千人。實際上，十年過后，這個展廳已經不再那么科幻了。盡管當年迷霧重重，但是研究人員的預測居然大部分都成真了。不過，這家公司卻連一個預測都沒能實現。所以，我問管理者他們接下來準備怎么做。他們告訴我，想把之前那些設計師找回來，再做接下來十年的預測！這家公司認為，沒能實現設計不是設計師的錯，而是工程人員和管理者的問題。

當我把這些告訴設計師之外的人時，他們感到十分震驚，并且對我說都是那個自以為是的設計公司的責任。我告訴高層管理者（包括大公司和初創公司）這個故事時，他們會很無奈，因為不同的部門都說自己很高效，并且走在時代最前沿，都是其他部門拖了后腿。當公司無法找到新的增長點時，這樣的指責就會滿天飛。

不過，責任其實并不在設計師、工程師，甚至也不在高層管理者身上。真正的問題在于公司的體系。世界在不斷變化，而我們仍然在使用這種一根筋的組織體系。這是一個必須全面合作才能成功的世界，而公司組織卻依然嚴格區分職能和部門。這是一個必須不斷做實驗才能持續創新的世界，而我們卻仍然在分析上浪費時間，為了說明文檔而爭執不休，拼命工作也只是為了完成交付任務。

我希望大家記住Jeff Gothelf提倡的"不要再談交付"。讓我們回歸本源，讓全公司都集中精力關注真正的問題——讓客戶滿意。

是打破筒倉、團結一心、一起工作的時候了！

——節選自《精益設計》 - Jeff Gothelf

歡迎進入我的碼云

https://gitee.com/lishilei0523

總結

以上是生活随笔為你收集整理的高效的筒仓的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。