5千字拆解【需求評審】,讓評審效果最大化

5 評論 16785 瀏覽 113 收藏 24 分鐘

需求評審是需求分析過程中的最后一個階段,可以分為組內需求評審、技術需求評審、客戶需求評審等。本文作者根據自己的工作經驗,對需求評審的過程進行了拆解,希望能給你帶來一些幫助。

需求評審是需求分析過程中的最后一個階段,本文結合自己的經驗對評審過程進行拆解,希望能讓我們的評審更順利,同時及時發現自己在評審前工作的不足之處,持續精進。

之前的文章中寫過需求洞察(從收到需求到明確需求——需求洞察)、需求變更(頻繁的需求變更讓你痛苦過嗎?)、需求蔓延(需求蔓延的復盤與思考)、需求講解(如何做好一場需求講解),再加上今天的需求評審,和需求相關的幾大重要節點就整理完了,后續我會繼續補充其他和需求相關的內容,歡迎持續關注~

言歸正傳,需求評審基于參與的人員不同、評審的目標不同、所處的階段不同,也可以再細分為組內需求評審、技術需求評審、客戶需求評審等,當然有些關鍵需求可能還會涉及與公司領導層進行評審。不同的情景下,我們評審的側重點和注意事項也會有很多差異。

雖然有很多差異,我還是盡量以標準化的形式進行拆解,再針對部分差異單獨說明。

全文概覽:

  1. 評審是評什么
  2. 評審的目標
  3. 評審前的準備
  4. 評審中的講解
  5. 評審中的討論
  6. 評審后的結論
  7. 評審后的完善

01 評審是評什么?

1)評審業務方案是否滿足原始需求

最基礎的目標,就是確認本次解決方案和原始需求是否貼切,通過我們深入的需求洞察和方案整理后,是否能夠滿足業務提出方的要求。

2)評審工作量是否可控

尤其對于有技術團隊參與的需求評審,他們需要對本方案的開發工作量進行預估,可能一句很簡單的方案但在執行時卻很復雜。

同時如果涉及到關聯方的改造,對方是否愿意配合,對方對我們的進度計劃是否接受,也是需要在評審過程中最終確認的(當然有些情況不需要在需求評審會確認,這里不再單獨羅列)。

3)評審方案是否滿足業務規劃

本次方案除了滿足原始需求之外,可能需要領導或者業務相關的其他負責人評估本次的方案是否支持后續的場景拓展,是否支持系統的中遠期規劃。我們也會遇到即便方案滿足原始需求,但有些業務規則的制定存在局限性的情況,這時為了后續業務的拓展,本次規則也需要同步修改。

不知道你是否聽到過客戶或者領導這樣的話:“這塊后續打算XXXX做,還要和XX系統對接上,你們要留個口子”。

這里與技術側的設計評審有相通之處,即便本次只是做MVP流程,但為了滿足后續的版本迭代,在設計時功能結構上也要對應滿足拓展性。

4)評審可行性是否合理

同樣的場景,會存在多種實現方式,需求人員在制定方案時可能只站在業務角度或個人經驗角度進行分析,但其他角色可能會有更優的、更貼合現狀的解決方案。

所以對于方案細節的合理性評估,也是本次評審的重點內容。

5)評審邏輯結構是否嚴謹

最后,對于很多評審而言,針對關鍵業務的邏輯規則嚴謹性也需要詳細確認。此時可能需要技術負責人、測試負責人發表自己的意見,對關鍵細節提出質疑并形成多方認可的解決方案。

以上提到的評審內容,不同團隊、不同業務模式,都會存在差異,每個參與評審的人員出發點不同,關注點不同。

雖然不能一概而論,但既然做評審,我們就是要圈定一個范疇,讓多方角色對這件事達成共識。

02 評審的目標

雖然說評審都是為了讓大家達成共識,但不同的參與人,不同的背景下,評審的目標也是不一樣的。而且不同的目標也會影響我們在具體評審過程中的流程和側重點。

1. 內部評審

屬于產品組內部的評審,會涉及其他產品同事、產品總監,當然也可能會邀請一些其他組的相關成員提前參與。

這一步的目標更偏向于整體方案的合理性、完整性以及和版本的規劃、市場反饋的優先級等綜合商討,具體功能的實現方法是否滿足當下訴求。

其中方案撰寫人可能在某個問題上有多個方案,或者無法權衡具體優劣,都可以在內部評審時先由產品團隊內部討論進行初步抉擇。同時要向組內的伙伴們講解關鍵功能的設計思路、背景原因等。

因為產品組內同事,都是你“最親密”的戰友,我們面對相同的合作環境,工作方法論也是相互貼近的,他們也是最能理解你的。所以在內部評審時,只要時間允許,我更傾向于【細致】。

對于產品組內評審,我認為的關鍵詞是:盡量完整。

5千字拆解【需求評審】,讓評審效果最大化

2. 技術評審

技術評審是和開發團隊進行評審,更側重于方案的落地性分析、工作量初步評估,疑難雜癥的解決方案商討,同時需要技術團隊幫我們查漏補缺。

尤其是涉及功能迭代的需求,可能我們認為一個很簡單的功能,在實現時需要傷筋動骨。

技術評審則需要我們把需求講明白,不要遺漏,同時結合開發人員提出的工作量、工期等問題進行權衡、補充或刪減。

同時我們可以通過他們的關注點更加理解技術思維,在后續的版本迭代過程中,合理的融入一部分技術思維來制定方案(當然這里面也有一個“尺度”問題,具體可查看歷史文章:辯證難題 | 產品經理要不要懂技術?)

對于和技術團隊進行的需求評審,我認為的關鍵詞是:工作量。

5千字拆解【需求評審】,讓評審效果最大化

3. 客戶評審

對于外包類項目等需要客戶方參與的需求評審,很多情況下評審會變成一個不可裁剪的流程節點。雖然有些可能是走個過場,但我們要認識到這次評審的重要性。

在評審時盡量解決之前因為協調困難等原因而遺留的需求問題,需要趁著領導在場時“拍板”或者“授權”或者“推進”。

客戶評審時除了我們的需求人員、項目經理,客戶方的領導,還可能有其他關聯方的配合人、其他業務部門的協作人等等。因為涉及成員比較復雜多變,所以通用的方法論也不像另外兩個評審標準,但更能體現需求人員的真實水平。

評審已經是最后一個階段了,如果前期工作到位,評審過程會很順利。一旦在評審時狀況百出,困難重重,那一定要回顧自己之前的階段是否有不到位的工作。

對于和客戶進行需求評審,我認為的關鍵詞是:簽字。

5千字拆解【需求評審】,讓評審效果最大化

4. 領導評審

其實和公司領導進行需求評審,會摻雜更多“匯報”的意味。如果前期匯報及時,最終的評審也會比較簡單順利。

如果前期領導比較忙,或者你們溝通的不及時,那也可能會在評審時對方案產生戰略性轉變。

而且對于領導的評審,可能更需要的是言簡意賅,挑重點,畢竟領導的時間也不會很多(這里和客戶評審在時間上的要求也比較類似)。

對于和領導進行需求評審,我認為的關鍵詞是:支持、授權。

5千字拆解【需求評審】,讓評審效果最大化

雖說每種評審形式有各自的側重點,但我認為最基礎的目標依然是為了形成多方之間的“執行對齊”。

03 評審前的準備

組織起一場正式的需求評審不太容易,所以為了讓評審的目標更容易達到,讓評審的價值更好的體現,我們在評審之前一定要做一些準備。

首先,主講人要對本次評審的需求和方案很熟悉,對一些具體的實現步驟產生的原因很了解(因為可能涉及工作交接、人員變動等情況,有些功能不一定出自自己的思考。延伸閱讀:工作交接中的“交”與“接”)。

5千字拆解【需求評審】,讓評審效果最大化

這樣既能保證講解過程的連貫和全面,也能確保在提問、討論環節的“穩定性”(包含情緒的穩定、思路的穩定、溝通表達的穩定)。

其次,我們要盡量讓參與人在會前對整個文檔,或涉及到自己工作的內容進行提前閱讀。雖然我們無法保障閱讀的質量,但是這一步的要求不能省去。因為屆時我們無法保證臨時性的理解能否真正到位,能否對此功能有全面考量。同時預防一些“漫無邊際”的想法影響評審的正常進行。

5千字拆解【需求評審】,讓評審效果最大化

而且,對于客戶評審來說,我們在評審之前,絕大多數問題都應該已經提前溝通完成,該確認的問題也確認清楚,需要關聯方配合的內容也已經私下確認,此時不應該遺留太多的問題準備在評審會上討論(特殊情況除外),從而提前保證評審的連續性和目標感。

最后,我們需要協調好時間,發會議通知(形式不限),并且準備好講解過程中需要用到的文檔、物料等。還要單獨準備一個文件或記事本,將討論過程中的遺留問題記錄下來,把待確認的問題列清楚,免得遺漏關鍵內容。

5千字拆解【需求評審】,讓評審效果最大化

04 評審中的講解

這里又涉及到需求講解的很多方法和細節,我在之前的文章中雖然總結了需求講解的注意事項,但是針對需求評審中的講解還有一些特殊的情況。

1. 針對評審內容和參與者,適當調整講解的細致程度

  • 我們以客戶評審為例,如果有大領導參加,而且需求的內容很多,那我們需要挑重點的功能來講解,并且不需要講解具體的規則;
  • 如果有很多關聯方參與,則側重點在這些關聯方如何配合,關聯方在整個平臺中扮演怎樣的角色;
  • 或者某些功能屬于產品的標準化流程,則也可以加快進度,重點講解特色化功能的邏輯關系。

總之一句話,同樣的內容根據不同的聽眾一定有不同的講解套路,我們要知道對方更關心什么,同時時刻提醒自己本次評審的目的是什么。

我們所有的講解、討論,都要基于目標而來。

2. 針對評審參與者與背景,適當調整宏觀場景的描述

  • 比如功能的迭代評審,宏觀場景描述更多側重于本次為什么要迭代這些新功能;
  • 如果是0-1的新系統評審,則要把需求的背景,整體的參與角色、場景通過流程圖或其他形式表達清楚;
  • 如果內部評審或技術評審大家對這部分內容很了解,則可以更快的直奔主題。

3. 搭配更易懂的表現形式

文字的表現力一定不如圖形、動畫。為了讓聽眾能夠更快的理解,或者避免對方和自己思路不同頻,我們可以搭配流程圖、原型圖、UI圖等物料來輔助自己的講解。尤其是相對復雜的處理邏輯,基于流程圖的講解能讓結果事半功倍。

如果條件允許,在講的過程中在白板上寫寫畫畫,不僅能更抓住聽眾的注意力,讓對方更好的理解,還能對講解人的水平有充足的認可,后續討論過程也會更信服你給出的方案。

去年有一個新系統的建設,客戶評審一共進行了兩個半小時,我針對系統的核心流程圖的講解、討論就占了一個多小時。而這些關鍵內容真正梳理清楚并讓大家理解后,后續的細節其實就沒有那么重要了。

而且通過這次評審,讓幾位關聯方負責人很認可我們的方案,后續推進執行過程也很順利。

05 評審中的討論

這一步其實是最不可控的,也是最容易產生風險的。因為我們無法預估對方的思維會對整個方案提出怎樣的影響。

但換個角度來考量,這個過程又是一個學習進步的時機,我們通過不斷的吸收對方的意見,并快速甄別篩選,想出應對策略,本質對自己的能力也是一個很高的要求。

同時還可以以同理心站在對方的角度深入考慮,他為什么如此關注這個問題?他為什么會想在這里加這個功能?他為什么對我的方案產生質疑?

這一系列的過程,最終都能夠讓我們通過本次評審“成指數型”成長。

具體問題和應對策略不再深入分析,這里總結幾點小建議供大家參考:

  1. 關注核心目標,不要讓發散性問題影響整體的評審進展;
  2. 關注問題根源,不要讓臨時性的方案為后續埋雷;
  3. 合理控制討論時間,不要讓評審變得“又臭又長”;
  4. 關注領導關注的內容,優先解決領導的問題;
  5. 及時甄別問題,不要因為小問題引申出大問題;
  6. 客戶評審時,討論的過程很容易引起需求變更和需求蔓延,要提前和自己團隊的人,或者關聯方的人提前溝通好,屆時一起“打打配合”;
  7. 討論的內容無論結果與否,都記下來,用于會后自己的復盤總結。

06 評審后的結論

評審即將結束時,一定要進行現場的總結。

總結依然要與本次評審會的目標相結合,并將遺留問題、或會中討論的結論進行復述,一是為了再次強調這些內容以免遺漏,二是避免大家仍然對這些討論結果沒達成共識,后續推進時又要重新掰扯。

同時對于遺留問題要列好推進周期、關聯人,并且對下一步的工作進行初步確認。

比如客戶需求評審完成后,遺留了5個問題,兩個需要完善方案,兩個需要找關聯方協調確認,一個屬于遺留問題,要等到某個階段再來決定。

  • 這時我們需要向參會者表達新的方案什么時間能夠完成,屆時會再更新一版供大家查閱;
  • 確認兩個關聯方的協調時間和人員,由誰負責主導,什么時間能夠確認下來;
  • 還要把遺留問題的風險提出來,而且等到可以做決定時不要遺忘,并且不能對項目的整體進展,上線驗收等產生影響。如果存在類似的風險,則要提前確認折中方案或置換方案。

最后確認本次評審是否需要二評。

07 評審后的完善

評審結束不是終點,也可能是新階段的起點,也可能是終點前的最后一步。

我沒有見過評審后不需要完善方案的評審會,所以無論是否需要二次評審,本次的待修改點一定是必做的。

同時像上文提及的復盤、同理心思考對方的問題,并從中引申出自己業務的新思路,或者拓展自己的認知盲區,從盲區中尋找業務風險點,這些都是在評審之后,或者說方案完善后,需要持續思考的內容。

這些思考要趁熱打鐵,盡量不要擱置,因為當下的感受是最真實的,自己的思路也是更全面、更發散的。即便有些優先級低的遺留問題,也千萬不要不了了之。

即便某個功能擱置不做,作為業務人員,我們也不能不想,否則怎么更進一步呢?

當然,復盤時我們依然要把握核心目標,不僅在本次需求評審會上提到的問題需要復盤,很多問題背后反映的前期工作問題,更要能意識到。

  • 比如張三當時為什么提了這樣一個驢唇不對馬嘴的問題?——很有可能是因為你開始的講解沒有讓他聽明白;
  • 比如李四為什么把上周確認的方案又拿出來討論?——可能當時的方案沒有得到他的認可,或者他原本就沒有明白這個方案的內容;
  • 比如王五為什么昨天說好幫我推進這個方案,結果今天“反水”了?——可能是因為他發現領導并不支持這個方法,或者他突然發現了此方案的邏輯漏洞;
  • 比如趙六今天提的這個問題為什么我之前沒有想過呢?——可能是之前工作交接時沒有把此功能當做重點,也可能自己本身對業務的理解還不全面,也可能……

所以,評審雖然結束了,但我們的工作沒有結束,個人的成長也遠沒有結束。

5千字拆解【需求評審】,讓評審效果最大化

08 寫在最后

不同的目標,不同的環境,不同的對接人,不同的業務場景,需求評審過程中需要注意的內容都會有很多差異,篇幅有限,不能把更多的例子逐一拆解,但上述所整理的關鍵節點和方法論,希望能夠給有緣讀到這里的你,帶來一些幫助。

上述的內容并不絕對,比如評審時間的控制,對于客戶評審盡量不要搞的太久。但是我也遇到有些客戶會和我們一條一條過規則,戰線拉的很長??傊覀円耙蛉硕悺焙侠磉m當的調整我們的評審節奏、內容。

更不能因為客戶問的細而不耐煩,也不能因為客戶什么都不問而沾沾自喜。畢竟最終這些沒有確認的細節,都可能是后期需求變更、系統缺陷、生產事故的一個個“伏筆”。

需求是系統的源頭,在需求階段每多確認一個細節,每多達成一個共識,每多識別一個風險,都能為后續的開發、測試、投產、運維等各個階段節省很多時間。

雖然需求的好與壞很難客觀評估,但作為一個負責任的需求分析、作為一個有職業素養的產品經理,讓需求更完整,更合理,更切合實際,應是我們持久的追求。

作者:不想延期,公眾號:不想延期

本文由 @不想延期 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 學習了,還好沒有廢,但(膽)是肥了 嘎嘎

    來自廣東 回復
  2. 牛!

    來自江西 回復
  3. 寫的太棒了,很全面

    來自北京 回復
    1. 感謝認可

      來自河北 回復
  4. 支持

    來自浙江 回復