>>>背景
2015年6月剛到平安社交金融平臺產品天下通時，通過和產品經理和開發工程師溝通，發現在版本開發的過程中存在一些問題，產品經理比較困惑的是不管提什么需求，讓開發人員進行評估，開發人員都給出了一個非常大的工作量，后續版本進度也經常延期。
開發人員更是一肚子怨氣，產品經理給出的都是一句話需求，無法進行分析和評估，逼得緊了，就隨便給出一個工作量估計。
這些歸根到底都是是產品和開發人員之間溝通的問題，產品經理沒有想辦法讓開發人員“聽懂”自己的需求，有效溝通首先要求產品經理能將需求描述清楚，其次要能準確無誤地將信息傳遞到開發人員并確保開發人員正確理解。
>>>基于場景組織產品策劃案
平安科技原來是一個傳統的金融IT公司，很多產品經理在組織策劃文案時，按照原來的模板來進行，基本上是按照功能來進行羅列，Android和IOS前端開發人員看了后，還是不知道界面要開發成什么樣子。
對于移動App，針對某個的功能，都是有一個特定的使用場景的。如對于天下通“問理財”應用，用戶在碰到股票或保險的問題時，需要咨詢某位專家，他會打開天下通App，點“專家”tab頁，查找到某位專家后，開始對話咨詢。
如果所有的策劃文案按照場景進行組織，配以交互圖，講解起來就會順暢很多。經過實踐后，開發人員反饋，這種按照場景的組織方式比按照功能進行組織的方式要好。
>>>反串講
在組織策劃案集中評審時，產品經理在費力的講解，給開發測試工程師傳遞自己想要什么。但開會時，與會者帶電腦的情況非常普遍，很多人埋頭盯著屏幕，不知道到底有沒有在傾聽，有沒有理解。散會后，到估工作量時，發現很多細節還是不清楚。
為了改變這種現狀，采用了“反串講”的形式，產品經理在講解完后，讓開發人員來再講解一遍，產品經理作為評判方，看開發人員所理解的是不是自己所想要的。
為了確保信息傳遞效果，反串講這種能獲取信息接收方積極反饋的雙向溝通效果較好，可以應用到有比較多復雜細節的產品需求講解中。
>>>工作量分解
原來的工作量估計的粒度很大，一方面是產品經理沒有能將需求澄清清楚，另外一個很重要的原因，開發工程師沒有對需求進行分解。粒度太大，不利于制定工作計劃以及后續的計劃監控。
因此，強制要求開發工程師必須對工作量進行分解，細化到2~3人天的粒度并具體到開發責任人。
分解的過程實際上也是對需求進行深入研究的過程，過程中肯定會碰到一些疑問，產品經理負責答疑，工作量拆解完后，對整個的需求也基本上理解清楚了，可以正式進入到開發的過程中。
>>>測試用例評審二次確認
需求澄清完后，測試工程師開始準備測試用例，完成后就召集產品經理、開發人員對測試用例進行集中評審。
測試用例是產品完成標準的細化描述，在評審過程中，產品經理對有偏差的測試用例進行糾偏，最終通過二次確認，讓產品經理、開發工程師和測試工程師在產品完成標準上達成一致。
>>>后記
在平安天下通V3.5.0版本中實踐后，產品經理、開發和測試工程師反饋較好，整個過程規范清晰了很多，進度也第一次實現了零偏差。
（本資訊于2016-08-09首次發布）
