溝通場景

1. 需求評審前、中、后期與技術(shù)人員溝通

需求評審前：

1. 產(chǎn)品團隊內(nèi)部先達成一致，考慮業(yè)務(wù)影響面，異常情況
2. 評審會前3天發(fā)送開會郵件給各與會人員，附件包含PRD等資料文件，督促開發(fā)查看，有疑問的點記下來
3. 開會前2天找技術(shù)Leader溝通，討論業(yè)務(wù)影響面、技術(shù)實現(xiàn)方案，并再次告知開會時間
4. 開會前1天做最后調(diào)整，準(zhǔn)備好開會資料，會議室設(shè)備，告知與會人員時間

需求評審中：

1. 為什么做，做什么，做的價值
2. PRD講解，盡可能的詳細(xì)，按照功能模塊-線框圖-需求用例-TC（Test Case）的流程講
3. 記錄好技術(shù)的問題，5分鐘能解決的就解決掉，解決不掉的記下來會后討論修改

需求評審后：

1. 準(zhǔn)備1-2天后的交互評審
2. 對會議中的問題總結(jié)修改
3. 發(fā)送會議記錄郵件CC給與會人員
4. 交付改后的PRD給UX同事（在交互評審前準(zhǔn)備好高保真原型圖）

2. 交互評審中技術(shù)評估交互實現(xiàn)可行性

需求評審會后增加交互評審會議，讓技術(shù)參與到交互評審中，對高保真原型圖進行評估，減少開工后溝通成本、實現(xiàn)成本，小公司通常沒有交互設(shè)計師的崗位，或者沒有交互評審會議，但是增加交互評審會議的目的，是為了減少后期溝通成本，避免返工。

3. 技術(shù)評審中的技術(shù)方案、實現(xiàn)細(xì)節(jié)

1. 確定需求的技術(shù)實現(xiàn)方案，實現(xiàn)細(xì)節(jié)
2. Android和iOS達成一致，避免上線后結(jié)果不一致。
3. 對技術(shù)的代碼梳理，從延展性，影響面，性能方面去考慮

4. 項目跟蹤過程中Debug、Release版的進度和質(zhì)量

1. 隨時跟進Debug版的進度和質(zhì)量，保證基本Demo方向，邏輯一致
2. 跟進Release版的進度和質(zhì)量，保證可用性測試，Test Case測試通過，產(chǎn)出的版本與設(shè)計一致，保證Android和iOS一致性。

5. 數(shù)據(jù)埋點需求

埋點分3種
- 代碼埋點：技術(shù)人員按照PM的統(tǒng)計要求在代碼中加入統(tǒng)計代碼
- 可視化埋點：無須RD協(xié)助，PM、運營可自行在SDK后臺加入統(tǒng)計代碼，無須發(fā)布新版本
- 無埋點：技術(shù)人員在App中所有的按鈕事件都加入統(tǒng)計代碼，耗時耗力，對網(wǎng)絡(luò)有性能要求
如果使用的第三方SDK不支持可視化埋點，則得請技術(shù)人員協(xié)助解決，如友盟只支持代碼埋點，Growing、諸葛支持可視化埋點，則無須技術(shù)人員協(xié)助

溝通方法

1. 同理心

同理心（Empathy），又叫做換位思考、神入、共情，指站在對方立場設(shè)身處地思考的一種方式，即與人際交往過程中，能夠體會他人的情緒和想法、理解他人的立場和感受，并站在他人的角度思考和處理問題。主要體現(xiàn)在情緒自控、換位思考、傾聽能力以及表達尊重等與情商相關(guān)的方面

我認(rèn)為同理心是產(chǎn)品經(jīng)理的第二大核心能力，在日常工作中，產(chǎn)品經(jīng)理會和各職能角色溝通，產(chǎn)品經(jīng)理要想把需求從設(shè)計到實現(xiàn)，需要技術(shù)角色協(xié)助，換位思考很重要，和技術(shù)溝通時，要站在他的角度思考問題，當(dāng)技術(shù)說不這樣做的理由是什么？做起來很難的理由又是什么？性能方面影響的面有哪些？后期為什么難擴展？現(xiàn)在的代碼low在哪里？等，當(dāng)遇到這些問題時，如果能換位思考，站在技術(shù)的角度去考慮需求，結(jié)合現(xiàn)有資源，做出最優(yōu)解的方案，那才是優(yōu)秀的產(chǎn)品經(jīng)理。因此，懂技術(shù)知識，有技術(shù)背景的產(chǎn)品經(jīng)理尤其受技術(shù)同事歡迎，在技術(shù)選型、成本預(yù)估、和技術(shù)同事溝通上占有強大優(yōu)勢。

2. 尊重

首先，產(chǎn)品經(jīng)理只是產(chǎn)品的經(jīng)理，不是各職能角色的經(jīng)理，和開發(fā)、測試、UI同事同級，并不具備領(lǐng)導(dǎo)權(quán)利。因此，在和技術(shù)人員溝通需求時，一定不要表現(xiàn)出經(jīng)理的樣子，以大壓小只會使你離的更遠(yuǎn)，給予技術(shù)充分的尊重，平時呢，多和技術(shù)聊聊工作、生活上的事，給予鼓勵，認(rèn)可其工作成果，多擔(dān)當(dāng)，尊重技術(shù)的能力，一起協(xié)助解決問題。所以，以下的話就千萬別說了。
- 別人App能實現(xiàn)啊
- 這個是老大的需求

3. 價值

大家都是來上班想做好事情、實現(xiàn)個人價值的（某些混日子的不在討論范圍內(nèi)），講清楚每一輪迭代，為什么做，做什么，做的價值，只要做的東西對公司、對客戶有價值，那技術(shù)也會認(rèn)可需求，只是具體實施過程中，怎么去結(jié)合團隊現(xiàn)有資源做到最優(yōu)，也就是MVP，因此，做好需求優(yōu)先級很重要，從定性和定量的角度去分析需求，讓各職能角色認(rèn)可需求，使大家達成一致推進迭代。

4. 找到對的人

如果實在和某些技術(shù)員工溝通不了的，則請教其他技術(shù)同事或者技術(shù)Leader，找到實現(xiàn)方案，注意喔，這里不是越權(quán)，而是團隊里面各技術(shù)角色技術(shù)能力不一，實現(xiàn)方案優(yōu)劣、所需時間長短、技術(shù)延展性往往不一樣，所以，找其他技術(shù)同事或技術(shù)Leader溝通解決方案更優(yōu)更快，當(dāng)然，產(chǎn)品經(jīng)理是跟具體技術(shù)人員溝通還是技術(shù)Leader溝通，這個得看團隊的管理方式了。