產品需求從無到有，經歷了頭腦風暴、調研溝通、業務討論、架構討論、產品評審、開發評審。溝通無處不在，和業務人員、架構師、產品人員、技術人員、領導的各種溝通協調、匯報，一路下來梳理些溝通的方式方法，自勉和改進。
1、心態： 一句很感同身受的話：開放的心態是我們要做的第一件事情，全局控制的想法其實是錯覺。你不能控制人或者任何事情。你可以影響他們，但絕不是控制。
2、與業務、產品的溝通：
1.溝通業務背景，了解產品流程背后的原因。
2.溝通產品故事，了解產品為用戶帶來什么價值。
3.討論產品方案，建設性提問并帶自己的建議方案。
4.涉及外部接口的交互及約束，從后端產品往前端產品推進、溝通。推進的方式：
1）從性能指標考量的角度，在前端產品盡可能少調用接口次數和中臺提供接口范圍不過分超出產品架構定義之間做好權衡。
2）從產品職責定位的角度，上游產品傳給下游產品的接口信息中不夠下游產品用的，原則上由上游產品提供，上游產品提供不了的從產品定位考慮是否由上游產品提供還是下游產品根據上游產品的傳參自己去其他平臺獲取。
5.和每個對接產品的人員單獨建群溝通，形成問題討論小組。
6.產品需求溝通、確認的完成度達90%以上時發正式郵件給所有干系人并告知開發團隊已開始著手產品開發。同時附上待確認的問題清單請相關方同步知悉。
3、與架構師的溝通： 1.先談業務，再談產品，接著談流程，最后溝通系統邊界。
2.有較清晰的產品需求和流程后再和架構師溝通。
備注：架構師在有較清晰產品需求前提下主持產品職責定義及各產品邊界劃分，輸出應用架構規劃與設計方案作為產品需求的參照。
4、與領導的溝通、匯報： 1.產品調研匯報時，哪些調研過、哪些沒調研過、哪些暫時沒有調研清楚的，客觀說明。
2.決策請示時，從業務角度出發，不要請領導確認產品細節、更不要技術細節，提出問題的同時帶建議解決方案（如：確認一期是否要做XX產品功能，解決方案要素含：競品是否也有做？我們做有什么價值？如果做該如何做？涉及哪些產品改造？上線時間節點下現有資源是否足夠？不足還需要多少資源？需要和其他部門做哪些配合和協調？）
5、與開發溝通：
講產品故事（講述業務背景）、畫草圖（講業務故事的同時黑板畫上下文流程圖）、解疑問（解答開發的問題）、當前遺留問題（自己當前還沒有想明白的產品流程可以邀請開發參與溝通）。其中：
1.業務需求講解要點：
1）為什么有這個產品
2）產品做什么的
3）產品所處的業務上下文
4）有哪些業務場景會經過產品，經過時的數據流向。
2.產品需求預審：
1）需求增量編寫過程中質量優先，明確一部分，提前請開發人員預審一部分，劃分好產品需求和概設/詳設的邊界。
2）需求增量給開發后，請開發提意見并開展溝通，正式評審前，澄清一些開發人員的疑問。
3.產品需求評審要點：
1）需求文檔結構介紹（分哪幾章節、各章節的含義及章節間的區別）
2）產品的功能結構圖
3）每個章節的功能需求描述、產品流程、對外接口描述
4）每個章節介紹完畢，請開發提問，產品答疑，問題批注到文檔。
5）評審完畢后及時將修訂的產品需求發給開發并說明已明確的內容、待定的內容，列出修訂記錄。
6）對于未能確定的需求，評審過后與技術溝通，請開發把握好概設/詳設的度。
posted on 2015-04-11 11:20
cheng 閱讀(4590)
評論(0) 編輯 收藏 所屬分類:
互聯網產品