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

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

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

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

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

首先說說我們的項(xiàng)目需求流程：

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

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

需求的來源：

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

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

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

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

需求的確定：

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

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

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

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

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

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

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

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

如何投票確定需求，打個(gè)比方：

會(huì)議共有9個(gè)人，有個(gè)需求進(jìn)行投票表決，每個(gè)人只能投一票。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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