高效的筒仓
有時候,我喜歡想象自己從高處俯視一家典型的現代公司的情形,我可以"看到"公司按照不同的職能分成了一個個封閉的圓筒倉庫,筒倉上寫著市場、運營、制造、IT、工程、設計,等等。各部門按部就班,有序運作。
想象一下,如果伸手下去,拿起一個筒倉,把頂蓋掀開,朝里面看,你會看到什么?這是一家現代公司,你將看到,每個筒倉都是以追求最大效率為目標設計的。要想實現高效率,就必須找到一個高度迭代的、以客戶為中心的方法來解決問題。對于制造部門來說,可能要采用傳統的精益生產法;工程和IT部門可能會采用敏捷開發方法;市場部門會使用客戶開發法;運營部門采用DevOps理念;設計部門則使用最新的設計思維、互動設計以及用戶研究方法。
重新站回高處,我們可能會覺得:"這家公司使用了各種方法。這些方法不僅嚴謹,而且是由假設驅動的,不僅以客戶為中心,而且是迭代式的。所以,它肯定是一家非常敏捷的公司,可以對市場變化作出快速反應,并不斷創新。"但是,凡是在現代公司中工作過的人都知道事實根本不是如此。
為什么每個部門都非常敏捷,但是整個公司卻死板、緩慢呢?從高處看,我們必然會忽視一些重要的細節。雖然各個部門都注重敏捷,但是部門之間的聯系卻一成不變,還在走工業時代的老路子。
再舉一個例子,也許你對它并不陌生。有一家公司覺得,要生存下去,就必須創新。所以,管理者指派了一個設計團隊(內部或者外來的)來分析公司的行業前景,并推薦一些創新產品以確保公司能持續經營下去。公司上下都覺得特別興奮。設計團隊和客戶面談,觀察并分析他們。各種實驗、問卷調查、小組討論、原型產品以及粗略測試一個接一個。各種理念迅速產生,然后驗證、否決,繼而改善。
結果是什么呢?設計師驕傲地用一大堆說明文檔來展示他們的研究結果和推薦,業務人員則歡呼雀躍。然后迭代結束,實驗和探索也隨之終止。接著,管理者叫工程團隊來落實這些設計。雖然工程流程是敏捷的,但說明文檔是完全固定的。萬一工程團隊發現設計無法實施或者有問題,怎么辦?要是這個設計在實驗室里很有用,但是沒有商業價值,怎么辦?要是在初期的"研究調查"之后,市場形勢發生了變化,又該怎么辦?
我曾經跟一家公司的領導聊過。這家公司曾不惜高價聘請一家設計公司,對公司所在行業進行一項跨度長達數年的研究。最后,這些設計師在公司總部布置了一間名為"未來景象"的展示廳。在這個展示廳里,你可以看到他們對未來十年行業發展的一些預測,還包括各種可以操作的、頗具科幻風的概念產品。你可能已經猜到了這家公司在接下來的十年做了些什么——什么也沒做。十年里,這家公司的高管、經理和員工來來去去換了成百上千人。實際上,十年過后,這個展廳已經不再那么科幻了。盡管當年迷霧重重,但是研究人員的預測居然大部分都成真了。不過,這家公司卻連一個預測都沒能實現。所以,我問管理者他們接下來準備怎么做。他們告訴我,想把之前那些設計師找回來,再做接下來十年的預測!這家公司認為,沒能實現設計不是設計師的錯,而是工程人員和管理者的問題。
當我把這些告訴設計師之外的人時,他們感到十分震驚,并且對我說都是那個自以為是的設計公司的責任。我告訴高層管理者(包括大公司和初創公司)這個故事時,他們會很無奈,因為不同的部門都說自己很高效,并且走在時代最前沿,都是其他部門拖了后腿。當公司無法找到新的增長點時,這樣的指責就會滿天飛。
不過,責任其實并不在設計師、工程師,甚至也不在高層管理者身上。真正的問題在于公司的體系。世界在不斷變化,而我們仍然在使用這種一根筋的組織體系。這是一個必須全面合作才能成功的世界,而公司組織卻依然嚴格區分職能和部門。這是一個必須不斷做實驗才能持續創新的世界,而我們卻仍然在分析上浪費時間,為了說明文檔而爭執不休,拼命工作也只是為了完成交付任務。
我希望大家記住Jeff Gothelf提倡的"不要再談交付"。讓我們回歸本源,讓全公司都集中精力關注真正的問題——讓客戶滿意。
是打破筒倉、團結一心、一起工作的時候了!
——節選自《精益設計》 - Jeff Gothelf
歡迎進入我的碼云
https://gitee.com/lishilei0523
總結
- 上一篇: (四)终值定理与稳态误差
- 下一篇: HDFS简介