摘要：

敏捷不是靈丹妙藥，不能當飯吃！這是本系列文章最后一篇，我們將會談談敏捷對組織架構、團隊文化的要求，特別是對薪金待遇的要求！最后根據我的個人理解，給出我對敏捷的定義。

?

本文大綱：

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大戰需求分析》作者

軟件知識原創基地創辦人

轉載于:https://www.cnblogs.com/umlonline/p/3456098.html

總結

以上是生活随笔為你收集整理的神马是敏捷？（4）——敏捷不能当饭吃的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。