說明：這個系列中可能會涉及到我身邊朝夕相處的團隊，雖然我會狠心地把我們踩過的坑，犯過的糗事拿出來曬，但這絲毫不影響我對產(chǎn)品經(jīng)理的高度認可，還有研發(fā)團隊的感激。實際上這是一支我認為最能體現(xiàn) One Team 精神的團隊。我為身處這樣的團隊而自豪，當然我們要改進的點還太多太多。

在分享具體的案例之前，讓我們先花點時間聊一聊需求評審。

某團隊需求評審的故事

1. 安靜的需求評審會

某天去參加團隊 A 的一個需求評審會，小小的會議室里擠滿了十來號人，中間產(chǎn)品經(jīng)理正在講解新版本的功能需求。奇怪的是從頭到尾幾乎沒有一個人打斷產(chǎn)品經(jīng)理，問一句：我們到底為什么要做這個功能？這個功能到底命中了用戶的哪些痛點？它又是如何解決用戶的痛點的？如何判斷這個功能實現(xiàn)的效果？用什么指標？

最終需求評審在研發(fā)詢問產(chǎn)品經(jīng)理想什么時候上線中結(jié)束，多么和諧而高效的評審啊。

但是總有那么一小撮人屬于來搗亂的，對此很不滿并公開表示研發(fā)要多挑戰(zhàn)、PK 產(chǎn)品經(jīng)理。研發(fā)帶著迷茫的眼神，“可是我們不知道該從哪里 PK 啊？”，“感覺產(chǎn)品經(jīng)理說得都有道理啊，沒什么好反對的??？”，“我們也不知道數(shù)據(jù)，想 PK 但說不過人家”

于是這一小撮搗亂的人給研發(fā)開了小灶。

2. 開不完的需求評審會

大概一個月后，第二次大版本評審開始。這次產(chǎn)品經(jīng)理驚奇地發(fā)現(xiàn)氣氛有點不對。

研發(fā)同學幾乎是帶著打倒一切產(chǎn)品經(jīng)理提出需求的姿態(tài)來開會的，產(chǎn)品經(jīng)理提出的每一個需求都遭遇了無情的激烈反駁和質(zhì)疑。每一句話剛說出口就引來若干個問題：理由呢？數(shù)據(jù)呢？你怎么說服我們做這個呢？

產(chǎn)品經(jīng)理一臉為難，“同學們，這個功能是新功能，之前沒有做過，競品也沒有，你讓我給數(shù)據(jù)我現(xiàn)在也給不了啊！”

“沒有數(shù)據(jù)那就是無法衡量了，那這個需求我們怎么知道該做不該做啊"

“可是你們不做，哪來的數(shù)據(jù)啊？”

“那你怎么證明這個需求的價值呢？”

。。。。

這研發(fā)估計是要造反了吧？—— 躲在角落的幕后指使者心想

最終大版本的需求評審以創(chuàng)記錄的接近2.5個小時才開完。而結(jié)論是 —— 產(chǎn)品重新回去想。需求延后。

研發(fā)同學帶著完勝產(chǎn)品的驕傲走出會議室，勝利的喜悅溢于言表。我們終于敢和產(chǎn)品 PK 而且贏了！

幕后指使者看了看表，撓撓頭，唉~~~

3. 不知所云的需求評審會

在第二次大版本評審會之后，搗亂分子又不甘心落敗，在隊伍內(nèi)部組織了好幾次討論，評審的形式也變化了好幾次，終于略有改觀。

這日子改好過了吧？Too young too simple，sometimes naive

某日 UI 評審，一屋子的產(chǎn)品、研發(fā)、UI。評審開始，UI 先介紹視覺稿，隊員甲首先拋出質(zhì)疑

“我覺得你這個顏色很難激起用戶參與的欲望，你覺得呢？”

沒等 UI 回復，隊員乙又再拋出一個問題。

“你這里面圖片太多，會影響性能”。

“我覺得挺好的啊”，UI 松了一口氣

“ 就是這個方案用戶需要理解你圖片的含義，會讓用戶參與門檻很高啊” 。隊員丙冷不防再補一刀。

BlaBlaBla。。。UI 同學的臉色越來越難看。

這個時候幕后指使者實在忍不住了，“我們到底在討論什么”？

“我們在對 UI 稿進行評審啊”，齊刷刷一致的答復。

好吧~

故事講完。

我們在談論什么？答案是我們在討論：什么是需求評審，以及需求評審的正確姿勢。

各位看官，要不你先幫團隊 A 把把脈，看看癥狀是什么？該如何下藥？

明天再接著聊，困了。

晚安各位！