昨天聽了曹大的產品經理入門課程，今天做個總結。

一、產品經理的職責

不同企業的工作范疇不同，存在不同的定義。其共性可以概括為：產品需求設計、與研發的溝通協調。其他外延，包括產品需求設計之前的市場調研分析、產品上線之后的運營決策支持及反饋。
本文僅討論 與研發的溝通協調

產品經理的職責

二、產品經理在與研發溝通溝通中常見問題

• 需求提出之后，研發做出來了，但是與需求有很大出入
• 提出一個簡單需求，研發表示需要很長時間，甚至做不到
• 研發做出了合適的需求，但故障頻發

三、解決方案

產品經理與研發的溝通協調

1. 一致性原則

確保老板與自己、你與研發，對產品的理解、定義、用戶目標、運營目標有相對一致的認識。了解產品背后真正的目標、訴求。
不要假裝研發知道你懂的背景常識，如產品的意義、價值，產品的核心目標用戶群，產品的對標市場，產品的運營特點、涵蓋范圍等。如果研發對這些常識認識不足，或者產生誤解，很容易產生的問題：

• 如果產品文檔不規范，研發自由發揮的空間很大，可能做出來的東西跟你想要的完全不是一回事
• 如果文檔規范，研發做出的功能可以按需求完全實現，但存在一些認知上的問題可能導致的結果：
  • 研發基于自己對產品目標、產品運營做結構上、性能上的準備，可能做大量的無用功，從而導致研發效率低
  • 僅僅滿足功能需求，該做的準備沒做，導致性能考慮不足，運營支持度考慮不足

因此，在 功能訴求 之前，盡可能讓技術理解產品的真實目的、目標用戶群、業務訴求、運營途徑、推廣途徑，對產品的涵蓋范圍有清晰的認識和了解；功能訴求要有整體大綱，讓系統整體構成一目了然；指定業務邊界，減少無用功；適當允許和鼓勵研發參與產品討論和功能規劃。
此外，在溝通技巧上，要與研發在產品目標上進行確認，并且定期回述目標（讓對方按他的理解，重述項目背景和目標，減少雙方理解上的歧義、偏差），發現問題。

2. 產品文檔規范

把東西說清楚，讓研發理解透。

• 列出總綱，總體目標定義。描述 產品需求定義 ，用戶目標定義、產品目標定義、相關邊界定義，描述 產品構成 ，功能視圖清單、基本操作流程、角色構成、數據構成。
• 根據角色、終端、功能項的視圖描述。
  • 頁面布局
  • 元素（圖標、圖案、文案，信息和數據、交互操作項）
  • 邏輯（數據邏輯、交互操作邏輯、異常和容錯性說明）

研發拿到產品文檔，一方面通過總綱，對系統總體流程、產品目標、角色構成、運營策略以及各個視圖間的關聯關系有一個完整性的認識；另一方面通過視圖，對各個模塊、功能點有具體、細致的認識。

3. 測試與反饋

測試與反饋是非常重要的產品與研發溝通的范疇。參與測試，就測試給出研發合理的反饋，這樣可以更好的進一步協調確保產品的質量和進度。

• 單元測試：每個模塊、每個獨立的功能特性理論上都可以測試。明確測試目標、測試角色、測試流程、測試用例。（產品必須和研發協調進行單元測試，單元測試的目的是有效保障研發效率，以及盡早發現和確認研發中的問題，如果為了測試，而打亂了正常的開發節奏，延誤了正常的開發周期，是得不償失的。）
• 整體測試：又分發測試環境測試和線上環境測試。
• 測試用例
  • 正常流程測試：測試完成度、可用性
  • 反流程測試：用戶按預期流程操作產品導致的問題處理
  • 限制性測試：超長字符、頻繁出錯的密碼等，對錯誤輸入的提示、容錯性，是否符合預期、是否符合產品目標
  • 數據規模、并發壓力測試
  • 安全性測試

對測試出的問題進行分類（可用性問題、體驗問題、運營支持問題、安全問題等），列好嚴重程度、優先級。

4. 需求邊界

技術有研發成本，同一個功能，同一個數據邏輯，面對的不同的用戶訴求邊界，實現成本、效率差異很大。明確用戶訴求邊界，可以在很大程度上減少無用功，提升研發效率。（取巧）

• 數據精確度邊界
• 數據覆蓋率邊界
• 功能性邊界

在目標一致性原則之下，考慮對需求邊界的 容忍度 范圍。

研發三境界

• 簡陋。對性能、風險、安全隱患、系統擴展性一無所知，功能完成，但上線后千倉百孔，問題層出不窮。
• 繁冗。明白了什么是性能瓶頸、什么是業務風險、安全隱患、什么是架構擴展，然后在架構上、代碼上做各種補丁、防范，其中大部分是想太多、無用功，導致大量的時間、精力消耗。
• 簡單，返璞歸真。已經清楚各種風險，可以用最低的成本最低的代價盡可能多的對風險進行覆蓋、對未來可能的擴展進行保留。舉重若輕，大巧若拙，代碼越寫短，架構越做越輕。

5. 產品人員建議了解的技術常識

• 性能
  • 數據規模
  • 每秒相應頻次（操作即完成，非持續性請求）
  • 最大并發訴求（保持實時在線的，如 1000 個請求，平均一個請求 10 秒完成釋放鏈接，并發為 10,000）

性能瓶頸可能出現在客戶端、網絡端（傳輸/帶寬）、服務器（腳本/緩存/數據庫）。核心業務系統單服務器下，在百萬甚至千萬的數據記錄下查詢，每秒能達到 1000 次的響應能力，算是一個比較合格的技術指標。

• 安全
  • SQL 注入
  • XSS（跨站腳本）
  • 上傳漏掉
  • 源代碼泄露
  • 防撞庫設計
  • cc 攻擊
• 架構
  系統考慮產品的整體實現，好的架構首先可以滿足更多的業務訴求（如 運營訴求、新增的產品需求）；其次能滿足業務激增的情況下快速擴充響應能力，同時保證成本可控；最后是團隊開發中更好的質量和安全控制。架構主要考慮的問題：
  • 擴展性問題：業務擴展、性能擴展
  • 工作協同問題
  • 安全問題：在架構層屏蔽一些安全隱患

核心原則是 低耦合 ，每個模塊只關心輸入、輸出，內部邏輯與其他模塊無關。（低耦合，高復用，是所謂優秀架構的標準，但不要過高拔高這個標準，舉個例子，php可以理解為就是從 c 語言基礎上，做出的一個低耦合，高復用架構。你把低耦合，高復用做到極致，能做的過一門編程語言么。）低耦合、高復用是所謂優秀架構的標準，但都需要考慮一個 度 的問題。

分層模型：請求、分發（又有一些策略，如先查緩存）、響應

• 提升響應處理能力。有些請求可以合并處理，有些請求可以通過緩存處理，此外請求可以分布式處理
• 提升業務擴展能力。比如做一些通用的標準接口，業務層面自由組合訴求
• 提升安全性。中間層可以對業務數據做過濾，防止改寫后端程序邏輯。

但分層結構同理，適度就好，不能搞得過于復雜，過于繁冗。另外，切忌為了分層而分層，為了結構而結構，一切以目標為導向。

四、總結

最核心的還是，多溝通，多交流，多換位思考，不要認為你知道的別人都知道，也盡量理解研發的顧慮和思考的過程。溝通一定要主動！