摘要：
敏捷不是靈丹妙藥，不能當飯吃！這是本系列文章最後一篇，我們將會談談敏捷對組織架構、團隊文化的要求，特別是對薪金待遇的要求！最後根據我的個人理解，給出我對敏捷的定義。
本文大綱：
1）部門設定惹得禍？
2）強矩陣還是弱矩陣？
3）敏捷對團隊文化的要求
4）敏捷對薪金待遇的要求
5）敏捷的本質是什麼？
本文是系列文章的第4篇，如果還沒有看過前面的文章，建議先按順序看看！
第一篇：敏捷的“官方”定義
連結：http://www.cnblogs.com/umlonline/p/3450032.html
第二篇：敏捷流程框架及敏捷實踐一覽
連結：http://www.cnblogs.com/umlonline/p/3450428.html
第三篇：敏捷在中國的水土不服
連結：http://www.cnblogs.com/umlonline/p/3453930.html
1）部門設定惹的禍？
下面我將會列舉三個例子，前面兩個是“杯具”，後面一個是“洗具”。
案例1：需求設計部 PK 編碼及實施部
先上圖：
圖4.1 部門之間的PK
某軟體公司設立了兩大部門：
需求及設計部：顧名思義，就是負責軟體需求分析及設計工作。（後面簡稱“A部門”）
實施部：負責編碼實現，負責軟體的安裝、部署、上線、培訓客戶等工作。（後面簡稱“B部門”）
公司內部有一個任務管理系統：A部門經過需求分析及軟體設計後，通過該系統分派編碼等任務給B部門，這個任務叫“工單”，而分派任務的工作叫“下單”。B部門需要完成這些任務，並接受A部門的檢查。B部門如果不能按時按質量要求完成任務，B部門的績效考核就會差；而B部門如果認為A部門分派的任務不合理、描述不清，可以拒絕該任務，稱之為“踢單”，“踢單”越多，A部門的績效考核就越差。
沒有這樣的部門設定和考核機制之前，兩個部門的人可以無分彼此地一起商量事情，共同解決問題，而這樣的部門設定及考核機制建立後，兩個部門的人經常為了一個“工單”而扯皮，工作的焦點變成不是如何讓專案成功，而是如何界定兩個部門的工作邊界以及想辦法推卸責任。
這樣的情況，如何敏捷？
案例2：客服部 PK 開發部
某網站有大量的使用者訪問，使用者可以向客服部投訴問題，客服部記錄問題後移交個開發部處理。使用者向客服部描述問題的時候，往往是描述不清的，往往只有“大概”的說法，而客服部往往也不能進一步向使用者問清楚情況，往往只能記錄問題而已。於是這樣的問題移交到開發部時，開發部就會說：記錄不清楚，無法定位問題所在，無法重現問題。開發部將問題踢回去，要求客服部進一步瞭解清楚情況。而客服部認為這些問題應該由開發進一步去搞清楚細節，畢竟客服不懂技術，可能無法跟使用者瞭解清楚情況。於是有些使用者提出來的問題因為客服部和開發部的扯皮，一直懸而未解，直到不了了之……
這樣的情況如何處理？又如何敏捷呢？！
案例3：服務部與開發部的協作
我曾經在某公司的開發部工作，公司也有服務部等其他部門，我們公司當時銷售產品為主，客戶數量有幾千甚至上萬。客戶使用軟體過程當中，自然會遇到很多問題，就會求助於服務部，服務部能解決很多問題，但有時候遇到一些複雜的問題或者程式出錯可能就無法處理，就會轉給開發部處理。
我負責其中一個產品，我是這個產品的開發者。服務部轉發過來的問題通常也是記錄不清的，有時候服務部的同事會直接將使用者的電話轉過來。我不會厭煩這樣的事情，反而是非常喜歡這樣，我很關注使用者使用我們的產品的感受，我會主動找客戶問清楚細節。有時候服務部有一段時間沒有意見反饋過來，我會主動問服務部同事：是不是出了什麼狀況？因為我相信只要軟體有人在用，就不可能沒有問題，沒有問題就意味著沒有人用這個軟體。每次處理完問題後，我都會向服務部的同事通報處理的情況，並告知服務部的同事下次遇到類似問題應該如何跟使用者溝通。開發部不僅僅是我，所有的同事都是這樣的態度工作的，開發部和服務部之間的協作是無縫和良好的。
我能這樣做是因為我人品好、工作態度好嗎？非也，這是因為我有強大的利益驅動，我是按軟體的銷售額拿提成的！終端使用者使用軟體的感受，我當然要關注，我要改善軟體讓軟體更加好賣，我好拿更多提成啊！
好的人品和好的工作態度，當然會幫助工作做得更好更主動，但如果有不合理的部門設定和績效考核辦法，就會逐步將這些“好東西”磨掉，甚至讓好的員工忍受不了選擇離職！合理的部門設定和績效考核辦法，能釋放大家的工作積極性，讓“懶人”變得更加勤勞和主動，同時淘汰掉不合適的員工。
上述三個例子說明了什麼呢？你是屬於哪種情況呢？很明顯，能不能敏捷與公司的某些機制有關係，下面繼續詳解……
2）強矩陣還是弱矩陣？
請看圖：
圖4.2 矩陣式管理
軟體公司一般會分為若干部門，比方說：行政部、財務部、研發部、質量部、銷售部等等。公司越大，有可能部門分得越細，研發類直接相關的部門還可能細分為：專案管理部、需求部、開發部、測試部等。通常部門的劃分標準是根據按工作性質，細分部門的目的是希望術業有專攻，公司老闆希望各部門能越做越專業，各部門各司其職，共同地完成公司的運作。軟體專案需要各類專業人才,包括以下方面的專業人才：需求分析、軟體設計、專案管理、程式設計師、測試工程師、實施工程師、配置管理員、QA等等，這些角色在專案中各司其職，發揮各自的作用，這些角色可能來自不同的部門。對於某位專案成員來說，他又雙重領導，分別是他所在部門的部門經理，還有就是專案中的專案經理。
上述部門及專案架構，就是矩陣式架構，基本上大部分公司都是這樣運作的，但又會分為弱矩陣和強矩陣。
弱矩陣：各人以部門職責為主，各人做好自己的事情就可以了，各人主要對部門經理負責。
強矩陣：各人以專案利益為主，不僅僅完成本崗位的工作，還需要跨職能地工作，只要對專案成功有意義的事情，都鼓勵專案組成員去完成，各人對專案成敗直接負責。
如果你們在開展專案工作中需要經常協調各部門，但經常要浪費很多時間和成本，要求其他部門配合就好像求“阿爺”做事情一樣；如果你們專案工作中某部門的文件輸出是另外一個部門工作的輸入，而這個文件經常成為扯皮的載體；如果專案出了問題領導要問責，各部門引用各自部門職責來相互推卸責任，最後可能會變成流程的錯、過程的錯…… 如果你們有上述情況之一或者是有類似的情況，那麼恭喜你，你們是“弱矩陣”！
如果專案小組成員能在專案經理的帶領下，無論是來自哪個部門，都能為專案的成功出力，都能自覺地做到“跨職能”地工作；如果專案出了問題，我們會認為這是我們的錯，而不是具體某個人或某個部門的錯…… 恭喜你，你們是“強矩陣”！
看上去似乎“強矩陣”比“弱矩陣”更好，其實兩種模式各有特點和適應面：
弱矩陣：
1）流水線生產，適用於穩定的專案或產品。
2）每個人完成自己的工作職責，對崗位負責。
強矩陣：
1）適用於高難度、高挑戰的專案或產品。
2）每個人都對專案成敗負責。
3）每個人除了完成本職工作，還需要跨職能地工作。
很多公司規模比較小的時候，一個人需要完成很多種工作，自然而然就是“強矩陣”；公司慢慢做大後會細分部門，但管理者沒有用某種考核方式來捆綁各部門的利益，就逐步會變成“弱矩陣”。經歷過由小到大的老闆可能都會感嘆，為什麼公司越大效率越低，很可能就是這個原因。
前文的案例1、2，明顯就是按“弱矩陣”的思路來管理企業，結果出現了很多問題，這些問題不是部門職責不清的問題，而是體制出了問題；案例3雖然也劃分了部門，但一個有效的績效考核辦法將大家的利益捆綁。
我們的軟體專案通常都是“高難度”和“高挑戰”，基本上不太可能流水線生產，所以我們更加需要“強矩陣”的管理模式，如果要實踐敏捷，“強矩陣”的管理模式是必須的。不過我也見過有人分享“弱矩陣”下的敏捷實踐，具體我還沒有研究過，我覺得“弱矩陣”下部門內可以部分敏捷，但如果專案需要各部門協調時，“弱矩陣”可能真的無法敏捷。
3）敏捷對團隊文化的要求
下面分享兩個跟團隊文化有關的案例。
案例1：皇帝急太監就是不急！
某專案經理為了專案心急如焚（皇帝急），而其他專案成員表示淡定（太監不急）：你安排任務給我就行了，老子的工作就是完成任務。專案經理很鬱悶，為什麼大家不能主動一點、多承擔一點呢？為什麼只有我急，大家不急？
案例2：“木頭人”團隊
某專案經理和某專案成員一起外出吃午飯，專案經理苦口婆心地跟他說：溝通很重要啊，一個專案的溝通很重要啊，很重要啊…… 如此這般說了很多溝通很重要的大道理，某專案成員一致不吭聲，最多隻是偶爾“嗯”一下，或者點一點頭。專案經理還是私人出錢請專案成員吃飯的呢，他這樣做是有原因的！因為他在實際專案中經常問大家有沒有問題，大家要麼不吭聲要麼就說沒有問題，然後後面專案問題超級多。救命啊，他受不了了，為什麼大家都藏著掖著，不溝通不說話呢！於是他才想出請吃飯這招，但你可以看到請吃飯的溝通效果是怎樣的？
前文提到中國軟體研發人員的幾個特點，如：一塊木頭、機械工人，如果沒有合適的管理方式，特別如果是“弱矩陣”的管理模式，那麼就會放大這些特點，結果就變成上述兩個案例的情況。
敏捷對團隊文化是有要求的，就是：我們要在一條船上！
如果只有專案經理在船上，其他人在其他船上或者是腳踏幾條船，專案情況跟我無關，出問題我就跳船或者換船！這如何敏捷呢？
4）敏捷對薪金待遇的要求
現在到了本文最高潮的部分了，因為我需要你回到幾個“尖銳”的問題，請你根據滿意程度用1-10分對以下三個問題打分：
1）你喜歡這份工作嗎？
2）你的薪金多少？你滿意嗎？
3）你滿意你的老闆嗎？
這三個尖銳的問題，我上現場課程的時候也會問大家，但我不需要大家現場打分，大家給個眼神給我就行了。因為學員們身邊就是他的同事甚至是老闆，他們是不方便當面打分的。但這三個題目，我在網路課程中問出來時，大家打分超級踴躍（因為大家都見不到面，互相不知道是誰），不僅僅是打分，各種抱怨都來了！
歡迎你評論本文時對這三個問題打打分，我想看看三個尖銳問題會不會炸了鍋！
有一次我分享一篇關於敏捷團隊建設的文章中提到“能力更高的人更有責任去推動水平低的同事進步”，結果網路上馬上有人說：憑什麼能力高的要多幹活啊！如果你對這份工作不滿，一直想跳槽只是暫時實施不了；如果你對薪金不滿；如果你對你的老闆不滿（這裡的老闆泛指你的上司及上司的上司，不一定是公司老闆）…… 你會對知識分享感興趣嗎？你會對敏捷感興趣嗎？
如果你是公司管理層，你想實施敏捷，請先用著三個題目自測一下，看看你們員工估計是怎樣的打分（當然你不可能真的讓員工去打分的），如果分數很低，你需要檢討問題在哪裡，強推敏捷並不能提升分數，反而會讓員工更加厭惡公司。
敏捷更多是一種精神層面上的要求，是一種精神文明，但精神文明是建立在一定物質文明的基礎上的。員工得不到尊重，員工的生活得不到保障，溫飽不解決，你跟我談敏捷，就是扯淡！
有機會你可以問問國外實踐敏捷很成功的大師們，能成功實施敏捷的團隊，他們的薪金是怎樣的？一般都是高於業界平均水平的。
但這是在中國啊，我們還有很多中小型企業，薪金可能低於業界平均水平，我們豈不是不能玩敏捷呢？
員工對公司的滿意度，除了來自於薪金，還來自於對公司對每位員工的成長關懷。如果不能讓我們的薪資水平在行業前列，那麼我們就更加應該創造一個可以加速員工成長的工作環境，讓員工可以學到更多賺錢本領，讓員工可以爭取到更高的薪酬。
5）敏捷的本質是什麼？
本系列文章最開始的時候給出了敏捷的“官方”定義，經過幾篇文章鋪墊後，現在可以用簡單的說話小結一下我對敏捷的理解了。
敏捷的核心基礎：我們在一條船上！包括：
1）專案組所有人在一條船上。
2）員工和公司在一條船上。
敏捷的幾個重要特徵：
1）所有人對專案成功負責。
2）所有人直接需求驅動地工作。
3）所有人都需要跨領域地工作。
4）持續交付、迭代前進。
5）小步前進，持續改進。
6）有效、簡單！
本文是系列文章的第4篇，如果你錯過了前面的文章，現在可以補救：
第一篇：敏捷的“官方”定義
連結：http://www.cnblogs.com/umlonline/p/3450032.html
第二篇：敏捷流程框架及敏捷實踐一覽
連結：http://www.cnblogs.com/umlonline/p/3450428.html
第三篇：敏捷在中國的水土不服
連結：http://www.cnblogs.com/umlonline/p/3453930.html
本系列文章已經全部結束，對敏捷感興趣的朋友，請留意其他敏捷文章，謝謝！
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟體研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者
軟體知識原創基地創辦人