作者 DS

8億用戶的微信是中國歷史上最成功的互聯(lián)網(wǎng)產(chǎn)品，沒有之一。

除了張小龍帶領的微信團隊在產(chǎn)品上極度尊重用戶的需求，保持克制和優(yōu)雅的產(chǎn)品理念。

最重要的就是微信團隊在成立初期就堅定的使用「敏捷」方法，時刻關注組織的「敏捷」性。

「敏捷」到底是什么？

先從字面上理解，顧名思義，「敏捷」一詞包含了兩層含義：

一是「靈活」——檢查調(diào)整，游刃有余；

二是「快速」——天下武功，唯快不破。

什么意思？

張小龍在微信領導力大會上談到：

關于敏捷開發(fā)，我特別希望大家能夠多去做一些嘗試，我們今天可以想一些與眾不同的點子，我們很快把它上線了，然后可以去驗證。

如果不對就下線，如果還有改進余地，下個星期再去改它。這是一個能夠持續(xù)實現(xiàn)你的想法的過程。

這其實就是「敏捷」的原理，既滿足產(chǎn)品開發(fā)過程中需求的動態(tài)變化，又能通過短迭代管理監(jiān)控項目的實時效果。

究其本質(zhì)而言，敏捷管理方法很簡單：就是“檢查與調(diào)整”循環(huán)。

每過一小段時間就停一停手頭的工作，檢查已經(jīng)取得了哪些成果，看看這些成果是不是自己期待的，想想有沒有更好的方法。

這一點看似容易，做起來并非易事，需要企業(yè)愿意改變固有方式，接受敏捷管理方法。

為什么優(yōu)秀的公司都在做「敏捷」？

優(yōu)秀的公司或者說團隊，之所以迫切需要「敏捷」這種新的工作方式。像是微信、京東、華為、通用電氣、Twitter 會一致采用「敏捷」。

原因就在于當前不少公司的開發(fā)項目都會延期超支，而且最后交付的成果還不能用。這明顯是工作方法不得當。

很多項目堅持采用「瀑布法」，堅持每件事都要事先規(guī)劃好，甚至還堅持要求在長達數(shù)年的項目執(zhí)行期之內(nèi)不能做出任何改變，這是非?；闹嚨摹?/span>

一個組織由小變大的過程中通常會出現(xiàn)一些問題，比如：

執(zhí)行力下降；發(fā)布頻率降低；不尊重用戶體驗；片面追求KPI；制造虛榮指標來獲取公司資源；團隊滿意度降低；團隊的能力和創(chuàng)造力受到限；

這一系列大公司病，早期通常被公司管理者忽視而造成極其惡劣的后果。

一些公司的高管更重視營銷，商務合作，文化洗腦而忽視用戶和團隊管理，等到積重難返，后悔不已，但是很難改變，優(yōu)秀人才流失，企業(yè)增長乏力，進入惡性循環(huán)。

「敏捷」方法充分考慮到了可能出現(xiàn)的不確定性因素，同時具有鮮明的創(chuàng)造性。

科普延伸：

《圖解敏捷教練和 ScrumMaster》

《賦能：打造不確定性的敏捷團隊》

這幾句話看起來像是口號，但貫徹得到實踐當中后，確實帶來了和在傳統(tǒng)瀑布模型下開發(fā)軟件截然不同的局面。

它的結構是圍繞著學習過程建立的，這樣一來，團隊既可以評估已經(jīng)取得的成果，同樣重要的是，也可以評估取得這些成果的方法。

這種架構能夠為團隊提供更加高效的工作方式，幫助他們更好地自我組織，提高工作速度，改進工作質(zhì)量。

當下競爭超級激烈，如果不采用一種全新的、能夠更好地回應客戶需求的工作模式，團隊未來可能會經(jīng)營不下去。

這時，只有兩個選擇：要么改變，要么解散。

如何實施「敏捷」？

無論你們的員工多優(yōu)秀，作為領導者，你們都必須確保在員工的能力范圍之內(nèi)，努力改善產(chǎn)品的質(zhì)量和一致性。

因此，第一步就是管理層必須讓員工知道，你們非常熱衷于改善產(chǎn)品的質(zhì)量和一致性，對產(chǎn)品的質(zhì)量具有深刻的責任感。

如果只說不做，那么一切改善都不會出現(xiàn)。行動是最重要的。

1. 聚焦團隊，實現(xiàn)高水平業(yè)績：
提升團隊業(yè)績比提升個人業(yè)績重要得多，卓越團隊的目標遠遠超越了個體的目標，你們的團隊必須擁有完成一個項目所需的全部技能，并且要把項目團隊拆解為一個個小團隊，團隊人數(shù)宜少不宜多。

2. 進行周期性項目管理
把你們項目的工作分解開，看看在一個固定的、短暫的時間段內(nèi)能完成多少工作量。最好以1—4周為一個周期，這個周期稱為沖刺。

沖刺后必須展示成果，讓每個人知悉一切，再做下一個沖刺循環(huán)。

3. 把快樂轉(zhuǎn)化為更高的績效
提升團隊運作的透明度，讓下屬獲得自主感、掌控感和目標感；

在每個「沖刺」階段結束時，讓每位員工找出一個有待改善的地方，在下一階段予以解決，使團隊成員擁有成就感。

員工是否快樂，是預測公司未來業(yè)績的指標，工作原本可以讓人愉悅。

4. 80%的價值來自20%的功能
敏捷的魔力在于能幫你把價值最高、風險最低的的事項優(yōu)先解決。

你需要擬定待辦事項清單，確定優(yōu)先順序，在戰(zhàn)略上著眼于全局，策略上迅速行動。

進行「觀察—導向—決定—行動循環(huán)」。

以上觀點來自，《敏捷宣言》的起草人之一、「Scrum 之父」的 Jeff Sutherland。

工作原本也可以不讓人垂頭喪氣，可以以非常流暢、令人愉悅的方式進行，最大限度的發(fā)揮自由和創(chuàng)造力，獲得高收益的成果。

「敏捷」在 IT 技術部門的延伸是？

眾所周知，「敏捷」延伸到IT部門后，產(chǎn)生了一個從「開發(fā)」到「運維」的跨領域問題，就是這兩年很熱門的「DevOps」

DevOps 的「一個中心，兩個基本點」——以業(yè)務敏捷為中心，構造適應快速發(fā)布軟件的工具（Tools）和文化（Culture）。

《鳳凰項目》，一個關于 DevOps 的故事，一本關于講述 IT人的從普通碼農(nóng)歷練成為 COO 的非勵志小說，一個非虛構的「敏捷」轉(zhuǎn)型故事。

· 如何讓一個幾乎失敗的項目死灰復燃？

· 如何挽救瀕臨拆分拋售的公司？

· 如何化腐朽為神奇？

關于 DevOps 更深度的講解：

《DevOps 轉(zhuǎn)型實踐》

在玩偶實驗室的「開發(fā)運維報告說明」中，為了更好地理解企業(yè)在采用開發(fā)運維各階段的情況和習慣，我們用基準問題測試了 4039 家 IT 企業(yè)。

第一點出人意料的是，在敏捷性性指標（agility metric）和可靠性指標（reliability metric）方面，運用開發(fā)運維的高績效公司遠遠勝過表現(xiàn)平平的同行：

代碼部署頻率快 30 倍；

代碼部署交付期快 8000 倍；

變更成功率高 2 倍；

MTTR（ Mean Time To Repair，平均修復時間 ）快 12 倍；

換言之，他們更為敏捷。他們的部署代碼的頻率快 30 倍，從「代碼提交」到「成功投產(chǎn)運行」的速度快了 8000 倍。

表現(xiàn)突出企業(yè)的交付期以分鐘或小時計算，而表現(xiàn)較差企業(yè)的交付期以周、月甚至季度計算，如此發(fā)展，這些表現(xiàn)差的企業(yè)終究會被淘汰。

當一個團隊在進行「敏捷」變革時，也在顛覆IT人現(xiàn)有的傳統(tǒng)認知，如何讓自己和團隊更加高效？