《架構即未來》（叄）

明天自罰蛋白粉一天，這兩天爭取把欠的補上。

第三章，「組織的設置」。

孫子說，凡治眾如治寡，分數是也。

——治理大軍團就象治理小部隊一樣有效，是依靠合理的組織、結構、編製。

這裡講的就是組織、結構、編製的作用。

3.1 論述了組織會影響溝通、效率、質量、標準和責任。這一段對我來說是非常直觀的，在本章中的作用也不過是論述了組織對可擴展性的重要性，因此略過不提。

3.2 談團隊規模，過大過小都不足取，多大合適？6-15人，「兩張披薩餅餵飽的人數」嘛！

影響團隊規模的幾點因素：

• 經理的管理經驗；
• 團隊任職時間；
• 經理的責任；
• 業務需要。

這也很直觀嘛，有經驗的管理者可以管理更多的人，團隊里有經驗的人越多，溝通成本越低，經理的責任越少，能管的就越多，業務發展了團隊規模就大，萎縮了就小。

如何判斷一個團隊的規模過大還是過小呢？書中給出了幾點特徵，還是蠻有趣的：

1. 團隊規模過大：
1. 溝通不暢
2. 生產率低下
3. 士氣低落
2. 團隊規模過小：
1. 不滿意的業務夥伴
2. 微觀管理的經理
3. 勞累的團隊成員

其實這也蠻直觀的……好吧，其實我覺得整個第三章前面一半的內容對我來說完全沒有意義，這些內容全部都可以直接的觀察到，與其背這些點，不如去與你的團隊聊。考慮到可能讀者也許難以理解——哪兒他媽有讀者啊？！我都停更一周了連個催更的都沒有！！

算了，還是舉個例子吧。

還記得第一章里我曾經提到過的，環形管理嗎？在我們建立起環形管理之前，實際上是星形管理，也就是，我的一個測試經理帶領15人的測試團隊。

這個規模在本書中看來都是太大了。從那四個要素來看：

• 經理的管理經驗非常豐富，加分；

• 團隊的總任職時間還是比較適當的，成員總體年齡在軟體行業不算年輕，加分；
• 經理的責任還是很多的，我當時要求他來負責給每個人分任務，並驗收每個人的任務完成情況，減分；
• 業務需要——這沒辦法，就這個規模人還不夠，後來我們擴展了一倍。

那麼，當時的問題有哪些呢？

最明顯的問題就是我的經理實在是累壞了。每天沒有自己的時間，只能不停的分活，驗收，分活，驗收。相對的，團隊到是沒有那麼多問題，有的時候經理不在了就有點兒慌，依賴心理比較強。

接著作者談了如何拆分團隊以及任命新經理等等，不再贅述。他們還提供了一個檢查表來做這個事兒，我就不放上來了。

3.3 組織結構。

這一節是我覺得最有意思的。可以好好聊聊這個事兒。

如果你觀察過一個組織從小變大的過程，你就會看到，最初的組織是小作坊，一人分飾多角，老闆、工人、採購、銷售都是他；老闆娘、會計、出納、收銀都是她。正所謂，外面要有摟錢的耙，家裡得有裝錢的匣，不怕那耙子沒齒兒，就怕那匣子沒底兒！

後來他們賺錢了，就開始僱傭更多的人來幫他們，於是，每個人都擁有了各自的角色，一個老闆，三十個工人，兩個採購，五個銷售……於是有了生產部，採購部，銷售部等等。

於是，很自然的，職能型組織誕生了。組織中的單元是一個個按照功能聚合的團隊。軟體行業里，就是產品、開發、測試、架構、運維、資料庫等等部門。

這種部門的特點就是一個需求需要翻越一座一座的山頭，經過N道審批，最後才會發布到用戶手中。在這樣的組織內，也很自然的發展出了按部就班的瀑布式開發模型。

我之前公司的技術團隊最初就是這個樣子，在這樣的組織結構上，我設計了基於看板的流程，需求、開發和測試，環環相扣，用隊列分隔。通過觀察隊列就知道當前瓶頸在哪裡。

運營、產品和銷售是我們的內部客戶，這些內部客戶想要完成一個需求，就要向需求團隊提個需求，然後需求團隊把這個需求與內部進行溝通，協調開發、測試資源，然後扔隊列里，開發團隊就去撈。開發做完了，扔測試隊列里，測試團隊就去撈。測試做完了，扔待上線隊列里，需求團隊去驗收，然後組織上線評審會。

結果那，這三個內部客戶有著各自的績效目標，而這些績效目標的達成，都依賴於技術團隊的產出。因此，誰的需求跑得快，誰的目標就更容易達成。為了達到這個目的，客戶們各顯神通。

最初，他們是稚嫩的，直接催技術團隊。我們這幫人老奸巨猾，直接把看板拉出來給他們看，每個需求當前投入資源都列在上面，沒資源就是沒資源，不用跟我催。後來實在催得沒辦法了，8月份政治性加班三周，堵住了客戶們的嘴。

他們轉移戰場，直接去跟開發人員套關係，小姑娘長得漂亮，求開發人員幫忙。開發人員不好拒絕啊，就偷偷給做了，到測試這裡，測試說，什麼玩意兒，需求在哪兒那？！開發團隊召開會議，狠批接私活的行為，這條路也廢了。

客戶們急得團團轉，我們給他們指了條明路，你的需求不是不給你做，實在是優先順序不夠高。怎麼才能夠高呢？找領導批啊！

我們建立了優先順序審批流程，客戶們四處求爺爺告奶奶，後來審批權直接歸到CEO那裡，我經常可以看到CEO審批，「不同意緊急，想辦法！」

呃，其實這種心態並不是以客戶為中心的服務心態，我懺悔。但是在當時的情況下，我也不知道該如何破局，當時只能本能的保護技術團隊的利益而已。

再後來，銷售乾產品，產品干運營，大家一起反應，技術都是大爺使喚不動。我領導和我私下裡說起這個事兒，我砸吧砸吧嘴，「那也比去年強啊，去年技術是孫子……」

下半年的時候，出了幾次嚴重的生產事故，於是技術管理層開始反思，說再也不能這樣下去了，我們必須整改！於是，我們開始了第二階段，矩陣型組織。

矩陣型組織的特點是，多維度彙報。一方面，開發組長有開發部門經理，測試組長有測試部門經理，另一方面，在項目組內，開發組長和測試組長又都要歸項目經理管理。

好處是，第一，項目內的事物可以在項目內解決，不需要外部審批，這樣減少了外部協調的成本；第二，專業方面的規範和標準有各自職能部門來監管，能夠保證項目質量。

壞處也很明顯，多頭彙報。

我曾經就作為這樣組織里的一個測試組長，向項目組經理彙報，同時向質量總監彙報。項目組經理希望我改進流程，質量總監希望我建設自動化平台，我他奶奶的只有一個腦袋，這倆貨天天給我念經。後來的解決方案是把我歸進項目團隊內了，質量總監玩兒球去。

我也曾經面對著作為矩陣的一個管理者的困惑，我的團隊被分散到項目組內，我根本不知道他們每天在做什麼；我的團隊在項目組內孤立無援，沒人懂測試，因此他們的要求根本沒人聽。我很困惑，到底這種形式的團隊如何管理？

其實在我跳到這兩家公司之前，我最早的老東家已經解決過類似的問題。他們使用的就是書中描述的「敏捷團隊」。只不過當時我們的過程不夠敏捷，我們基本上依賴於本能在把事情做好。但是由於組織形式的敏捷，導致每個人都敏捷起來。

我們那時候叫做項目團隊，外包到甲方公司去。項目經理就是老大，下面需求開發測試一大幫。客戶無論有什麼需求都是這幫人給你搞定，相當於給甲方業務部門配置了一個便攜型技術工具箱。

項目團隊內部有自己的流程和方法，但是管理水平非常低，基本上也沒什麼過程管理，更不要想量化管理。但是客戶一般對這種團隊都還比較滿意，因為需求進來出去非常快。

現在我的工作就是在給一個個敏捷團隊劃定底線，給予他們流程制度上的支撐；另一方面，其他的架構師們在給予他們技術平台上的支撐。

作者建立了一個模型，是關於創新和影響創新的因素的：

• 創新

• 關係的多樣性 +
• 被授權的感覺 +
• 情感型衝突 -
• 組織邊界 +
• 經驗的多樣性 +
• 認知型衝突 +
• 經驗的多樣性

解讀這個模型，加號的是會對上級因素加強的因素，減號是減弱的因素。

可以看出，關係的多樣性、被授權的感覺和認知型衝突都會加強組織的創新，而情感型衝突則會減少。其中，組織邊界和經驗的多樣性會增加情感型衝突。

解釋一下，所謂關係的多樣性，是指團隊中來自各個團隊的不同背景的人，他們能夠通過人脈和溝通幫團隊解決很多問題，所以會加強創新。

被授權的感覺是指團隊感覺到自己把握著自己的命運，這往往是通過目標的達成實現的。而矩陣式管理的最大問題就是多頭彙報，也就是經常有兩個目標在不停的拉扯團隊。

組織邊界，俗稱部門牆，這玩意兒在職能型組織中很常見，加強情感型衝突妥妥的。

在上家公司，我們在把客戶折騰了一年之後，我的領導離職了。年底討論改革方案的時候，我本來很想把技術團隊乾脆全扔給業務團隊算了，結果在這個想法下發散出來了依照需求源重新劃分組織的想法，於是出現了敏捷團隊直接對應客戶。

總結一下，也就是說，敏捷好，敏捷妙，敏捷呱呱叫！