国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

好久沒有寫文章了，因為最近換工作了，正在拼命學習新東西中…

上周連續(xù)針對同一個版本進行了三次需求評審，第一次進行了全范圍的評審，涉及到各方相關人員，包含：產(chǎn)品、設計、開發(fā)（客戶端和服務端）、測試；第二次產(chǎn)品團隊內(nèi)部小范圍的評審，主要是為了確定第一次評審中部分不太確定的/沒考慮到實際可能遇到的問題的需求，涉及人員：產(chǎn)品（iOS端和Android端）和運營；第三次針對那些不太確定的/沒考慮到實際可能遇到的問題的需求進行確認，涉及人員：開發(fā)和測試。等三場評審下來，就累成了狗。

一場需求評審會議變成了三場，這肯定是有問題的，是該好好檢討下了。

之前一直在創(chuàng)業(yè)公司，需求評審會基本很隨意，叫上開發(fā)、設計和老板就可以直接開始了，評審會上也會遇到一些問題，但涉及的人比較少，且一個人從頭到尾都只負責一個項目，事后基本上只要口頭確認下評審時的問題就行了。但流程較復雜的公司情況就有些不一樣了，需求評審會參會人數(shù)比較多，并且一個人可能會負責多個項目，需要重新調(diào)配資源，一旦評審中需求不確定/沒考慮周全的問題，就會出現(xiàn)多次需求評審的情況，這就極大的降低了工作效率。

需求評審時常發(fā)生的情況：

1. 與會人員對需求的目標不明確，易發(fā)散思維，最終偏離方向。
2. 對某個需求點相持不下，認為該需求不合理/開發(fā)周期長不劃算，從而導致場面混亂，長時間僵持下去。
3. 對技術方案探討不定，對問題點無限引申。
4. 遺漏評審時的待改動的需求點，會后找相關人員再次確認。

基本上遇到上面情況中的任意一種，都會將需求評審時間拉長，導致效率低下，輕則需求產(chǎn)生變更，重則需求功能無法實現(xiàn)，產(chǎn)品人員在評審過程中也容易產(chǎn)生渾身燥熱、體乏無力和頭昏腦漲的感覺_|￣|○…

那如何進行有效的需求評審呢？

我結(jié)合我自己上周做的需求評審作了一些總結(jié)，天熱了給自己拔拔罐，希望能做到更規(guī)范，減少評審時會出現(xiàn)的問題，少踩點坑。

將需求評審分為三階段：

評審前

相關資料準備（確保人身安全）

1）產(chǎn)品需求文檔

我的需求文檔里一般包含四塊：項目背景、項目目標、需求概述和需求詳細描述，必要的時候可以帶上項目風險（說明此次版本可能帶來的問題或考慮不夠完善的地方）和業(yè)務流程圖（對某些復雜功能/邏輯的分解）。

（需求文檔結(jié)構(gòu)）

產(chǎn)品需求文檔主要是要把需求的邏輯表達清楚沒歧義，對各個細節(jié)描述清晰，各輸入輸出項（涉及到表單/數(shù)據(jù)的輸入輸出）、業(yè)務流程（功能的交互步驟和數(shù)據(jù)的流轉(zhuǎn)）、計算規(guī)則（某些特定須計算的規(guī)則）、判斷邏輯 （業(yè)務流程中出現(xiàn)的一些判斷邏輯及各種判斷下的反饋情況，賬號的權限范圍也屬于這種）和一些特殊情況（如是否支持橫屏啊之類的）都要寫清楚，如果實在記不住太多，每次寫需求文檔時都會這里漏個流程那里漏個判斷的，可以整理一份適合自己的需求文檔自查清單，每次寫完后從頭到尾對照一遍。當然不能事無巨細都通通一股腦寫進去，不然開發(fā)和測試的朋友會看的很辛苦，小心被打…

舉一個活生生的反例：上周寫文檔時有一個計算規(guī)則比較想當然了，要算“累計閱讀時長”，閱讀時長嘛就是閱讀時長嘛，一句話就帶過了，然后在需求評審時就比較慘了，該如何統(tǒng)計這個閱讀時長？直接用定時器嗎？還是使用本地時間？用定時器比用本地時間相比既復雜又低效，但如果用本地時間，那用戶直接修改手機上的時間給不給累計閱讀時長？還有用戶如果一直停留在當前閱讀頁還給不給算閱讀時長？…后面對這個功能的計算規(guī)則討論了好久，最終評審會上也沒確定下來。所以說，做好細節(jié)是多么的重要！/(ㄒoㄒ)/~~

產(chǎn)品需求文檔的準確和詳細可以有效減少需求評審時的花費的時間，也能讓參會人員更清楚地了解需求。

2）線框圖

帶上線框圖而不是比如這樣或那樣，配合線框圖有利于對需求點的梳理。需求文檔里可以簡要配些線框圖方便文字的理解，不過需求評審時還是另外打包一份線框圖單獨帶著吧，可以詳細點，把交互稿也帶上。

第一次評審的時候，我忘了帶，而需求文檔里也剛好沒放那個頁面的線框圖…于是我只能讓大家跟著我一起在腦海中繪制一副圖，能不能繪出來我就不清楚了Orz…反正不要學我！

3）相關數(shù)據(jù)

帶上數(shù)據(jù)而不是我認為，一些需要數(shù)據(jù)支撐的需求點要帶上相關的數(shù)據(jù)，用數(shù)據(jù)說話。

小范圍的溝通（確認方案）

產(chǎn)品需求文檔寫好了，這個時候就可以去找涉及到本次改版的同事們?nèi)チ牧牧?，不要有寫好產(chǎn)品需求文檔就萬事大吉，接下來只要等需求評審會就可以了這樣的想法。提前小范圍溝通可以避免很多不必要的撕逼，將一些不確定的方案給確定下來，探討方案實現(xiàn)的難易程度，確保某些需求的可行性，還可以發(fā)現(xiàn)可能與原有產(chǎn)品邏輯相沖突的地方等，把這些坑都填好，這樣在需求評審的時候就可以快速走過了。

上周我連開了兩個項目的需求評審會，一個是改版還有一個是新應用的上線，改版的需求評審總共開了三次，就是最開始說的那種情況，而新應用上線的評審只開了一次而且只用了不到半小時，需求評審前和開發(fā)溝通就基本上已經(jīng)將我不太確定的方案給確定了下來，并且確保了部分不確定需求的可行性，在評審會上是一次就過。有對比才會有真相，多么痛的領悟，不要什么都等到需求評審會議上才去確認/解決，提前做好溝通工作，能大大提高需求評審的效率。但不是說提前把所有的需求都溝通一遍啦！大家都很忙，動好腦子帶好方案再去溝通！

產(chǎn)品內(nèi)部評審（確認需求）

產(chǎn)品內(nèi)部評審就是在產(chǎn)品團隊內(nèi)部進行小范圍評審，確保需求邏輯的一致性。在確定好各種方案后，最好在產(chǎn)品內(nèi)部先進行評審，特別是當有兩個產(chǎn)品經(jīng)理分別負責Android客戶端和iOS客戶端但是兩種終端數(shù)據(jù)又是用的同一個接口數(shù)據(jù)的情況，說白點，就是Android客戶端和iOS客戶端要求在大體上保持一致的情況下，為了保證邏輯的一致性，最好先進行產(chǎn)品團隊內(nèi)部的小范圍評審。

一次內(nèi)部的小范圍評審可以規(guī)避大部分需求不合理的地方，可以直接有效的提升需求評審的效率，同時也能增加其他團隊對產(chǎn)品團隊的信任感，以后辦起事來就比較方便了你懂得\(^o^)/。之前在創(chuàng)業(yè)公司就沒有碰到過這種情況，因為Android端和iOS端都是我負責的，功能是一致的，所以就沒這種情況，也就可以省去這一步產(chǎn)品內(nèi)部評審了…如果功能邏輯涉及到多個產(chǎn)品負責人，這一步還是很有必要的！

提前把需求文檔發(fā)出來（有備無患）

根據(jù)以上步驟確認好需求后就可以把需求文檔發(fā)出來了，以郵件/群聊的方式發(fā)出來，讓與會者提前查看產(chǎn)品需求文檔，不求他們能夠把需求文檔從頭到尾看一遍，但求大家能知道下個版本要做的需求有哪些，這樣前期的服務工作才算到位。

以上工作都做好了基本上就可以進行需求評審了，預約好會議室后通知相關參會人員參加。

評審中

正式需求評審時，帶好必備品，就可以開始了，基本上只要前期準備工作做得好，需求評審時出現(xiàn)的幺蛾子就不會太多，稍微拍拍就能滅掉，所以評審時狀況百出，多半是準備工作不到位。但除了前期的準備工作，在評審時還有幾個需要注意的地方，能夠幫助提升需求評審的效率。

產(chǎn)品經(jīng)理應有的態(tài)度（兵來將擋水來土掩）

1）有清晰的目標

相比其他參與者，產(chǎn)品經(jīng)理要對此次需求評審更有方向性和目標性，這次改版所要解決的問題以及所要達成的目標都應銘記于心，只有產(chǎn)品經(jīng)理自己有清晰的目標才能做到即使同時被多人撕也不發(fā)生動搖，才可能確保參會的其他團隊能理解并認同該版本所要達成的目標以及要做的功能點。

即使有著明確的目標，也別想著要把自己的想法強加到別人的腦子里，很容易發(fā)生：目標很明確，所以大家要按我的想法走的這種情況。需求評審目標并不是為了要說服誰！召開評審會，就是為了讓大家對你提出的方案進行批評指正或提出疑問點，從而能及時地解決并發(fā)現(xiàn)方案中的問題，保持各團隊目標一致，將產(chǎn)品做好。

2）把控好時間

需求評審時很容易會對某個需求/方案僵持不下，常一討論起來就是半個小時，多遇到這么幾個僵持情況，一場需求評審下來就好幾個小時，不僅會慢慢耗盡大家的精力，而且需求評審的效果也不好，得不償失！所以產(chǎn)品經(jīng)理要嚴格把控好時間，由于前期工作準備不充分而導致一些需求/方案模棱兩可，且暫時無法立馬提出解決方案的可以會后確認好后再溝通，必要時可以進行第二次評審。

3）認真傾聽

可能別人一上來就開始對你的方案提出不認可，這個時候就得認真傾聽；開發(fā)在探討技術方案的時候你也要認真傾聽；先在大腦梳理好他們在說什么，傾聽后才能對癥下藥，而不是打斷然后陳述自己的觀點。

傾聽后再陳述而不是直接打斷，可以讓人覺得你在認真思考后才說出這番陳述的，更有說服力，并且不跟其他團隊硬碰硬，先了解他們的問題再提出解決方案，不是顯得更理智么？

4）保持清醒的頭腦

在需求評審會議中，很有可能會發(fā)生爭論，產(chǎn)品經(jīng)理一定要保持理性，切不可讓怒氣或膽怯沖昏了頭腦，失去理智。對會議上提出的每一個問題都應該記錄下來并作出解答，要冷靜客觀的把自己的觀點給陳述出來。

小范圍的討論（見仁見智）

在需求評審講需求點時，開發(fā)會針對某個點進行技術方案探討，這樣有利于及早發(fā)現(xiàn)需求點與現(xiàn)有邏輯相沖突或由于硬件問題而導致需求變更或夭折的問題，避免到開發(fā)時才發(fā)現(xiàn)需求沒法做…但也要控制好時間，引導大概討論下技術實現(xiàn)方案，具體的細節(jié)之后再討論。

除了開發(fā)團隊內(nèi)部小范圍的討論外，還有設計團隊，不過設計一般不在需求評審會上討論了，畢竟，設計基本上不會影響到產(chǎn)品需求的變更。

定下開發(fā)周期（誕辰）

如果評審順利的話，就可以直接定下開發(fā)周期了；如果不順利，那就放在評審后吧~上周評審時就各種不順利，三場評審后還加了一場開發(fā)周期的確定…祝愿以后一切順利吧！

評審后

會后及時輸出會議紀要，羅列出會議中有爭議仍待解決的問題、改動的部分和結(jié)論，將完善后最終更新過的需求文檔發(fā)送給參會人員，通知需求評審已完成。之后對問題進行跟蹤，保證評審結(jié)果的落實。

總結(jié)

能否在產(chǎn)品需求評審會議中如魚得水，提高需求評審的效率，我覺得前期的準備工作很關鍵！

作者：小圣，個人微信公眾號：hi_xiaosheng，簡書賬號：小圣。歡迎戳我小窗一起探討產(chǎn)品！

本文由 @小圣 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。