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

作為產品經理，需求評審環節是非常重要的，遇上會溝通的技術皆大歡喜，遇上溝通困難的技術也在所難免。本文作者總結了一些產品與技術在需求評審各個階段中，可能會出現溝通困難的場景、復盤思路和應對建議，希望能給你帶來一些幫助。

入產品坑的這5年，我直接對接工作交流過的技術人員至少50+，運氣好遇到好交流的技術，與他們進行需求評審時，他們總會非常認真地對自己認知不清晰的地方，以提出問題、同義轉化或作出假設等表達方式進行需求確認，或者將你在需求分析和產品設計之中的不足之處暴露出來，還非常積極地跟你一起討論解決方案，更有甚者還能為你提供用戶體驗更好的參考設計，讓你的產品之路跟開了掛一樣地輕松、有趣。

運氣不好就會在需求評審時遇到一些“奇奇怪怪”的技術，例如：

• 提前發布了需求評審的相關材料后，技術不會提前閱讀，等評審會上過需求時，技術依然會問一些評審材料中已提到過的需求細節；
• 在需求評審過程中，當你詢問是否有疑惑或者技術難點時，技術穩坐泰山一般不表達自己的觀點，宛如對需求已經了然于胸；又或者提出一些似是而非的問題，當你追問是否有建議時，又不吭氣了，仿佛剛剛提問題的不是他；更有甚者職責分明的質問你：“這難道不是你作為產品該思考的問題？”。

作為產品經理，在需求評審環節能遇上會溝通的技術皆大歡喜，遇上奇奇怪怪溝通困難的技術也在所難免。

當遇到溝通困難的技術時少不得會忍不住吐槽：xxx技術好難搞?。xx技術事兒真多！xxx技術不配合產品工作！

說實話我之前也這么吐槽過，也有過其他產品小伙伴響應我說遇到過同款技術。后面隨著對工作的復盤和技術轉產品同學的分享才發現：在產品覺得技術“難搞”的時候，技術可能也是這么看產品的。

換個角度，假設你是技術，在需求評審環節是不是也會有“一頭霧水”的時候？又或者是“不敢說”的情況？例如：產品給的資料都是什么呀，東一份西一份的，到底哪個是重點？需求評審的資料要么全是文字，要么就一個不帶交互的原型圖，這也太簡單了吧！需求評審時產品講了半天，因為不知道需求背景沒聽懂，提問題反倒被產品說我是在故意找茬？我看到有個需求有問題，想提醒一下產品，一想到之前有遇到過向產品提問題就被懟的情況，還是不說了吧……

還記得之前“產品汪”與“程序猿”因為需求評審意見不合而爆出來的各種熱門文章么？這些文章會通過文字或漫畫的形式，給讀者還原一些產品與技術在需求評審環節中搞笑、暴力、充滿火藥味的場景，由此火了很多自媒體賬號。這也說明產品跟技術關于需求的“意見不合”是長期存在的共性問題，而這些問題追根溯源實際上都是“溝通問題”惹的禍。

正所謂一個巴掌拍不響，在需求評審環節出現溝通不暢時，必然是雙方都有一定的因素，只是多與少的區別。

當你遇到在需求評審環節中與技術對接過程中溝通不困難時，不要先急于從技術身上找原因，要先自省，檢查自己有沒有做好自己在需求評審過程中的本職工作。

怎么進行自查呢？以讓你最崩潰的一次需求評審為基礎進行復盤，回顧一下在你在此次需求評審的各個階段。例如，你為該階段做了什么準備工作？該階段你是怎樣與技術/產品溝通的？最終造成了怎樣的后果？你當時的情緒是怎樣的？你覺得對方當時的情緒是怎樣的？是否有思考過以下提到過的相關問題？

以下便是我總結的關于產品與技術在需求評審各個階段可能會出現溝通困難的場景、復盤思路和應對建議：

01 需求調研時

作為產品，你是否有做到在需求調研和規劃過程中，就會與技術同步客戶訴求或者產品規劃思路？是否有主動與技術溝通客戶新訴求中有哪些可能會涉及到新技術？

涉及新功能開發或新流程設計時，是否有給技術預留充足的技術選型時間？是否有在條件允許的情況下就讓技術參與與客戶進行需求確認時的需求確認會或者將相關信息事后同步給技術？整個需求調研環節中是否有過技術參與？提升技術的參與感強不強？

建議在每次需求調研結束后第一時間與技術同步信息，主動詢問技術是否有技術難點或者對客戶需求不明確的地方，如果有你則溝通好替代方案或想辦法砍掉后，再拿這些結果找客戶進行重點溝通確認，以確保需求符合客戶需求的同時技術可實現。

這個階段的溝通的技巧在于：選擇合適的場合與時間，主動“勾搭”你的目標人物，將你要說的內容以故事的形式傳遞出去。

例如：午飯時，產品和技術一起吃飯，這時候產品可以“不經意”的說起xxx客戶今天又給我打電話提新需求了，說的是……搞得我不知道怎么搞，頭都想痛了，你覺得這個需求能整不？如果是技術，同樣可以在午飯時間問產品，今天聽到你好像在跟客戶討論xx需求，這個是干啥的？是我們后面要做的么？是有新的功能還是可以套用現有功能呢？

另外，產品可以通過場景式的“用戶故事”引導技術代入到用戶的使用場景中，便于技術了解用戶需求、對研發難度有所評估。參考表達方式“我作為XXX角色，我希望擁有XXXX需求，目的是XXXX”。例如：當我要買一輛車時，我希望能同時看到尼桑逍客與長安75plus的各項配置，如大小、可選顏色、排量、價格等，好讓我能更方便的對比兩個車的配置哪一個更適合我。

至于為什么會把這部分放在前面呢？因為需求調研是需求評審的“地基”。需求調研過程中產品與技術溝通良好、對項目的參與感強，才能讓技術同產品一樣，愿意把此次要做的需求當作是自己的“孩子”，而不是全靠產品思考及規劃，能進一步地推動后續工作的有效開展，提升溝通的效率，同時雙方也會將需求背景、目標、內容等達成共同的認知，而不是等后期再向技術傳遞二次加工過的內容，導致技術認知產生片面化。

02 需求評審前

咱們作為產品經理，需要提前準備好需求評審相關的所有資料，并發起需求評審會議。這時候要重點關注的點：評審資料里包含什么？是否有做好全部資料中文件名的備注，可以讓人直觀地了解文件是干嘛的？

會議通知中是否有說清楚資料之間存在什么關系？如何引導參會人按要求閱讀評審資料？怎么檢驗參會人是否有在會前按要求完成資料閱讀/會前任務？哪些人必須參加需求評審會議？是否有跟必須參加的人員溝通確認好參與時間內肯定可以到場或遠程參與？

建議在需求評審前提前與主要的技術進行一些有互動性的溝通。例如，針對在評審會議通知的內容中，除了會議通知中必要的：會議主題、時間、地點、參與人、會議形式、會議地點、會議流程之外，一定要把附件的評審材料都包含哪些、閱讀順序是怎樣的講清楚，并設置會前任務。

如針對材料中的一些重點內容進行問題設定，要求哪些參會人員需要在什么時間之前閱讀完材料并進行回答，以此促使技術提前閱讀材料，給自己預留會前與技術溝通并補充評審材料的時間。

由此可見，如果一個產品能做好需求調研和需求評審前的準備工作，技術能在需求評審前認真熟悉評審材料并進行過思考。等到需求評審時，就只需敲定一些未被確認的事項及接下來的工作安排，這樣的需求評審效率肯定非常高！

等需求評審時才會真的沒有“硝煙”，而不是產品個人“脫口秀”造成的“全員靜默”。在評審會前有充分溝通的前提下，需求評審會可能就淪為查漏補缺過流程了。

03 需求評審時

有沒有過產品在上面講的“激情四射”，宛若無人之境一般不與技術進行眼神交流、互動問答？又或者一問技術有沒有問題，全場你看我我看你“大眼瞪小眼”，于是默認大家都聽懂了而結束評審環節？

有沒有技術看起來在需求評審時好像都聽懂了，但是等執行的時候卻發現，實際還有好多不清楚的地方？又或者聽產品講需求時會“神游天外”或者“昏昏欲睡”？

建議產品每講完一個需求關鍵點后，就問下技術是否有問題、是否有建議等多與技術進行互動；如果沒有人回復，就點一個比較相熟或者負責該部分需求寫代碼的技術，讓其同義轉化一下，以確認對方真的有聽懂，而不是產品一人單方面的“演講”，讓技術也聽的“神游天外”。

有互動的需求評審能讓會議參與的相關人員時刻保持相對集中的狀態，以防參會人被問到時，避免因沒認真聽而無法做出問答反饋所造成的尷尬。

這個環節可能產品和技術最擔心的就是因“情緒失控”造成會議“場面失控”，產品過需求時要思路要比較清晰，才能減少被技術噴的次數，而技術也要以具體問題具體分析的態度向產品提問，而不是抱著“事不關己”的態度把需求評審環節當作過場。

04 需求評審后

作為產品的你是否有做好需求評審會的會議記錄？是否有將評審會議記錄同步給所有參會人和計劃參會但無法參會的人？有沒有做好會后確認工作？是否有明確會后任務的具體執行人、交付時間和驗收標準？如果當前需求評審未通過，是否有確認二次需求評審的時間？

就此我提出以下建議：

首先，一定要將調研紀要整理好同步給所有產品相關人員，包括你的直屬領導、銷售、項目經理、UI、UE、技術、測試、運營等。這一步可以有效減少后期出現問題后“相互甩鍋”的現象，特別是將結果同步了領導知曉，有助于整個進度順利實施或爭取資源。

其次，需要與主要的技術再次確認其是否已經明確了自己要做的任務內容、主流程情況等。必要的時候找平時溝通相對比較困難的技術，讓其對自己負責的需求進行同義轉化，簡單復述一遍以確認技術真的已經明白了需求。

最后，每次需求評審結束后對需求評審結果進行復盤：例如，整個評審各個階段是否順利？有哪些可以改進的地方？遇到過哪些問題？如果再遇到了該怎么避免？哪些技術有一定的產品思維好溝通？哪些技術需要重點關注其對需求的了解程度等。

05 寫在最后

我換過比較多的公司，其中有一家公司在需求評審時就做得比較好：

第一點，有統一的參考模板，包含會議通知、會議紀要、需求開發確認書、功能清單、數據口徑說明書、郵件匯報等。

第二點，會讓項目的核心技術盡量全程參與需求評審過程，從需求調研到需求評審結束。

第三點，會充分了解客戶各個層級對系統的需求，以用戶故事的方式轉達給技術。

第四點，團隊合作遇到困難時會開會進行復盤，而不是相互指責或則甩鍋。整個需求評審流程一環扣一環形成了閉環，所以經手的產品和項目很少有返工的現象，最多是微調數據口徑，客戶口碑還不錯。

由此可見需求評審的成功與失敗是和產品的成功與失敗直接關聯的。因為需求評審結束后形成的已確認材料，對接下來的研發工作是關鍵的指導性文件，團隊所有人都會以此為目標進行自己的工作安排實現最終的交付工作，所以必須要做到團隊成員通過需求評審實現對需求的認知一致。

想達到需求評審環節的認知一致，就需要需求評審在調研時、評審前、評審時和評審后都要做好。可以嘗試使用PDCA循環來管理，事先有計劃（Plan）、按計劃執行（Do）、設定檢查點（Check）、復盤并處理（Act）。

例如需求調研時，列好計劃要調研哪些人、哪些問題、什么時間完成調研等，按計劃執行調研工作，定期檢查調研計劃是否有按計劃執行，輸出調研報告并復盤調研過程是否順利，有那些經驗教訓可以形成知識庫等。

因此，只有項目團隊在需求評審過程中達成了共同認知，才能對后面工作的展開形成有效的溝通環境，才是做好產品的底層邏輯。

以上是我對如何形成需求評審閉環的方法論供大家參考，因文字有限，僅列舉部分，希望能對大家在需求評審時有所幫助。如有想詳細溝通的可直接找我交流，非常歡迎大家找我分享或者進一步研討。