關于需求評審的一些實踐方法和思考

6 評論 14650 瀏覽 119 收藏 8 分鐘

開需求評審是產品經理的工作內容之一,那么如何做好這項工作呢?梳理自己在工作中的實踐和感悟,希望能找到更適合的最佳實踐方法。

需求評審的作用

1. 向他人傳達自己設計理念

如何在會議上講解清楚自己的設計思路并得到大家認可,是需求評審前應準備和考慮的問題。

2. 發現自己設計的不足,查漏補缺

一個人的思維畢竟是有限的,通過評審,讓不同角色的人員站在不同的角度審視方案,是很好地補充自己思維不足和發現方案缺陷的方式。所以,沒有評審,沒有交流,沒有討論,是一件多么可怕的事情。

3. 推動研發工作的重要節點

每次的需求評審都意味著產品研發進度又前進了一步,說明各項工作在慢慢不斷完善和向前推進。

4. 凝結團隊成員的力量

通過開會交流、討論,團隊成員對自己的工作有更清晰的認知和責任感,也是無形中團結大家向同一目標努力的一股力量。

需求評審的流程

1、版本范圍評審會

當一個版本開啟時,需要先界定此次迭代的范圍。產品經理先根據需求優先級,確定一些需要做的需求點,并對這些需求點的業務邏輯和功能設置可進行清晰地闡述。迭代需求點確認后,召集需求方(如tob系統的業務部門、運營部門等)、后端、前端、UI等干系人參加評審會議。此次會議更像是一個版本啟動會(類似項目啟動會),目的在于:

  • 正式告知需求方,接下來我們打算做這些功能,若他們有更緊急的需求,可及時提出,保證每次迭代都在做最緊急重要的需求(當然,不同的部門會從自身角度出發提出要求,此時,需要產品經理進行綜合考量)
  • 使團隊每個人對接下來將要做的事情有一個初步的概念和認知,使團隊就此事達成共識;
  • 使每個人對自己接下來的工作做到心里有數,接下來有這些活等著我;
  • 技術人員(尤其是后端)評估功能實現的技術難點及可行性,避免原型、交互等前期工作做完后,交到技術人員手上才知道有技術瓶頸造成前期工作和資源的浪費。

此次評審需特別注意:需求點講解的粒度不應過細,產品經理只要講清楚,接下來我們將要做XXX這幾條需求,每個需求大概實現的是一個什么功能即可,避免陷在業務細節中,偏離會議的主旨。

2、功能方案業務確認評審會

產品經理根據確定后的需求列表,初步完成設計原型方案后,召集業務或需求方(若無需求方,應在產品組內部進行評審)對功能設計進行評審確認。此次評審相當于方案確認會,目的在于:

  • 從不同的視角審視方案是否符合需求,是否合理;
  • 查漏補缺,通過評審,可以及早發現問題并及時補充完善;
  • 通過業務需求方的審核,使得產品設計更貼近實際需求

此次評審,講解的重點在于,每個需求點是如何轉換為頁面上的功能結構的?這樣的功能結構是如何滿足需求的?為什么是這樣的結構,設計的思路是什么?有人說,產品經理最難的是,說服別人肯定自己的設計,此次會議要達到的就是這個目的。

3、UI交互需求講解評審會

方案經過評審后,完善修改問題,無誤后,即可開啟UI設計。此時,召集UI人員講解和溝通需求。此次評審會的目的在于,讓UI理解每個頁面,為什么這個頁面上有這些功能點?這些功能點之間的聯系是什么?在講解的過程中,應著重于頁面交互和功能說明,避免過多的業務細節困擾UI。

4、前端交互需求講解會

待UI出具了交互和設計規范后,需想前端宣講細節。此次會議主要由UI負責人講解,產品經理輔助解釋。以前端人員理解規范、交互和功能設計初衷為目的。當然在開會前,產品經理應該對交互設計稿先進行審核,發現與需求不滿足的地方,并進行討論修改。

5、后端技術需求評審

業務細節規則、功能設計符合需要,需求方通過評審后,可交由后端技術設計數據表等準備工作。此時召集所有技術人員,一個個功能點進行詳細的業務邏輯介紹,旨在幫助研發人員理解業務細節,幫助他們更好地進行架構規劃和代碼編寫。

6、評審路線圖

大致可以總結成下圖,當然各項評審之間沒有固定的前后順序,不同職能間若不是強關聯,往往是并期進行的:

(在新標簽頁中打開,即可查看大圖)

需求評審的注意點

除了細節功能的講解,宏觀大框架的交代也必不可少:

  1. 交代產品定位和目標:不要一開會就馬上進入細節功能,balaba講一通,別人還沒反應過來,你給講完了。應該先交代你要做的是個什么產品?PC端、移動端?APP、H5?為什們打算做這個產品?若是后期迭代,此處交代此次迭代的目標即可。
  2. 交代產品的面向用戶:產品是做給誰用的呀?產品給這些人提供什么樣的功能呀?此次迭代的功能主要是面向哪一些用戶的呀?
  3. 交代產品的功能架構:這么多功能,他們之間的層級關系是什么樣的?是用什么樣的線索和結構組織起來的?
  4. 交代功能設計的思路:一個產品肯定有一套統一的設計思路,比如統一的信息展示、統一的頁面流轉路勁。

總結一下,大概下面這些內容是都應該講解的:

誠然,不同的項目、產品、團隊,實際的操作方式不同,但想要達到的效果一致,關鍵在于找到一個清晰的標準又靈活的適合自己的操作方式。

 

本文由 @小麻雀 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 很詳細

    來自北京 回復
    1. ??

      來自廣東 回復
  2. 今天下午開前端開發需求講解會,整個過程很沉悶和讓人焦躁,究其原因主要在于:
    1.缺少前情介紹:整份文檔沒有清晰地結構,講解之前也沒有做一個整體的說明,點開頁面直接講,很容易讓聽眾摸不著頭腦,所以更凸顯了細節講解前,一些框架性東西介紹的必要性
    2.講解思路不清晰:講解過程中,點開頁面,沒有交代頁面的作用和想要講解的主題,看到那講那,整個過程很零散,聽下來找不到一個線索可以把他們串起來,讓聽眾不知所云,更別說聽懂理解
    3.聲音小語氣平:講解者聲音太小,再加上思路不順暢,講起來都磕磕絆絆,聽著讓人好焦急
    因此,我覺得需求評審前應:1.準備好整份文檔、每個頁面的講解思路,不說寫出來,至少自己心里要打好草稿;2.培養自己的演講能力,當然不是讓自己成為演講家那么厲害的,但至少應做到,表達清晰流暢,當然思路清晰后,表達出來自然就是順暢的

    來自廣東 回復
    1. ?? 自己常常也做不到第二點 可怕可怕 ??

      來自廣東 回復
    2. 這是相隔兩年多,回來復盤嗎 ??

      來自北京 回復
    3. 哈哈哈 是呀 復盤就覺得慚愧不堪

      來自廣東 回復