前言
“我們是誰”
“我們是產品經理”
“我們的日常是”
“撕逼、背鍋、甩鍋”
“人在工位坐，鍋從天上來”，作為苦逼的產品經理，必須要做好時刻背鍋、接鍋的準備。
“常在河邊走，哪有不溼鞋”，其實，不僅僅是產品經理，只要身處職場中，總會有那麼一兩個鍋砸來，輕則撕逼，重則大打出手，造成團隊關係惡化，進而對團隊工作產生不可逆的影響。
與其被動的“後發受制於人”，何不嘗試“先發制人”。那麼，作為團隊“主心骨”的產品經理，我們怎樣做可以儘量避免團隊成員之間甩鍋現象的發生，從源頭遏制問題的產生呢？
通過“Case-Case”的方式重現問題，會更加明確的給我們一些實際的提示。下面我們一起跟著故事去思考，產品經理可以通過哪些方法來避免團隊之間甩鍋現象的發生。
雪崩時，沒有一片雪花覺得自己有責任
案例一：
某童鞋在剛入坑時，負責了一個簡單的數據產品，由於是數據產品，所以需求只是通過簡單的口述，就進入了開發流程，結果出了上線事故。
事後覆盤，分析原因，發現是由於Python與Java語言規則不同，導致了接口聯調失敗。測試認為已按照需求完成了測試，且代碼功能正常，問題不在測試；其他兩個接口開發也覺得自己的代碼運行正常，問題在於上線前未進行聯調，一時間三方各執一詞，開啟了“甩鍋大戰”。
那麼，針對案例裡的出現甩鍋事件，我們又該如何避免呢？
1. 漏測的測試
案例中，上線任務是依照“產品-開發-測試-上線”流程開展的，出現了上線事故，多數時候，測試作為上線前的最後一道關卡，往往也會因為測試用例未覆蓋到位，而成了直接責任人。
仔細的我們會發現，導致漏測最主要的原因就是需求沒有說清楚，問題既然已經定位清楚了，那下一步就是“對症下藥”了。
在工作中，我們經常會使用文檔用來交流，因為其具有可傳遞性和完整性。因此，像這種技術上的對接，我們必須要有一個完整的文檔對一些必要的細節進行記錄和描述，減少溝通過程中信息的遺漏，使大家都可以接收到完整有效的信息，進而保證了溝通的有效性。
所以，一份完整且清晰的需求文檔是開發環節必不可少的。好的需求文檔，需要具備以下幾點特徵：
1）正確
用戶的需求能夠被正確的滿足，且邏輯清晰無誤的被表達。
2）完備
需求文檔要儘可能完整且顆粒度較細的把所有場景、特殊情況、業務、產品、數據流邏輯都寫清楚。
3）無歧義
文檔裡所有的用詞、描述要精確，切不可出現“可能”、“大約”“在某種程度上”等模稜兩可的表述，讓開發人員去猜測我們的想法。
4）優先級
像畫原型一樣，一個產品必然由多個功能來滿足，而多個功能等待開發時，就一定要註明優先級，告訴開發我們的重點是什麼，而後是什麼。
5）可驗證
所有設計的功能，是在技術評估後，可以被準確實現，且測試驗證無誤的。
2. 低效的團隊溝通
案例中，在產品上線失敗後，由於相互甩鍋而再一次引發了團隊矛盾，上演了一場“甩鍋大戰”。究其根本原因，實則是開發過程中，團隊出現了低效的溝通所致。
因此，一次有效的需求評審是至關重要的，因此，我們可以將需求評審分為三個階段進行：
評審前
1）準備並確定相關資料的接收對象，並提前下發
相關資料包括我們的需求文檔、線框圖、原型、相關數據等。
圖2-1 需求文檔目錄
圖2-2 需求文檔思維導圖
由產品經理主導，召開一次簡單的需求評審會（強調下，再簡單的需求，也是需要拉上團隊成員開一次簡短的需求評審的）。會議前，我們需要把需求文檔、提綱、流程等提前1-2工作日通知到大家，使大家對會議目的、時長和需求有一個瞭解，以便做好評審會議前的準備工作。
2）小範圍的溝通確認方案
產品的需求文檔寫好了，但是裡面的功能和解決辦法卻不一定都可以實現，那我們在不確定的時候，就可以先去找開發私下溝通這塊的內容，在會前提前討論，達成一致意見。這樣可以避免我們在評審時，因為一個功能點實現不了或不合理而被1000次暴擊。
3）產品內部評審，降低被懟的風險
俗話說，“三個臭皮匠，能抵諸葛亮”，一個人的思維和能力往往是有限的，設計出來的產品也不可能做到面面具到。所以，在需求評審前，我們往往可以在產品內部進行一次小範圍的評審，這樣可以避免大部分需求不合理的地方，能直接有效的提升需求評審的效率，同時，也能增加團隊對我們的信任感，減少被懟情況的發生。
評審中
1）適當的強硬，在氣勢上壓倒一切
在需求評審會議正式開始前，我們一定要做好準備，針對需求裡面可能會被懟的地方，提前想好、做好應對策略，作為我們的態度強硬的底氣。
2）明確目標，做好會議的主導者
產品經理作為需求評審會的發起者和組織者，在此次評審的目的上和方向上應具有足夠清晰的認識和把控。比如討論A功能能不能被實現時，話題突然變成了該功能要不要做的問題，此時，我們就要及時的把大家拉回來，告訴大家此時所有的需求都是已經確定了的，是必須要做的，我們只需要討論出如何實現的問題就可以了。
時刻記住自己此次需求評審的目的和要達到的效果，即使在被多人手撕的時候，也不能動搖，才讓大家跟著我們評審的目標走，明白要做哪些功能點。
3）果斷出手，做好會議時間的控制者
本來一個小時的會議，硬是被開成了三個小時的長會，一場會議下，經常是汗流浹背，精神虛脫，這樣的評審效果其實並不理想。
所以，我們產品經理要做好時間的控制者，如果遇到需求模稜兩可的問題，並且已經超過了會議討論時間，還沒有商量出解決方案的情況時，此時便是按下暫停鍵的最好時機，切不可因小失大，過度糾結於局部。可以將問題確認後，記錄下來，會後完善，必要的時候開二次評審也是OK的。
4）認真聆聽，理智回應
人在接受到與自己認知不一樣的看法和觀點的時候，往往第一反應就是要打斷別人，闡述自己的想法與之分辨。這樣在會議中，很容易浪費時間，並且很能會產生爭執，脫離會議主題。
因此，產品經理作為最作為先闡述需求和解決方案的一方，必然要面對這樣的挑戰。
選擇認真聆聽，而後對症下藥，是一個尊重別人，又能獲取表述機會的好方法。
通常在被別人打斷了，我們先冷靜下來，不妨認真聽下別人的看法和觀點，並在大腦中快速形成一個思維導圖，迅速對比兩個方案，並找出差異點。再針對兩個方案的差異點，想出一個更好的解決方案。
這時，我們就可以把自己的理解複述給對方聽，在獲得對方的認可後，再拋出自己的疑惑，當發現對方顯然沒想到時，我們再引出自己的方案，獲得臺下掌聲一片，豈不美哉！
當然，這樣的臨場反應能力不是一朝一夕就能練就出來的，需得“久經沙場”方可提升。不過，這只是應對之策，還是要提前準備充足，方可先發制人，才不會陷入被動的境地。
5）定好開發週期和人員，確定產品誕辰
在需求評審順利的情況下，開發的工作量一般都能當場評估出來，會後就可直接安排上線時間了。
假如由於功能複雜，需要會後給出評估結果，那麼就讓大家會後統一評估後，再上報工作量。我們彙總後，在其結果上延後2-3個工作日即可給出線時間了。
又或是需求未評審清楚，需要二次評估時，那麼我們就在下次會議上給出結果。注意兩次需求評審會議不能間隔時間過長，時間久了，大家都會忘記最開始的需求。
評審後
會後要在24小時之內輸出會議紀要，從兩方面概述本次會議內容，不需要詳細記錄每個過程，比如每個人說的每一句話。
1）已解決的
包含已解決的問題描述、解決方案、責任人、起止時間，可以用表格的形式列在文件裡，一目瞭然。
2）待解決的
也可以用上述同樣的方式記錄下，發給大家。
RICA矩陣是呈現工作包、人、責任三者關係的管理工具，如下列圖表，“什麼人、做什麼事、需要承擔怎樣的責任”，在網格化的管理下，項目中每個角色的職責變得都清晰、明瞭，易於管理，我們可以將其作為產品/項目管理的工具。
這樣一來，既獲得了大家對需求的一致意見，也確保了需求的可操作性和團隊之間溝通的順暢和有效性。
3. 未識別的風險
在項目中，團隊成員都要有敢於質疑的精神。如果大家都能保持這樣的警惕，那麼案例中的問題，是否會有可能被避免掉呢？答案是肯定的。
所以，作為產品經理，我們首先要明確，風險識別是風險管理的一部分，是貫穿整個產品開發生命週期的，在生命週期的不同階段，關注的風險點也是不一樣的。
那麼在實際開展工作中，我們該如何儘早識別風險呢？
在項目管理中，風險經常被分類為以下幾種：
1）外部風險
主要來自於項目開發環境，比如社會環境、國家的政策法規的變化；自然環境的變化，如地震、水災、火災等的發生，會給項目帶來風險。
2）組織風險
主要來自公司內部，如公司領導支持不到位，缺乏資金或外部資源；項目組中人員流動、內部部門壁壘等。
3）項目管理風險
常見有計劃不到位、產品立項太草率，脫離用戶和市場需求；產品經理、項目經理不懂得如何採用項目管理方法去管理風險等。
4）技術管理風險
需求評估時，對功能實現的技術評估不到位導致後面實際開發中出現很多技術難點、專利等技術壁壘帶來的風險。
同樣，對於產品管理來說，我們也可以用上面的方式來提前識別風險。
比如：
設計階段
我們要關注：“是否會缺乏相關的技術專家對技術可行性的評估”，“產品的需求定義不清楚是否會造成後續不斷進行變更”，“產品的目標客戶不明確，開發出來的產品是否要對哪個市場和需求負責”等問題。
開發階段
則要考慮：“需求夠不夠明確”，“公司管理層意見不統一，是否會突然停掉開發”，“團隊角色定義不清楚，缺乏有經驗的成員”等問題。
做好對常見問題的排查工作，以達到預識別風險的目的。
然後，就是要做好風險收集。作為風險識別的主要責任人，我們需要及時的收集到大家在產品開發過程中，提前識別出的問題，並將其登記在冊。
最後
產品在最終上線出現了問題，必然是由眾多因素所致，所以才會出現團隊甩鍋現象的發生。
出現問題不要緊，重要的是，聰明的我們要學會用“二八法則”，很好的分離出那20%的最主要原因，針對甩鍋事件的具體問題，提出針對性的方案。
本文由作者@晚如一 在PMCAFF社區發佈，轉載請註明作者及出處。
閱讀更多 PMCAFF產品經理社區 的文章
