自組織是不是團隊管理的烏托邦？

jopen 9年前發布 | 15K 次閱讀團隊管理

對于很多管理者，最幸福的事，莫過于做到名義上管理一個團隊，但實際上什么都不需要做。他所帶的逆天團隊還可以成果迭出。對于團隊中的成員來講，如果他可以做什么都不被管，做什么都有人幫，那真是可以做夢也會笑醒的。這樣的團隊存在么？自組織的團隊據說就可以，不管你信不信，所以我看了這本書。

我想要談論它，還有個人變動的原因。我曾經待過養老的公司，也從熱衷微管理的公司走過。幾個月前又剛從一個大公司出來，到了一個小小的初創企業。環境的變化會讓人變得更加敏感，上面那些變化讓我得以對比思考管理的各個方面。其實那個大公司也不大，不過大公司很多問題它都有而已。（大公司病嘛，等有時間再討論）

很多時候，加入一個有問題的團隊，就像旅行路上經過的沼澤地。為了生存你只能滾著前進，與沼澤保持盡可能大的接觸面，然后弄一身臟泥巴。等到滾多了，再加上勤奮努力，很容易的，你會成為一個滾泥巴專家。

你很可能忘記，本來只是為了經過。你想要去的，是美好的遠方。

這只是個提醒。也許你只想研究技術，但你值得知道，那些是該受的，那些是該得的。如果你還想管理，不想掉進泥沼里，你更不應該停止對好團隊的追求。這本書也就更值得一看。

這是一篇讀書筆記，書是《管理3.0》。這本書都很多理論和觀點有意思，我會談談我喜歡的一些，包括自組織相關的思維方式、創新問題、開發模式和團隊管理。也會補充我認為缺失的一環。最后是一個問題，也是對個人最重要的問題，你適合什么樣的團隊？

思維方式

值得一提的是系統思維，來源于彼得·桑吉的《第五項修煉》，“將問題視為整個系統的一個組成部分，側重于組織內的循環關系和非線性因果關系” （P47）。其實就是不要將一個運動的整體割裂對待。當一個人作為個體存在于團隊內部時，其他人都是環境變量。你做的所有動作，都會對其他人產生影響。要認識到自己能力可以擴展的邊界。當然重要的是，不要跟豬做隊友。

這本書我也是幾年前看過，關于系統內部正向反向反饋的說法印象深刻。只要反饋環建立起來，就會有習慣的力量幫助你或者阻礙你。所以要關心當前團隊的運轉情況，強化正向反饋。

其次是關于簡化論的說明，“找到了心臟病的誘因（簡化論），并不意味著可以制造一個不生病的心臟（構建論）”（P9）。這也是很多人知道自己團隊的問題，卻不知道如何構建一個好團隊的原因。簡化論是很多人思考停止的地方，因為對于吐槽來說足夠了，殊不知后面才是更有價值的。

關于創新

創新需要土壤

在這個人人視抄襲為平常的國家里，創新已經稀有到要比鬼還少了。為什么中世紀后有文藝復興，為什么有春秋戰國可以百家爭鳴？我與作者一樣，非常贊同土壤的說法，“復雜性系統方法認為創新是可遇而不可求的，它是水到渠成而自然涌現的結果。得先有涌現所需的土壤，才能期待它的發生”（P52）。就在去年提這說法的時候（內部在創新方面一直有討論），我是希望說明創新是需要多數人參與，發生在少數人身上的，要給工程師們空間，不要太多管理操作。

前文有個關鍵詞是“涌現”，它在做屬性時，按照定義是“當一個系統的屬性不能追溯到系統的任何獨立部分時，我們就稱之為涌現屬性”，就像“流動性是水的涌現屬性，文化是群體的涌現屬性”；做動詞時，強調的是自然發生，整體性質的體現，比如在說涌現式設計則強調 “最好的架構不是預先定義好的（可能有一個基本的形式），它可以在產品開發過程中逐步浮現出來”（P21）。這里隱含的意思，我理解，創新是一種整體表現，也是需要用結果后驗的，我們要做和能做的只是增大其可能性而已。
包容式多樣性

作者更進一步，強調了土壤的肥沃問題，“團隊的多樣性能夠顯著增加其創造力。但必須有足夠的共同點加一些制衡，即包容式多樣性”（P60）。做事要找志趣相投的人只是其一，只有能力互補，才容易有火花碰撞出來。這個在我組織過的黑客馬拉松、參加過的內部創新大賽表現得十分明顯，如果只是技術人組隊，很容易陷在 Geek 圈里，玩玩原型做技術儲備可以，離產品化還是甚遠。

說起來，此次微博的升級視頻，我自認為是個小的正向例子。那是有一天，設計師跑過來問說如果想利用每個人的信息來生成個性化的視頻，能不能搞得定。如果沒有服務的話，他只能每個人手動生成了，可能幾千個。我說沒有經驗，但可以試試看。于是有了最后的 AppleScript + Shell + JavascriptX 的奇怪組合。我想說的是，由于有設計師的參與，由于不同領域的人共同對技術應用邊界的摸索，才有了產品質量的成果出來。事實上效果還是比較令人滿意的，沒看過的可以看看這里：http://www.weibo.com/1819367693/Bp6II3a1V

我說這個例子是偶然，因為從想法到實現還有相當長的路要走。大多數想法都像書中所說，"一個很好地想法可能在公司內被踢來踢去好幾年而得不到利用，這不是因為大家沒有看到它的好處，而是因為不知道應該由誰來負責將它踏實地落到行動上”（P63）。我是負責后端團隊，通常不會與設計師打交道，與這位設計師認識純粹是由于組織黑客馬拉松的時候他幫忙設計制作了宣傳視頻。
勒曼第六法則

對于一個業務基本穩定的公司，創新難還有一個重要原因，就是勒曼第六法則，"許多軟件產品并沒有演化使自身變得更好，他們演化之目的只是為了盡量不被用戶拋棄（不可避免）”（P310），大多時候，它們 “為了將客戶滿意度維持在相同的水平，要不斷增加產品的功能性”。制定 KPI 當然要 SMART 不是么？你見過 KPI 說要將創新水平提高幾個百分點么？。。。

說回創造力，還有個有趣的三階段理論。先是前習俗創造力，屬于兒童的，是自發性的；然后是習俗創造力，一般在7-11歲左右，開始是真正的思考，了解世界的邊界；最后是后習俗創造力，也是創新開始的地方（P67）。最后一階段的時候，便是講初心的地方，“即使知道有實實在在的約束，也可以像小孩子一樣充滿想象力”（P70）。這個理論很類似的一個學習理論，會在后面人員培養處再講。這里主要說明邊界學習對創新的影響。邊界客觀存在，不要讓它制約你的想法。
羅杰斯創新曲線

羅杰斯有個創新曲線，說的是團隊人群分布。“創新者2.5%、早期采用者13.5%、早期采用人群34%、后期采用者34%、遲緩者16%。改變要從渴望嘗試新事物的創新者入手，一次努力推動后面人群。忽略行動遲緩者，他們會一直抵制改變，直到其他所有人都采用”（P335）。這個比例在不同團隊肯定會有所差異，你只要記住，不要想當然所有人都愿意改變就行。然后在嘗試新事物的時候，不要怕反對聲音。

管理者要做的就是發現這種萌芽，幫助其成長而不被惡劣環境影響。對那些不愿意改變的力量進行驅趕，甚至可以讓他們適當痛苦。“讓停滯痛苦不堪”（P336）說的就是這種迂回方式，有些人吃一塹才能長一智。

手中的鞭子和驢頭前面的胡蘿卜同樣有用。

開發模式

書中提了兩家的宣言：

敏捷軟件開發（P19）

“個人和交互 勝于 流程和工具；可以工作的軟件 勝于 復雜的文檔”；
“雖然右項也具有價值，我們認為左項具有更大的價值”

精益軟件開發（P24）

“可以工作的軟件猶不足，尚需精益求精；響應變化猶不足，尚需穩步增加價值”
“在追求左項的過程中，我們發現右項亦不可或缺”

說實話我對這些模式都不感冒，這方面我更功利，我覺得不同發展階段需要不同的開發方式。特別在互聯網行業，一個團隊的開發活動需要在高速度和高質量方面反復切換。

在團隊人員緊缺的時候，你要有速度意識，這是質量下降幾乎是必然的；如果人員稍微充沛，就要重新思考質量問題，承認低質量軟件的存在與不合理之處，持續改進。因為當用戶請求量上來，幾乎所有的問題都會顯現出來（墨菲定律），你要做的是在Bug 釀成災難之前消滅掉。

我在心里是渴望精益的。

關于不同開發方式其實網上有很多爭吵，極端言論也比比皆是，但看兩者的宣言，你很難產生針鋒相對的感覺。為什么？因為很多人在交流時急于表達自己的觀點，（或有意或無意地）不會強調與對方觀點的相同之處，這在溝通中造成了很多無謂的爭執。相互熟悉的人之間也無法避免這種情況，更別說背景差異的團隊成員之間了。

因此我也更加贊同敏捷宣言里對個人和交互的強調。有效溝通才可能讓改進發生。

團隊管理

動機管理，以人為本

“人是任何軟件項目中最復雜的元素”（P62），確實所有對時間和項目的管理，都是對人的管理。而其中最難的部分，是人員的動機管理，“所有管理者首先關注的應該是激勵員工以確保他們愿意全心全意做事，而這一切，都需要動力”（P56）。如果一個人已經與團隊貳心，那你實質上已經失去他了。所有的 CEO（大忽悠）都會談價值觀，談企業文化，也是這個目的。

我們把只畫餅的宣傳叫做忽悠，是在強調獎勵的必要性。但獎勵最重要的目的是要變成激勵，書里提醒 “不要把為團隊聚餐買單當成慶祝里程碑式勝利表達謝意的方式。為團隊買單是為了解決人們社交和相互聯系的需求”（P85）。而且“不要應某些員工的要求而取悅他們，從而引入規則、實踐和政策。真正的目的必須是引入秩序和穩定性”。

后面這句話我不知道是否理解得準確，我只能說部分同意。我同意規則和秩序，只要他們是公平的，而不在意是否為了取悅員工。事實上我認為，除了真正的團隊目標，其他所有事情都應該為了成員愉悅而做，這樣才能最大發揮成員的價值。

在某種程度上，管理應該是服務性的。
適當授權，解除電網

如果說動機管理搞定了人員能動性的問題，那么授權管理就是為解決工作效率的問題。“智慧的控制要做到無形中的影響。決策的制定也應該來自人員之間的互動，而非來自我的權威”（P109），這方面英文Empowerment更容易理解一些。把權力下放給員工，但不要忘記目的是“不是增強激勵，而是改善管理”。當然，授權也是分級別的：告知、販賣、咨詢、商定、建議、征詢、委托（P125）。當然，“這并不意味著需要分級的架構”。

授權不當就會造成隱形電網的存在。“當管理者對下屬賦能時，他們并不會清楚地點明其職權界限，這意味著人們往往只能摸著石頭過河，磕磕絆絆，中間還伴隨著情感傷害”，“它是時間和資源的雙重浪費。屢屢觸及隱形電網的經歷會扼殺人們的積極性”（P173）。這方面我倒是體會頗深，因為不同等級的信息不對稱和相互之間的溝通問題，會造成很多理解上的偏差，碰上電網是非常可能發生的。這個事故的預防（降低頻次）以及處理好壞（減輕傷害），不同的管理者之間差距非常明顯。壞的結果多了，就很容易造成多一事不如少一事的氛圍，離自組織也必然是越來越遠。
運用同儕壓力

適當授權之后，就可以放手團隊去解決問題了，也是時候做好準備接受成員犯錯的考驗了。“若要有所作為，必先磨練耐性”（P130），而且“當已授權的團隊走進辦公室請求你決定某件事情時，要想辦法讓他們自己解決問題”（P135）。不要做保姆，不止是減輕當前的負擔，重要的是要防止成員思維惰性，養成依賴別人思考的習慣。

團隊可以自行運轉，來源于成員想一起共事的意愿，但意愿能促進協作么？書里提到的“同儕壓力”，很好的說明了這一點。當你做事的時候，大家都在看著你。你的能力展現無遺，好與不好都在每個人心里。這種社會壓力讓成員之間可以互相驅動，也是規則發揮作用的地方。

要讓同儕壓力轉化成動力，要注意“與那些試圖破壞這些團隊的人做斗爭”，因為“只有在人們想要加入某個團體時，該團體的社會壓力才會起作用” （P224）。最好的方式是，“建立團隊、設定目標、再退后一步”。如果有人要破壞團隊的規則，那么“找他談一談”，不奏效就“再談一談”，還不行就“請他離開”。團隊是作為團隊而存在，而不是為某個人。我的經驗是，在這方面越果斷越好。

如果怕請人離開，那就把好入門的關。“在允許某人加入（有挑戰性的）項目之前，必須對他進行適當的測試”（P185），這是書中根據荷蘭的低交通事故率總結的經驗。我在微博也一直堅持，沒有經過內部新兵訓練以及高性能服務設計演練的人，再忙也不會讓其進入正式的開發序列。這是對當事人負責，如果他因為經驗缺乏釀成事故，以后做事也會畏手畏腳；更是對團隊其他人負責，團隊不應該因為某個人的問題而受拖累。互聯網應用，完成功能只是基本的，還要保證性能、可用性等很多方面。問題在上線前解決要遠比上線后簡單。而一旦上線，就是7x24小時的服務，出了問題基本是不搞定不眠不休的（也是苦逼之處）。

一句話，寧肯一堆人累，也不要被一個人坑。
保護團隊成員

“管理者既要促進自組織，還要保護大家不受傷害”（P175）。我本來覺得這是對管理者基本的要求，但是在一次內部討論中，出現了截然不同的相反觀點。有人反問說，如果一個人不能很好地保護自己，總需要人呵護，如何期望他在對外合作中，甚至在公司外部的行業洗禮中生存下來？

如果說從個人角度來看待這個問題，尚可以理解的話，從團隊角度看來我是完全不贊同。組成團隊的主要目的是為了完成共同的目標，而不是為了讓個人接受鍛煉。而在完成目標過程中成員之間互相配合互相幫助，也是團隊存在的價值所在。讓個人成長，在團隊中發揮更大價值，跟讓個人接受磨練以成長到更高層次，是兩件事。

特別是當管理者不是領導整個公司的時候（個人還沒體驗過），如果不喜歡隨波逐流，期望自己的團隊在公司內可以變得更好，舉例來講先變成自組織模式，更要注意這點。如果讓團隊中的普通成員去接受不必要的壓力，要么他覺得太困難無法做事，要么他適應下來，結果把外界的習慣帶回當前小團隊，所有這些都會對團隊向自組織轉變起到負面作用。這就是環境的力量。用系統思維方式來看，如之前所述，就是不要讓環境對團隊改進產生負向反饋。
開始，不要停止改進

開始改變并不意味著就從此一路向前了。一切都在變化之中，環境、人員甚至是目標都有可能隨時改變。而整個團隊也很可能進入局部優化的狀態，事情做得馬馬虎虎，也總是問題不斷。這時候就要考慮模擬退火了。“先加熱再冷卻會改變金屬的性質，比如強度和硬度，這種技術叫退火。復雜性系統中，錯誤和噪聲-通常由環境引發，會擾亂系統并使之拜托局部優化，在這之后，系統更容易找到更好地位置安定下來。”（P339）

用錯誤和噪聲來改善團隊，說起來有些奇怪，再看一下模因論可能就好理解了：“不要求模因組內所有思想、概念和實踐都必須是有益的。其中的一些有害處，但由于同屬于一個模因組，負面思想也會幫助正面思想互相復制，這樣便可以中和負面影響。危險范例：沒有確鑿證據能夠證明代碼集體所有制的價值，但是此實踐似乎能增強其他敏捷實踐，所以復制它也不會有什么壞處。”（P204）

如果發生了局部優化，我理解很可能是某些方法措施有了什么副作用。這時就要重新審視團隊，是否有規則沒有實施或者被錯誤的實施了；如果發現新規則不適應當前的團隊，要繼續嘗試其他可能。

不恰當的錯誤補救例子很多，比如彈性制度下一個人鉆空子不好好工作變為全部人強制坐班，或者一個人在項目過程中出現溝通問題，全部人天天一起開會。這種情況還有很多，說個親身經歷的創新相關的例子。

曾經有一次大家想搞創新，但是在如何創新上分化成了兩派。一派就是我剛才提的土壤論，希望解放大多數同學的創造力；另一派則是規劃論，認為創新是可以規劃出來，用項目來管理的。討論結果是決定先用后者。不出意料的是，執行規劃論的結果就是，大家只是將其看做是另一項工作任務而已。問題是本來都忙不過來了，還要再進行一項自己毫不在意的事情，即使它的名字叫創新，會有什么動力呢。因此這個行動基本上還未開始就結束了。然后，整個事情最奇怪的地方出現了，再沒有人談論創新問題，好像不存在這件事情一樣。

舉這個例子，不是說理念分歧的問題，而是整個團隊在失敗嘗試之后的總結和使用方式，也就是如何獲取經驗的問題。當一件事情失敗之后，不要怕把事情放在臺面上討論，特別是嘗試，大部分都是要失敗的。如果失敗了而不總結，才是對自己最大的不負責任。總結可以得到經驗，但要時刻對經驗保持警惕。好的經驗固然讓人成熟進步，錯誤經驗卻讓人裹足不前。

攻打威虎山的時候，正面土匪多有坦克，小分隊又從背面上山了不是？

這就夠了么

思想是好思想，行動也有方法，就能實現么？在我看來，至少還有兩個問題需要解決才行，也是書上沒有講的。一是目標管理，二是人員培養。

目標管理

這個目標管理不同于前面說的動機管理。動機管理是解決愿不愿意做的問題，目標是解決要做什么的問題。一個團隊是自組織的，意味著每個人都是自主的而不是被管理的，好的時候會像大雁一樣跟隨頭雁，不好的時候就各自為政，一盤散沙。

因此目標管理是不可忽略的。咦，那還怎么自組織？我個人理解，這不是像KPI 一樣的設定與分解，而是一起來討論團隊目標，然后自我選擇與設定的過程。事情一樣，但規則不同。
人員培養

并不是每個人都適合自組織團隊。有的人能力不足，無法自主完成任務；有的人驅動不足，需要監督和指導；有的人悟性不夠，無法自己發現問題。你也許會說，那就不是我們需要的人啊。

那只是理想。什么都是變化的，市場是變的，目標是變的，人也是如此。好的方面是，他的能力會提高，你有可能培養出一個合格的人；不好的方面是，他可能離開，你會流失已有的成員。

所以現實是，在你集合一群合格的人之前，你有漫長的路要走，而你的船不能停或掉頭。因此，人員培養是必須要重視的。但其實團隊能給的幫助有限，只有足夠的壓力和適當的指導。適當的指導讓其找到方向，適當的壓力讓其不要懈怠，如此而已。

人必先自救，而后人救之。這句話放在這里依然是適用的。