產品經理的技術修養

晚飯的時候據說大舅子從產品崗轉到了技術崗，目的是爲了更進一步的瞭解技術從而能更好的與程序員溝通。我就想，產品真的須要以這種方式才能與程序員和諧共處嗎？哎，我是無法忍受產品經理對我寫的程序指手畫腳。我合做過不少產品經理，其中不乏佼佼者，但這些優秀的產品經理從未跟我講過我要怎麼寫程序才能符合他的需求；並且我合做過的產品裏，甚至有一位我把他看做個人導師，帶我突破了技術生涯的第一次瓶頸，從一個新的角度來觀察產品實現。

如無必要，勿增實體。

1. 不要試圖去教程序員如何寫程序

就像產品不可能願意接受技術教他一個產品該如何設計同樣，程序員也（更）不肯意別人批評他程序寫的不對，甚至本身的同行說這個話都得撩開了鍵盤敲一仗。至於實習生或剛加入的新人，那有技術經理罩着，還輪不到產品出馬。若是發生這樣的事，這不是在把一個項目往好的方向帶，只會更糟糕，到不可調和的境地。

這種狀況有沒有，從個人經從來看仍是不少的。大約兩年前我接手過一個項目的管理工做，整個團隊人心渙散，5個技術槓着3個產品；技術經理也是半路接手，對外壓力重重對內沒法服衆。我記得當時首當其衝的一個需求是對已經存在的數據作一個搜索過濾的功能，操做上相似 LinkedIn，長得就像這樣：

上面是搜索框，左側是更細緻的分類篩選。

當時已經上了一個關鍵詞搜索引擎了，可是左側的篩選功能產品始終不滿意，特別是一個細節在用到了各類什麼異步請求、分塊查詢，最終實現仍是不太好：

從第一個圖到第二個圖，勾選了英國後，地區的全部統計量都沒變，而除地區外的條件切換了；若是我再勾選目前就任，則就任板塊全部選項和數量（包括沒勾選的）都不會變，而地區除已勾選的外根據條件改變……

產品特意寫了一個很長的文檔來描述這個動做應當如何變化如何查詢，沒錯，他真的寫了一個不太嚴謹僞代碼，顯然他是懂一些程序判斷邏輯和 SQL 的。大體上是：

1. 按關鍵詞查詢到結果

2. 選擇 A 分類的選項後篩選結果，A 分類再也不根據結果從新計算，A 分類外的須要根據結果從新計算

3. 選擇 B 分類的選項後須要記住 A 分類的數量，而後 B 再也不從新計算，計算 A 分類已選以外的選項
   ……

請原諒我沒辦法回憶清楚那份邏輯，太晦澀太難懂了，要記錄和判斷各類條件，沒等看完就扔了。

在我看來，HTTP 的無狀態特性是不太適合這種須要記錄各個環節的需求的，既然已經有人實現了，那我能夠認爲必定存在一個函數 fn1 和 fn2 給定相同條件 x 時能返回我要的 分類統計 和 查詢結果，我如今只要實現這個黑盒就能解決這個問題。

分析結果是確實我不須要存放已經計算過的 A 分類、B 分類的結果（排除須要優化運算量的狀況），也不用管什麼先點後點的順序，我只須要給出已經選擇的選項值便可，好比 url 查詢: ?wd=王&area[]=1&area[]=2&work[]=x ，以這個條件我就能獲得左側的分類和統計以及右側的結果，而整個過程我不須要用到 Session,Cookie 等任何暫存狀態的東西。若是你先點 A 再點 B 而後 A、B 已選的條件的統計數量不能改變，這根本就是個現象而不是需求；這個查詢對應的 URL 在另外一個新開的不一樣的瀏覽器同一用戶打開看到結果和統計值應當一致，他須要這個 URL 來作信息分類推廣，這個需求一樣只是個現象而已。能夠經過現象來檢驗程序，但不要用現象來約束程序。

事實上，只要在計算數量時排除此分類對應的條件就 OK 了，根本沒什麼點擊順序，我敢打保票效果一致，就這麼簡單。你說這效率是否是不高，那把左側計算和查詢分開請求好啦，還不夠就再來點緩存啦；但緩存不該當是一個優先考慮的措施，若是把一個程序看做一個洋蔥，應當先把裏面那個芯弄活了，至於外面的皮（緩存、過濾）多一層少一層能決定它未來活得好很差，不該當決定它此刻的生死。

其實相似這樣的搜索篩選邏輯如今處處都是，你能夠去 LinkedIn 也能夠去京東、淘寶嘗試。至於我給咱們公司寫的程序，那無法公開也不必，這裏我寫了個相似功能的代碼: SearchHelper，雖是單機也能撐起還湊合的數量，感興趣的能夠看看提提意見。

2. 什麼樣的文檔是恰到好處的文檔

文檔是產品與其餘部門交流的重要工具，下面這幅漫畫你們應該都見過（侵刪）：

不少事口頭是說不明白的，嘴巴上說「記得記得」，過上個把月，照樣板着個臉死無對證。

之前在魔都某公司，拼盡力氣抗下一個項目，初期只有我和產品兩人。每次去見客戶都由他牽頭，會議紀要卻都是客戶發，回到公司商量細節，他也歷來不記錄，我只好每次在白板上儘可能畫清楚而後拿手機拍照而後發封郵件請他確認。這個經歷實在很糟糕，最後這個項目也成了個人滑鐵盧；固然了，錯不能全推給人家，我當時也自認爲本身夠牛B、能作到原型即產品一步到位快速開發快速修改。

產品主要的文檔有 BRD、MRD、PRD、原型，前二者通常不用給技術看，但也不能什麼都掖着藏着，那是心虛的表現。一個老練的程序員最怕（不喜歡）什麼呢？就是你跟他說：「你別管了，老闆（客戶）就要這樣」。還有些產品沉迷於原型、仿真（這裏不討論 UI、UX 等分工），畫得很精細，但不外乎仍是在傳達一個命令：「照個人來作別問爲何」。

其實到我這個年紀還真懶得問「爲何」了，老油條了嘛，但你要想你的產品夠健壯，想最大限度的挖掘開發人員的能力，頗有必要講明白這個「爲何」，由於————請看下一節。

3. 來，咱們一塊兒找不一樣（相同）

【侵刪】

我女兒很愛玩相似的遊戲，在一堆圖案裏找相同的或不一樣的。晚飯時我妻子還問我產品經理跟程序員有什麼區別？我想了想指了桌子上兩個水壺，一個大的我女兒的，一個小的是她的。產品看到是兩個水壺，一個粉色的，上面有卡通圖案，有杯蓋，裏面有內膽；一個紅色的，彈簧蓋，裏面有內膽。而程序員看到的是：

你會說這也過小瞧產品了吧，這個誰不會畫。是的，誰都會如此分析，可是根本的地方在於產品感覺不到痛。產品會在一個項目啓動時畫，會在新需求來時畫，畫不少不少這樣的樹叉子，卻不多想，若是再來第三個給我這大老爺們用的杯子時，要如何併入這棵樹。

假設，這回來了一個搞藝術的客戶，他要一個 L 形狀的杯子，錢多人嘛傻不傻不知道。尼瑪這讓人咋搞，老子模具一直都是造圓筒形；產品說那還不簡單拿兩個圓筒焊到一塊兒不就得了；我靠，我這但是全自動化封閉式車間；產品說那你就在末端人工處理一下嘛別跟錢過不去嘛；操，那我外殼、噴漆、包裝咋辦……

我不懂製造業上面的類比可能不太恰當。不少時候狀況就是這樣，曾經拍胸脯說「不會變了、你寫死吧」，到某天變起來牽一髮動全身。

4. 程序 or 數據庫

那看來是否是產品就必須深刻前線體察一下軍情呢？個人回答是不必且不須要。

若是你真的想了解點技術，從程序入手不如從數據庫入手（此觀點限於信息系統或類信息系統）。瞭解一點數據庫結構、ERM 知識對產品的底層認知會更完全，由於在信息系統中，全部的程序都是圍繞着數據的增刪改查來展開的，HTTP 的 REST 規範也是將衆多咱們看到各類五花八門的動做規範爲 4 類狀態轉換的。

包括程序員，若是你只糾結於程序邏輯，極可能會「不識廬山真面目」，「只緣身在此山中」。樹總歸仍是那棵樹，只是多了、少了些葉子而已。不少所謂複雜的邏輯不外乎幾個 CRUD 互相調用罷了，好比：保存完新聞要聯動索引並給運營發條審覈消息，獲取新聞內容同時要附帶做者信息和統計信息以及熱門評論；有的可能查詢套查詢，有的可能要遠程調用其餘接口。可是其背後，爲何能夠這樣調用、關聯，都是 ERM 上描述好了的，一對1、一對多、多對多 這些關係就在那裏，它是靜態的，與外面能看到的東西是相映射的。

我沒有書能夠推薦，由於我也沒有買過，而這個經驗就是一位產品經理曾經教給個人，在那以前我瞭解 ERM、UML，但歷來沒有重視過。

5. 與敏捷共舞

有人說程序員跟妓女同樣，吃的是青春飯，30 歲之後要想辦法轉管理。呵呵，這行當是辛苦了點，什麼熱門什麼就更新快，就像如今的前端技術進展得我這個10多年前就從創意到數據通吃的老傢伙（別捅、讓我慢慢裝個 B）都看不懂了。

我以爲程序員就要像特種兵（某些服務程序員的程序員除外，他們是後勤保障，也多是火箭軍），必須邁開腿，從海底爬過去、從飛機跳下去，到前線去才能打勝仗；留在首長身邊當個捲簾大將撐門面？看咱們也有研發部也是科技公司耶——呸、無聊。

好吧，別跑題了，說回來。產品經理好歹有個 Manager 的頭銜，雖然不少產品經理自嘲本身就是個光桿司令，咱們來說點經理該乾的活。

上面扯了那麼多「術」的層面，可融合的「道」在哪呢？項目老是延期、技術叫苦連天，本該是融洽的上下游（注意了不是上下級）關係，咱們的好政委，咋就能鬧翻呢？解決之道在「敏捷」，來，大聲朗讀：

• 個體和交互 賽過 過程和工具；

• 能夠工做的軟件 賽過 面面俱到的文檔；

• 客戶合做 賽過 合同談判；

• 響應變化 賽過 遵循計劃；

• 雖然右項也有價值，可是咱們認爲左項具備更大的價值。

千萬、千萬別把第五句給漏了，這很重要、這很重要、這很重要。不要一開始敏捷了，就再不寫文檔、不作紀要、不記錄 QA 了，搞一塊白板鬼畫符頂多拍個照就完事了。這個意思是說，兩邊都很重要，若是作獲得固然也要作到右邊的，只是咱們認爲（來不及了）能夠適當的放棄右邊的一部分，更看重結果而不拘泥於形式；但顯然你得視項目大小、時間跨度來考量，哪些右邊的措施是必須的，保障項目長期正常運轉的。

須要注意，上面說但願程序員像特種兵同樣主動出擊，但從團體來說，表現更像海盜，精力旺盛而又神經脆弱，要有活幹，有新活幹，有挑戰性的活幹，留夠 10%~20% 的連續的自由時間、思考空間，這也許會給您的公司帶來意想不到的效果。「敏捷」也不是靈丹妙藥，我甚至感受這有點像宗教，光一個小圈子沒有外在配合（擴張）是玩不轉的。

6. 再來扯個蛋

《舊約》裏有個「巴別塔」的故事都聽過吧，講的是起初人類都講同樣的語言因此合做很順暢，能夠構建能通天的巴別塔好去找神聊聊，神怒了神馬玩意還吵吵嚷嚷的還讓不讓好好睡覺了，如是把人類拔散了趕到各地，讓人們說不一樣的語言用不一樣的文字，今後世界吵歸吵但吵不到他老人家了。

這個故事放在這裏有相通的道理，「人心齊、泰山移」。往大了說產品要跟研發一條心，要和諧不要分裂；往小了說，沒有名詞解釋、組件設計的產品文檔都是耍流氓。你都沒定義好關鍵詞，開個會雞同鴨講扯又扯不清楚；或是沒有個組件定義，講什麼都要來一大段，不能把信息壓縮，傳來傳去變了味。

固然我做爲一個曾經轉產品沒轉成功的碼農，呵呵，此文章寫得立場不明，雙方都不要罵我好吧。

---

剛想起點再補充下，我這人鍵盤嘮。

上面說到不要隨便「教」人寫程序，即便你就是程序員也不要這麼幹，對方不提出須要幫助不要去幫助，而那些解決不了問題還不呼叫支援的只會發愣的程序員讓他自生自滅好了。因此我不會主動去「教」咱們的前端程序員如何作，他作得很棒讓我眼前一亮，瞎指揮什麼呢；一樣我不會去指揮咱們的 App 開發，儘管 Java 我會 C 也沒忘乾淨，但那畢竟不是個人領域，不要去裝什麼大尾巴狼，正確的目標會指引着一切正確的運轉。固然了，我不發號施令也不會偷閒躲靜，不會中止寫程序和實踐新技術。

讓人們能走到一塊兒的是道，不是術。

---

再嘮 5 毛錢的。

篇幅有限能力欠費，不少點沒能覆蓋到。「革命只有分工不一樣，沒有高低貴賤之分」。產品經理有產品經理該幹得活，程序員有程序員該乾的活，不存在誰踹了誰飯碗的問題，實際狀況中可能存在出了誤差領導光罵產品不罵技術的，一是由於產品經理蹲在上游，離得近；二是不少老闆不是技術出身，聊不來。

有些軟手段可能在某些環境下也不太玩得轉，但總要有些東西要堅持的。