評審PRD老被懟?拆解評審會減少被懟

玩新媒體,引流、轉化、留存3大難題如何破?通過6周系統學習,這些問題都能解決。了解一下>>

評審會是產品開發的重要環節,產品參與人需要在這個會上對關鍵要素達成一致,從而才能保證產品的順利上線。那么,評審會該如何開呢?

被懟,只能減少不能消除,減少是可以有方法,本文就講述了一個方法,人人可做到。

PRD的評審會,是一個方案的確認會,主要講產品“是什么”,為后續環節“怎么做”提供依據。

本文通過將PRD評審會議過程進行結構化拆解,然后將執行過程標準化,以解決PRD評審會常見問題,提高評審效率和質量。

本文主要對如下幾個環節的操作進行了說明:

  1. PRD評審會目的;
  2. 會議的兩大原則;
  3. 會前準備;
  4. 會議議程;
  5. 會后收尾。

一、會議目的

搞清楚目的是做事情的第一個步驟,因為有了目的才能有的放矢,確定原則,對方案進行取舍優化,對PRD的評審會議也是如此。

PRD評審會的會議目的有兩個,一主一次:

  1. 最主要的是統一各方對產品方案的認知,以便項目組協同作戰;
  2. 次要的方面是通過會議群策群力,查漏補缺。

如果主次弄混了,就會評審會變討論會,討論會是應該在方案確定之前進行的。

如果有大幅修改,不二審會有很大的認知不一致風險,進而給項目帶來額外的成本和風險;進行二審不僅延誤時間,同時還會讓合作方對你能力產生懷疑。

如何評估PRD的評審會是開好了呢?

理想情況下,所有參會人員在三個方面都理解一致且認同了:方案的整體思路、關鍵點風險點、細節設計。

然而現實中大部分項目是不可能做到的,所以可行的標準是對產品方案:

  • 整體思路理解一致且認同;
  • 關鍵點風險點理解一致且認同;
  • 對需要注意的詳細設計點理解一致且認同,大部分的設計可以不記得,回頭看PRD。

主要是需求目的,方案的實現思路、實現方式、實現程度、實現范圍、時間計劃、已知風險的理解達成一致。所謂認同,就是在對疑問進行質詢后,認為方案可行。

二、會議兩大原則

  1. 問題解決在會前;可能的問題,有預案;
  2. 就事論事,好的建議要吸收。

我們可以借助一個場景來理解:

有個大集團M,對某個功能的設計方案進行招標,產品方案就是針對這個招標進行的方案。

PRD評審會就是這個招標評審會,會議直接決定了你能不能拿到這個大集團合同,賺到錢。對方參與招標評審的是除產品經理外的相關方。

這時應該如何去做,才能最大可能的通過招標評審,拿下合同,限制條件是沒有灰色行為。

總結起來,其實就是上面的兩條。

三、會前準備

要將問題解決在會前,就需要充足的準備,一個會開的順利不順利,會前準備的工作可以占到80%,另外20%才是在會上取得的。

這個會前準備包括兩個方面:溝通準備,資料準備。

如果我們要拿下上例中M集團的合同,對他們的關鍵人員提前接觸是必須的,當好服務員,服務周到也是必須的。

1. 溝通準備

是指要在開會前與關鍵人員就方案進行溝通,并有一致的認識。

1)?包括與業務方進行溝通,對方案思路、關鍵點達成一致。

2)?與項目執行人員(設計、開發、測試等)對方案進行建議和提出意見的人進行溝通,提前掃雷。有兩個方式,一個是將產品方案郵件給相關人員,請他們將問題郵件發回來,你在針對每個問題進行回復;另外一個是一對一的進行溝通,可以微信、可以面對面。

3)?提前建立微信或者QQ、釘釘等項目群,將核心人員拉入。

2. 資料準備

1)?將PRD文檔上傳至約定位置(如?Teambition、leangoo等寫作工具,也可能是直接郵件附件,各公司不一而論);

2)?提前至少一天發出PRD、原型等資料,盡量提前2-3天,如果大型項目還要提前。

目的是讓項目成員有足夠的時間了解方案,只有了解了,PRD評審會時,講解時才容易理解,不會出現一些初級問題;同時只有了解了,才更可能進行有效的評判和提出一些有價值的問題。

收件人是所有與項目相關的成員,包括業務方、設計、開發、測試,抄送自己的主管、各方的直接主管;如果有約定,可以按約定抄送,比如有些公司要求小組(部門)負責人必須參會,就需要將其列入收件人而不是抄送人。

發送時機在與關鍵人員就方案基本達成一致之后。

3)?預訂會議室,并發送會議邀請。

會議室要提前訂,沒有會議室預訂制度的公司,最好提前在會議室門上貼個紙條,說明占用時間。變更會議時間可能會導致人員不齊,或者影響項目成員原來的工作計劃。

會議邀請的標題,要直接體現是什么項目的PRD評審,寫清楚時間、地點、參與人員、附帶PRD文檔或者文檔地址。實際操作中也大部分會將發送資料和發送會議邀請兩件事,合二為一進行。

4)?提前考慮好哪個地方需要重點說明、哪些地方容易被挑戰,可能有什么問題會被扔出來。

5)?指定會議的記錄人員,正常情況下,是由產品經理自己記錄。

6)?如遇時間變更,及早通知參會人員;不要漏了,會被罵的。

四、會議議程

作為一個格式會議,會議的議程是固定且相對簡單的,主要包括三個部分:

  1. 介紹項目背景、方案目標、期望時間;
  2. 介紹方案、答疑、討論;
  3. Review會議記錄,會議成果確認。

1. 介紹項目背景、方案目標、期望時間

介紹背景、方案目標有些同學不會去做,但這并不是一個可省略的環節。

因為項目背景和目標是方案思路的基礎,包括了很多的限定條件,介紹后容易讓參會人員理解你的設計思路,理解你設計出發點和設計終點,從而在視覺方案、技術、測試方案設計時,在大方向上能夠有所遵循。

另外一個好處是,給參會者強調了共同目標,會形成站在一條戰線上,如何去共同努力去實現目標的思維方向,而不是有略微對抗的思維。例如,沒說明時,技術同學可能會跟你爭,“方案太差,工作量太多”;但是說明目標后,技術同學的思維很可能轉變為“如何能更好的實現這個目標”。

雖然工作量大,但是對目標有益,這就是站在一起了。

介紹方案時,要按照總-分的順序進行,先概要介紹一下思路、結構,再分塊詳細介紹。

正常情況下,各公司的PRD模板雖有所不同,但應該也都是按照總-分結構設計的。有些同學喜歡在原型上講,PRD輔助;有些同學喜歡在PRD上講,原型輔助,都是可以的,看團隊磨合情況,前一種情況多一些。

2. 介紹方案、答疑、討論

在講的過程中,還要進行答疑。如果參會者有疑問,一般采用馬上提出或者講完一個模塊再提問的方式,主講人要進行答疑,這個過程中也可能會發生方案變更,如果變更就要記入會議記錄。

如果答疑過程中產生了一些不能在會上立刻決策的問題,要在會解決,也要記入會議記錄的未決事項,同時需要確定跟進人、反饋時間。

答疑環節容易發散,導致會議失焦,需要注意幾個事情:

最經常的事情是討論著就進入技術實現細節,這個要及時拉回,技術實現細節是技術方案環節的事情;還有可能進入的是設計細節,也需要及時拉回;還有可能遇到的是“我覺得用戶不是這樣的,而是這樣的……”類似對方案的挑剔問題,這時就是體現專業性的時候,拿出理由說服他。

除此外還需要從長遠考慮,跟設計、技術有一個約定,產品設計環節雙方都是感覺僵持不下時,應該聽產品的,產品對設計方案負責。

但是這個過程要注意硬剛和拍腦袋決策,在確信自己方案的前提下進行,否則就應該作為未決事項,會后進行解決。

經過結果說明和答疑環節,會議記錄應該有變更事項和未決事項的記錄,對每個會議記錄,所有參會者花幾分鐘一起進行一次確認。檢查是否每個未決事項都有跟進人、反饋時間。

3. Review會議記錄,會議成果確認

Review過會議記錄后,需要讓項目后續各方給出自己的反饋時間表。如果能當場確定完成時間的當場確定,不能的需要給出可確定的反饋時間。

例如,一個項目設計工作量小,但是開發大,這時設計可能直接給出設計稿評審時間是下周二,而技術則只能給出來“周五給你技術方案完成/評審時間”。將各方后續的執行動作、跟進人、時間記入會議記錄。

4. 關于會議記錄

所有會議都要記會議記錄。記錄的原則是:記不同、記結論。

記錄與原來方案不同的地方,包括修改和補充;記錄對某個問題的討論結果;對只是疑問-解答而未進行變更的無需記錄;記錄結果也可能是確定的問題解決方案,也可能包括后續跟進人,反饋時間等會議成果。

5. 關于會上爭論

評審會議相比復盤會、總結會是相對更好開的一個會,因為這個會不涉及敏感的責任劃分。

如果出現爭論,幾乎都是對方案的討論。對解決這種討論,我總結了一個三步法,可以比較好地解決:

  1. 跳出爭論細節,雙方重新回歸功能的設計目的,確認目的是相同的;
  2. 確認方案的基本原則,比如是安全優先,時間優先,還是先有后優等,簡單需求這步是被省略的;
  3. 根據目的和基本原則進行方案取舍。

盡量不要出現“我覺得用戶XXX”這樣的用語,這個句子表達了自己兩個狀態特點:一個是我對這個事情沒有考慮清楚;另外一個是這是我個人感覺,有猜測的成分。

如果想用這個句式,請將問題拆分的更細,從可觀察的用戶行為、事件上進行分析,以邏輯說服,或者用數據說服。

如果相持不下,可以“這個問題我們先記下來,會后我再想想,到時還需要向你請教”。

五、會后收尾

會議開完了,不代表PRD的評審工作已經結束,還需要做如下幾件事情:

  • 整理會議記錄并發出,建議在24小時以內;注意變更、未決事項的跟進人、跟進時間;與會前PRD接收人相同,大體是所有參會人員、各方主管(視項目大小發到不同層級)。
  • 對已確定需要方案修改的部分,進行修改;如果是方案未決,盡快與相關方確定掉;上傳/發出更新后的PRD文檔;需要列出修改的內容,注意范圍與第一個PRD要相同,只多不少;通知項目組PRD文檔已經更新。
  • 通知項目組PRD文檔已經更新;至此PRD評審會議才算告一段落。

 

公眾號:qusujiyuan;微信號:qusujiyuan2151

本文由 @曲速紀元 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自Unsplash,基于 CC0 協議

給作者打賞,鼓勵TA抓緊創作!
1人打賞
評論
歡迎留言討論~!
北京赛车投注