“敏”于思“捷”于行的團隊管理模式

韓鳳

編者按：

敏捷軟件開發又稱敏捷開發，是在一個既定的時段內將本應由一個項目組完成的獨立產品開發任務切分成若干個有關或無關的任務，并行或迭代開發。相對于“非敏捷”而言，“敏捷”開發更強調程序開發團隊與業務專家之間的緊密協作、面對面的溝通、緊湊而自我組織型的團隊、能夠很好地適應需求變化的團隊組織方法。因其更注重軟件開發過程中“人”的作用，人們也將敏捷開發的理念應用于組織管理當中。

許多數碼公司通過在業務部門實行敏捷軟件開發方法，迅速設計與開發出產品的新功能，引入消費者參與測試，并在快速迭代中完成產品更新。但是，若想將敏捷開發推行到多個業務單元，則需要重新思考基礎步驟、公司結構以及各部門間的關系。

相反，只有極少數同時擁有線上及線下業務的公司，會在其主要的產品和應用開發團隊中采用敏捷開發方式。盡管許多銀行已經成立數字部門以加速推出移動端應用及網站功能，但是這些數字部門從行政結構及策略布局上，通常與IT部門以及公司其他部門相對獨立。

阻止傳統型公司推行敏捷開發模式的原因有很多，但我們認為最主要的障礙是其現存的運營模式及組織結構。大部分傳統型公司的產品開發依舊保持著分散和復雜的狀態：一家需要在網站上搭建新功能的公司，會啟動一個涉及多部門的開發流程，而每個部門都只能負責流程中的幾項任務。比如：一支團隊專注于前端應用開發，另一支團隊負責更新相關服務器和數據庫，可能還有一支團隊負責協調系統前后端對接。

對大部分公司來說，敏捷開發的試運行都極為成功，但如果不對公司結構進行調整，便很難將敏捷管理從小范圍推廣到所有業務單元。

擴大敏捷開發的實踐范圍

為了更好地理解大規模部署敏捷開發的障礙，我們對13家公司進行了深入調研，它們涉及金融服務、醫療保健、電子通信等多個行業，且正處于大規模部署敏捷開發的不同進程中，部分推進較快的公司已在其60%或更多的創新活動中采用了敏捷開發。

這些公司針對一個或是多個運營模型進行了調整，主要集中在以下四個方面：調整組織結構，使之轉變為以產品為主導；改進業務部門與 IT部門的交流；重新定義業務部門及IT部門的角色與職能；反思現有預算及規劃模型（如表1）。

敏捷開發的優越性已廣為人知。在敏捷開發方式下，IT部門、產品開發者與業務部門共同創造產品和服務，而非簡單地將功能要求匯總起來，直接丟給后方。不同團隊可以利用極簡版的可行性產品進行實驗、測試并從中學習，最終在幾天或幾周內便開發出新的軟件功能，而無需花費幾年時間。

傳統型企業傾向于根據應用及項目來組織分配IT資源，最終形成之前提到的那種分裂式的產品開發過程。實際上，公司應當以產品為中心來分配IT資源，并將業務單元領頭人、開發人員以及公司內其他成員，以一種穩定的、面對面的團隊組織形式集中起來，為同一個業務結果而努力。

采用以產品為導向的組織結構

在大規模的敏捷開發環境中，“產品”不應被狹隘地定義為商業產品，它們也包括不同產品的組合，比如薪資管理服務，或者客戶體驗，或者一個產品團隊共用的IT系統。因此對業務部門和IT部門的領導者來說，重新定義部門承擔的責任非常重要。當產品被重新歸類后，公司必須派出一支或是幾支專門的敏捷開發小組，來負責這些產品的開發與維護。

一家大型的醫藥設備制造商通過調整組織結構，顯著地縮短了產品上市的時間。如果想在其原有基礎上開發一個新的軟件或是在現有軟件上增加新功能時，業務部門與技術部門所共享的規格和技術要求，可能會有多達20項的交接。領導層意識到，只在單個業務單元或特定的幾個產品組里部署敏捷開發是完全不可行的。

2015年，該公司調整了產品所有權模式，使來自業務部門的產品負責人可以直接向敏捷開發團隊提出軟件要求，而無需通過多個部門來傳遞。結構上的調整促進了好幾個敏捷操作團隊的形成。這些根據角色或話題組織起來的小組，對公司大規模推行敏捷開發起著至關重要的作用。他們能夠鼓勵團隊成員分享各自擅長的專業知識，促進團隊與職能部門的合作，并且持續推進團隊成員的業務進步。

加強業務部門與IT部門的交流

大部分傳統企業中，來自業務部門的負責人在軟件開發過程中參與有限，僅在被問及時才提出意見。為了彌補該負責人的參與不足，IT部門通常會派出一個代表作為產品負責人。這種安排在短期內會比較有效，但是會損害產品和項目的長期成功。

由于組織結構的原因，IT部門的負責人通常并不直接與用戶打交道，也無最終決定權。由于項目缺少方向性指導，工作項目優先級不明確以及責任人缺失，敏捷開發便無法進行下去，整個團隊也面臨著重復工作和資源浪費的問題。

相反，一個強大的產品負責人對產品相關問題、與客戶的關系以及客戶本身都有深入的了解，并有權做出快速決策，以便提高效率，減少在開發過程中遇到的瓶頸。

一家提供“軟件即服務”的公司一直被如何將產品更快地推向市場困擾。這家公司存在著IT部門與業務部門決策緩慢、溝通不暢的問題，經常一年才能推出一到兩個產品。2014年，該公司實施了一個三層的產品擁有權架構，由一個首席產品負責人帶領一個產品區塊，一個高級產品負責人帶領一條產品線，以及多個產品負責人與迭代式增量軟件開發團隊合作。

在這個新的結構下，IT部門和業務部門之間的交流有了顯著改善。溝通更加清晰，公司也能夠更快地做出決策，并保持產品團隊間的一致性以及緊密合作。也是由于結構上的調整，這家公司每個季度都能向市場推出新的軟件產品，有時甚至每月都推出新產品。

重新定義管理層角色與職責

在被調研的公司中，有半數公司都針對敏捷開發的獨特要求，重新定義了原有開發模式下經理層的角色以及職責。在原來的開發模式下，項目經理通常要在應用開發團隊、數據庫團隊及其他團隊間協調不同的任務。而在敏捷開發操作下，涉及的任務以及需要協調的事務都被最小化。問題會被產品負責人或是敏捷開發團隊自行解決。原來由直線經理所負責的與開發流程相關的任務，現在都由自我管理、以產品為中心的敏捷開發團隊自行解決了。

這些在大范圍內推行敏捷開發并取得成效的公司，流程都極為透明公開。他們向團隊成員提供了清晰的指導，詳細說明決策的達成方式。責任界限劃分清晰，團隊成員被賦予適當責任，同時也避免惡意行為或是全權委托造成過大的風險。

重新制定預算以及規劃模式

IT部門通常都會有年度預算以及規劃周期，在不同項目之間平衡預算極為痛苦，也有可能帶來很大程度的重復勞動以及資源浪費。這種模式對于想要大規模實施敏捷管理的公司來說幾乎就是個詛咒。

歐洲一家大型保險公司重新調整了預算制定的過程，將預算用途分成三類：一個由業務部及IT部門經理組成的開發委員會，每月定期會面，以決定新項目是否該執行；首席產品負責人負責資金的具體分配和調整，以便在新的商業機遇出現時能夠快速做出決定；產品負責人的主要職責是滾動式地審查預算，保證軟件開發能夠在40小時的工作框架中得到執行，維護任務及產品待辦列表得到管理。預算制定過程調整后，該公司在預算方面的靈活性大大提高，并且加快了對市場的反應速度。

有不少公司甚至嘗試風投模式的預算。初始資金能夠極快地批準給極簡的可行產品，然后根據客戶的初級反饋進行調整后再次推向市場。而接下來是否繼續提供資金支持，則要根據這些極簡可行產品在市場上的表現來決定。風投模式的預算使公司能在早期就消滅掉那些沒有潛力的產品。

選擇正確的方式

改革運營模式是一項大工程，需要考慮一些較大的風險以及短期內對日常工作的干擾。就像其他的管理行為調整一樣，向敏捷管理轉變也需要不同級別、不同職能的部門與業務單元的長期付出與承諾。

一種極端的情況是，部分公司采用了實驗室方式。 這種方式對那些暫時只有部分高層支持實行敏捷管理的公司來說比較明智，它能夠迅速證明其商業理由，以便讓敏捷管理獲得更大規模的推廣。然而，為采用實驗室方式而單獨建立起來的敏捷開發部門，依舊傾向于自成一派，未能在整個公司內部形成更大的影響。

另外一種極端就是采取爆發式重組方式。公司將職能部門和業務單元規劃到新的組織結構及新角色中，建立自我管理的敏捷開發小組，并同時加速業務流程。

兩個極端方式之間則為棘波方式。在這種方式下，小團隊被分批次轉化為敏捷開發團隊，而公司整個運營模式按照不同階段進行轉化。舉例來說，一家大型技術服務公司想要快速提高其數字化能力，決定將產品開發團隊分為5個批次轉化為敏捷開發團隊。第一批次培訓并部署了5個團隊，而第二批次安排了20個團隊。當這些團隊接連被轉化至敏捷開發操作后，收到的反饋以及培訓資料將被改進并用于下一批次團隊。

在完成敏捷開發轉化6個月后，這家公司采用了以產品為中心的組織架構，將業務部門領導、開發者、工程師以及IT部門的其他成員組織到不同的“部落”中。又過去幾個月后，公司運營模式開始又一層級的調整，重點調整IT部門與業務部門的交流。由于運行模式發生改變，使得產品開發組能夠與IT操作團隊緊密合作。經過上述一系列調整之后，產品推向市場的速度顯著提高，更因為不同團隊共同參與和創造了產品，產品缺陷以及返工現象也明顯減少。 責編/張曉莉

來源：麥肯錫網站