編輯導語：在日常工作中，一些崗位會進行產品的需求分析，對于產品需求來說，用戶占到了很大的比重，因為產品最終是服務于用戶的；從用戶提出的需求出發，挖掘用戶內心真正的目標，并轉為產品需求的過程；本文作者分享了關于實現需求全流程思考進行梳理，我們一起來看一下。

作為首次做產品需求，在需求實現中遇到一些坎，于是把實現的全流程進行思考整理后，才有此篇文章；撰寫此文也是為了加深需求實現全流程過程，方便后續如何去避坑，在整個過程能夠更加高效實現需求方案。

一、需求前

1. 為什么做這個需求？

做任何事情之前，我們就需要明白一個目的，就是為什么要做這件事情？只有對事情目的足夠了解，才好判斷這件事情，到底該不該做？以及如何做才能做好的問題？

為什么做需求，一般都是來幾個地方？老板、運營、產品、用戶反饋，競品，需求的來源大致從這幾個角色中獲得；就拿競品來說，競品上線一個新功能，我們不能說直接去copy，而是需要弄明白，競品為什么做這個需求？

但是，需求上來之后，我們就一定要做這個需求嗎？不是的，此刻而是要弄明白這個需求，為什么做？就算老板讓做這個需求，那也得弄明白需求因何原因去做。

以加班為例，某公司經常加班導致員工下班太晚無公交可做，這個時候大家就需要打車，為了迎合這個需求，而產出一個深夜加班打車的需求；其實打車線下是可以打車，只是在大家在報銷的時，特別麻煩，希望能解決報銷麻煩的事情；而此刻推出打車功能，就需要考慮如何更高效處理打完車后報銷的問題，不是簡單打車這么簡單。

2. 這個需求面向的用戶是誰？

從打車為例，我們面向的用戶是經常加班的公司，而這些公司的特征是什么？具體是哪些公司？

一看是哪些互聯網公司，因為互聯網公司經常要為某個項目趕進度，會經常有員工加班；然后又去招聘網站上看一看這類公司寫明的信息，發現這類公司招聘上都會有些加班相關字眼，就足以證明這個需求存在，且還非常多。

3. 用戶在什么場景使用？

前面也提到了，用戶都是在加班后使用，也就是經常到深夜，推出這個功能之外，我們還需要調動司機資源，在深夜配合，才能將功能推動正常運行。

4. 這個用戶群體有多大？

通過在招聘網上扒一扒，看到了許多公司都提到加班，可以再對這些公司的HR進行深入的定性采訪幾家，就能驗證這個公司群體的大小，從而好估算這個市場空間的大小。

需求腦暴會議：

需求腦暴會議，作為功能推動者，需要做足了相關調研，尤其是面向用戶的調研，然后拉上能提供點子的相關人員可以進行腦暴，這樣他們能提供很好的實現思路，從而能夠更快找到好的解決方案。

需求腦暴會議的目的，就是為了找到能夠解決問題的方案，雖然會議可以發散，但是作為主持者，還是需要控制，當跑題時，需要將大家拉回來。

有的時候沒有這樣的機會，主持腦暴會議，就需要靠自己思考了。

需求預期目標：

當我們確定要做一個需求功能時，就需要定下預期目標，當然這個不是隨便制定，而是經過深思熟慮，通過多維度的理論、相關數據證明，制定出合理的預期目標。

因為有了預期目的，才能更好的判斷該功能是否值得去做。

二、需求中

1. 需求實現前的技術方案調研

技術實現方案，決定著該需求能否實現，是比較重要的環。

有沒有技術方案可以復用？

因為一個新的需求要滿足時，如果發現實現這個新的需求時，發現技術方案特別難，那可以往以前舊功能看下，有哪些可以復用？

在《騰訊產品法》一書中李立老師分享到，當初微信要做“搖一搖識別歌曲”而搖一搖中識別就是語音識別技術，如果真要重新做一個搖一搖識別歌曲，這個應該就是有一定的成本了。

包括在需求時，有些組件是在產品中哪里實現過？如果重新在開發一個組件，那無意就增加成本。所以，除了要思考需求給用戶帶來好處之外，還需要思考實現的成本是否可以更低？

需要哪些新的技術方案？

如果發現無法復用舊的技術方案，那就需要調研新的技術方案，技術方案的實現成本，包括技術方案實現出來后是否可以有拓展性？

同時是否除了想到A技術方案之外，還有其它的技術方案？可通過反推的方式，跳躍思考的方式，來找到其它的技術解決方案，爭取選擇最優的技術解決方案。

技術方案的難度？

技術方案的難度決定是否可以實現需求？有些原本思考的需求，但是在技術方案調研時不夠嚴謹導致需求執行了一半，無法完成，因此卡在一半時就不斷的找技術解決方案從而導致需求上線時間耽擱。

還有的時候，技術實現方案在前面調研時，沒有考慮周全，在實現后經常出現BUG，從而導致返工的成本，這些都是需要提前思考到，這樣能確保需求順利進行。

技術方案的優劣勢？

優勢就是實現了這樣的技術方案得到了什么好處？劣勢就是實現后會導致什么樣的弊端？

舉例，實現后該需求能很快上線，但是劣勢就是上線后穩定性不確定，或者上線后導致后續可拓展性變低，產品容易進入死循環，這些都是大忌。

另外，該方案實行后，對原有相關的功能技術方案，是否存在不支持和需要重新調整？如果是，則需要調研該需求的影響嚴重程度，因為一旦實現該需求，就會造成不止該需求的研發，還需要拆解原有的功能，重新寫或者拆解技術方案，來支持新的需求。

不過反過來說，我們需要思考清楚，目前實現的技術方案，是否會支持以后可拓展？比如：我們做一個拼團功能，正常的一般都是2拼團，但是如果在技術方案上寫的時候，直接寫死了，后續如果要做一個百人拼團，或者萬人拼團，那開展起來就特別麻煩；但是，在寫拼團方案時，早就考慮此后可拓展，這個技術方案就是非常靈活，對后續發展有幫助。

技術方案實現周期？

也就是執行該技術方案后，要多久才能完成需求上線？這些都是需要技術方案討論時，就需要敲定好，這樣深入討論才能對需求實現更加的可控。

技術方案是否有多種？

技術方案多種，是為了能選擇到更優的那種技術方案，一切需要從更加全面的思考來選擇技術方案，不單單只考慮現在實現的速度，還要考慮實現后的可拓展性，以及需求上線的安全和穩定性；只有上線后能順利進行，且后續能夠更好的新增需求，才是做合適的技術方案。

數據儲存是怎樣的？

如果有可能我們還是需要考慮數據儲存，該功能的相關數據如何存儲？是保存現有的某個數據結構中？還是另存數據？作為一個產品，需要提前思考，并且和技術進行確認，讓技術拿出解決方案是最好的。

測試驗收

其余的地方都思考到位了，最后上線需要測試給力，測試越給力，才能保障產品上線穩定，減少BUG出現率；所以這里涉及到測試對需求的思考，最重要是測試編寫用例。

2. 產品需求方案

需求實現的場景都有哪些？

需求實現的場景，也就是指該需求用戶會在什么場景下使用？需要把所有場景下使用全部梳理出來，才能把業務邏輯梳理清楚，比如：用滴滴打車，每當輸入的出發地址與定位地點不同，這個時候產品就會提示是否為他人叫車？再比如：用戶在早上打開滴滴，那可以判斷基本都是上班打車，這個時候滴滴就會從以訂單往記錄給用戶選擇終點，只需用戶確認即可。

梳理清楚場景，就能很好的提升用戶體驗，產品邏輯也能很好的梳理清楚。有的時候不同場景使用，調用的數據庫、包括其他資源都會有不相同。

還是以打車為例：如果在高峰期打車，當用戶打的是特惠快車，如果此刻用戶定位周邊XX公里內沒有特惠快車司機，當等待XX分鐘后，如果還未有匹配的司機進入該范圍，就會調用快車資源完成該筆訂單。

另外，如果需求梳理一點之后，然后又想起一點，再去完善文檔，這樣會導致增加很多無用功；如果產品文檔已經給到技術進行研發時，再去和技術說補充文檔時，技術又需要重新理解一遍，會產生成本，技術也會反感；所以，在思考產品需求場景時，一定需要再三思考，深度思考清楚，把所有想到的都羅列出來，才能避免后續尷尬事情發生。

需求是否需要拆分？

需求拆分的情況下，一般是看需求的大小、以及目前的技術任務量、還有需求需要上線的時間節點；如果著急使用的需求，會進行拆分，拆分后的目的是為了能夠快速上線需求，驗證需求效果，這樣也能做一次成本控制，保證項目整體的上線進度。

但是在拆分需求時，也需要將需求文檔全部寫出來，能讓技術有個前提了解，這樣對需求拆分后，后續實現有很好的幫助。

3. 需求會議

會議是必不可少，足夠的討論會議，才能確保實現的需求方案是可行，缺少討論光是執行，有可能會讓實現的方案變得以后拓展性空間變少，以及實現過程出現很多遺漏點等等。

技術方案會議

當進入技術方案會議前，已經確定該需求是大致把握可以做，或者說從產品層面是可以做，技術方案需要相關技術人員，或者技術負責人進行前期的調研，整理技術方案。

有的時候，在產品做之前，產品就可以先和技術進行溝通，先初步了解技術實現，這樣確保該需求在技術實現上不會有難度，至少能解決問題，不會因為各方面都準備好了，到了技術方案實現時才導致有個技術難題無法攻破。

技術方案會議，需要相關相關技術人員以及產品經理同時參與，由技術來演講，而產品經理在旁邊聽和提出異議，需要做的就是幫助技術，檢查是否有漏洞，如果不懂技術，可以從業務邏輯進行思考提問。

產品需求評審會議

進入到這個階段，是產品經理主導，拉上相關技術人員，開始宣講自己的產品需求文檔，針對重要的必須要再三強調，確保信息同步到位。

當然，因為這個時候是給技術安排任務，所以技術肯定會靈魂拷問，產品需要做的就是——提前將需求思考的特別仔細，面對每一個問題，都能是提前已經思考、想好的，避免一問答不上，會在技術面前失足，造成大家的是浪費。

三、需求后

1. 數據監測

需求監測需要在產品實現方案時候，就需要提供需要埋點的，因為有了埋點，才有現在數據監測，在很多招聘JD都能看見針對產品經理有一個要求，就是數據的重要性；當上線一個功能之后，數據監測是必不可少的。

監測數據有需要注意的點，當數據上漲后是直接性、還是相關性，比如：朋友圈改了一個表情評論功能，這個時候朋友圈發布條數突然上漲了，會認為是這個功能刺激的嗎？

不一定，因為這個時候有可能剛好是某個熱點導致，很多人突然感概，發朋友圈的數量激增。

還有另外一種情況，也就是數據剛上線后，數據暴跌幾個點，是否要將功能馬上下線，回退版本呢？

遇到這種情況，也不一定，只要是在可承受的范圍，如果時間較短，就應該對數據持續觀察，沒有發現異常，那也可以再進行嘗試優化，也許可能是引導沒有做好，導致數據不太樂觀。

2. 用戶反饋

功能上線后是用戶使用，不管數據好和壞，都需要看用戶的反饋，如果有條件，可以直接準備相關問卷，或者訪談的方式，做用戶反饋收集，為的是確保功能上線后能夠持續帶給用戶好的體驗。

持續穩定的良好用戶體驗，產品才能走向正循環，前期的使用數據達到預期，后續留存也需要保證不失足。

四、總結

對于需求首先需要思考清楚收益，也就是實現的成本和回報，有的時候功能可能是增加體驗，那也需要思考該功能影響多多少人使用；如果是實現增收的、用戶增長相關，需要思考預期目標，通過分析用戶群體、使用場景、該類型群體的數量、以及使用頻次、歷史相關數據進行多維度分析，來確保需求面向的使用用戶是能支撐開發成本。

當需求確定之后，需要確定實現方案、技術方案，重要的幾個維度，就是如何更低成本、更穩妥、對未來拓展空間無束縛等，讓需求保質保量完成。

需求上線后，數據和用戶反饋尤其重要，因為這個時候是驗證假設的時候，需要注意的不是單維度觀察，而是要從正面、側面，不同角度來觀察當前數據和用戶反饋，有必要的時候必須要主動向用戶收集反饋，確保后續能夠做好持續好的使用留存。

每個人思考的方式不一樣，有些人確定了要做該需求時，會優先從技術實現方案來思考；因為有的一個需求動到原本的其他的功能，導致實現的邏輯和約束增多，這個時候考慮的就更多。

總之細致細致再細致，思考思考再思考。

本文由 @大劉小飛 原創發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議