拋出問題：醉漢路燈下找鑰匙，但要是根本不在燈下，起始就在你身邊

現狀：我們只看局部，研發過程中PRD是不是符合規范，提單多不多啊，代碼量多不多啊，是不是很忙啊？
我們輸出的數據中匯報的總是開發，產品，測試，看到的是人，看到的是部門維度人力的投入情況，看上去的只是局部的。

影響效率的本質：是需求溝通問題，目標對齊的問題，各部門協作的問題，質量的問題，交付模式的問題，這些問題都不是局部，而正是交付中這種各類的問題，都會導致需求的停滯，價值流動的停滯。

停滯的需求又從更本上損害了研發效能，如何讓需求在流程上更順暢的流動，以流動效率為核心，才是我們應該關注的，才是光該照亮的地方。

組織的終極目標：在動蕩的商業環境下持續的創造價值，持續產生利潤
1：那我們改如何提升效能，持續的交付有效的價值呢？

2：我們以敏捷視角如何做，如何落地呢？
a：精益的核心是減少浪費，減耗提產，平時遇到的浪費問題有哪些呢？

• 價值交付，但未被使用-價值驅動，用戶故事
• 需求傳遞但訴求不清晰-澄清會議
• 需求完成度低-做一半取消、設計方案有大問題導致BUG太多偏離原始訴求，代碼分支問題-專家分析，交互式開發，制定缺陷閉環原則，時間觀念。
• 價值流動緩慢，阻塞-看板
• 缺陷太多-TDD測試驅動開發，通過測試用例來寫代碼。自動化測試。
• 人員流動大，新任務上手難度大-必要的組織資產

b：具體方法論如下圖

RACI
明確權利和責任，明確知情人，因人設事。

提高協同效率
SCRUM模式交付

報漏問題
看板，及時反映問題現象

聚焦價值，4VC && CROI方法

微軟2W1H方法論

故事地圖
要開發的功能總能超出你能投入的開發資源
所以我的建議：
1：聚焦價值傾向決定系統需要什么功能
2：最小化輸出，最大化影響
3：將需求按照價值維度分層，聚焦用戶痛點和合適自己產品的價值維度。

對于產品來說
1：尋找差異化功能，明顯區分于競爭對手
2：攪局功能，別人有我也有
3：提升功能
4：基礎功能
歸根到底的事，解決了誰的痛點，這個‘誰’優先級高不高，他的問題是否是真正存在的，動機是什么，能帶來多大價值（對他自己，對組織，對產品建設）
方式方法論可以采用現成的故事地圖方法，微軟等敏捷大廠都有優秀案例

學習分享型組織
PDCA：復盤會議，組織過程資產沉淀

3：效能提升的終極形態（三步走）

附錄1：
1：看板：
判斷看板的好壞：
1：是否反應端到端的交付過程
2：是否即時體現影響價值流動的瓶頸和問題
3：能否依據可視化信息協作和做決定

2：只有精益的產品創新配合精益的需求管理，得到大家敏捷的協作來持續交付和實踐，才能系統的提升研發效能，提升價值流動速率，提升需求交付吞吐率，提升交付質量。
最終達到利潤、用戶、運營效率以及口碑的增長

3：項目中常遇到的問題，應該都能從本文中找到答案。
a:需求入池標準低，需求池不清晰
b:缺乏用戶故事梳理，用戶訴求引導
c:產品線產品缺乏需求偏向性，不能更好的聚焦
d:需求承接后內部流傳過程不清晰，往往出問題才暴露
e:版本缺乏公示公開途徑和方法
f:組織缺乏精細化管理
g:緊急需求識別互斥或者拆解耦合能力低，組織資產沉淀不足，導致需求前后互斥。影響質量
h:開發人員意識不足分支繁雜亂，很如意出現多軌跡并行，無法及時響應需求變化，影響變更質量
i:沒有中長期規劃，必須做且重要的自研優化和升級到節骨眼上在做，一方面影響版本質量，一方面會影響價值流動。

PS：推薦給大家一個好東西，思路整理專用
https://www.processon.com/diagrams