隨着羊群人數的不斷增加，使得大部分同事改成居家辦公和線上會議。線上會議的特點不用提前搶會議，不用擔心會議時長，頂着40℃的高燒，聽者需求評審會，也不知道燒了多久，睡了多久，會議開了多久....
需求評審會經常被大家吐槽時間久，最終問題得不到解決似乎是無法破解的問題。我記錄了最近幾次PM組織的評審會過程，發現一些問題，並想到一些可以改變的方法。
問題1
開場一句話背景和模糊的收益
介紹背景和收益必不可少，這是團隊成員在初期達成目標一致的必要過程，並且通過說明相關成員能夠認同該項目的價值和意義，通常一句話輕描淡寫是不夠的。
建議：充分做好會前功課和線下溝通，保證會上快速達成一致
①老項目要介紹上一個版本歷史數據分析結論或者用戶反饋問題分析結論。
②新項要使用SWOT等分析方法，明確自身的競爭優勢，市場規模等核心問題。
③競品分析講結論。不要挨個講競品，也不要講字號和顏色等細枝末節問題(可以在需求文檔中給予參考建議)，注重戰略層面和功能層面的差異介紹，以及那些適合自身與競品之間的差異。
④本次要解決的問題，也就是具體我們要做什麼。不需要複雜的論述，簡單列出本次需求點，一目了然。
⑤清晰表述項目價值。講明白本次優化能給項目帶來多大的價值，以及是如何推導出來的，讓團隊成員信服。價值一定是可以衡量的，我們常聽到項目的價值是提升用戶體驗，但實際既沒有用戶滿意度等用戶指標，也沒有具體收益等業務指標，那這就是不可衡量，全靠感覺，項目後期對於方案的討論分歧點會很多。
⑥不要一開始就甩鍋給老闆。很多PM在開會時功課做得不夠，被問到一些無法回到的問題時直接說這是老闆讓做的，如果覺得需求有問題可以去找老闆，這樣的結果大家以後對於項目態度都會變成應付了事，PM自己的工作後續也很難推進。
問題2
上來就講原型，陷入細節紛爭
PM喜歡畫原型喜歡講原型應該是不爭的事實，還有一些PM對原型的精美度要求還很高，於是需求確認前就找交互設計師按照自己設想完成交互設計，很多不完善、不合理的地方也很強硬的要按照自己的來。需求評審會上來講原型很容易讓團隊成員陷入界面的細節爭論不休，開發又會追問每個有台邏輯，評審會你一句我一句就亂套了，同這時通常設計也會與開發一邊，表示出不滿。
建議：清晰且詳細文字的描述產品邏輯及字段
①清晰表述產品中所有的字段、數據格式以及相應的邏輯。讓開發能看懂所有功能邏輯、操作邏輯、展示邏輯，設計能看懂產品需要用戶如何操作以及限制條件，通過文字能明白整體需求邏輯關係。
②儘量使用文字描述。我們發現當圖和文字同時出現在文檔中時，設計師和前端更偏向於看圖，後端會細看文字描述的邏輯，這樣到了打法階段容易形成gap，導致新的問題產生。
③產品畫的原型會影響設計師的思考，造成設計師被帶跑偏，甚至一些強硬的PM要求設計師按照記得來，這樣一來設計師不想給自己找不痛快，就按照美工的標準應付完工，並沒有發揮真正的價值。
問題3
需求評審開成技術評審
很多時候在評審會上開發人員會就從能不能實現聊到怎麼實現，然後聊到各服務端如何來配合，一聊起來就沒完沒了，線上會還可能隨時就拉個新成員進入參與討論，需求背景又要被重複。此時的需求還沒有定論，占用大量會議時間討論技術實現明顯是不合適的，浪費大家寶貴的時間。
建議：做好會議把控，控制問題討論邊界
①PM在會議中要起到把控的作用，會上不討論技術實現方案，只討論需求是否合理，技術可否實現，如果當時不能確定能否實現的，需要記錄todo在規定的時間內反饋。
②對於一些不確定的技術問題，或可能存在爭議的難點，最好在開會前就能和技術負責人了解清楚技術背景，做好功課，防止在評審會上被牽着鼻子走。
問題4
跑題
跑題通常是不知不覺的，甚至全體參會人都享受其中，越聊越嗨，忘記了開會真正的目的。印象比較深的是一個方案要主管確認，主管從這個方案聊到了另一個項目，開發順着另個項目聊到了項目進度，遇到的問題。整個評審會成為了另一個項目的匯報會，到最後也沒確認當前方案。
建議：明確會議目標，時刻關注會議方向
①PM會前要和主觀確認好方案，以保證內部一致性，會上主觀只要回復確認沒問題即可。
②放下面子敢於說話。很多時候PM不太好意思打斷大家的對話，這樣就不能把跑題扼殺在搖籃里。
總結一下，就是立足本職做好自己職責範圍內的工作，承擔好項目角色。
啥都別說了，點它就對了
留言列表