經驗對應工作實踐中的問題，下面以拋出問題、思考問題、指定處理措施的方式，介紹具體的實踐經驗。
問題描述 ：產品立項需求比較多，項目周期比較長，需求評審會效率低
問題思考 ：上面問題的根源在產品立項需求比較多，通過跟PD溝通了解到，有多方面的原因
1、從產品業務邏輯上看，業務流程很簡單，不清楚技術實現層面上的工作量，所以只能按照產品的角度進行需求設計
2、從產品功能上看，就是需要這麽多業務支持，不然用戶無法使用
3、好不容易爭取到開發測試資源，這次如果不做，不知道要拖到什麽時候了
處理措施： 添加內部評審環節
措施時間點 ： 內部評審 ······> 立項會?······
措施內容 ：PD組織討論或會議，與服務端、客戶端主管進行內部需求方案評審
1、討論確定方案可行性及工作量
2、確保立項需求內容的開發周期在兩周左右，如果周期過長，進行拆分，分多期叠代，及時進行產品設計更改
註：針對第三點原因，後面項目排期問題解決了，PD就不會有這個顧慮了
問題描述 ：開發任務排期不積極，開發提測時間點不確定，開發進度不可控
問題思考 ：任務排期對後面開發有指導性作用，並且排期過程中，會整體梳理壹遍業務流程及待開發功能點，可以提前發現壹些業務問題，明確開發目標。因為這個環節比較繁瑣，所以壹般開發積極性都不是很高，需要壹個強制性流程幫開發養成任務排期的好習慣
處理措施： 添加任務評審會
措施時間點 ： ······>?架構評審會 ······> 任務評審會 ······> 開發階段?······
措施內容 ：明確開發任務，及計劃時間，評估確認提測時間點
註：任務完整性，及計劃時間的合理性，需要TM把控
問題描述 ：提測質量不好
問題思考 ：開發關註的是功能開發，壹般對自測是抗拒的，或者說自願性很低，所以需要從工具或流程上，保障下自測執行情況
處理措施： 添加冒煙演示環節
措施時間點 ：?······> 聯調自測 ······>? 冒煙演示? ······> 提測?······
措施內容 ：開發當場做功能演示給測試、產品，冒煙用例通過後，準予提測
註：參考了青稞的建議
問題描述 ：項目並行情況嚴重，開發、測試時間不匹配
問題思考 ：項目節奏的問題，主要是對開發、測試資源、當前項目情況沒有比較清晰的認識，導致項目並行情況嚴重，團隊效率降低
處理措施： PM把控項目節奏
措施時間點 ：? PM把控項目節奏 ······>?立項會 ? ······
措施內容 ：根據開發測試資源及項目情況，確定是否立項，及立項時間，這樣可以有效減少項目並行混亂的情況
註：多謝豆腐幹及會員線所有同事對我的信任
上面的問題措施，已經在會員線實施，下面還有幾個問題，只是做了分析，制定措施，還未實踐。
問題描述 ：產品設計文檔質量差，需求設計問題多
問題思考 ：產品內部文檔評審壹般關註主要的業務流程，規範和部分細節方案會有疏漏，可以通過添加流程進行把控
處理措施： 靜態測試
措施時間點 ：······ 立項會 ······> 靜態測試? ······> 需求評審?······?
措施內容 ：針對PRD文件規範及業務邏輯進行檢測，規範PRD文檔，提前發現解決業務邏輯問題，提高需求評審效率
註：參考了菇米的建議