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

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

一、需求前

1. 為什么做這個需求？

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

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

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

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

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

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

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

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

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

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

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

需求腦暴會議：

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

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

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

需求預(yù)期目標(biāo)：

當(dāng)我們確定要做一個需求功能時，就需要定下預(yù)期目標(biāo)，當(dāng)然這個不是隨便制定，而是經(jīng)過深思熟慮，通過多維度的理論、相關(guān)數(shù)據(jù)證明，制定出合理的預(yù)期目標(biāo)。

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

二、需求中

1. 需求實現(xiàn)前的技術(shù)方案調(diào)研

技術(shù)實現(xiàn)方案，決定著該需求能否實現(xiàn)，是比較重要的環(huán)。

有沒有技術(shù)方案可以復(fù)用？

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

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

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

需要哪些新的技術(shù)方案？

如果發(fā)現(xiàn)無法復(fù)用舊的技術(shù)方案，那就需要調(diào)研新的技術(shù)方案，技術(shù)方案的實現(xiàn)成本，包括技術(shù)方案實現(xiàn)出來后是否可以有拓展性？

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

技術(shù)方案的難度？

技術(shù)方案的難度決定是否可以實現(xiàn)需求？有些原本思考的需求，但是在技術(shù)方案調(diào)研時不夠嚴(yán)謹(jǐn)導(dǎo)致需求執(zhí)行了一半，無法完成，因此卡在一半時就不斷的找技術(shù)解決方案從而導(dǎo)致需求上線時間耽擱。

還有的時候，技術(shù)實現(xiàn)方案在前面調(diào)研時，沒有考慮周全，在實現(xiàn)后經(jīng)常出現(xiàn)BUG，從而導(dǎo)致返工的成本，這些都是需要提前思考到，這樣能確保需求順利進行。

技術(shù)方案的優(yōu)劣勢？

優(yōu)勢就是實現(xiàn)了這樣的技術(shù)方案得到了什么好處？劣勢就是實現(xiàn)后會導(dǎo)致什么樣的弊端？

舉例，實現(xiàn)后該需求能很快上線，但是劣勢就是上線后穩(wěn)定性不確定，或者上線后導(dǎo)致后續(xù)可拓展性變低，產(chǎn)品容易進入死循環(huán)，這些都是大忌。

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

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

技術(shù)方案實現(xiàn)周期？

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

技術(shù)方案是否有多種？

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

數(shù)據(jù)儲存是怎樣的？

如果有可能我們還是需要考慮數(shù)據(jù)儲存，該功能的相關(guān)數(shù)據(jù)如何存儲？是保存現(xiàn)有的某個數(shù)據(jù)結(jié)構(gòu)中？還是另存數(shù)據(jù)？作為一個產(chǎn)品，需要提前思考，并且和技術(shù)進行確認(rèn)，讓技術(shù)拿出解決方案是最好的。

測試驗收

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

2. 產(chǎn)品需求方案

需求實現(xiàn)的場景都有哪些？

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

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

還是以打車為例：如果在高峰期打車，當(dāng)用戶打的是特惠快車，如果此刻用戶定位周邊XX公里內(nèi)沒有特惠快車司機，當(dāng)?shù)却齒X分鐘后，如果還未有匹配的司機進入該范圍，就會調(diào)用快車資源完成該筆訂單。

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

需求是否需要拆分？

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

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

3. 需求會議

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

技術(shù)方案會議

當(dāng)進入技術(shù)方案會議前，已經(jīng)確定該需求是大致把握可以做，或者說從產(chǎn)品層面是可以做，技術(shù)方案需要相關(guān)技術(shù)人員，或者技術(shù)負(fù)責(zé)人進行前期的調(diào)研，整理技術(shù)方案。

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

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

產(chǎn)品需求評審會議

進入到這個階段，是產(chǎn)品經(jīng)理主導(dǎo)，拉上相關(guān)技術(shù)人員，開始宣講自己的產(chǎn)品需求文檔，針對重要的必須要再三強調(diào)，確保信息同步到位。

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

三、需求后

1. 數(shù)據(jù)監(jiān)測

需求監(jiān)測需要在產(chǎn)品實現(xiàn)方案時候，就需要提供需要埋點的，因為有了埋點，才有現(xiàn)在數(shù)據(jù)監(jiān)測，在很多招聘JD都能看見針對產(chǎn)品經(jīng)理有一個要求，就是數(shù)據(jù)的重要性；當(dāng)上線一個功能之后，數(shù)據(jù)監(jiān)測是必不可少的。

監(jiān)測數(shù)據(jù)有需要注意的點，當(dāng)數(shù)據(jù)上漲后是直接性、還是相關(guān)性，比如：朋友圈改了一個表情評論功能，這個時候朋友圈發(fā)布條數(shù)突然上漲了，會認(rèn)為是這個功能刺激的嗎？

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

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

遇到這種情況，也不一定，只要是在可承受的范圍，如果時間較短，就應(yīng)該對數(shù)據(jù)持續(xù)觀察，沒有發(fā)現(xiàn)異常，那也可以再進行嘗試優(yōu)化，也許可能是引導(dǎo)沒有做好，導(dǎo)致數(shù)據(jù)不太樂觀。

2. 用戶反饋

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

持續(xù)穩(wěn)定的良好用戶體驗，產(chǎn)品才能走向正循環(huán)，前期的使用數(shù)據(jù)達到預(yù)期，后續(xù)留存也需要保證不失足。

四、總結(jié)

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

當(dāng)需求確定之后，需要確定實現(xiàn)方案、技術(shù)方案，重要的幾個維度，就是如何更低成本、更穩(wěn)妥、對未來拓展空間無束縛等，讓需求保質(zhì)保量完成。

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

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

總之細(xì)致細(xì)致再細(xì)致，思考思考再思考。

本文由 @大劉小飛 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

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