起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識臨時需求的特點，及兩種臨時需求的處理方式
希望這篇分享能給大家帶來一些小啟發，至少以后別人給你丟了個臨時需求時，不會慌張，能夠淡定高效的把它完成。
“跟進臨時需求”、“具有項目協調和推動能力”，這是產品崗位介紹中經常出現的兩句話。那么，那些臨時需求和我們認識的一般需求有什么不同？如何有效的推進這類需求 ？這是我想和大家分享的兩個地方。
臨時需求的特點
臨時需求有兩個含義：
1、自己正在做的需求，因為產品內部或外界因素需要在原本功能需求中臨時添加，有些甚至在需求封版后還要進行臨時的一些“不太友好“的改動（求各位研發大大輕噴）
這類需求的特點有以下三個方面：明確、緊急、一般可控；
2、別人做了一半的需求，產品組內分工或臨時調整后交給了你，狀態不一，有些還在需求收集階段，有些已經在開發狀態了。
這類需求的特點是：懵逼、易背鍋、還不好控制；
兩類臨時需求的介入與處理方法：
新增或需要改動的需求
先介紹下第一類：在自己的需求完成過程中，新增或需要改動的需求。
需求優先級
給這類臨時需求排優先級要先思考兩個問題：這個臨時需求來源于誰，他或者他們的目的是什么？如果這個出現在我正常的進度中，會不會導致我核心功能受到影響或者整個項目delay？
我分享下我對需求的優先級簡單快速的排序（采用否定的態度思考）：
NO.1 產品目標or公司商業目標：
我就嘗試下不做、不加、不改對產品目標or相關商業目標是否有影響？如果影響到了整個公司的商業計劃或者是產品的大目標，那么毫無疑問，優先級高高的。本版確實要加要改，研發兄弟們的一個月麻辣小龍蝦我包了！
NO.2 對原始核心需求的影響：
我是不是只有不加這個臨時的需求，才能確保我原有功能的完整上線、才能保證原有進度的正?；蛘咛崆巴瓿?。如果這個需求對我的原有功能影響太大，讓我不能愉快的刷夜上線了。果斷拒絕，下一版再見。
NO.3 對情感與后續影響的把握：
我不加這個臨時需求是不會影響到我之后的工作安排與后續的需求實現，在完全的摸透需求方的需求后，是不是存在必須先有一再有二才能有三的關系鏈，因為自己挖的坑遲早自己是要跳的。。。以及市場運營等等的各位大大會不會對我有偏見，出去聚餐不帶上我，導致不能好好工作了等等。
NO.X BOSS或者總監點名
該需求需要在本版或者什么版上線之類的，這部分的優先級請大家自行把握。站的角度不一樣，思考的維度與層次不一，但是這部分我每次都是在據理力爭后才被迫接受的，嗯。。。
需求實現難度
研發弟兄們對需求的態度不一， 但是把握好以下幾點還是可以在這個過程中找到平衡點的
- 講道理：在思考優先級的時候因為都是從否定的角度上去考慮，我們實際上已經考慮了大部分研發兄弟們的疑惑。這個功能臨時加了有用嗎？不做不可以嗎？萬一讓XX功能受到影響怎么辦？這時候只需要開會的時候和他們一一解答下自己對該需求的認識與思路即可。
- 帶節奏：在緊張刺激的需求過審會上，趁著氣氛帶下節奏，好了，那這個需求就過了。有什么疑問的話直接私聊我就行。
- 細整理：把臨時需求會影響到的前后臺邏輯與交互細節整理出來，即使是一個摁扭、一個交互樣式或者是后臺數據傳輸等，與測試碰個小會。確保臨時需求的加入對原有需求不會產生影響，保證驗收的時候不落不少。
當然，以上實現的難度與排期長短與麻辣小龍蝦的口味與分量有關。
未完成需求
接下來重點介紹第二類：在自己正常的工作中，臨時接到個未完成的需求。
需求詳情
當部分完成的需求來的時候，大部分人一開始并不知道這個需求是干啥的，誰提的都不知道。但是在現實的場景中出現的頻率又很高，尤其是在人員變動較大或者人手不足的團隊。往往就是產品總監或者boss一句話：“xxx，你來跟下這個需求”，還沒反應過來，然后你就一臉懵逼的被接下了。
想要快速了解這個未完成的需求，試試從以下4個問題出發：
1.為什么要做這個需求？
從需求的具體目標出發是了解一個新需求的快速方法之一。
- 交互類：這個功能是要提升用戶體驗還是誘導用戶做一些事情；
- 運營類：這個需求是要配合一次拉新活動還是要確保留存率等的提高；
- 數據類：要配合完成用戶畫像還是進行數據監控；
- 后臺類：解決了多年來吐槽的點還是提高了工作人員的效率。
其他等等。這部分可以與“前任產品”或者該需求主要需求方溝通。這里就發現留有MRD/BRD/PRD的好處了吧。
當然，要是在這個第一問題中可以把這個需求砍了，那也是極好的。
2.現在完成的進度怎么樣了？
是在需求收集階段還是在已經研發的階段，是需要協調外部資源還是在上線最后驗收的階段。掌握這個未完成的需求的進度對產品經理來說十分必要。他可以有效的減少與各部門的溝通成本。
是在調研階段那是很幸福的，相當于可以在掌握了上一個產品收集的資料后，自己從頭做個需求。但是如果現在已經在需求封版正在開發的階段，你頻繁的去找需求方聊當初聊的需求而不知道看交付給研發的PRD。遇到強勢的需求方，后面就會發現這是很吃力不討好的行為。。。
總之一句話：拒絕閉眼睛干活！
3.開發有沒有遇到困難點？
是否在需求實現的過程中遇到了困難，和研發的溝通極為重要，這部分你是新介入的產品，研發兄弟們是否在開發的過程中遇到了新的問題。是需求本身需要修改還是有疑惑的地方。
知道困難點在哪，緊急且不懂的細節要及時求助“前任”產品。
4.該需求的直接支持方又有哪些？
需求的直接支持方決定了你借力的難度與程度。臨時介入的產品相對比較弱勢，熟悉需求需要時間，項目組成員之間需要互相磨合等。所以遇到阻力有時候可以借助原始需求方的力量。
人多力量大，產品經理的影響力是需要慢慢積累的。吼吼。
與三方的配合
這里的三方指的是：需求方、相關研發負責人、其他相關的配合人員
需求方：
確認各需求方，并告知該需求的產品負責人已變更，同上所說，得到他們的支持。因為確認需求、改需求等都是要他們確認。
研發負責人：
告知研發兄弟們這個需求產品這塊的負責人已經變更了，并詳細了解需求實現的進度與技術難點有哪些，需要得到哪些部門等資源的支持。并確認該需求計劃完成時間。
其他配合人員：告知該需求產品負責人已變更，落實相關資源可支持人員。時刻保持緊密有效的溝通。
記錄與反饋
這類未完成的臨時需求除了正常的記錄等以外，還需要特別注意的就是相關細節的反饋與記錄。
- 時間：通常是指立項時間、排期等。這里還需要加上一些每次會議上約定的時間。避免互相傷害！
- 人員：因不熟悉團隊相關人員，尤其要注意責任需要到人。避免跟丟！
- 反饋：與上級與以上三方進行進度的匯報，形式不限。確?；ハ啾O督！
PS：為了避免費時費力，項目還可能要無限delay，特別提醒大家注意這三塊的記錄與反饋
總結
希望這篇分享能給大家帶來一些小啟發，至少以后別人給你丟了個臨時需求時，不會慌張，能夠淡定高效的把它完成。當然，具備能夠跟進臨時需求和具有項目協調推動的能力要求遠遠不止這些。
以上僅是我一年多以來的經驗與分享，如有錯誤，還請大家多多包涵。同時歡迎大家來一起討論哈。
本文由 @奔跑的鴕鳥 原創發布于人人都是產品經理。未經許可，禁止轉載。
您好，請問您之前是有給方正集團做過產品經理的培訓嗎？
謝謝大家的打賞與收藏，歡迎大家一起來討論，有約小龍蝦擼串的私聊我。我在北京這塊 ??