B端產品雙週迭代交付的思考

一、背景

筆者之前在職一家傳統制造業公司做產品，負責的產品線可以劃分至電商類B端產品，業務體量每週在幾百萬級別。

部門基於交付質量及交付週期的一系列考量，在一個風和日麗的日子，推行雙週迭代。

有點類似敏捷，但實際不是；熟悉敏捷的人都知道，敏捷開發是輕流程輕文件的，其過程曲線是螺旋上升式的；我司施行的迭代實際就是小型的瀑布式專案，按照雙週的節奏進行交付。

二、過去VS現在

簡而言之，過去版本釋出沒有控制節奏，有需求、缺陷完工了就安排上線，視優先順序安排釋出；可能極端的情況是一天發幾次，當然前提是不影響業務正常開展。

現在則是按照約定的節奏，只允許雙週釋出一次，遇到特殊情況則需申請走緊急釋出。

三、過程執行

雙週迭代的大前提下，要求嚴格按照瀑布式的流程來走，具體：

• 需求或缺陷需要從內部系統收集，並且確定承諾解決時間之後進入禪道系統，延期未解決的缺陷或者按照優先順序排出的需求沒上將扣專案KPI；
• 每一次雙週迭代需要在禪道上維護計劃，並關聯相應的版本和需求，版本日期與常規釋出的日期一致，命名需按照規範，否則同上視為不合規，扣合規性KPI；
• 所有需求需要拆解成為方案、開發、測試任務，由不同角色去建立，指派以及跟蹤閉環；如果沒有定義任務的起止日期也將被審計定義為不合格，扣合規性KPI；為每個需求建立測試用例，開發完畢提交測試需建測試單以及關聯用例，缺陷則不需；
• 系統釋出或者資料變更，需要走OA流程發起，並附相應的測試記錄清單，流程審批完之後才能釋出上線；
• 雙週即小專案，該有的需求調研，解決方案設計、設計評審、開發、程式碼評審、整合測試、UAT測試、上線準備、釋出、釋出驗證，一個都不能省。

看起來一整套的流程十分嚴謹，該有的都有了，該連線的都連線了，該監控的都監控了，我們也在短短雙週內做了很多的事情；但實際過程中是總有各種各樣的問題，我們的出發點是平衡需求和運維的完工佔比，嚴控上線缺陷指標；同時在這兩個大前提下控制版本釋出的節奏，促使業務端養成提真正有價值的需求的習慣，把資源用在有價值的事情上。

四、問題顯露

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

如果這個迭代延期了，無疑要佔用下個迭代的時間，導致下個迭代延期，惡性迴圈；即使下個迭代從需求池砍掉需求了，團隊還是感覺吃力，按預期上線似乎是一件很難達成的目標。

我們做過相應調整，但每到釋出節點依舊如通魔咒扣在了頭上，一方面焦慮不已，另一方面陷入釋出還是不釋出的兩難境地；不釋出意味著延期，釋出意味著有bug，欠了技術債。

出來混不就是怕有人說你不靠譜，喊著要你還債麼，團隊情緒難免陷入負面，甚至有時候會抱怨相互之間協同不夠積極，資訊失真或溝通不到位；但好在每次大家都在面對並無逃避，一直在積極尋求改進切入點。

五、問題點分析

作為親身經歷者，做著對內較大體量的產品線發展、交付和維護的工作，也因為雙週敏捷交付屬於值得分析的交付方式。

此間種種背景和現狀，激發了筆者的興趣，就做了一些歸納和思考，丟擲了幾個問題：

1. 計劃層面

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

2）排計劃僅依賴開發人員個人經驗，未記錄歷史迭代的工作情況資料進行參考；需求/bug的數量比例、人員分配未形成經驗教訓資料，開發人員績效沒有進行復盤分析，沒有資料作為指導進行合理調整。

2. 執行層面

1）沒有明確具體迭代責任人

組內多個產品線同時作業，每次釋出計劃開始由產品經理負責，方案或原型確定之後交由開發，中間的過程幾乎是放養狀態。

以致臨近釋出時間點，經常出現這樣的畫面：

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

A：趕緊發測試服啊，說了很多遍提前發啊。B：哦（老系統，釋出挺麻煩）。

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

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

在設計與開發溝工作交替後，大家都各自專心忙著自己手頭的事情，如果沒被指明去管，一般當然是先做好自己的事情。

所以協同出現了問題，導致交付前發現失控；這個我把他歸於管控層面，也就是小組需要一個去監控、統籌大家步調的人，當然這個人擔子不輕。

2）一人身兼多職

產品要做商務談判、專案管理、資料分析、測試等一系列工作，甚至做一些開發相關的工作（極少）。

重點是，還要每週應付各類合規性的檢查、取數和通報；如果同時負責多個產品線和擔任正式專案的專案經理，可想而知了，絕不輕鬆，可能導致的情況是無法專注產品本身，無法對使用者使用關心的重點了解不夠充分。

當然，這裡最大的問題可能在於團隊分工，合理的分工和人員配置才能發揮最大的效率。

3）流程過於形式化

每次釋出需要交付的文件及需登記相應的bug管理系統記錄條目較多，且需要嚴格按照標準執行；比如計劃、版本的命名不能錯，否則扣KPI。

我們應對的措施是每次發版本前，偷偷用SQL語句去檢驗下是否符合標準（無奈冷漠臉）。

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

六、關於改進

推行雙週迭代交付確實給帶來了好處。如釋出的節奏統一了，研供產銷各個IT產品線的節奏幾乎一致；大家也會根據規定的釋出時間點組織系統互動會議，保證釋出不會相互影響。

另外業務部門也認可一整套的需求/缺陷收集、解決、釋出的方式，減少了不必要的溝通；各個流程節點有據可循、有跡可查，PMO和質量人員也都有資料作為統計，指標相對已經很完善，管理層面方便不少。

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

通常解決問題的第一步是找到問題，而後在不斷調整摸索的過程中找到最佳的方法，無視問題才是最大的問題；找到問題點了，方法有很多種，關鍵看組織力和執行力。

筆者提出的改進，【重點】基於以下兩個方面：

1. 最佳化分工

1）每個迭代須有負責人

明確了責任人之後，該責任人對整個過程進行統籌，可以是產品經理、技術經理，也可以是業務人員（懂IT專案過程的最好）；否則每個流程都是獨立行走的機器，最後的交付變成了孤兒，nobody cares，結果就是所有人不甘的淚水。

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

當前對於專案和產品沒有做明確的分工，金額較大的專案，一旦立項，就得走另外一套複雜的流程，需專業的專案經理帶；同時如果又要應對日常流程複雜的雙週迭代交付，工作量可想而知；當然這個跟部門的人員編制有關，也要看機緣去適當擴充人員，如今疫情大環境下，更慎重了。

3）產品設計與專案管理職責區分

一般產品的一期上線之後，宣告本期專案結束，就進入正常的產品線迭代升級期，可以使用雙週迭代的形式推進。

需要注意的是，切忌常以交付專案的思維交付產品，專案管理是過程管理，講究進度、成本、質量的平衡；而產品功能的迭代，更多的要考慮運營部門、關鍵使用者的需求。

在產品規劃、設計、定框架、定型的環節，如果過多被專案管理的思維束縛，做出來的產品通常會不符合預期、不好用，給下後面的迭代埋下難以填補的深坑。

2. 簡化流程

當前的流程，在有限的雙週時間內，無疑是過於冗長的，可適當進行縮減；例如使用PDCA法、ECRS法分析，設定價值點，分析流程節點的價值，沒有存在的意義的節點即可認為是無關緊要的環節，直接去掉，減少無謂的重複工作；另一方面，進行適當分門別類，不搞一刀切，該簡的簡，該繁的繁。

該項實施起來並不容易，因為需要從部門層面去推動，近150號人參與其中的流程，不是說推就推的。

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

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

最後，思考是一切的起點。

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

本文由 @Daylight 原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議