“這個需求什么時候上線”

聽過一個說法，如果你經(jīng)常被人問到一個問題，并且每次都要給一樣的回答，最好的方式是把你的回答寫成文檔，之后用「發(fā)文檔」這個工作，代替你的回答就好。
“這個需求什么時候上線”這個問題，我作為產(chǎn)品經(jīng)理會經(jīng)常被問到。所以我在內(nèi)部寫了一篇文檔，之后在工作中，就會用這篇文章來代替我的回答。

從業(yè)到現(xiàn)在，作為產(chǎn)品經(jīng)理，我被問到過最多的問題就是：這個需求時候可以上線？
寫這篇文檔就是跟大家介紹一下一個需求是如何上線的，以及，面對這個問題，我能給到的回答是什么。
這樣，以后再有小伙伴問我這樣的問題，我就可以把這篇文檔發(fā)給TA看了。
首先想強調(diào)一點，從主觀上，產(chǎn)品，研發(fā)和設計，都希望每一個需求早點上線，而這肯定不現(xiàn)實。
但我想寫這篇文章，就是想告訴所有人，我們此刻不能告訴你什么時候上線，不是因為我們不想去做這件事，或者對你的需求不上心。
恰恰是因為，我們尊重一個需求的全流程，所以需要按照客觀的規(guī)律去做事情。
先回答大家的第一個問題，一個需求的流程是什么樣的。
這里會分成兩個階段：
首先，我們要確認一個業(yè)務訴求，是否在當前階段要成為一個產(chǎn)品需求；
其次，我們要把這個產(chǎn)品需求，變成一個在工作流中的任務。
一、先說說從業(yè)務訴求到產(chǎn)品需求的流程
有一點很重要，就是產(chǎn)品對于需求的理解，和業(yè)務對于需求的理解，可能是不一樣的。業(yè)務看需求，就是看我需要什么樣的產(chǎn)品能力，來幫助我解決一個當前棘手的問題。
這里的不確定性在于，這個產(chǎn)品能力，是否就是解決這個問題最好的答案。而好又包括：是否是最經(jīng)濟的，即是否現(xiàn)在就要做；是否能解決這一類的問題。
舉個例子，很多業(yè)務跟我表達過，想要一個裂變工具，然后問我什么時候上線。
對的，“我想要一個什么，這個東西什么時候能上線”這可能是我遇到過頻次最高的提問了。然后呢，我就會問，WHY，為什么要，現(xiàn)在就要么，你要的這個東西真的是解決你問題最好的答案么。
放心，我們產(chǎn)品絕對不是想要抬扛，或者是變相拒絕。因為我們只關心一點，解決辦法是否是這個問題最好的答案，背后就是一點：資源該如何最優(yōu)配置。
所以呢，如果業(yè)務和產(chǎn)品在某個問題上達成了共識，即一件事就是解決一個問題目前看來最好的答案，那我覺得，這時候業(yè)務訴求就變成了產(chǎn)品需求。
再說回那個需求，裂變工具什么時候上線。
那我會問，為什么要做這個需求。然后我會得到一些業(yè)務的輸入，沒問題，我認可這些輸入，但仍然不夠。我會初步去判斷，裂變工具不是一個小需求，是一個小系統(tǒng)，所以我需要更多的輸入。
接著我會問，那為什么要現(xiàn)在做這個需求，之前沒有做的時候，你們是怎么解決的。然后我了解到，之前用的是第三方工具。
但會有一些問題。比如不支持二級轉(zhuǎn)化數(shù)據(jù)的拉取，比如無法基于低轉(zhuǎn)高做激勵。
那聊到這里我就明白了，要做裂變工具的原因是什么，以及，到底需要產(chǎn)研投入資源解決哪些核心的問題。這時候，共識就算達成了。
當然，如果有一些數(shù)據(jù)，說明擁有裂變工具的潛力和價值，那是更好了。
二、再說說從產(chǎn)品需求到功能上線的流程
1、產(chǎn)出需求文檔（即我們常說的PRD）
沒錯，如果你問一個產(chǎn)品經(jīng)理每天在做些什么，那么他大部分的時間可能都在寫需求文檔。
需求文檔是給研發(fā)看的，方便將需求從一個想法，變成一個可以落地的操作手冊。
而要寫一篇合格的需求文檔，又會經(jīng)過這么幾個步驟：
1）需求的調(diào)研：關于需求的收益量化和可行性，會有更進一步的調(diào)研。比如跟研發(fā)的溝通，給數(shù)據(jù)分析提需求看某個數(shù)據(jù)等等，這都是為了把這個需求想得更明白。
2）畫原型圖：為了更清楚地說明一個需求，需要用Axure等原型工具，將需求可視化的展示出來。3）寫需求文檔：用飛書文檔，將需求的背景、目標、模塊劃分、功能的詳細說明，都說清楚。
有時候，對于特別重要的需求，在畫完原型圖之后，我們會有一個內(nèi)部評審的流程，這是為了讓產(chǎn)品經(jīng)理之間互相提建議，確保沒有忽略什么重要的點，或者有更好的想法迸發(fā)出來。
有時候，產(chǎn)品需求和業(yè)務訴求之間會有一些出入，畢竟想法從產(chǎn)生到具體落地，本身可能就會有一些變化。所以我們還會看需要，拿著原型圖跟業(yè)務方去做一個業(yè)務評審，這也是為了保證我們產(chǎn)出的東西，是滿足業(yè)務方需要的。
如果是涉及到客戶端的改動，我們還會在這個階段額外做兩件事：準備AB測試的方案，完成頁面的埋點，這兩件事也需要跟數(shù)據(jù)分析部門一起準備。
所以你看，單單是產(chǎn)出需求文檔這一步，就會有這么多事情要做。
2、進行需求評審
需求評審，就是產(chǎn)品會召集研發(fā)一起，跟大家講講這個需求的具體內(nèi)容，解答研發(fā)的疑問。最終目標，都是從實現(xiàn)角度考慮，看看這個需求要做些什么樣的事情。
理想的需求評審，是大家一起開一次會就結(jié)束了，然后開始拆任務，做分工。但現(xiàn)實中，經(jīng)過評審后，往往有些事情是不確定的，需要下來確認，有些事情經(jīng)討論是不能做的，會將功能暫時砍掉，或者再返回去跟業(yè)務做溝通。
所以，實際的需求評審，可能不止一次（要看需求的復雜度）
接著，將所有可能影響排期的不確定因素都解決之后，研發(fā)內(nèi)部就可以做排期了。我單獨講講排期吧，畢竟排期在很大程度上決定了：
“這個需求什么時候可以上線”
3、排期
影響排期的第一個因素是估時，意思是：大家將任務做拆分，然后每個人評估下自己那一部分的任務需要多久。
但還有一個因素會影響，那就是耦合程度。一個人的工作，需要在另一個人完成之后，才能做完。
比如說，客戶端如果要開始自己的工作，那前提條件是設計稿基本確認了。
而設計稿確認的前提是，設計師的排期是合理的。但設計這個工作，對于大的需求來說，又經(jīng)常會發(fā)生改變。
所以呀，如果需求變更了，設計稿就要改，設計稿改了，客戶端就要改，客戶端延遲了，連調(diào)就延遲了，連調(diào)延遲了，測試測功能就要延遲。
因此，盡管很多需求能夠給到一個預估的工時和排期，但如果需求頻繁變更，或者某個角色的估時不準，都會導致最終的功能上線時間往后延遲。
這時候就需要產(chǎn)品經(jīng)理去判斷，到底準時上線是必須的（就意味著有些變更來不及做），還是這一次100%完成是必須的（就意味著需求會延期上線）
無論是質(zhì)量有損，還是交付延期，都是我們在日常工作中會面臨的。我們都希望又好又快，但現(xiàn)實就是求取平衡的藝術(shù)。
說到這里，你就會明白：
“這個需求什么時候可以上線”，即使我給你回答了，也是一種概率層面的回答，在排期結(jié)果出來之后，有很大可能會按照這個排期來交付。
但是如果在整個流程中出現(xiàn)任何變動，都會影響最后的結(jié)果。產(chǎn)品經(jīng)理要做的，就是跟業(yè)務一起，保證準時上線，又保證上線的功能可以滿足業(yè)務的訴求。
4、給不出排期，那能給什么呢
最后，從產(chǎn)品經(jīng)理的角度也應該思考，業(yè)務方問我們要排期的時候，就只是關心什么時候上線么？
當然不排除只有這樣想法的業(yè)務方，那我就給他們看這篇文章就好，解釋了我們接到需求的時候，還不能給出排期的原因。
但是不是也包括，業(yè)務想了解我們有沒有在推動這個需求，有沒有一些關鍵的進展，可能他們也是需要用來向上做匯報的。
所以，如果給不出排期，能做什么呢？
把我們能確定的時間點給到，比如什么時候開始做方案設計，比如什么時候進內(nèi)部討論，比如預計什么時候可以寫完prd等。
能把控的流程，越公開越好。
其次，當流程有任何重要的進展時，跟業(yè)務同步，同步是一個可以帶來安全感的動作。即使資源突然出現(xiàn)了意外，或者是一些負面消息，也及時同步。
最后總結(jié)一下：
如果以后業(yè)務問我，這個需求什么時候上線，我會希望他們說明一下：1、為什么要做這個需求2、為什么現(xiàn)在要做3、你想解決的問題是什么4、有沒有現(xiàn)成的數(shù)據(jù)或者分析，給到一些參考
當然，我也會盡自己的能力，做好信息同步和推進。
最后，我希望他們可以理解，從需求文檔的產(chǎn)生到功能上線，是一個復雜的系統(tǒng)，我會跟你們站在一起保證最好的結(jié)果，但也希望你們理解這其中的不確定性。
大家是一個球隊，把產(chǎn)研設的協(xié)作流程與大家分享，也是多求一些理解和支持。

這篇文章我掛在了自己在公司內(nèi)部的blog里，而靈感來源于飛書聽友群里的一篇文章《我為什么要寫blog》。

我覺得有一點說的好，如果頻繁面向不同人回答同一個問題，影響了你的效率，那就把它變成知識，沉淀下來，然后下次再遇到同樣問題的時候，可以給提問者先看看。

當然，如果你想要成為產(chǎn)品經(jīng)理，或者正在跟產(chǎn)品經(jīng)理對接工作，我也希望你了解產(chǎn)品需求的上線流程。

而實際工作，也遠比我描述的復雜得多。