一、整體策略思考
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參加） |
| 准入 | 階段性度量報告 |
| 準出 | 改進措施、期限及責任人 |