需求評審基於參與的人員不同、評審的目標不同、所處的階段不同，也可以再細分為組內需求評審、技術需求評審、客戶需求評審等，當然有些關鍵需求可能還會涉及與公司領導層進行評審。不同的情景下，我們評審的側重點和注意事項也會有很多差異。雖然有很多差異，我還是儘量以標準化的形式進行拆解，再針對部分差異單獨說明。最基礎的目標，就是確認本次解決方案和原始需求是否貼切，通過我們深入的需求洞察和方案整理後，是否能夠滿足業務提出方的要求。尤其對於有技術團隊參與的需求評審，他們需要對本方案的開發工作量進行預估，可能一句很簡單的方案但在執行時卻很複雜。同時如果涉及到關聯方的改造，對方是否願意配合，對方對我們的進度計劃是否接受，也是需要在評審過程中最終確認的（當然有些情況不需要在需求評審會確認，這裡不再單獨羅列）。本次方案除了滿足原始需求之外，可能需要領導或者業務相關的其他負責人評估本次的方案是否支持後續的場景拓展，是否支持系統的中遠期規劃。我們也會遇到即便方案滿足原始需求，但有些業務規則的制定存在局限性的情況，這時為了後續業務的拓展，本次規則也需要同步修改。不知道你是否聽到過客戶或者領導這樣的話：「這塊後續打算XXXX做，還要和XX系統對接上，你們要留個口子」。這裡與技術側的設計評審有相通之處，即便本次只是做MVP流程，但為了滿足後續的版本迭代，在設計時功能結構上也要對應滿足拓展性。同樣的場景，會存在多種實現方式，需求人員在制定方案時可能只站在業務角度或個人經驗角度進行分析，但其他角色可能會有更優的、更貼合現狀的解決方案。所以對於方案細節的合理性評估，也是本次評審的重點內容。最後，對於很多評審而言，針對關鍵業務的邏輯規則嚴謹性也需要詳細確認。此時可能需要技術負責人、測試負責人發表自己的意見，對關鍵細節提出質疑並形成多方認可的解決方案。以上提到的評審內容，不同團隊、不同業務模式，都會存在差異，每個參與評審的人員出發點不同，關注點不同。雖然不能一概而論，但既然做評審，我們就是要圈定一個範疇，讓多方角色對這件事達成共識。雖然說評審都是為了讓大家達成共識，但不同的參與人，不同的背景下，評審的目標也是不一樣的。而且不同的目標也會影響我們在具體評審過程中的流程和側重點。內部評審：
屬於產品組內部的評審，會涉及其他產品同事、產品總監，當然也可能會邀請一些其他組的相關成員提前參與。這一步的目標更偏向於整體方案的合理性、完整性以及和版本的規劃、市場反饋的優先級等綜合商討，具體功能的實現方法是否滿足當下訴求。其中方案撰寫人可能在某個問題上有多個方案，或者無法權衡具體優劣，都可以在內部評審時先由產品團隊內部討論進行初步抉擇。同時要向組內的夥伴們講解關鍵功能的設計思路、背景原因等。因為產品組內同事，都是你「最親密」的戰友，我們面對相同的合作環境，工作方法論也是相互貼近的，他們也是最能理解你的。所以在內部評審時，只要時間允許，我更傾向於【細緻】技術評審：
技術評審是和開發團隊進行評審，更側重於方案的落地性分析、工作量初步評估，疑難雜症的解決方案商討，同時需要技術團隊幫我們查漏補缺。尤其是涉及功能迭代的需求，可能我們認為一個很簡單的功能，在實現時需要傷筋動骨。技術評審則需要我們把需求講明白，不要遺漏，同時結合開發人員提出的工作量、工期等問題進行權衡、補充或刪減。同時我們可以通過他們的關注點更加理解技術思維，在後續的版本迭代過程中，合理的融入一部分技術思維來制定方案（當然這裡面也有一個「尺度」問題，具體可查看歷史文章：辯證難題 | 產品經理要不要懂技術？）對於和技術團隊進行的需求評審，我認為的關鍵詞是：工作量客戶評審：
對於外包類項目等需要客戶方參與的需求評審，很多情況下評審會變成一個不可裁剪的流程節點。雖然有些可能是走個過場，但我們要認識到這次評審的重要性。在評審時儘量解決之前因為協調困難等原因而遺留的需求問題，需要趁着領導在場時「拍板」或者「授權」或者「推進」。客戶評審時除了我們的需求人員、項目經理，客戶方的領導，還可能有其他關聯方的配合人、其他業務部門的協作人等等。因為涉及成員比較複雜多變，所以通用的方法論也不像另外兩個評審標準，但更能體現需求人員的真實水平。評審已經是最後一個階段了，如果前期工作到位，評審過程會很順利。一旦在評審時狀況百出，困難重重，那一定要回顧自己之前的階段是否有不到位的工作。領導評審：
其實和公司領導進行需求評審，會摻雜更多「匯報」的意味。如果前期匯報及時，最終的評審也會比較簡單順利。如果前期領導比較忙，或者你們溝通的不及時，那也可能會在評審時對方案產生戰略性轉變。而且對於領導的評審，可能更需要的是言簡意賅，挑重點，畢竟領導的時間也不會很多（這裡和客戶評審在時間上的要求也比較類似）對於和領導進行需求評審，我認為的關鍵詞是：支持、授權雖說每種評審形式有各自的側重點，但我認為最基礎的目標依然是為了形成多方之間的「執行對齊」。組織起一場正式的需求評審不太容易，所以為了讓評審的目標更容易達到，讓評審的價值更好的體現，我們在評審之前一定要做一些準備。首先，主講人要對本次評審的需求和方案很熟悉，對一些具體的實現步驟產生的原因很了解（因為可能涉及工作交接、人員變動等情況，有些功能不一定出自自己的思考。延伸閱讀：工作交接中的「交」與「接」）。這樣既能保證講解過程的連貫和全面，也能確保在提問、討論環節的「穩定性」（包含情緒的穩定、思路的穩定、溝通表達的穩定）。其次，我們要儘量讓參與人在會前對整個文檔，或涉及到自己工作的內容進行提前閱讀。雖然我們無法保障閱讀的質量，但是這一步的要求不能省去。因為屆時我們無法保證臨時性的理解能否真正到位，能否對此功能有全面考量。同時預防一些「漫無邊際」的想法影響評審的正常進行。而且，對於客戶評審來說，我們在評審之前，絕大多數問題都應該已經提前溝通完成，該確認的問題也確認清楚，需要關聯方配合的內容也已經私下確認，此時不應該遺留太多的問題準備在評審會上討論（特殊情況除外），從而提前保證評審的連續性和目標感。最後，我們需要協調好時間，發會議通知（形式不限），並且準備好講解過程中需要用到的文檔、物料等。還要單獨準備一個文件或記事本，將討論過程中的遺留問題記錄下來，把待確認的問題列清楚，免得遺漏關鍵內容。這裡又涉及到需求講解的很多方法和細節，我在之前的文章中雖然總結了需求講解的注意事項，但是針對需求評審中的講解還有一些特殊的情況。我們以客戶評審為例，如果有大領導參加，而且需求的內容很多，那我們需要挑重點的功能來講解，並且不需要講解具體的規則；如果有很多關聯方參與，則側重點在這些關聯方如何配合，關聯方在整個平台中扮演怎樣的角色；或者某些功能屬於產品的標準化流程，則也可以加快進度，重點講解特色化功能的邏輯關係。總之一句話，同樣的內容根據不同的聽眾一定有不同的講解套路，我們要知道對方更關心什麼，同時時刻提醒自己本次評審的目的是什麼。比如功能的迭代評審，宏觀場景描述更多側重於本次為什麼要迭代這些新功能；如果是0-1的新系統評審，則要把需求的背景，整體的參與角色、場景通過流程圖或其他形式表達清楚；如果內部評審或技術評審大家對這部分內容很了解，則可以更快的直奔主題。文字的表現力一定不如圖形、動畫。為了讓聽眾能夠更快的理解，或者避免對方和自己思路不同頻，我們可以搭配流程圖、原型圖、UI圖等物料來輔助自己的講解。尤其是相對複雜的處理邏輯，基於流程圖的講解能讓結果事半功倍。如果條件允許，在講的過程中在白板上寫寫畫畫，不僅能更抓住聽眾的注意力，讓對方更好的理解，還能對講解人的水平有充足的認可，後續討論過程也會更信服你給出的方案。去年有一個新系統的建設，客戶評審一共進行了兩個半小時，我針對系統的核心流程圖的講解、討論就占了一個多小時。而這些關鍵內容真正梳理清楚並讓大家理解後，後續的細節其實就沒有那麼重要了。而且通過這次評審，讓幾位關聯方負責人很認可我們的方案，後續推進執行過程也很順利。這一步其實是最不可控的，也是最容易產生風險的。因為我們無法預估對方的思維會對整個方案提出怎樣的影響。但換個角度來考量，這個過程又是一個學習進步的時機，我們通過不斷的吸收對方的意見，並快速甄別篩選，想出應對策略，本質對自己的能力也是一個很高的要求。同時還可以以同理心站在對方的角度深入考慮，他為什麼如此關注這個問題？他為什麼會想在這裡加這個功能？他為什麼對我的方案產生質疑？這一系列的過程，最終都能夠讓我們通過本次評審「成指數型」成長。具體問題和應對策略不再深入分析，這裡總結幾點小建議供大家參考：1、關注核心目標，不要讓發散性問題影響整體的評審進展；3、合理控制討論時間，不要讓評審變得「又臭又長」；6、客戶評審時，討論的過程很容易引起需求變更和需求蔓延，要提前和自己團隊的人，或者關聯方的人提前溝通好，屆時一起「打打配合」；7、討論的內容無論結果與否，都記下來，用於會後自己的復盤總結。總結依然要與本次評審會的目標相結合，並將遺留問題、或會中討論的結論進行複述，一是為了再次強調這些內容以免遺漏，二是避免大家仍然對這些討論結果沒達成共識，後續推進時又要重新掰扯。同時對於遺留問題要列好推進周期、關聯人，並且對下一步的工作進行初步確認。比如客戶需求評審完成後，遺留了5個問題，兩個需要完善方案，兩個需要找關聯方協調確認，一個屬於遺留問題，要等到某個階段再來決定。這時我們需要向參會者表達新的方案什麼時間能夠完成，屆時會再更新一版供大家查閱；確認兩個關聯方的協調時間和人員，由誰負責主導，什麼時間能夠確認下來；還要把遺留問題的風險提出來，而且等到可以做決定時不要遺忘，並且不能對項目的整體進展，上線驗收等產生影響。如果存在類似的風險，則要提前確認折中方案或置換方案。評審結束不是終點，也可能是新階段的起點，也可能是終點前的最後一步。我沒有見過評審後不需要完善方案的評審會，所以無論是否需要二次評審，本次的待修改點一定是必做的。同時像上文提及的復盤、同理心思考對方的問題，並從中引申出自己業務的新思路，或者拓展自己的認知盲區，從盲區中尋找業務風險點，這些都是在評審之後，或者說方案完善後，需要持續思考的內容。這些思考要趁熱打鐵，儘量不要擱置，因為當下的感受是最真實的，自己的思路也是更全面、更發散的。即便有些優先級低的遺留問題，也千萬不要不了了之。即便某個功能擱置不做，作為業務人員，我們也不能不想，否則怎麼更進一步呢？當然，復盤時我們依然要把握核心目標，不僅在本次需求評審會上提到的問題需要復盤，很多問題背後反映的前期工作問題，更要能意識到。比如張三當時為什麼提了這樣一個驢唇不對馬嘴的問題？--可能當時的方案沒有得到他的認可，或者他原本就沒有明白這個方案的內容；比如王五為什麼昨天說好幫我推進這個方案，結果今天「反水」了？--可能是因為他發現領導並不支持這個方法，或者他突然發現了此方案的邏輯漏洞；--可能是之前工作交接時沒有把此功能當做重點，也可能自己本身對業務的理解還不全面，也可能....所以，評審雖然結束了，但我們的工作沒有結束，個人的成長也遠沒有結束。不同的目標，不同的環境，不同的對接人，不同的業務場景，需求評審過程中需要注意的內容都會有很多差異，篇幅有限，不能把更多的例子逐一拆解，但上述所整理的關鍵節點和方法論，希望能夠給有緣讀到這裡的你，帶來一些幫助。上述的內容並不絕對，比如評審時間的控制，對於客戶評審儘量不要搞的太久。但是我也遇到有些客戶會和我們一條一條過規則，戰線拉的很長。總之我們要「因人而異」合理適當的調整我們的評審節奏、內容。更不能因為客戶問的細而不耐煩，也不能因為客戶什麼都不問而沾沾自喜。畢竟最終這些沒有確認的細節，都可能是後期需求變更、系統缺陷、生產事故的一個個「伏筆」。需求是系統的源頭，在需求階段每多確認一個細節，每多達成一個共識，每多識別一個風險，都能為後續的開發、測試、投產、運維等各個階段節省很多時間。雖然需求的好與壞很難客觀評估，但作為一個負責任的需求分析、作為一個有職業素養的產品經理讓需求更完整，更合理，更切合實際，應是我們持久的追求。【2023產品經理成長日曆】整合了30+位老師的原創內容和遴選自價值12000+元書籍等。每天一個乾貨內容，包括產品規劃、需求分析、產品運營、數據分析、工作技巧、每月話題討論等乾貨。
留言列表
留言列表