我是一個從傳統(tǒng)行業(yè)5年需求分析師轉(zhuǎn)型做產(chǎn)品經(jīng)理的同行，很多人都說需求分析師就是產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理就是需求分析師。對于這個理解我個人覺得是狹義的，在某些方面或者某些公司，需求分析師和產(chǎn)品經(jīng)理的工作是有重合的，但這并不代表兩者就是一致；

產(chǎn)品經(jīng)理負(fù)責(zé)調(diào)查并根據(jù)用戶的需求，確定開發(fā)何種產(chǎn)品，選擇何種技術(shù)、商業(yè)模式等。并推動相應(yīng)產(chǎn)品的開發(fā)組織，他還要根據(jù)產(chǎn)品的生命周期，協(xié)調(diào)研發(fā)、營銷、運營等，確定和組織實施相應(yīng)的產(chǎn)品策略，以及其他一系列相關(guān)的產(chǎn)品管理活動。

需求分析師則負(fù)責(zé)解決的問題進行詳細(xì)的分析，弄清楚問題的要求，包括需要輸入什么數(shù)據(jù)，要得到什么結(jié)果，最后應(yīng)輸出什么。可以說，在軟件工程當(dāng)中的“需求分析”就是確定要計算機“做什么”，要達到什么樣的效果。可以說需求分析是做系統(tǒng)之前必做的。

那么說來說去都包含了需求，我們?nèi)绾未_定需求的正確性，來拒絕不合理的需求呢？

有人說產(chǎn)品經(jīng)理就是在不斷的重復(fù)一個挖坑、填坑的動作，當(dāng)你在不斷挖坑填坑的過程中有所感悟了，說明你就進步了。

首先說說我們的項目需求流程：

老板提出重點設(shè)想-----大家一起劃定功能界限----產(chǎn)品進行構(gòu)思畫出原型----與老板進行需求原型溝通確認(rèn)，進行相關(guān)調(diào)整----召集項目經(jīng)理及相關(guān)技術(shù)人員進行需求功能評審------調(diào)整原型及需求規(guī)則-----項目經(jīng)理確認(rèn)完成進入開發(fā)階段。

這里想強調(diào)一點，需求的完成不是產(chǎn)品經(jīng)理和老板確認(rèn)好就行的，在開發(fā)前需求一點需要項目經(jīng)理介入和最終確認(rèn)，因為實現(xiàn)完成者需要技術(shù)執(zhí)行。不管你需求把握分析的多么準(zhǔn)確，原型畫的多么漂亮，技術(shù)實現(xiàn)不了，一切都是空想，只有跨部門間溝通確認(rèn)才能完成。

需求的來源：

老板提出的戰(zhàn)略方向的需求：老板會站在戰(zhàn)略層的事務(wù)，在確定了產(chǎn)品的方向之后，他會對產(chǎn)品的樣子有個大致的想象，有些功能是必須要有的，這時候，他會和大家討論哪些需求建議加上去。

產(chǎn)品經(jīng)理根據(jù)產(chǎn)品方向規(guī)劃需求：產(chǎn)品經(jīng)理需要進行基本的競品分析對比、收集各方面的數(shù)據(jù)，然后分析得出需求有哪些。

產(chǎn)品運營根據(jù)推廣運營活動及用戶訪談提出需求：產(chǎn)品設(shè)計出來是給用戶用的，而最接近用戶的是產(chǎn)品運營人員。那么，不管是一個產(chǎn)品最初的誕生以及迭代，產(chǎn)品運營人員都應(yīng)該做用戶訪談，去獲取用戶的痛點，用戶用得不爽的地方有哪些，然后列一份需求清單給產(chǎn)品經(jīng)理進行反饋。

其他參與者和關(guān)注者反饋需求：這里包括UI、UE、dve，因為對于這些人來說他們也希望自己做的事情、負(fù)責(zé)的事情能有成就感，往往他們提出一個問題，我們應(yīng)該去思考，而不是一下子否則，最終大家溝通討論從而確認(rèn)需求，這樣不僅讓他們做的事情有成就感，同時也會讓他們更關(guān)注和主動。

需求的確定：

我們目前的需求確定方式都是采用TDD記錄需求源。為了保證需求的不遺漏，也為了驗證需求的有效性及改動頻率，我們目前正在做一個需求管理的小系統(tǒng)，流程如下圖：

一切需求源完成后，我會召集相關(guān)人員進行需求確定，這里的人員包括項目經(jīng)理，需求提出人、產(chǎn)品經(jīng)理、老板等干系人員。

會議上產(chǎn)品經(jīng)理作為主持人，在介紹完產(chǎn)品背景以及產(chǎn)品戰(zhàn)略上的信息后，就正式進行需求的評審。

先列出需求，然后先讓提出此需求的人說下提出此需求的原因，然后進行投票：

• 認(rèn)同：指的的關(guān)于產(chǎn)品需求，這個需求你也想到這個需求，和提出者想的一樣

• 贊同：之前你沒想到有這個需求，但是經(jīng)過他人提出后，你很贊同，在使用這個產(chǎn)品你會需要這個功能。

• 不贊同：之前你沒想到這個需求，雖然經(jīng)過他人提出，但是你不贊同，在使用這個產(chǎn)品你不需要這個功能。

在思考的過程中，強調(diào)給出意見之前，站在你是一個產(chǎn)品小白用戶的角度上，你會不會有使用這個功能的需求。

如何投票確定需求，打個比方：

會議共有9個人，有個需求進行投票表決，每個人只能投一票。

• 認(rèn)同人數(shù)加上贊同人數(shù)加起來大于三分之二，那么這個需求就確定必須加。

• 認(rèn)同人數(shù)加上贊同人數(shù)加起來大一三分之一，那么這個需求待確定，參會人員重新進行討論，站在小白的角度上說出各自的意見，重新進行投票，此刻投票只有贊同以及不贊同兩種，贊同人數(shù)超過三分之二，確定此需求，反之，則放棄。

• 認(rèn)同人數(shù)加上贊同人數(shù)小于三分之一，那么這個需求直接放棄，大家和需求提出者說下不贊同的看法以及意見。

需求的總結(jié)和歸納：

會議結(jié)束的過程中，需要專門有人在旁做會議記錄，把會議過程以及最后的決策記錄下來，會議后轉(zhuǎn)發(fā)給參會人員，很多時候，記憶總是不如文檔來得實在。（我們都會上傳到svn存檔）

匯總的需求在整理完成后需要發(fā)給相關(guān)參會人員包括老板，讓老板知道需求確認(rèn)的最終結(jié)果。

有些時候老板可能由于事情耽誤無法參與需求確認(rèn)會議，這時候作為產(chǎn)品經(jīng)理的你需要把老板提出的需求進行詳細(xì)的反饋并發(fā)給老板。

大家可能經(jīng)常會遇到在進行一些需求確認(rèn)的時候，一些開發(fā)人員總認(rèn)為這個需求太荒謬，這個需求太不合理，有些可能對老板提的一些需求直接覺得不靠譜，這時候作為產(chǎn)品經(jīng)理的你，不僅需要把老板的需求背景、需求描述、需求來源給參會人員進行講解，讓大家都理解的情況下進行投票。如果最終老板的需求被pass掉了，你需要記錄并把大家的意見反饋給老板，讓老板知道具體原因，從而再次確認(rèn)。

項目經(jīng)理在需求確認(rèn)過程中有一票否決權(quán)，不管這個需求來源于哪個部門角色，甚至來源于老板自己，因為項目經(jīng)理會站在技術(shù)的角度對這個需求進行評估考慮，如果不能實現(xiàn)，大家討論再多都是扯淡，但是需要進行記錄原因，為何不能實現(xiàn)？有何風(fēng)險？是否會影響進度？

以上是我們目前需求來源搜集、需求確認(rèn)、需求會議總結(jié)的方式和方法，但是在實際過程中我們也遇到了許多問題，表現(xiàn)如下：

1、開發(fā)人員質(zhì)疑這個需求不合理：這個時候作為產(chǎn)品經(jīng)理的你就需要從自身思考，是否這個需求沒有講述清楚？從而誤導(dǎo)了開發(fā)人員？

（這里切記不要說這是xxx的需求，我也認(rèn)為不合理，但是沒有辦法，這樣只會讓開發(fā)人員鄙視你，造成你后續(xù)的被動，工作越來越難開展）

2、開發(fā)人員在實現(xiàn)需求的過程中可能會比較復(fù)雜，不愿意實現(xiàn)：這個時候作為產(chǎn)品經(jīng)理的你需要了解這個需求為啥實現(xiàn)中比較復(fù)雜，是否和你理解的正確？

（這里就需求你和技術(shù)多多溝通，有些必須實現(xiàn)的需求絕對不能讓步，這種問題當(dāng)你讓出第一步的時候就會出現(xiàn)第二步，不僅到時候會讓老板對你有看法，同時也會很被動）

3、開發(fā)人員簡單實現(xiàn)一些和規(guī)則不符：遇到這種事情你不能直接上去就是指責(zé)xxx，而是要了解下這個需求這種實現(xiàn)是否可以，能否滿足功能要求。開發(fā)人員基于啥這樣實現(xiàn)。

（產(chǎn)品經(jīng)理和開發(fā)人員是承上啟下的關(guān)系，也是完成一個需求功能不可缺少的一部分，正確的溝通和理解會讓你在以后的工作中得心應(yīng)手）

總之我個人認(rèn)為需求的確認(rèn)需要大家一起來確認(rèn)，不是老板的責(zé)任，不是某一個部門的責(zé)任，不是某一個角色的責(zé)任；要適當(dāng)?shù)膶W(xué)會拒絕，學(xué)會溝通，才能讓需求更正確的執(zhí)行。

在工作中我也會跟開發(fā)、UI等相關(guān)人員進行激烈的溝通和爭吵，但是都是基于工作需求；任何一個需求的確認(rèn)如果只是平平淡淡，沒有一點問題和摩擦肯定會出現(xiàn)問題，只有大家一起溝通確認(rèn)才能讓需求正確的執(zhí)行。

學(xué)會拒絕不合理需求，學(xué)會正確溝通需求，這是作為一個產(chǎn)品經(jīng)理最基本的責(zé)任；

謝謝大家！歡迎有想法的人一起溝通，一起交流，覺得不錯的給個認(rèn)可，點個贊哦~~~~~~~~~~

本文由PMCAFF產(chǎn)品經(jīng)理社區(qū)作者@Andy-pm? 原創(chuàng)，未經(jīng)允許，禁止轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的拒绝不靠谱的需求：怎样确定需求才是正确的？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。