中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文主要是想和大家分享一下自身和外界溝通這方面，我對于“產品經理和開發gg溝通”這個問題的理解。供有意愿和開發gg共謀大事的產品經理參考。

經常和開發哥哥（簡稱開發gg）開玩笑說，產品經理是一個高危職業，隨時面臨著被砍、被炒、被集體攻擊、被要求請吃飯等等，真心是用繩命（生命）在工作。對此多少讓人有些啼笑皆非。

但是玩笑歸玩笑，仔細想想，對于產品經理面臨的種種“威脅”，個人從自身工作經驗角度感覺，有兩方面需要注意：一方面需要考慮自身能力問題，更重要的一方面，是要考慮自身和外界的溝通問題。

對于自身能力問題，我早些時候有寫過一篇《成熟產品經理必備的特質》，在此就不羅嗦了。本文主要是想和大家分享一下自身和外界溝通這方面，我對于“產品經理和開發gg溝通”這個問題的理解。供有意愿和開發gg共謀大事的產品經理參考。閑言不扯，直奔主題。

一、需求細節的把控

我們知道，大多數需求，都是由產品經理提出并逐步推送給開發gg的。如果作為產品經理的你，日常處理的需求多數也是此類，那就一定得注意對需求細節的把控了。

這里所說的細節把控，尤其是指在產品經理策劃“提供給開發gg的PRD”時需要注意的：要將自己能考慮到的細節均描述在內。舉一個很基礎的例子：

如果是要實現一個注冊頁面，僅有用戶名、郵箱、密碼三個字段，如下圖的視覺設計效果所示：

看起來簡簡單單的4個輸入框和1個按鈕，但對于產品經理而言，在策劃PRD時，需要考慮的細節要素不下15個，我可以簡單羅列一下：

用戶名的格式要求、郵箱的格式校驗、密碼的長度要求、密碼包含的字符要求、兩次密碼輸入時的一致性校驗、按鈕默認顯示狀態、用戶輸入信息后按鈕顏色變化效果描述、四個輸入框用戶輸入錯誤時的報錯提示文字、提示文字的擺放的位置、頁面格式根據提示文字的變化，需要有怎樣的視覺效果、用戶不小心點擊了左上角的返回按鈕后的提示文字、誤點之后的下一步動作描述、用戶點擊立即注冊時在網絡較慢的情況下，頁面和按鈕如何響應、是否要加鎖屏浮層等等。

雖然以上細節要素中，有一些是需要交互設計和視覺設計給出效果圖的，但是產品經理還是需要對一些動態變化、點擊響應事件效果等進行詳細描述。

想要說明的是，如果產品在不告訴開發gg這些細節的情況下，開發gg應該怎樣去理解和實現這些效果呢？如果開發gg專心做這一個項目，那么他耐心和產品經理反復溝通一下，也能達到預期效果。但是當開發gg身兼多職，業務異常繁忙時，就很難確保效果了。這不但影響開發gg心情，也難免會影響到產品經理自己的耐心。
近期我也有個經歷，做一個注冊功能：用戶先是登記郵箱信息，登記成功后，系統自動給用戶的郵箱發送一個登記成功的郵件驗證碼，用戶用此驗證碼去完成注冊。

我非常認真的描述了整個登記和注冊流程，提交開發gg開發。當我正在慶幸自己考慮的很周全時，開發gg很無奈的說：“發送給用戶的郵件沒有說明啊，標題是啥，郵件展示內容、展示字段、有問題如何反饋，這些內容又是啥呢？”。這時我才恍然大悟：需求細節，沒有最細，只有更細??！

把控好細節，有3方面的好處：

1. 可以在開發執行時，盡量減少開發gg和產品經理進入狀態和跳出狀態的時間成本。意思就是當一個人沉下去專注做一件事兒的時候，尤其是寫代碼或寫文檔這類，中間再跳出來做溝通的事兒，大腦會有一個進入狀態和跳出狀態的轉換過程，這個過程需要時間。
2. 減少開發gg在溝通過程中的“耐心”和專注精力的消耗。凱莉.麥格尼格爾在《自控力》一書中說，每個人的自控力每天都是有限的，而這里所謂的自控力，就是耐心和專注的精力。這也是為什么忙碌的人們往往會在下午五六點的時候脾氣變差。
3. 一個輔助功能，協助后期產品經理當作備份文檔來查看自己的產品細節邏輯，尤其是邏輯復雜的產品。
   通過細節的把控，明顯可以給到開發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年，騰訊產品經理。對于互聯網與航空的結合、互聯網產品有較深入的了解且持續關注中。愛好音樂與文學，文藝青年一枚。

轉載請保留上述作者信息并附帶本文鏈接