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