編輯導(dǎo)語：雙周迭代是控制團(tuán)隊(duì)交付節(jié)奏的，但如果沒有運(yùn)行好的話，后續(xù)可能會出現(xiàn)一系列的Bug；怎么控制節(jié)奏，讓產(chǎn)品無缺陷的準(zhǔn)時上線，需要產(chǎn)品經(jīng)理和整個團(tuán)隊(duì)的配合；本文作者分享了關(guān)于B端產(chǎn)品雙周迭代交付的詳細(xì)思考，我們一起來看一下。

一、背景

筆者之前在職一家傳統(tǒng)制造業(yè)公司做產(chǎn)品，負(fù)責(zé)的產(chǎn)品線可以劃分至電商類B端產(chǎn)品，業(yè)務(wù)體量每周在幾百萬級別。

部門基于交付質(zhì)量及交付周期的一系列考量，在一個風(fēng)和日麗的日子，推行雙周迭代。

有點(diǎn)類似敏捷，但實(shí)際不是；熟悉敏捷的人都知道，敏捷開發(fā)是輕流程輕文檔的，其過程曲線是螺旋上升式的；我司施行的迭代實(shí)際就是小型的瀑布式項(xiàng)目，按照雙周的節(jié)奏進(jìn)行交付。

二、過去VS現(xiàn)在

簡而言之，過去版本發(fā)布沒有控制節(jié)奏，有需求、缺陷完工了就安排上線，視優(yōu)先級安排發(fā)布；可能極端的情況是一天發(fā)幾次，當(dāng)然前提是不影響業(yè)務(wù)正常開展。

現(xiàn)在則是按照約定的節(jié)奏，只允許雙周發(fā)布一次，遇到特殊情況則需申請走緊急發(fā)布。

三、過程執(zhí)行

雙周迭代的大前提下，要求嚴(yán)格按照瀑布式的流程來走，具體：

• 需求或缺陷需要從內(nèi)部系統(tǒng)收集，并且確定承諾解決時間之后進(jìn)入禪道系統(tǒng)，延期未解決的缺陷或者按照優(yōu)先級排出的需求沒上將扣項(xiàng)目KPI；
• 每一次雙周迭代需要在禪道上維護(hù)計(jì)劃，并關(guān)聯(lián)相應(yīng)的版本和需求，版本日期與常規(guī)發(fā)布的日期一致，命名需按照規(guī)范，否則同上視為不合規(guī)，扣合規(guī)性KPI；
• 所有需求需要拆解成為方案、開發(fā)、測試任務(wù)，由不同角色去創(chuàng)建，指派以及跟蹤閉環(huán)；如果沒有定義任務(wù)的起止日期也將被審計(jì)定義為不合格，扣合規(guī)性KPI；為每個需求建立測試用例，開發(fā)完畢提交測試需建測試單以及關(guān)聯(lián)用例，缺陷則不需；
• 系統(tǒng)發(fā)布或者數(shù)據(jù)變更，需要走OA流程發(fā)起，并附相應(yīng)的測試記錄清單，流程審批完之后才能發(fā)布上線；
• 雙周即小項(xiàng)目，該有的需求調(diào)研，解決方案設(shè)計(jì)、設(shè)計(jì)評審、開發(fā)、代碼評審、集成測試、UAT測試、上線準(zhǔn)備、發(fā)布、發(fā)布驗(yàn)證，一個都不能省。

看起來一整套的流程十分嚴(yán)謹(jǐn)，該有的都有了，該連接的都連接了，該監(jiān)控的都監(jiān)控了，我們也在短短雙周內(nèi)做了很多的事情；但實(shí)際過程中是總有各種各樣的問題，我們的出發(fā)點(diǎn)是平衡需求和運(yùn)維的完工占比，嚴(yán)控上線缺陷指標(biāo)；同時在這兩個大前提下控制版本發(fā)布的節(jié)奏，促使業(yè)務(wù)端養(yǎng)成提真正有價值的需求的習(xí)慣，把資源用在有價值的事情上。

四、問題顯露

實(shí)行了約兩個多月之后，我們遇到了很頭疼的問題：總是在上線的前1天有問題遺留，無法按時解決；或者磕磕絆絆解決完，上線后質(zhì)量堪憂，欠下技術(shù)債，又要在下個迭代預(yù)留時間來解決。

如果這個迭代延期了，無疑要占用下個迭代的時間，導(dǎo)致下個迭代延期，惡性循環(huán)；即使下個迭代從需求池砍掉需求了，團(tuán)隊(duì)還是感覺吃力，按預(yù)期上線似乎是一件很難達(dá)成的目標(biāo)。

我們做過相應(yīng)調(diào)整，但每到發(fā)布節(jié)點(diǎn)依舊如通魔咒扣在了頭上，一方面焦慮不已，另一方面陷入發(fā)布還是不發(fā)布的兩難境地；不發(fā)布意味著延期，發(fā)布意味著有bug，欠了技術(shù)債。

出來混不就是怕有人說你不靠譜，喊著要你還債么，團(tuán)隊(duì)情緒難免陷入負(fù)面，甚至有時候會抱怨相互之間協(xié)同不夠積極，信息失真或溝通不到位；但好在每次大家都在面對并無逃避，一直在積極尋求改進(jìn)切入點(diǎn)。

五、問題點(diǎn)分析

作為親身經(jīng)歷者，做著對內(nèi)較大體量的產(chǎn)品線發(fā)展、交付和維護(hù)的工作，也因?yàn)殡p周敏捷交付屬于值得分析的交付方式。

此間種種背景和現(xiàn)狀，激發(fā)了筆者的興趣，就做了一些歸納和思考，拋出了幾個問題：

1. 計(jì)劃層面

1）需求和問題數(shù)量難以平衡：每迭代前評估需求進(jìn)入數(shù)量，需求數(shù)+bug數(shù)的工作量=現(xiàn)有可用人天的工作量，但通常很常見的情況是——迭代中間有很多需求插入進(jìn)來，比如某領(lǐng)導(dǎo)要求的，組織架構(gòu)變化，搞活動等等；通常這種插入的需求，要不拆分迭代，要不加班完成；這兩種處理方式都對原先制定的迭代計(jì)劃產(chǎn)生或多或少的影響，越晚提出的影響越大，越難有效的控制執(zhí)行效果。

2）排計(jì)劃僅依賴開發(fā)人員個人經(jīng)驗(yàn)，未記錄歷史迭代的工作情況數(shù)據(jù)進(jìn)行參考；需求/bug的數(shù)量比例、人員分配未形成經(jīng)驗(yàn)教訓(xùn)數(shù)據(jù)，開發(fā)人員績效沒有進(jìn)行復(fù)盤分析，沒有數(shù)據(jù)作為指導(dǎo)進(jìn)行合理調(diào)整。

2. 執(zhí)行層面

1）沒有明確具體迭代責(zé)任人

組內(nèi)多個產(chǎn)品線同時作業(yè)，每次發(fā)布計(jì)劃開始由產(chǎn)品經(jīng)理負(fù)責(zé)，方案或原型確定之后交由開發(fā)，中間的過程幾乎是放養(yǎng)狀態(tài)。

以致臨近發(fā)布時間點(diǎn)，經(jīng)常出現(xiàn)這樣的畫面：

A：xx需求做完了嗎？B：做完了。

A：趕緊發(fā)測試服啊，說了很多遍提前發(fā)啊。B：哦（老系統(tǒng)，發(fā)布挺麻煩）。

A：這個需求怎么這么多bug，您沒有自測過嗎？！有沒有按照方案來啊。

A：xx需求可以測試了嗎？B：兄弟，你的那個需求還沒開始做呢，臨時去修一個bug了，要找好幾個組的人協(xié)調(diào)，不好弄啊（哭泣臉）。 A：（一臉驚恐）。

在設(shè)計(jì)與開發(fā)溝工作交替后，大家都各自專心忙著自己手頭的事情，如果沒被指明去管，一般當(dāng)然是先做好自己的事情。

所以協(xié)同出現(xiàn)了問題，導(dǎo)致交付前發(fā)現(xiàn)失控；這個我把他歸于管控層面，也就是小組需要一個去監(jiān)控、統(tǒng)籌大家步調(diào)的人，當(dāng)然這個人擔(dān)子不輕。

2）一人身兼多職

產(chǎn)品要做商務(wù)談判、項(xiàng)目管理、數(shù)據(jù)分析、測試等一系列工作，甚至做一些開發(fā)相關(guān)的工作（極少）。

重點(diǎn)是，還要每周應(yīng)付各類合規(guī)性的檢查、取數(shù)和通報；如果同時負(fù)責(zé)多個產(chǎn)品線和擔(dān)任正式項(xiàng)目的項(xiàng)目經(jīng)理，可想而知了，絕不輕松，可能導(dǎo)致的情況是無法專注產(chǎn)品本身，無法對用戶使用關(guān)心的重點(diǎn)了解不夠充分。

當(dāng)然，這里最大的問題可能在于團(tuán)隊(duì)分工，合理的分工和人員配置才能發(fā)揮最大的效率。

3）流程過于形式化

每次發(fā)布需要交付的文檔及需登記相應(yīng)的bug管理系統(tǒng)記錄條目較多，且需要嚴(yán)格按照標(biāo)準(zhǔn)執(zhí)行；比如計(jì)劃、版本的命名不能錯，否則扣KPI。

我們應(yīng)對的措施是每次發(fā)版本前，偷偷用SQL語句去檢驗(yàn)下是否符合標(biāo)準(zhǔn)（無奈冷漠臉）。

能語句話的話自然最好，不能轉(zhuǎn)換成語句的就容易踩雷，得靠自己強(qiáng)行記憶了；一旦有新的流程或者標(biāo)準(zhǔn)出來，都需要不小的學(xué)習(xí)成本，尤其是對新兵蛋子來說很要命——流程太長太難理解，不實(shí)際參與迭代很難消化。

六、關(guān)于改進(jìn)

推行雙周迭代交付確實(shí)給帶來了好處。如發(fā)布的節(jié)奏統(tǒng)一了，研供產(chǎn)銷各個IT產(chǎn)品線的節(jié)奏幾乎一致；大家也會根據(jù)規(guī)定的發(fā)布時間點(diǎn)組織系統(tǒng)交互會議，保證發(fā)布不會相互影響。

另外業(yè)務(wù)部門也認(rèn)可一整套的需求/缺陷收集、解決、發(fā)布的方式，減少了不必要的溝通；各個流程節(jié)點(diǎn)有據(jù)可循、有跡可查，PMO和質(zhì)量人員也都有數(shù)據(jù)作為統(tǒng)計(jì)，指標(biāo)相對已經(jīng)很完善，管理層面方便不少。

筆者上面提到的是雙周迭代辦法執(zhí)行時面臨的一些坑和問題，讓工作的人不爽，工作的結(jié)果差強(qiáng)人意，不能說它是一個完全適合、高效的辦法。

通常解決問題的第一步是找到問題，而后在不斷調(diào)整摸索的過程中找到最佳的方法，無視問題才是最大的問題；找到問題點(diǎn)了，方法有很多種，關(guān)鍵看組織力和執(zhí)行力。

筆者提出的改進(jìn)，【重點(diǎn)】基于以下兩個方面：

1. 優(yōu)化分工

1）每個迭代須有負(fù)責(zé)人

明確了責(zé)任人之后，該責(zé)任人對整個過程進(jìn)行統(tǒng)籌，可以是產(chǎn)品經(jīng)理、技術(shù)經(jīng)理，也可以是業(yè)務(wù)人員（懂IT項(xiàng)目過程的最好）；否則每個流程都是獨(dú)立行走的機(jī)器，最后的交付變成了孤兒，nobody cares，結(jié)果就是所有人不甘的淚水。

2）盡量避免每個人身兼多個角色

當(dāng)前對于項(xiàng)目和產(chǎn)品沒有做明確的分工，金額較大的項(xiàng)目，一旦立項(xiàng)，就得走另外一套復(fù)雜的流程，需專業(yè)的項(xiàng)目經(jīng)理帶；同時如果又要應(yīng)對日常流程復(fù)雜的雙周迭代交付，工作量可想而知；當(dāng)然這個跟部門的人員編制有關(guān)，也要看機(jī)緣去適當(dāng)擴(kuò)充人員，如今疫情大環(huán)境下，更慎重了。

3）產(chǎn)品設(shè)計(jì)與項(xiàng)目管理職責(zé)區(qū)分

一般產(chǎn)品的一期上線之后，宣告本期項(xiàng)目結(jié)束，就進(jìn)入正常的產(chǎn)品線迭代升級期，可以使用雙周迭代的形式推進(jìn)。

需要注意的是，切忌常以交付項(xiàng)目的思維交付產(chǎn)品，項(xiàng)目管理是過程管理，講究進(jìn)度、成本、質(zhì)量的平衡；而產(chǎn)品功能的迭代，更多的要考慮運(yùn)營部門、關(guān)鍵用戶的需求。

在產(chǎn)品規(guī)劃、設(shè)計(jì)、定框架、定型的環(huán)節(jié)，如果過多被項(xiàng)目管理的思維束縛，做出來的產(chǎn)品通常會不符合預(yù)期、不好用，給下后面的迭代埋下難以填補(bǔ)的深坑。

2. 簡化流程

當(dāng)前的流程，在有限的雙周時間內(nèi)，無疑是過于冗長的，可適當(dāng)進(jìn)行縮減；例如使用PDCA法、ECRS法分析，設(shè)置價值點(diǎn)，分析流程節(jié)點(diǎn)的價值，沒有存在的意義的節(jié)點(diǎn)即可認(rèn)為是無關(guān)緊要的環(huán)節(jié)，直接去掉，減少無謂的重復(fù)工作；另一方面，進(jìn)行適當(dāng)分門別類，不搞一刀切，該簡的簡，該繁的繁。

該項(xiàng)實(shí)施起來并不容易，因?yàn)樾枰獜牟块T層面去推動，近150號人參與其中的流程，不是說推就推的。

在制定流程過程中，但凡不同的角色充分參與了，也不至于干起活來這么痛苦；當(dāng)然有的人就是即使被叫過去了，也沒有利用好參與者的角色。

所以部門層面去發(fā)動、制定流程，相對而言，至少能解決大部分人的痛點(diǎn)；更重要的是很多經(jīng)驗(yàn)不是一蹴而就的，更多的是從負(fù)面的經(jīng)歷獲取的經(jīng)驗(yàn)值更高，這也是激發(fā)我寫這篇文章的初衷。

最后，思考是一切的起點(diǎn)。

以上，歡迎留言討論指正。

本文由 @Daylight 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議