起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識一個需求的一生
求這個詞對產品的意義，就像代碼這個詞對于開發的意義；一個需求由提出到解決經歷了哪些過程？一個需求的“一生”是怎樣的？讓我們隨著作者的思路看下去。
相信對于產品人員來說，聽到頻率最高的一個詞莫過于“需求”了。
業務人員或者客戶會對產品說：這里要加一個需求/功能；產品會對各方人員解釋說：這個需求是這樣的，這個場景是那樣的……為了加需求和改需求，產品和開發相愛相殺的案例也不少。
可以說，產品的日常工作，最繞不開的一個詞，就是需求了。
我們每天要接收需求，要處理需求，要傳達需求。需求這個詞對產品的意義，就像代碼這個詞對于開發的意義。
對于產品每天都要打交道的“需求”，我突然想聊一聊“一個需求的一生”這個話題。首先我們看一下關于需求的流程：
一、需求的產生
需求是怎么來的呢？很多人會以為需求產生的源頭是產品經理。其實并不全是。需求方有幾類人員：客戶、老板、產品、業務/銷售、測試。而需求的產生也并不是一開始就是需求（此類需求稱為“純需求”），也有從bug轉化過來的需求（此類需求稱為“bug轉需求”）。
純需求一般是客戶提出來較多，業務/銷售傳達的純需求也是客戶的想法?？蛻粼谌粘Ｊ褂卯a品的時候，會發現有的產品的流程和實際業務有出入，會覺得“系統不好用”。這個時候他們經常會聯系技術支持人員或者業務人員，傳達自己的想法。
客戶在提需求的時候也會有不同，一種是根據實際業務提需求，一種是根據競品提需求。
如果是根據實際業務提需求的話，在提需求的時候，客戶會告訴你實際的業務流程、當前系統存在的問題以及他所期望的效果。雖然這類需求算是比較明確的，但是產品在接到這類需求的時候，還是需要多問多思考；因為有的時候客戶提的需求有可能是“偽需求”。
他們可能覺得業務上需要這個，那就得增加這個功能；其實有些問題可以通過更好、更優的方案來解決。這就需要產品深入地思考客戶的“痛點”到底是什么，通過對客戶的訴求抽絲剝繭，找到他們真實的需求。
如果全部按照客戶的描述去產出方案的話，雖然能夠滿足客戶的需求，但是對整個產品未必是有益的。
除了根據業務提需求，客戶還會根據競品提需求。有可能客戶試用了或者看到了其他競品的某個功能，覺得很不錯。會過來跟我們提需求：“人家XX系統的那個簽合同的功能可好了，現在你們系統沒有，很不方便，需要加一個”。
這種需求其實是比較明確的，連競品幫產品都找好了。產品如果確定了要做這個需求的話，直接去梳理一下競品的邏輯，然后根據自己系統做好調整就可以了。
還有一類需求是bug轉需求，這些一般是由測試人員發現。
測試人員在測出或收集bug的時候，會將這些東西推送到產品經理那里，由產品給出解決方案和排期。還有一些比較復雜的bug，在迭代里做不完，就會轉成需求。產品可以有更多的時間進行規劃。
產品經理和老板也經常會根據系統的規劃提出需求，產品和老板會根據自己對用戶、業務、當前系統的了解，對系統提出改進和優化。這個時候就會有一些優化的想法，這些也是“需求”。
當然，不管是產品還是老板，在提需求的時候都應當實事求是，考慮自己產品的定位和開發的能力。不然的話，只根據自己天馬行空的想法來，提出類似“手機主題顏色根據手機殼變化”這種無理需求，很容易被吐槽，也很容易挨打。
二、需求的處理
需求產生后，需要產品人員去進行處理。接到需求后，不管是大需求還是小需求，產品需要找到提出需求的人，去了解這個問題的前因后果。通常由于開發資源、產品時間的問題，很多需求會來不及做。
那么很多需求就會堆積在產品人員這里。如果產品沒有對這些需求做好整理和排期的話，很容易遺漏需求，會容易這個需求“永不見天日”，問題就沒辦法解決。
在整理需求的時候，產品人員需要記錄需求的模塊、頁面、提需求的人、需求提出的時間、需求來源、具體問題、排期、優先級等問題。你寫的越詳細，等過段時間忘了這個需求的時候，看需求記錄能夠讓自己快速回想起該需求的相關內容。實在不行，找到提出這個問題的人，再重新了解一遍就夠了。
當需求了解得很透徹了，產品經理就需要靜下心來思考怎么解決這個問題。如果是小需求的話，產品可以快速地給出解決方案，把這個問題放在最近的迭代里即可。
如果是比較復雜的需求，則需要立項，把這個當著一個項目來做了。（可查看以往的文章→產品新人第一次負責項目應該怎么做？）
大需求的話，則需要產品畫出原型，寫好PRD。
這個時候“需求”已經變成為“方案”了。
此時產品可以邀請業務人員、其他產品進行方案評審，方案評審通過后進行技術評審。這一輪一輪的評審和修改過去后，這個需求已經變成“成熟方案”了。
當方案確定后，項目經理要在禪道（需求管理工具）里建項目。而產品則需要在該項目下建任務。
禪道里各類角色的職責
任務有兩類：一類是開發任務，有前端任務和后端任務；另一類就是測試任務。
在寫開發任務的時候需要注重描述方案、功能、交互。
而測試任務除了這些外，還需要產品確定好此次修改的影響范圍。產品需要和開發人員，不管是前端還是后端，確認好此次改動的范圍、改動的影響范圍，這樣測試人員在測試的時候就能夠提前評估測試的工作量，最大程度地擴大測試范圍。
不然的話，測試很容易漏掉一些需要測試的地方，容易導致上線后產生其他的bug。
三、需求的終結
當這個需求開發完了，測試完了，這個需求也就結束了。需求在進入開發之前，產品人員要做的是將需求準確地傳達給開發人員。開發人員將需求開發完成后，測試就可以對這個功能進行測試了。
這時候產品需要確認測試用例，然后自己也需要進行測試。主要測試頁面樣式是否和自己的想法一致，功能是否有效，業務流程能不能順利進行等等。
當功能上線后，這個需求在禪道里被點擊“完成”后，這個需求也就終結了。
四、總結
用戶所看到的是一個完整、優秀的產品，而對產品、測試、開發人員來說，這些都是由一個個或大或小的需求組成。尤其是產品，要有整體規劃產品的格局和視野，也要有拆解需求、處理需求的細心和效率。
一個優秀產品的開始和迭代，都是在不斷提出需求，解決需求的過程中完善的。
#專欄作家#
異彩，微信公眾號：一只蝸牛慢慢跑，人人都是產品經理專欄作家。從事房產管理系統的產品工作，關注To C產品的交互設計、運營、結構設計和商業模式。在成為一名優秀的產品人的路上努力前行。
本文原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash，基于CC0協議
是不是第一句話的第一個詞少了一個“需”