Java開源生鮮電商平臺-程序員的溝通的方式與方法
Java開源生鮮電商平臺-程序員的溝通的方式與方法
今天看了一張圖，有感而發。
這個是一個實際的截圖，內容是否真實，我們不得而知，但是這張圖引起了我的以下思考：
1. 溝通能力。
2. 溝通的方式。
3. 溝通的方法
1. 為什麽會出現最後罵娘，而且要離職的一種裂變結果呢？
2. 從這個溝通的對話中，如何理解程序員與產品經理之間的方式與方法呢？
3. 為什麽會出現這樣的溝通方式與行為呢？這個背後到底發生了什麽事情呢？
其實，我覺得還是一個溝通的思維問題，行動是思維的最終結果。
那麽實際溝通中，到底會出現那些溝通的問題與障礙，以及有什麽辦法可以克服的呢？
1. 需求評審前、中、後期與技術人員溝通
需求評審前：
- 產品團隊內部先達成一致，考慮業務影響面，異常情況
- 評審會前3天發送開會郵件給各與會人員，附件包含PRD等資料文件，督促開發查看，有疑問的點記下來
- 開會前2天找技術Leader溝通，討論業務影響面、技術實現方案，並再次告知開會時間
- 開會前1天做最後調整，準備好開會資料，會議室設備，告知與會人員時間
需求評審中：
- 為什麽做，做什麽，做的價值
- PRD講解，盡可能的詳細，按照功能模塊-線框圖-需求用例-TC（Test Case）的流程講
- 記錄好技術的問題，5分鐘能解決的就解決掉，解決不掉的記下來會後討論修改
需求評審後：
- 準備1-2天後的交互評審
- 對會議中的問題總結修改
- 發送會議記錄郵件CC給與會人員
- 交付改後的PRD給UX同事（在交互評審前準備好高保真原型圖）
2. 交互評審中技術評估交互實現可行性
需求評審會後增加交互評審會議，讓技術參與到交互評審中，對高保真原型圖進行評估，減少開工後溝通成本、實現成本，小公司通常沒有交互設計師的崗位，或者沒有交互評審會議，但是增加交互評審會議的目的，是為了減少後期溝通成本，避免返工。
3. 技術評審中的技術方案、實現細節
- 確定需求的技術實現方案，實現細節
- Android和iOS達成一致，避免上線後結果不一致。
- 對技術的代碼梳理，從延展性，影響面，性能方面去考慮
4. 項目跟蹤過程中Debug、Release版的進度和質量
- 隨時跟進Debug版的進度和質量，保證基本Demo方向，邏輯一致
- 跟進Release版的進度和質量，保證可用性測試，Test Case測試通過，產出的版本與設計一致，保證Android和iOS一致性。
5. 數據埋點需求
埋點分3種
- 代碼埋點：技術人員按照PM的統計要求在代碼中加入統計代碼
- 可視化埋點：無須RD協助，PM、運營可自行在SDK後臺加入統計代碼，無須發布新版本
- 無埋點：技術人員在App中所有的按鈕事件都加入統計代碼，耗時耗力，對網絡有性能要求
如果使用的第三方SDK不支持可視化埋點，則得請技術人員協助解決，如友盟只支持代碼埋點，Growing、諸葛支持可視化埋點，則無須技術人員協助
6. 學會尊重
首先，產品經理只是產品的經理，不是各職能角色的經理，和開發、測試、UI同事同級，並不具備領導權利。因此，在和技術人員溝通需求時，一定不要表現出經理的樣子，以大壓小只會使你離的更遠，給予技術充分的尊重，平時呢，多和技術聊聊工作、生活上的事，給予鼓勵，認可其工作成果，多擔當，尊重技術的能力，一起協助解決問題。所以，以下的話就千萬別說了。
- 別人App能實現啊
- 這個是老大的需求
7. 體現價值
大家都是來上班想做好事情、實現個人價值的（某些混日子的不在討論範圍內），講清楚每一輪叠代，為什麽做，做什麽，做的價值，只要做的東西對公司、對客戶有價值，那技術也會認可需求，只是具體實施過程中，怎麽去結合團隊現有資源做到最優，也就是MVP，因此，做好需求優先級很重要，從定性和定量的角度去分析需求，讓各職能角色認可需求，使大家達成一致推進叠代。
最終所有的結果都是自己造成的，怪不得他人，我們需要的是冷靜的處理所有的事情，所有的工作，善待他人。
Java開源生鮮電商平臺-程序員的溝通的方式與方法