一、整體政策思考
1. 了解問題
首先,面對問題需要了解這個問題的場景,搞清問題背後的原因到底是什麼,這對于解決問題來說是關鍵前提條件。那麼就需要對問題相關的幹系人進行溝通,換位思考,以尋求最優解決方案。
2. 明确目的
遇到問題不可怕,可怕的是并不知道這個問題到底帶來什麼影響,隻是主觀上認為這是問題,那就無從評估其嚴重性,結果就是很大可能花了大精力隻解決了一個很小的問題,沒有帶來實際的價值。是以,也要在解決問題之前,思考清楚目的是什麼,為什麼要這麼做,成本和收益關系如何,再做下一步執行決策。
3. 溝通引導
出現問題往往是因為雙方立場不同、目标不一緻而導緻的,是以想要更好地解決問題,就要從目标一緻的視角出發去與當事人溝通,在互相尊重、盡可能說清雙方的困難并引導互相了解的基礎上,使雙方能夠達成共赢的目标,再去交流解決方案直到達成協定會更加高效。
4. 賦能組織
将遇到過的問題總結經驗,舉一反三,從點到面去形成可複制的方法論,在團隊内外進行分享與交流,幫助更多的團隊解決實際問題。
二、問題解法及實施
上面講的是一些面對問題時思考的通用方法,在理清思路後,下面就來看看那幾個常見問題的解法吧!
1. 明确業務規劃
當團隊回報不太了解業務規劃時,這是一個需要特别警示的資訊,因為當一個團隊沒有明确方向的時候,後續的執行也會出現很大偏差,導緻組織的低效。其背後的原因可能是管理層資訊下達不夠,也可能是團隊之間的目标并沒有橫向拉通隻局限于關注自己這部分事情而導緻。
解決方案可以是通過定期召開業務規劃會,聚焦季度或半年核心心事件、目标及資源配置設定原則,各團隊TL在會上充分達成一緻,會後堅決執行,将政策拆解成産品需求疊代進行規範化管理。建議可與BI團隊協同,在團隊定期會議上回報業務目标進展及近期上線的核心産品功能資料效果,做到有規劃、有回報,這是建立團隊間信任的一個非常好的方式。此外,也可以通過OKR目标管理的方式,使上下遊協同的團隊在目标層面進行橫向拉通,彼此在共同的目标下制定政策方案,定期回顧或調整目标以確定團隊整體方向在主線上正常運作。
2. 客戶傳遞周期提效
客戶傳遞周期是指産品需求從評審到釋出的周期時間。一般提出“客戶傳遞周期比較長”的問題時,可能并不是周期長短的問題,而是在整個産品疊代生命周期過程中協同不順暢的問題導緻了體感上覺得周期長,是以也需要具體問題具體分析。
常見的解決方案是通過梳理産品需求評審到釋出的關鍵裡程碑,定義裡程碑的标準,制定版本疊代的計劃與節奏,界定職責分工,讓各團隊養成相對穩定的節奏,步調一緻,以此來幫助上下遊更高效地協同。産品疊代生命周期關鍵裡程碑通常為評審、設計、開發、測試、內建(代碼當機封版)、釋出,可根據團隊現狀和具體問題進行更加細化的标準制定。
需要注意的是,當一個産品疊代的裡程碑規劃好後,同時也要關注前後疊代的上下并行情況,不合理的并行會導緻更加低效的傳遞,可以參考以下兩個關鍵邏輯來減輕并行對團隊的影響:
1)目前疊代啟動開發時,下一個疊代可啟動評審(這裡的評審指的是隻需TL層參加的初次評審會,明确需求價值及技術可行性,不需一線同學參加。經過初次評審會的需求則進入設計階段,在召開細節評審會後确定需求排期)。
2)目前疊代完成內建(代碼當機封闆)時,下一個疊代可啟動開發。

疊代并行裡程碑規劃示意圖
是以,當多個産品疊代裡程碑規劃好後,各團隊會明确自己在不同階段要做的事情,養成疊代節奏感,再通過制定協同機制,監督執行過程,記錄關鍵效能資料及分析問題的手段來不斷提升客戶傳遞周期效率。
3. 維護協同秩序
針對前面講到關鍵裡程碑的規劃,那麼問題來了,裡程碑規劃後,如何使團隊很好地執行而不是多次被延期呢?舉個例子,大家都知道高鐵的乘車規則,提前10-15分鐘集中進站檢票,按時發車,遲到的人隻能承擔退改簽的成本。同理,為了能夠保障關鍵裡程碑按時完成傳遞,除了制定規則機制外,還需要借助平台去進行系統化管理,以確定機制是可執行、可落地的。
常見的工具有:
1)産品需求管理平台
主要用于需求管理及缺陷管理,可通過當機需求池來管理變更,也可配合看闆建立開發任務跟進研發測試過程,并自動生成資料報表。
2)研發內建與釋出平台
主要用于APP開發項目管理、版本內建管理及釋出管理,通過平台卡口管理品質及過程效率,對于品質不達标或晚于內建當機時間的需求,觸發上級審批流程加以管控,同時度量大盤可生成版本次元的資料報告。
三、效果提升
通過機制和平台組合拳,統一團隊階段性目标,以上在團隊試行二至三個産品疊代後,上述問題得到了很大的改善效果,以近期賦能的大麥網APP用戶端為例,經過改進,可在産品規劃的方向上明确每個版本疊代的需求範圍,APP版本固定在每三周釋出一次,同時也改善了內建品質,子產品一次內建成功率從50%提升至80%,團隊整體對問題影響面的評估意識有所提升,不再一有問題就阻礙釋出,連續多個版本緊急內建次數為零,灰階釋出周期也從3天下降到0.5天。
四、關鍵沉澱
最後,簡單整理了産品疊代生命周期的關鍵裡程碑目的及主要标準,細節之處可以根據不同的組織進行個性化定制,關鍵在于從問題出發,通過有資料支撐的不斷過程改進,使團隊之間更加信任彼此,高效協同,切實幫助組織提效。
産品疊代生命周期關鍵裡程碑目标及标準:
啟動
需求規劃 | |
---|---|
目的 | 明确業務近期重點、核心目标及資源配置設定原則 |
工具 | 産品規劃會議(各團隊TL層參加) |
準入 | 産品規劃文檔 |
準出 | 結論明确的會議紀要 |
産品内審 | |
---|---|
明确單個産品疊代内的需求及優先級 | |
産品需求管理平台 | |
需求與規劃方向一緻,目标或價值明确 | |
由産品負責人負責稽核及輸出需求優先級 |
計劃
需求初評 | |
---|---|
對需求價值各團隊TL達成一緻,初步評估技術可行性 | |
初評會議(各團隊TL參加) | |
需求目标或價值明确,具備Demo或線框圖 | |
價值及可行性達成一緻的會議紀要 |
互動設計 | |
---|---|
按需求初評範圍完成互動及視覺設計 |
可行性
需求細評 | |
---|---|
對需求實作各團隊達成一緻 | |
細評會議(相關團隊一線同學參加) | |
需求互動及視覺稿,完整的PRD文檔 | |
通過細評的需求清單及完善的會議紀要 |
确定排期 | |
---|---|
細評後由技術TL在1-2個工作日回報确認排期 |
執行
需求研發 | |
---|---|
按排期完成指定需求的研發,確定自測品質,按時提測 |
需求測試 | |
---|---|
按排期完成指定需求的測試,確定需求品質 |
內建(代碼)當機 | |
---|---|
對代碼變更送出內建限期完成,以保證按時釋出 |
灰階釋出 | |
---|---|
用于少量使用者更新更新,收集問題後快速修複 |
正式釋出 | |
---|---|
将通過灰階釋出驗證的安裝包,傳遞至全量使用者進行更新更新 |
監控
目标進展 | |
---|---|
針對每個需求進行上線後的目标追蹤及回報,引導業務調整政策 |
關鍵裡程碑 | |
---|---|
對關鍵裡程碑進展及效果進行過程監控,確定按時、按質傳遞 |
過程品質及效率 | |
---|---|
對過程品質及效率監控,記錄問題,指引改進 |
收尾
度量報告 | |
---|---|
用資料回報結果目标趨勢及過程問題,分析原因,指引改進 |
複盤改進 | |
---|---|
聚焦問題,改進過程 | |
複盤會議(各團隊TL參加) | |
階段性度量報告 | |
改進措施、期限及責任人 |