希望這篇分享能給大家?guī)硪恍┬l(fā)，至少以后別人給你丟了個臨時需求時，不會慌張，能夠淡定高效的把它完成。

“跟進臨時需求”、“具有項目協(xié)調(diào)和推動能力”，這是產(chǎn)品崗位介紹中經(jīng)常出現(xiàn)的兩句話。那么，那些臨時需求和我們認識的一般需求有什么不同？如何有效的推進這類需求 ？這是我想和大家分享的兩個地方。

臨時需求的特點

臨時需求有兩個含義：

1、自己正在做的需求，因為產(chǎn)品內(nèi)部或外界因素需要在原本功能需求中臨時添加，有些甚至在需求封版后還要進行臨時的一些“不太友好“的改動（求各位研發(fā)大大輕噴）

這類需求的特點有以下三個方面：明確、緊急、一般可控；

2、別人做了一半的需求，產(chǎn)品組內(nèi)分工或臨時調(diào)整后交給了你，狀態(tài)不一，有些還在需求收集階段，有些已經(jīng)在開發(fā)狀態(tài)了。

這類需求的特點是：懵逼、易背鍋、還不好控制；

兩類臨時需求的介入與處理方法：

新增或需要改動的需求

先介紹下第一類：在自己的需求完成過程中，新增或需要改動的需求。

需求優(yōu)先級

給這類臨時需求排優(yōu)先級要先思考兩個問題：這個臨時需求來源于誰，他或者他們的目的是什么？如果這個出現(xiàn)在我正常的進度中，會不會導(dǎo)致我核心功能受到影響或者整個項目delay？

我分享下我對需求的優(yōu)先級簡單快速的排序（采用否定的態(tài)度思考）：

NO.1 產(chǎn)品目標or公司商業(yè)目標：

我就嘗試下不做、不加、不改對產(chǎn)品目標or相關(guān)商業(yè)目標是否有影響？如果影響到了整個公司的商業(yè)計劃或者是產(chǎn)品的大目標，那么毫無疑問，優(yōu)先級高高的。本版確實要加要改，研發(fā)兄弟們的一個月麻辣小龍蝦我包了！

NO.2 對原始核心需求的影響：

我是不是只有不加這個臨時的需求，才能確保我原有功能的完整上線、才能保證原有進度的正?；蛘咛崆巴瓿伞Ｈ绻@個需求對我的原有功能影響太大，讓我不能愉快的刷夜上線了。果斷拒絕，下一版再見。

NO.3 對情感與后續(xù)影響的把握：

我不加這個臨時需求是不會影響到我之后的工作安排與后續(xù)的需求實現(xiàn)，在完全的摸透需求方的需求后，是不是存在必須先有一再有二才能有三的關(guān)系鏈，因為自己挖的坑遲早自己是要跳的。。。以及市場運營等等的各位大大會不會對我有偏見，出去聚餐不帶上我，導(dǎo)致不能好好工作了等等。

NO.X BOSS或者總監(jiān)點名

該需求需要在本版或者什么版上線之類的，這部分的優(yōu)先級請大家自行把握。站的角度不一樣，思考的維度與層次不一，但是這部分我每次都是在據(jù)理力爭后才被迫接受的，嗯。。。

需求實現(xiàn)難度

研發(fā)弟兄們對需求的態(tài)度不一， 但是把握好以下幾點還是可以在這個過程中找到平衡點的

• 講道理：在思考優(yōu)先級的時候因為都是從否定的角度上去考慮，我們實際上已經(jīng)考慮了大部分研發(fā)兄弟們的疑惑。這個功能臨時加了有用嗎？不做不可以嗎？萬一讓XX功能受到影響怎么辦？這時候只需要開會的時候和他們一一解答下自己對該需求的認識與思路即可。
• 帶節(jié)奏：在緊張刺激的需求過審會上，趁著氣氛帶下節(jié)奏，好了，那這個需求就過了。有什么疑問的話直接私聊我就行。
• 細整理：把臨時需求會影響到的前后臺邏輯與交互細節(jié)整理出來，即使是一個摁扭、一個交互樣式或者是后臺數(shù)據(jù)傳輸?shù)?，與測試碰個小會。確保臨時需求的加入對原有需求不會產(chǎn)生影響，保證驗收的時候不落不少。

當(dāng)然，以上實現(xiàn)的難度與排期長短與麻辣小龍蝦的口味與分量有關(guān)。

未完成需求

接下來重點介紹第二類：在自己正常的工作中，臨時接到個未完成的需求。

需求詳情

當(dāng)部分完成的需求來的時候，大部分人一開始并不知道這個需求是干啥的，誰提的都不知道。但是在現(xiàn)實的場景中出現(xiàn)的頻率又很高，尤其是在人員變動較大或者人手不足的團隊。往往就是產(chǎn)品總監(jiān)或者boss一句話：“xxx，你來跟下這個需求”，還沒反應(yīng)過來，然后你就一臉懵逼的被接下了。

想要快速了解這個未完成的需求，試試從以下4個問題出發(fā)：

1.為什么要做這個需求？

從需求的具體目標出發(fā)是了解一個新需求的快速方法之一。

• 交互類：這個功能是要提升用戶體驗還是誘導(dǎo)用戶做一些事情；
• 運營類：這個需求是要配合一次拉新活動還是要確保留存率等的提高；
• 數(shù)據(jù)類：要配合完成用戶畫像還是進行數(shù)據(jù)監(jiān)控；
• 后臺類：解決了多年來吐槽的點還是提高了工作人員的效率。

其他等等。這部分可以與“前任產(chǎn)品”或者該需求主要需求方溝通。這里就發(fā)現(xiàn)留有MRD/BRD/PRD的好處了吧。

當(dāng)然，要是在這個第一問題中可以把這個需求砍了，那也是極好的。

2.現(xiàn)在完成的進度怎么樣了？

是在需求收集階段還是在已經(jīng)研發(fā)的階段，是需要協(xié)調(diào)外部資源還是在上線最后驗收的階段。掌握這個未完成的需求的進度對產(chǎn)品經(jīng)理來說十分必要。他可以有效的減少與各部門的溝通成本。

是在調(diào)研階段那是很幸福的，相當(dāng)于可以在掌握了上一個產(chǎn)品收集的資料后，自己從頭做個需求。但是如果現(xiàn)在已經(jīng)在需求封版正在開發(fā)的階段，你頻繁的去找需求方聊當(dāng)初聊的需求而不知道看交付給研發(fā)的PRD。遇到強勢的需求方，后面就會發(fā)現(xiàn)這是很吃力不討好的行為。。。

總之一句話：拒絕閉眼睛干活！

3.開發(fā)有沒有遇到困難點？

是否在需求實現(xiàn)的過程中遇到了困難，和研發(fā)的溝通極為重要，這部分你是新介入的產(chǎn)品，研發(fā)兄弟們是否在開發(fā)的過程中遇到了新的問題。是需求本身需要修改還是有疑惑的地方。

知道困難點在哪，緊急且不懂的細節(jié)要及時求助“前任”產(chǎn)品。

4.該需求的直接支持方又有哪些？

需求的直接支持方?jīng)Q定了你借力的難度與程度。臨時介入的產(chǎn)品相對比較弱勢，熟悉需求需要時間，項目組成員之間需要互相磨合等。所以遇到阻力有時候可以借助原始需求方的力量。

人多力量大，產(chǎn)品經(jīng)理的影響力是需要慢慢積累的。吼吼。

與三方的配合

這里的三方指的是：需求方、相關(guān)研發(fā)負責(zé)人、其他相關(guān)的配合人員

需求方：

確認各需求方，并告知該需求的產(chǎn)品負責(zé)人已變更，同上所說，得到他們的支持。因為確認需求、改需求等都是要他們確認。

研發(fā)負責(zé)人：

告知研發(fā)兄弟們這個需求產(chǎn)品這塊的負責(zé)人已經(jīng)變更了，并詳細了解需求實現(xiàn)的進度與技術(shù)難點有哪些，需要得到哪些部門等資源的支持。并確認該需求計劃完成時間。

其他配合人員：告知該需求產(chǎn)品負責(zé)人已變更，落實相關(guān)資源可支持人員。時刻保持緊密有效的溝通。

記錄與反饋

這類未完成的臨時需求除了正常的記錄等以外，還需要特別注意的就是相關(guān)細節(jié)的反饋與記錄。

• 時間：通常是指立項時間、排期等。這里還需要加上一些每次會議上約定的時間。避免互相傷害！
• 人員：因不熟悉團隊相關(guān)人員，尤其要注意責(zé)任需要到人。避免跟丟！
• 反饋：與上級與以上三方進行進度的匯報，形式不限。確?；ハ啾O(jiān)督！

PS：為了避免費時費力，項目還可能要無限delay，特別提醒大家注意這三塊的記錄與反饋

總結(jié)

希望這篇分享能給大家?guī)硪恍┬l(fā)，至少以后別人給你丟了個臨時需求時，不會慌張，能夠淡定高效的把它完成。當(dāng)然，具備能夠跟進臨時需求和具有項目協(xié)調(diào)推動的能力要求遠遠不止這些。

以上僅是我一年多以來的經(jīng)驗與分享，如有錯誤，還請大家多多包涵。同時歡迎大家來一起討論哈。

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