隕石需求指的是「突如其來且意料之外的需求與改動」，在團隊沒有心理準備的狀況下打亂計劃，導致資源要重新安排。如何辨認隕石、面對隕石、擊退隕石，已經成為產品經理的一種日常防衛戰。產品經理可以如何面對“隕石”呢？本文作者對此進行了分析，希望能給你帶來幫助。

產品經理難免都會遇到天外飛來的「隕石」需求，辨認隕石、面對隕石、擊退隕石已經變成一種日常防衛戰。

這篇文章我會分享我對隕石的定義、成因、來源，以及從產品經理的角度可以如何去面對。

另外也希望大家可以思考一下，隕石開發在任何情境下真的都是不好的嗎？會不會有時候這種強大的外在推力會將產品推到意想不到的軌道並進而帶來成長呢？

本篇文章包含：

什麼是隕石開發？

隕石其實是很主觀的：隕石的定義與可能的成因

為什麼會有隕石出現？老闆就不能交給專業的來嗎？

針對老闆型隕石的處理方法

迎接隕石撞擊的正確姿勢

待在充滿隕石的團隊真的很痛苦嗎？敏捷與隕石開發的不同？

01 什麼是隕石開發？天神說「要有光」於是就有了光。

隕石開發有別於瀑布開發（Waterfall）、敏捷開發（Agile）等會出現在教科書上的正規方法論，它是 2018 年時在日本工程師社群中以戲謔的形式出現的一個名詞。

意指有一個「天神」般存在的老闆，無論我們先前規劃地多完整、開發地多順利，只要他一聲令下，前面所有的規劃、開發都要因應而改，就像是隕石擊落在地球上一般，原本的建設都會付之一炬、功虧一簣，所有東西都要從頭來過。

02 隕石其實很主觀：隕石的型別與可能的成因

我遇到的隕石沒有上述文章提到的這麼恐怖與直接，或者應該說，在它還沒擊落任何東西時，通常就會被團隊裡的 PM 辨認出來並小心處理，試圖將它引導到其他軌道上，避免正面迎擊。

若用一句話來形容，我認為所謂的隕石開發、隕石需求就是

「突如其來且意料之外的需求與改動」

，在團隊沒有心理準備的狀況下打亂計劃，導致資源要重新安排。

我遇過的狀況大致上可以分成以下這幾個型別。

型別一：針對開發中、已開發任務的臨時改動

情境A：面對B端客戶的需求變更

有時候 PM 已經跟客戶的視窗前前後後多次確認過需求與規劃了，等到開發完成，才在最後驗收關卡被退回說「後來我們老闆看了說希望可以改 XX 」「我很喜歡、但是老闆覺得 XX」「我最後想再動一個小地方」

那你們不會之前就確認嗎？！你不喜歡你要先講啊！我當下除了傻眼外，也覺得很對不起自己的團隊做了無用功。

我相信這個情境也不只是網際網路行業會碰到，這種情況可以透過在合約裡面明確定義驗收次數、驗收時間、可以修正的次數等等，只要自家公司老闆是挺你的，就有機會可以避免。

情境B：產品做到一半老闆說「這個設計我不太喜歡，我們改一個版本好不好？」

如果是自有產品的團隊，也有可能會遇到產品經理規劃好、進開發後，自家老闆/主管某天去看mockup 的時候說「這個怎麼用這個方法處理啊？這個設計我不太喜歡，我們改一個版本好不好？」好，你說什麼都好。

我還比較資淺的時候，對自己的產品規劃與設計能力不太有把握，也不熟悉老闆/主管喜歡的設計風格，因此解決方法就是在前期研究與規劃階段就頻繁的跟老闆/主管討論、溝通、確認，做好雙方的期待管理。

等到比較有經驗了，對自己產品規劃與設計能力比較有信心、且跟老闆/主管彼此間也有信任感之後，儘管不會所有大大小小的規劃都持續跟他們討論，但還是會定期報告手上的任務，也因此這型別的隕石也就比較少出現了。

型別二：突然提出緊急的新需求、功能

情境C：在銷售眼裡，大型客戶的需求總是重要且緊急

如果是 B2B 公司，銷售隔三差五就會帶著客戶的意見回來詢問；B2C 公司中，則是客服會每天彙報使用者遇到的問題，這都是長遠來看對團隊非常有價值的資料。

但怕的是所謂的重要客戶（Key Accounts）強硬的要求我們在某個時限內做什麼功能，否則他就要離開我們去使用競爭品牌；或者是新客戶還沒簽下來，就說「你們如果有 X 功能我才要簽約」，因此業務為了拿到這筆訂單，就會急急忙忙地跑來找 PM 詢問最近可不可以插入這個新的需求。

這種需求有一個麻煩的地方是，客戶通常對於需求/功能的想像已經非常明確，所以不像平常產品團隊在工作時可以有多次迭代、從 beta 版本開始測試與實作的機會。客戶如果夠大聲（錢給得夠多），就要小心業務單位照單全收。

儘管上述文章已經列了很多情境與處理方式，但我還是常常無法倖免。

有次已經正當地拒絕需求方了，沒想到需求方又去拜託另外一個 PM 處理這個功能，而他們做一做之後因為趕不上預定的時程，最後還是得借調我團隊的研發去開發那個需求。

哎，所以事情真的沒有那麼簡單。

情境D：來自老闆的隕石需求

我認為所有隕石之中最難處理的就是從「老闆」來的需求。

一來是因為我領他薪水、靠他晉升，要拒絕他的需求的時候常常拿不出應有的骨氣；二來是前面的那些隕石的出發點都有憑有據，業務的需求從客戶來、行銷的需求從社群來。

但老闆不像其他團隊成員一樣有明確的職務內容，因此老闆的需求到底從哪來？也許是他的鬼腦袋、也許是投資人的一句話、也許是看到競品大張旗鼓進攻。這樣的未知才是最讓人恐懼的。

常見的狀況是老闆突然跑來問說可不可以研究一下什麼產品、什麼功能、什麼需求，或是突然說「我覺得我們現在應該來做這個，現在 XX 是趨勢啊！」因此想要調動資源，或是公司方向要來個大改動，也是很讓人頭痛。

這部分的原因跟解決方法比較複雜一些，容我用多點篇幅來分享我的想法～

03 為什麼會有隕石出現？老闆就不能交給專業的來嗎？

在跟一些也是在老闆身邊工作的人聊過之後，我們大概可以將遇到的情況與背後的原因分成以下幾種。

1. 風險承受度的不同

身為一個員工，我喜歡東西事先規劃得妥妥的，東西一次改一點點，把高風險的東西拆開、分散，降低每次上線的風險。也許最後我們還是大改，但這樣的程序在我心裡是比較踏實跟舒服的，而這樣頻繁把改動丟到市場測試與滾動式調整，就是做產品中使用者中心的敏捷方法論嘛！

我通常覺得一次大改風險很高、突然說要做什麼都很可怕，因為如果方向錯了或者因此引發其他問題，會讓團隊很痛苦。

敏捷方法論、設計思考這種東西，就是讓沒經驗、比較不聰明的我們，有個系統化的方法可以快速學習跟做出像樣的東西，而不用在一開始就承受高風險 — — 自己太雷、太嫩的風險。

但是對老闆來說，他已經承擔了超大的風險，這個產品改動對他來說可能是眾多決策的一個小部分而已，扛責任就是他的日常生活，他也不怕被員工討厭，只在乎事情是不是有朝他認為對的方向前進。

講難聽點，甚至有些風險承受度高（有錢沒地方花）的老闆，他真的不在意產品做怎樣，他在意的是「我有沒有賭對」、「我的商業眼光是不是很準」，所以他願意十賭九輸，有其中一次賭對就可以拿去跟朋友說，「嘿、我的商業眼光很準！你看我們做了很棒的產品/功能成效很好。」他欣賞的是他自己，而不是欣賞這個市場、他的團隊、和我們服務的使用者。

2. 經驗與眼界造成的資訊落差

有些情況並不完全是因為老闆風險承受度高、我跟同事承受度低，而是因為我們各自評估出來的風險不同。

對跑第一線的業務、或是有多次創業經驗與商業頭腦的老闆來說，他看到某些新機會的當下，腦袋中已經有許多資訊與判斷在高速運轉，只是還來不及白紙黑字寫下來，或是跟對這個商業領域或產業還不熟的我解釋的時候我還無法徹底理解。

也因此他們眼中看到的風險是小的，他們覺得做這個東西絕對是穩的、是合理的，現在不做更待何時？所以這時我眼中的隕石才會下來。

隕石來的時候我覺得天啊風險好高，天要塌了，怎麼突然要做這個，什麼意思啊，但他們眼中看到的也許是一顆難得一見的流星。

這某種層面來看也可以說是資訊不對稱、資訊落差，但總歸來說，不管是誰提的意見，都應該要有明確的商業資料跟使用者研究的佐證才行，才能站穩利基點來互相說服。

3. 身為老闆的焦慮

產業快速變動、業內競爭的產品多，可能老闆今天去跟投資人聊，投資人說做 A 市場很有機會；明天去參加一個老闆們的聚會，另個產業的老闆說我們可以來試試合作 B 商業模式；後天上網亂逛競爭品牌網站發現他們未來策略會主打 C 型別的使用者/功能，心裡想著我們可不能在這時候落後啊！

就是這樣，我每天都不知道老闆的工作到底是什麼，他到底哪來那麼多靈感，今天問 A 明天問 B ，可是我們現在在做 XYZ ，誰有空突然做那麼多事情？

04 針對老闆型隕石的處理方法

1. 確認需求背後的目標與原因，以及老闆的期待

第一就是確認老闆為什麼想做這個？背後的想法是什麼？訊息與資料來源為何？為何他深信做這件事情能達成那個目標？

就像前面提到的，老闆擁有的資訊通常比我們多很多，思想可能也很跳躍，當他提出需求的時候，先幫助他說出一般人在提需求時也應該要提供 PM 的脈絡與邏輯推論流程，至少讓我們是在差不多的資訊水平上，再開始進行討論。雖然真的很難！

2. 重新討論與排序優先順序

第二就是跟處理其他部門的臨時需求的處理方式一樣，跟老闆好好討論優先順序，大家判斷後真的覺得功能 A 是最重要的話那我們就看看是不是先做 A 然後把其他原本的優先事項先擱置暫緩，重新排序正在進行中的功能優先順序。

3. 成立隕石專門機構

另一個作法就是安排一個專門做「機會研究」或是處理「新商業模式」的團隊，他們沒有固定的 roadmap 而是專門在找新的機會點，畢竟所謂隕石就是意料之外突然需要處理的議題嘛，如果有個團隊的使命就是處理這些事情，大家的工作都會順利一些。

05 迎接隕石撞擊的正確姿勢

如果已經確定自己的團隊要迎擊隕石、避不開了，代表有新的需求、時程變動、可能需要藉助外部資源，要有被討厭的心理準備。

為什麼大家討厭隕石？臨時改東西就代表之前都在做無用功，新的需求就代表可能要加班，同時無法做自己真的覺得有價值的事情，前面花好多時間討論的東西有說跟沒說一樣，很浪費時間。

在這種情況下，我認為有幾點要把握：

儘量不加班，如果必須要加班也要幫助團隊拿到相對應的回報（加班費、補休、被老闆在會議上大力表揚）

確保現在的新版本不再是在做無用功，這次真的是最後一次改了！

讓團隊（包括我本人）在這次隕石結束後可以繼續做自己覺得有價值的事情一段時間（畢竟也很難保下次不會再有隕石）

06 待在充滿隕石的團隊真的很痛苦嗎？

其實我以前覺得還好。當自己沒什麼想法的時候，老闆很有想法就是個優點，我只要煩惱怎樣執行最有效率就好；另一方面是如果老闆夠強，隕石砸到的地方都正中紅心，產品是可以跑很快的。

如果原本就沒有一套明確的產品規劃、產品路線圖，那也根本不會有所謂的隕石，畢竟沒目標的時候往哪邊走都算是前進，這是一個相對的概念。

我過去待的其中一個團隊常有隕石需求，但團隊氣氛與產能還是很不錯，因為大家就是相信老闆英明，而且他也的確多次判斷正確，讓產品有所成長。當時的工程師設計師覺得只要需求明確、PM 跟老闆會幫忙背責任、不用加班，那實際上開發什麼內容也都很好講話。所以真的就是看自己和團隊喜歡的工作方式跟對突如其來變動的承受度。

但有個重要依據是，老闆是不是有個明確目標，而那個目標跟你相不相同？

舉例來說，目標是發大財，大家都很明確朝著這方向前進。今天突然有一個新的大桉子進來可以發大財，那大家放這個功能進來就是有共識的；最怕的就是目標是「老闆個人的自我實現」，也就是說他只是想要享受指揮大家、看大家為他辛苦為他忙的心態。

而如果你很討厭隕石，又剛好在一個充滿隕石的團隊，那我會建議你儘快轉換團隊。從 PM 本身的角度來看，比起精準執行老闆/團隊的想法，無論成果好或壞，有些人可能會更想試試看自己的方法、去驗證自己心裡的產品判斷跟商業決策，爽感會更高一些，也才能持續學習跟發揮長才。

此外，有些團隊會打著「敏捷」的大旗行「隕石」之實，這兩者所具備的「彈性」是很不同的。敏捷開發的彈性在於有個明確的目標與路線規劃，工作方法與執行內容都圍繞在目標之上，同時快速去測試不同的解法，每個小階段的結束都能調整產品開發方向、資源投入程度等等；隕石開發的彈性則在於，只要我說要做、要改，現在就要馬上生出人力來幫忙處理。

不過團隊就算跑敏捷也不代表這輩子就不會有隕石出現。

就聊這麼多。

作者：駱齊；公眾號：產品經理駱齊

本文由 @產品經理駱齊 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。