韓鳳

編者按：

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

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

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

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

對大部分公司來說，敏捷開發(fā)的試運行都極為成功，但如果不對公司結(jié)構(gòu)進行調(diào)整，便很難將敏捷管理從小范圍推廣到所有業(yè)務(wù)單元。

擴大敏捷開發(fā)的實踐范圍

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

這些公司針對一個或是多個運營模型進行了調(diào)整，主要集中在以下四個方面：調(diào)整組織結(jié)構(gòu)，使之轉(zhuǎn)變?yōu)橐援a(chǎn)品為主導(dǎo)；改進業(yè)務(wù)部門與 IT部門的交流；重新定義業(yè)務(wù)部門及IT部門的角色與職能；反思現(xiàn)有預(yù)算及規(guī)劃模型（如表1）。

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

傳統(tǒng)型企業(yè)傾向于根據(jù)應(yīng)用及項目來組織分配IT資源，最終形成之前提到的那種分裂式的產(chǎn)品開發(fā)過程。實際上，公司應(yīng)當以產(chǎn)品為中心來分配IT資源，并將業(yè)務(wù)單元領(lǐng)頭人、開發(fā)人員以及公司內(nèi)其他成員，以一種穩(wěn)定的、面對面的團隊組織形式集中起來，為同一個業(yè)務(wù)結(jié)果而努力。

采用以產(chǎn)品為導(dǎo)向的組織結(jié)構(gòu)

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

一家大型的醫(yī)藥設(shè)備制造商通過調(diào)整組織結(jié)構(gòu)，顯著地縮短了產(chǎn)品上市的時間。如果想在其原有基礎(chǔ)上開發(fā)一個新的軟件或是在現(xiàn)有軟件上增加新功能時，業(yè)務(wù)部門與技術(shù)部門所共享的規(guī)格和技術(shù)要求，可能會有多達20項的交接。領(lǐng)導(dǎo)層意識到，只在單個業(yè)務(wù)單元或特定的幾個產(chǎn)品組里部署敏捷開發(fā)是完全不可行的。

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

加強業(yè)務(wù)部門與IT部門的交流

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

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

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

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

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

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

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

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

重新制定預(yù)算以及規(guī)劃模式

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

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

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

選擇正確的方式

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

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

另外一種極端就是采取爆發(fā)式重組方式。公司將職能部門和業(yè)務(wù)單元規(guī)劃到新的組織結(jié)構(gòu)及新角色中，建立自我管理的敏捷開發(fā)小組，并同時加速業(yè)務(wù)流程。

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

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

來源：麥肯錫網(wǎng)站