求這個詞對產(chǎn)品的意義，就像代碼這個詞對于開發(fā)的意義；一個需求由提出到解決經(jīng)歷了哪些過程？一個需求的“一生”是怎樣的？讓我們隨著作者的思路看下去。

相信對于產(chǎn)品人員來說，聽到頻率最高的一個詞莫過于“需求”了。

業(yè)務(wù)人員或者客戶會對產(chǎn)品說：這里要加一個需求/功能；產(chǎn)品會對各方人員解釋說：這個需求是這樣的，這個場景是那樣的……為了加需求和改需求，產(chǎn)品和開發(fā)相愛相殺的案例也不少。

可以說，產(chǎn)品的日常工作，最繞不開的一個詞，就是需求了。

我們每天要接收需求，要處理需求，要傳達(dá)需求。需求這個詞對產(chǎn)品的意義，就像代碼這個詞對于開發(fā)的意義。

對于產(chǎn)品每天都要打交道的“需求”，我突然想聊一聊“一個需求的一生”這個話題。首先我們看一下關(guān)于需求的流程：

一、需求的產(chǎn)生

需求是怎么來的呢？很多人會以為需求產(chǎn)生的源頭是產(chǎn)品經(jīng)理。其實并不全是。需求方有幾類人員：客戶、老板、產(chǎn)品、業(yè)務(wù)/銷售、測試。而需求的產(chǎn)生也并不是一開始就是需求（此類需求稱為“純需求”），也有從bug轉(zhuǎn)化過來的需求（此類需求稱為“bug轉(zhuǎn)需求”）。

純需求一般是客戶提出來較多，業(yè)務(wù)/銷售傳達(dá)的純需求也是客戶的想法?？蛻粼谌粘Ｊ褂卯a(chǎn)品的時候，會發(fā)現(xiàn)有的產(chǎn)品的流程和實際業(yè)務(wù)有出入，會覺得“系統(tǒng)不好用”。這個時候他們經(jīng)常會聯(lián)系技術(shù)支持人員或者業(yè)務(wù)人員，傳達(dá)自己的想法。

客戶在提需求的時候也會有不同，一種是根據(jù)實際業(yè)務(wù)提需求，一種是根據(jù)競品提需求。

如果是根據(jù)實際業(yè)務(wù)提需求的話，在提需求的時候，客戶會告訴你實際的業(yè)務(wù)流程、當(dāng)前系統(tǒng)存在的問題以及他所期望的效果。雖然這類需求算是比較明確的，但是產(chǎn)品在接到這類需求的時候，還是需要多問多思考；因為有的時候客戶提的需求有可能是“偽需求”。

他們可能覺得業(yè)務(wù)上需要這個，那就得增加這個功能；其實有些問題可以通過更好、更優(yōu)的方案來解決。這就需要產(chǎn)品深入地思考客戶的“痛點”到底是什么，通過對客戶的訴求抽絲剝繭，找到他們真實的需求。

如果全部按照客戶的描述去產(chǎn)出方案的話，雖然能夠滿足客戶的需求，但是對整個產(chǎn)品未必是有益的。

除了根據(jù)業(yè)務(wù)提需求，客戶還會根據(jù)競品提需求。有可能客戶試用了或者看到了其他競品的某個功能，覺得很不錯。會過來跟我們提需求：“人家XX系統(tǒng)的那個簽合同的功能可好了，現(xiàn)在你們系統(tǒng)沒有，很不方便，需要加一個”。

這種需求其實是比較明確的，連競品幫產(chǎn)品都找好了。產(chǎn)品如果確定了要做這個需求的話，直接去梳理一下競品的邏輯，然后根據(jù)自己系統(tǒng)做好調(diào)整就可以了。

還有一類需求是bug轉(zhuǎn)需求，這些一般是由測試人員發(fā)現(xiàn)。

測試人員在測出或收集bug的時候，會將這些東西推送到產(chǎn)品經(jīng)理那里，由產(chǎn)品給出解決方案和排期。還有一些比較復(fù)雜的bug，在迭代里做不完，就會轉(zhuǎn)成需求。產(chǎn)品可以有更多的時間進(jìn)行規(guī)劃。

產(chǎn)品經(jīng)理和老板也經(jīng)常會根據(jù)系統(tǒng)的規(guī)劃提出需求，產(chǎn)品和老板會根據(jù)自己對用戶、業(yè)務(wù)、當(dāng)前系統(tǒng)的了解，對系統(tǒng)提出改進(jìn)和優(yōu)化。這個時候就會有一些優(yōu)化的想法，這些也是“需求”。

當(dāng)然，不管是產(chǎn)品還是老板，在提需求的時候都應(yīng)當(dāng)實事求是，考慮自己產(chǎn)品的定位和開發(fā)的能力。不然的話，只根據(jù)自己天馬行空的想法來，提出類似“手機(jī)主題顏色根據(jù)手機(jī)殼變化”這種無理需求，很容易被吐槽，也很容易挨打。

二、需求的處理

需求產(chǎn)生后，需要產(chǎn)品人員去進(jìn)行處理。接到需求后，不管是大需求還是小需求，產(chǎn)品需要找到提出需求的人，去了解這個問題的前因后果。通常由于開發(fā)資源、產(chǎn)品時間的問題，很多需求會來不及做。

那么很多需求就會堆積在產(chǎn)品人員這里。如果產(chǎn)品沒有對這些需求做好整理和排期的話，很容易遺漏需求，會容易這個需求“永不見天日”，問題就沒辦法解決。

在整理需求的時候，產(chǎn)品人員需要記錄需求的模塊、頁面、提需求的人、需求提出的時間、需求來源、具體問題、排期、優(yōu)先級等問題。你寫的越詳細(xì)，等過段時間忘了這個需求的時候，看需求記錄能夠讓自己快速回想起該需求的相關(guān)內(nèi)容。實在不行，找到提出這個問題的人，再重新了解一遍就夠了。

當(dāng)需求了解得很透徹了，產(chǎn)品經(jīng)理就需要靜下心來思考怎么解決這個問題。如果是小需求的話，產(chǎn)品可以快速地給出解決方案，把這個問題放在最近的迭代里即可。

如果是比較復(fù)雜的需求，則需要立項，把這個當(dāng)著一個項目來做了。（可查看以往的文章→產(chǎn)品新人第一次負(fù)責(zé)項目應(yīng)該怎么做？）

大需求的話，則需要產(chǎn)品畫出原型，寫好PRD。

這個時候“需求”已經(jīng)變成為“方案”了。

此時產(chǎn)品可以邀請業(yè)務(wù)人員、其他產(chǎn)品進(jìn)行方案評審，方案評審?fù)ㄟ^后進(jìn)行技術(shù)評審。這一輪一輪的評審和修改過去后，這個需求已經(jīng)變成“成熟方案”了。

當(dāng)方案確定后，項目經(jīng)理要在禪道（需求管理工具）里建項目。而產(chǎn)品則需要在該項目下建任務(wù)。

禪道里各類角色的職責(zé)

任務(wù)有兩類：一類是開發(fā)任務(wù)，有前端任務(wù)和后端任務(wù)；另一類就是測試任務(wù)。

在寫開發(fā)任務(wù)的時候需要注重描述方案、功能、交互。

而測試任務(wù)除了這些外，還需要產(chǎn)品確定好此次修改的影響范圍。產(chǎn)品需要和開發(fā)人員，不管是前端還是后端，確認(rèn)好此次改動的范圍、改動的影響范圍，這樣測試人員在測試的時候就能夠提前評估測試的工作量，最大程度地擴(kuò)大測試范圍。

不然的話，測試很容易漏掉一些需要測試的地方，容易導(dǎo)致上線后產(chǎn)生其他的bug。

三、需求的終結(jié)

當(dāng)這個需求開發(fā)完了，測試完了，這個需求也就結(jié)束了。需求在進(jìn)入開發(fā)之前，產(chǎn)品人員要做的是將需求準(zhǔn)確地傳達(dá)給開發(fā)人員。開發(fā)人員將需求開發(fā)完成后，測試就可以對這個功能進(jìn)行測試了。

這時候產(chǎn)品需要確認(rèn)測試用例，然后自己也需要進(jìn)行測試。主要測試頁面樣式是否和自己的想法一致，功能是否有效，業(yè)務(wù)流程能不能順利進(jìn)行等等。

當(dāng)功能上線后，這個需求在禪道里被點擊“完成”后，這個需求也就終結(jié)了。

四、總結(jié)

用戶所看到的是一個完整、優(yōu)秀的產(chǎn)品，而對產(chǎn)品、測試、開發(fā)人員來說，這些都是由一個個或大或小的需求組成。尤其是產(chǎn)品，要有整體規(guī)劃產(chǎn)品的格局和視野，也要有拆解需求、處理需求的細(xì)心和效率。

一個優(yōu)秀產(chǎn)品的開始和迭代，都是在不斷提出需求，解決需求的過程中完善的。

#專欄作家#

異彩，微信公眾號：一只蝸牛慢慢跑，人人都是產(chǎn)品經(jīng)理專欄作家。從事房產(chǎn)管理系統(tǒng)的產(chǎn)品工作，關(guān)注To C產(chǎn)品的交互設(shè)計、運營、結(jié)構(gòu)設(shè)計和商業(yè)模式。在成為一名優(yōu)秀的產(chǎn)品人的路上努力前行。

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

題圖來自 Unsplash，基于CC0協(xié)議