產品經理：你是怎樣和開發gg溝通的？

---

經常和開發哥哥（簡稱開發gg）開玩笑說，產品經理是一個高危職業，隨時面臨著被砍、被炒、被集體攻擊、被要求請吃飯等等，真心是用繩命（生命）在工作。對此多少讓人有些啼笑皆非。
但是玩笑歸玩笑，仔細想想，對於產品經理面臨的種種“威脅”，個人從自身工作經驗角度感覺，有兩方面需要注意：一方面需要考慮自身能力問題，更重要的一方面，是要考慮自身和外界的溝通問題。
對於自身能力問題，我早些時候有寫過一篇《成熟產品經理必備的特質》，在此就不羅嗦了。本文主要是想和大家分享一下自身和外界溝通這方面，我對於“產品經理和開發gg溝通”這個問題的理解。供有意願和開發gg共謀大事的產品經理參考。閒言不扯，直奔主題。

一、需求細節的把控
我們知道，大多數需求，都是由產品經理提出並逐步推送給開發gg的。如果作為產品經理的你，日常處理的需求多數也是此類，那就一定得注意對需求細節的把控了。
這裡所說的細節把控，尤其是指在產品經理策劃“提供給開發gg的PRD”時需要注意的：要將自己能考慮到的細節均描述在內。舉一個很基礎的例子：
如果是要實現一個註冊頁面，僅有使用者名稱、郵箱、密碼三個欄位，如下圖的視覺設計效果所示：

看起來簡簡單單的4個輸入框和1個按鈕，但對於產品經理而言，在策劃PRD時，需要考慮的細節要素不下15個，我可以簡單羅列一下：
使用者名稱的格式要求、郵箱的格式校驗、密碼的長度要求、密碼包含的字元要求、兩次密碼輸入時的一致性校驗、按鈕預設顯示狀態、使用者輸入資訊後按鈕顏色變化效果描述、四個輸入框使用者輸入錯誤時的報錯提示文字、提示文字的擺放的位置、頁面格式根據提示文字的變化，需要有怎樣的視覺效果、使用者不小心點選了左上角的返回按鈕後的提示文字、誤點之後的下一步動作描述、使用者點選立即註冊時在網路較慢的情況下，頁面和按鈕如何響應、是否要加鎖屏浮層等等。
雖然以上細節要素中，有一些是需要互動設計和視覺設計給出效果圖的，但是產品經理還是需要對一些動態變化、點選響應事件效果等進行詳細描述。
想要說明的是，如果產品在不告訴開發gg這些細節的情況下，開發gg應該怎樣去理解和實現這些效果呢？如果開發gg專心做這一個專案，那麼他耐心和產品經理反覆溝通一下，也能達到預期效果。但是當開發gg身兼多職，業務異常繁忙時，就很難確保效果了。這不但影響開發gg心情，也難免會影響到產品經理自己的耐心。
近期我也有個經歷，做一個註冊功能：使用者先是登記郵箱資訊，登記成功後，系統自動給使用者的郵箱傳送一個登記成功的郵件驗證碼，使用者用此驗證碼去完成註冊。
我非常認真的描述了整個登記和註冊流程，提交開發gg開發。當我正在慶幸自己考慮的很周全時，開發gg很無奈的說：“傳送給使用者的郵件沒有說明啊，標題是啥，郵件展示內容、展示欄位、有問題如何反饋，這些內容又是啥呢？”。這時我才恍然大悟：需求細節，沒有最細，只有更細啊！
把控好細節，有3方面的好處：
一:可以在開發執行時，儘量減少開發gg和產品經理進入狀態和跳出狀態的時間成本。意思就是當一個人沉下去專注做一件事兒的時候，尤其是寫程式碼或寫文件這類，中間再跳出來做溝通的事兒，大腦會有一個進入狀態和跳出狀態的轉換過程，這個過程需要時間。
二:減少開發gg在溝通過程中的“耐心”和專注精力的消耗。凱莉.麥格尼格爾在《自控力》一書中說，每個人的自控力每天都是有限的，而這裡所謂的自控力，就是耐心和專注的精力。這也是為什麼忙碌的人們往往會在下午五六點的時候脾氣變差。
三:一個輔助功能，協助後期產品經理當作備份文件來檢視自己的產品細節邏輯，尤其是邏輯複雜的產品。
通過細節的把控，明顯可以給到開發gg更多的時間、更好的心情去做你的需求，那何樂而不為呢？

二、要有同理心
同理心，就是願意站在對方角度考慮問題。
我們身邊不乏這樣的案例：PRD提交給開發gg之後，不再和開發gg討論能否實現、如何實現、可否有更好的優化方案。而是直接定一個deadline，告訴開發gg說需求緊急，急到頭腦生煙、雙腳磨爛，必須此前完成，否則就殺人了。
這個時候即使開發gg同意了，心底裡也是有反彈的：不但考慮如何閱讀天馬行空的PRD，還要考慮如何在粗糙的PRD基礎上自己去做完善，更要考慮如何加班加點把程式碼敲完。他的心情怎麼能好起來呢？他怎能不厭惡產品經理呢？
當開發gg站在產品經理的角度，幫你把粗糙的PRD完善好之後，他的耐心已經耗去十有八九。那站在開發gg的角度，你會怎麼考慮？會靜心去分析每一行程式碼的實現邏輯嗎？
我自己有個經歷：洋洋灑灑五千字描述了十頁的word，效果圖+邏輯圖+詳細文字描述，提交開發後要求在4天內將一個商品價格體系的計算邏輯調整掉。開發gg看到後頓時蒙掉了。其實當我提交這個需求時，我自己心理就清楚，按照現行的方案，4天內實現這個功能，是根本不可能的。但我還是帶著這樣的心情把需求甩給了開發gg，想通過各種壓力，逼迫開發gg完成需求。自己心理帶著一份僥倖，帶著一份不屑，也帶著一份戰戰兢兢，期待著那個deadline來臨之後，這個需求可以華麗麗的被完成。
但是明顯可以看出，即使時間延長一倍，要完成需求也是有挑戰的。最終需求延遲完成之後，我在開發gg中的口碑也已蕩然無存，人人願得而誅之。
後來主程（需求主開發）跟我說，需求開發完成後我曾問過一個問題：商品價格體系調整，是不是把涉及到的幾個欄位捋一捋，把折扣變一變？這句話讓他想到了一個更好的實現方案，需求延遲不用那麼久應該都可以實現的。
如果我在需求實現前，就可以站在開發gg角度，考慮一下他們需求調整具體涉及到的欄位、程式碼之間的關係和邏輯是怎樣的，也許就不會有後來的“人人得而誅之”了。
所以說，千萬不能拿deadline給開發gg施加壓力，並抱著僥倖心理等待deadline之後能出一個華麗麗的需求，而是需要站在開發gg角度，跟他們一起戰鬥，一起優化，一起完成。自己看不懂的，不要給他，自己覺得不可能的事兒，也不能強壓給他，這就是產品經理的同理心。這裡就引起了另一個問題，有人會問，我不懂程式碼怎麼辦？這就是下一點將會提到的“技術理解力”。

三、技術理解力

相信大家在多種渠道都接觸過，騰訊公司的產品經理能力體系中，有一個很重要的指標，叫技術理解力。說白了就是，一個產品經理跟開發gg有沒有共同語言，能不能聽得懂開發gg在說什麼。
這個能力，對於懂得的產品經理，不說也懂。但對於不懂的產品經理，怎麼說可能都不太懂。也是舉一個我自己的例子。
微信剛剛推出模版訊息的時候，我看了手機上發出的訊息，如下圖：

就也想在自己的業務上實現。所以自己定義了標題、詳細內容、連結地址等。直接就提交給開發gg去實施了。
當開發gg告訴我說，好像他們沒辦法直接實現，需要諮詢一下微信的專業人士。
通過了解發現，這個需要在微信公眾平臺找自己業務對應的行業，並在行業中選擇需要的模版，通過模版的欄位才能來定義和傳送。
這時候我才明白了，原來並不是我們想怎麼做，就能怎麼做的。而是要先了解微信對於模版訊息的定義。
首先選擇模版：

然後看具體模版的定義欄位：

根據具體的欄位，定義好相應的內容，然後再通過每個模版的ID，通過開發實現，傳送給使用者。
瞭解之後，我只需要將模版ID，以及對應每個欄位需要填充的內容提交給開發gg即可。不要提交互動及視覺設計去自己弄一個模版訊息的效果圖，因為即使我弄了，微信公眾平臺中也不一定有我設計的模版樣式。
這個例子說明了，如果沒有一定的技術理解，也不一定能夠看懂微信公眾平臺的模版訊息涉及的定義、欄位等內容。
就像我剛開始不理解，走了互動、設計、文件描述，提交開發之後才發現不能實現。瞭解過後才發現，只需要填寫相應欄位的內容，並通過模版ID就可以傳送。這2種不同的需求跟進風格，一方面時間效率相差很遠，另外一方面，在自己未理解的情況下，冒然把需求提交到開發gg去，也會讓開發gg一頭霧水。
當然這只是一個簡單的例子，還有一些和開發gg一起梳理程式碼邏輯的例子，就不一一贅述了。
再次說明，技術理解就是和開發gg開始對話的前提，不懂的產品經理，趕緊惡補一下吧。

四、小結
和大家分享了3點個人工作中覺得和開發gg溝通時需要注意的要點，希望能對產品經理和開發gg的溝通起到幫助作用。
如有不妥的地方，特別是開發gg覺得我沒說到心上的，也歡迎隨時拆樓拍磚哈。

#專欄作家#
哈勃，微信公眾號：哈勃筆跡（habobiji），人人都是產品經理專欄作家，網際網路從業6年，騰訊產品經理。對於網際網路與航空的結合、網際網路產品有較深入的瞭解且持續關注中。愛好音樂與文學，文藝青年一枚。