需求變化太快,快速迭代已經不夠用了
快速迭代不夠快
一提到互聯網產品開發,大家馬上就會想到「快速迭代」,但本文的核心觀點是,「迭代」與是否「快速」並不相關,甚至是相矛盾的。
經典的迭代模式可能需要兩周發布一次,但我們的實際情況是一周要發布兩次,迭代模式明顯不合適。
對於一個正在迭代周期中的團隊,新增的需求如果排在後面的迭代的話,要將近兩周之後才能開始規劃評估,再等兩周之後才能最終上線,對於一個需要快速反應的互聯網團隊而言,這樣顯然太慢了。
通常所謂的「快速迭代」,實際上只是人為地將迭代的周期縮短了而已。我所接觸到的很多團隊已經把迭代看得越來越弱,只保留了定期總結的意義,甚至直接認為團隊並不需要迭代。
所謂迭代
迭代從廣義上來說是指對於特定過程的重複。具體到互聯網產品開發領域,說的是一種項目管理模式。互聯網團隊常用的Scrum模式也好,「小瀑布」模式也好,基礎都是迭代模式,也就是整個團隊不斷重複一個人為設定的過程,分階段達到目標。
一個迭代的開發周期一般設為兩周,模式大概是這樣:
(迭代周期示意圖 - 圖片來源)
為什麼我們喜歡用迭代
迭代模式的核心優勢:
- 使用固定的時間窗以便於協調資源
- 對齊整個團隊的開發流程以促進協作
如果測試、設計、運營資源為整個事業部或者事業群共有,項目管理者必須去預定資源,要「排期」,甚至「PK」,這時候有一個固定的開發周期明顯更靠譜一些。
在迭代內部開發流程是對齊的。團隊先是進入需求評審,然後集體規劃,規劃完畢之後投入開發,迭代結尾一起發布。處在同一個階段的團隊成員更容易溝通,模塊之間相互關聯的部分更容易被照顧到,成員之間還能相互抵消風險。
迭代模式的缺點
人為限定的時間窗不符合實際需要。迭代模式通常約定在固定周期內打包發布一組需求:
(需求按期打包發布示意圖 - 圖片來源)
一個需求的真實開發周期只應該與客觀需要有關,不應該被人為設定的時間窗所限制。時間不足會降低質量,時間過多則降低效率。即使不考慮項目的變更風險,如上圖所示的完美打包和時間窗適配現實中也是很少見的。如果需求之間的關聯性不強的話,本身也沒有必要打包在一起。
迭代模式的管理成本高。為了得到一個靠譜的迭代規劃,項目成員需要做很多的預估工作,迭代進行中要不斷Check整個團隊的進度,一旦有變化就要重新規劃,無法按預期交付的時候就要砍需求,如果需求不能砍的話就要延期,這背後都是各種會議和不必要的相互博弈。
(監控項目進展的燃盡圖 - 圖片來源)迭代模式通常用各種測量方法和變更流程來保證迭代能夠按期交付,但為此付出的成本也是不可忽視的,要整體考慮投入產出比。
迭代模式不能很好地應對變化。由於迭代規劃是在一開始的時候就制定好了,一旦變更就會產生各種成本,所以整個團隊都會傾向於保持原有的計劃,而無論是團隊內部的開發狀態還是外部的商業環境都是在動態變化之中,迭代模式的變更成本會影響團隊的應變能力。
過度承諾導致Buffer膨脹。整個迭代的順利進行依賴於太多假設,由於項目風險客觀存在,很多假設並不能實現,迭代進行得不順利將是常態。如果我們過於在意各個環節的交付時間是否符合預期,那麼引起延期的參與者就會受到指責,導致大家都要為自己的工作留足夠的Buffer以應對風險。
我總結的Buffer膨脹定律:
需求和風險水平不變的情況下,迭代按期交付的概率越高,成本評估中含有的Buffer就越多,團隊整體效率就越低。
去迭代化
互聯網產品的發布成本越來越低,團隊內部的協作關係也更加靈活,組結構織趨向於網狀化。固定的時間周期和統一的開發流程帶來的優勢已經逐漸消減,反而成為團隊響應速度和開發效率的障礙。
所謂去迭代化,包括但不限於以下轉變:
- 項目管理方面:
- 不再設定人為的時間周期,一切以實際需要為準
- 不要將不相關的需求打包在一起
- 減少不必要的規划行為和測量行為
- 聚焦於需求的實際開發質量和流動效率,而非既定規劃的實現程度
- 團隊管理方面:
- 從集體推進到分頭出擊
- 從定期反饋到即時反饋
- 從階段性改進到持續改進
- 產品策略方面:
- 從宏觀規划到局部創新
- 從衝刺式產出到流動式產出
- 業務需求相對分散,不穩定性強
- 發布成本低。比如應用能夠動態更新,不需要地面實施。
- 資源協調成本低,內部溝通充分
- 人員素質高,能夠獨立推動項目
總結
If youre in control, youre not going fast.
迭代模式有其優勢,但不一定適合你的團隊特質和商業環境。一個團隊不能想當然地認為有嚴謹的迭代過程就是管理水平高的體現。管理模式要隨著客觀條件動態演進。去迭代化絕對不是要削弱管理,反而是為了實現管理升級。
我相信管理能力是一個團隊的基礎資源。管理升級促進技術升級,技術升級促進產品升級,產品升級才能適應消費升級背景下的商業競爭。
其它
題圖:Not fast enough sonic (圖片來源)
我們團隊急需高級前端工程師,在這裡查看職位信息,可以在線投簡歷,也可以直接投到我的郵箱zhangxin19@meituan.com。
推薦閱讀:
※【修真院「純潔」系列之二十四】十年敏捷開發Live開始了~
※項目風險如何處理?——看看這三步走的原則
※產品經理如何用「 石墨文檔 」管理項目?
※用戶研究項目管理——研究計劃
※《全面變革》尾聲