也談大公司病4——大公司中的反模式

序
多數大公司大了後都不可避免會遇到大公司病，機構臃腫，行動緩慢，協調困難，思維僵化。為此，大公司採取了各種各樣的做法，建設企業文化，調整組織機構，更換領導人，加強流程規範，建立特區，建立快捷通道，引入敏捷方法。這些措施往往都能取得一定時間的效果，卻很難與整個公司抗衡，隨著時間流逝，大公司病還在蔓延。
為什麼會這樣？是解決措施有問題？還是管理能力不足？還是沒有找到真正的問題？
下面對大公司病的一些另類思考，試圖向真正問題邁進一步，“大公司中的反模式”是其中第四篇。

正文
整個系列應該叫《理解大公司病》，不理解大公司病，如何能夠治病。這是第四篇，在前面三篇“正確是最大的錯誤”、“減少錯誤不等於增加成功”、“治大國不是烹小鮮”中，從一些大家平時不甚關注的角度向大家講述了大公司病的部分理解。本文將對上三篇進行一些總結。

正確、安全、簡單 vs. 成功、創新、複雜
正確、安全、簡單是存在於每個人心中的渴望。公司的本質還是由人組成的，人和人與人之間的關係構成了公司的基石，所以源於個人的這些渴望在不自覺地影響著人們的行為，最終體現到公司行為中。在大公司，尤其如此。即使在大公司中，你依然會聽到人們對缺乏安全感，不知道什麼是正確，太複雜不夠簡單等種種抱怨，這正是力量的表現。
成功、創新、複雜是真實世界對企業的要求。公司是一個盈利性的組織，成功是公司追求的，因為不成功則成仁。創新是公司持續成功的保障，公司必須持續滿足客戶的需求。而複雜是公司面臨的現實情況，在網際網路時代，公司服務的人群快速擴大，市場競爭越發激烈，公司生存的環境越來越複雜。公司，尤其是大公司需要在這複雜的環境中不斷創新以取得持續的成功。
當正確、安全、簡單在大公司碰到了成功、創新與複雜，會發生些什麼？正確、安全、簡單代表著公司向內的力量，它們引導著公司看自己，關注公司內部。成功、創新和複雜是外部環境要求，是外在的驅動力。如果兩者不能匹配上，會出現各種怪現象。當然，100%匹配幾乎不可能。
下面，就以大公司中幾個常見話題作為示例進行簡單討論。分工和績效兩個話題因篇幅限制，討論不深刻，未來可能單獨成篇。

反模式1：分工不應該是扯皮的基點，逃避責任的港灣
大公司強調的分工會逐漸演變成“圈地運動”。分工在傳統意義上是通過分工加強專業能力，降低人員培養成本，提升整體工作效率，最終有效提升公司的成功、創新，幫助公司更有效的應對複雜環境。而在大公司，分工的主要目的卻是為了劃分職責地盤，不能有任何模糊，因為只有這樣，工作中誰該做什麼才是簡單清晰的，誰該承擔什麼責任是清晰的，人們才知道什麼是正確。主導分工的管理者覺得正確、安全、簡單，接受分工的員工也這麼感覺。然而，分工與成功、創新、複雜的關係越來越弱。
“圈地運動”式的分工往往成為扯皮的基點。類似的場景經常出現，兩個農夫各自站在自己的田裡罵對方的田沒種好，說對方沒有證據證明自己的田沒種好。一個例子可以參看王建碩部落格《寫程式碼這件事》http://www.huxiu.com/article/3267/1.html?odby=agree。
“圈地運動”式的分工往往成為逃避責任的港灣。還有一種情況，在所有分工都明確的情況下，產品依然失敗了，是誰的責任？要不是都沒有責任，因為每個人都做好了自己分工內的工作，找不出做錯的證據，最終公司承擔；要不是大家承擔責任，每個人都有錯，才導致了錯誤的發生，最終法不責眾。

反模式2：績效KPI應該是跑道而不是終點
績效評估是大多數大公司都有的制度，而這項制度在大多數大公司都實施的不盡如人意。其本意是通過績效評估，統一組織發展方向，傳遞組織目標，保持組織活力，幫助組織在複雜環境中成功與創新。然而在實際過程中，因為成本原因、因為溝通障礙、因為工作複雜度增加，績效評估的難度不斷上升。因為各種原因，管理者會採用簡單的方式來進行績效評估。從而導致如下結果：
績效評估最終促成KPI導向。績效評估極大的破壞了員工的安全感，尤其是在有末位淘汰的情況下。績效評估清晰向員工指明什麼是正確的。只做KPI上規定的事是最簡單的。從而為了正確、安全、簡單，員工變成了KPI導向，唯KPI是從，不在KPI上的一概不做，在KPI上的積極做好。
績效評估最終促成老闆導向。績效評估可能成為老闆顯示威嚴的工具。它用簡單的方式幫助老闆鞏固了安全感，清晰闡釋了老闆需要的正確。員工為了自身的正確、安全、簡單，唯老闆之命是從。
KPI導向、老闆導向極大制約了公司的成功、創新，阻礙公司靈活應對複雜環境。對於員工來說，正確、安全、簡單的創新是在是太難了，一個人在對抗一個體系。在有些公司，情況甚至發展到阻礙公司發展的程度。

其他反模式
流程制度能防止錯誤，也能阻礙成功。流程制度是好的，僅在他們能夠幫助公司更加成功這一前提下。因為分工過細，每個人都站在自己的田裡看問題，為了保證自身的正確、安全和簡單那，大公司中的流程制度如果不經刻意控制的話會源源不斷的增加。然而，這與公司的成功、創新、應對複雜很可能存在一定矛盾，降低了整體執行效率，甚至會出現內部分工中的矛盾衝突。
Smart目標讓我們撿了芝麻丟了西瓜。管理學課程告訴我們，目標要Smart，但對於知識密集型產業例如軟體研發而言，Smart目標不是個好主意。符合Smart目標能讓管理者感到正確、安全和簡單，但員工則會用另一種方式讓Smart目標不能達到效果，例如單元測試覆蓋率。單元測試是軟體研發中的流行實踐，80%的單元測試覆蓋率顯然是Smart目標，制訂此目標的目的是提升研發團隊的軟體研發能力，保證軟體質量。然而，提升單元測試覆蓋率卻不去提升軟體研發能力是更簡單的選擇，員工可以用自動生成單元測試方法的方式，他們總能達成管理者規定的Smart目標，卻讓管理者的期望變為流水。

尾聲
國慶大假幾天，終於寫完了近期關注的“理解大公司病”話題。後續的話題還很多，如複雜系統、敏捷、管理實踐、軟體研發等等。如同賈伯斯所說，大公司病、複雜系統、管理實踐、敏捷、軟體研發這些都是點，我們需要不斷學習回顧以讓這些點最終都匯聚成線。希望在不久的將來，能夠把串起的線呈現給大家。
配合正確、安全、簡單vs.成功、創新、複雜，可以設計出一系列的小工具來檢查公司對內力量與對外力量間的協調程度，還可以進行鍼對性的一些改進。讀完了，你有什麼收穫呢？

參考
再次推薦《BBC系列：神祕的混沌理論》http://v.youku.com/v_show/id_XMTcyNjE2MzMy.html，理解複雜系統，理解簡單與複雜的關係，非常重要。
我有另一系列文章講述了分工在軟體研發中不再有效，《債思維——軟體研發新視角》http://www.ituring.com.cn/article/1836。