【產品團隊甘苦談】如何處理各種「隕石開發」的緊急要求？
【產品團隊甘苦談】是產品三眼怪的新系列，我們想要藉由這個系列跟大家分享 PM 工作中不那麼有趣的一面，希望讓正在面對這些困境的朋友們感到自己不孤單、一起分享壓力，也讓想要進入這個職能的讀者們了解實務上可能遇到的狀況。
我待過幾個不同的產品團隊，團隊文化分別偏向台灣、香港、日本（隕石的故鄉），都是在公司走來走去看得到老闆本人的小型團隊。而不論我在哪個團隊工作時，難免都會遇到天外飛來的「隕石」需求，辨認隕石、面對隕石、擊退隕石已經變成一種日常防衛戰。
這篇文章我會分享我對隕石的定義、成因、來源，以及從產品經理的角度可以如何去面對。另外也希望大家可以思考一下，隕石開發在任何情境下真的都是不好的嗎？會不會有時候這種強大的外在推力會將產品推到意想不到的軌道並進而帶來成長呢？
【本篇文章包含】 ✔ 什麼是隕石開發？ ✔ 隕石其實是很主觀的：隕石的定義與可能的成因 ✔ 為什麼會有隕石出現？老闆就不能交給專業的來嗎？ ✔ 針對老闆型隕石的處理方法 ✔ 迎接隕石撞擊的正確姿勢 ✔ 待在充滿隕石的團隊真的很痛苦嗎？敏捷與隕石開發的不同？
▍什麼是隕石開發？神說「要有光」於是就有了光。
隕石開發（Meteo Fall、メテオフォール型開発）有別於瀑布開發（Waterfall）、敏捷開發（Agile）等會出現在教科書上的正規方法論，它是 2018 年時在日本工程師社群中以戲謔的形式出現的一個名詞，意指有一個「天神」般存在的老闆，無論我們先前規劃地多完整、開發地多順利，只要他一聲令下，前面所有的規劃、開發都要因應而改，就像是隕石擊落在地球上一般，原本的建設都會付之一炬、功虧一簣，所有東西都要從頭來過。
原文（日文）：メテオフォール型開発
翻譯（繁中）：轉載好文 — 隕石開發法
▍隕石其實很主觀：隕石的類型與可能的成因
我遇到的隕石沒有上述文章提到的這麼恐怖與直接，或者應該說，在它還沒擊落任何東西時，通常就會被團隊裡的 PM 辨認出來並小心處理，試圖將它引導到其他軌道上，避免正面迎擊。
若用一句話來形容，我認為所謂的隕石開發、隕石需求就是「突如其來且意料之外的需求與改動」，在團隊沒有心理準備的狀況下打亂計劃，導致資源要重新安排。
我遇過的狀況大致上可以分成以下這幾個類型。
類型一：針對開發中、已開發任務的臨時改動
情境A：接案公司遇到的白目客戶在接案團隊中，有時候 PM 已經跟客戶的窗口前前後後多次確認過需求與規劃了，等到開發完成，才在最後驗收關卡被退回說「欸後來我們老闆看了說希望可以改 OOXX 」「我很喜歡、但是老闆覺得 OOXX」「我最後想再動一個小地方」那你們是不會之前就確認嗎？！你不喜歡你要先講啊！！！我當下除了傻眼外，也覺得很對不起自己的團隊做了白工 🙄
我相信這個情境也不是只有網路或軟體產業會碰到，這種情況可以透過在合約裡面明確定義驗收次數、驗收時間、可以修正的次數等等，只要自家公司老闆是挺你的，就有機會可以避免。
情境B：產品做到一半老闆說「這個設計我不太喜歡欸我們改一個版本好不好？」如果是自有產品的團隊，也有可能會遇到產品經理規劃好、進開發後，自家老闆/主管某天測試或去看 spec、mockup 的時候說「欸這個怎麼用這個方法處理啊？這個設計我不太喜歡欸我們改一個版本好不好？」好，你說什麼都好。
我還比較資淺的時候，對自己的產品規劃與設計能力不太有把握，也不熟悉老闆/主管喜歡的設計風格，因此解決方法就是在前期研究與規劃階段就頻繁的跟老闆/主管討論、溝通、確認，做好雙方的期待管理。
等到比較有經驗了，對自己產品規劃與設計能力比較有信心、且跟老闆/主管彼此間也有信任感之後，儘管不會所有大大小小的規劃都持續跟他們討論，但還是會定期報告手上的任務，也因此這類型的隕石也就比較少出現了。
類型二：突然提出緊急的新需求、插件
情境C：在業務單位眼中，大型客戶的需求總是重要且緊急如果是 B2B 公司，業務、AM 三不五時就會帶著客戶的意見回來詢問；B2C 公司中，則是客服會每天回報使用者遇到的問題，這都是長遠來看對團隊非常有價值的資料。
但怕的是所謂的重要客戶（Key Accounts）強硬的要求我們在某個時限內做什麼功能，否則他就要離開我們換去使用競爭品牌；或者是新客戶還沒簽下來，就說「你們如果有 X 功能我才要簽約」，因此業務為了拿到這筆訂單，就會急急忙忙地跑來找 PM 詢問最近可不可以插入這個新的需求。
這種需求有一個麻煩的地方是，客戶通常對於需求/功能的想像已經非常明確，所以不像平常產品團隊在工作時可以有多次迭代、從 beta 版本開始測試與實作的機會。客戶如果夠大聲（錢給得夠多），就要小心業務單位照單全收。
處理方式我之前寫過一篇完整的文章分享，詳情請見：
儘管上述文章已經列了滿多情境與處理方式，但我還是常常無法倖免。有次已經正當地拒絕需求方了，沒想到需求方又去拜託另外一個 PM 處理這擋插件，而他們做一做之後因為趕不上預定的時程，最後還是得借調我團隊的工程師去開發那個需求。哎～～～所以事情真的沒有那麼簡單 😢
情境D：來自老闆的隕石需求我認為所有隕石之中最難處理的就是從「老闆」來的需求，一來是因為我領他薪水、靠他升遷，要拒絕他的需求的時候常常拿不出應有的骨氣；二來是前面的那些隕石的出發點都有憑有據，業務的需求從客戶來、行銷的需求從社群來，但老闆不像其他團隊成員一樣有明確的職務內容，因此老闆的需求到底從哪來？也許是他的鬼腦袋、也許是投資人的一句話、也許是看到競品大張旗鼓進攻。這樣的未知才是最讓人恐懼的。
常見的狀況是老闆突然跑來問說可不可以研究一下什麼產品、什麼功能、什麼需求，或是突然說「欸我覺得我們現在應該來做這個，現在 OOXX 是趨勢阿！」因此想要調動資源，或是公司方向要來個大改動，也是很讓人頭痛。
這部分的原因跟解決方法比較複雜一些，容我用多點篇幅來分享我的想法～
▍為什麼會有隕石出現？老闆就不能交給專業的來嗎？
前面有提到我待的團隊都是較小型的公司，公司/BU 人數介於 10–100 人，因此我所提到的老闆就是公司的老闆，CEO 或是創辦人本人，產業快速變動中、業內競爭的產品也非常多，請大家在這個前提下來理解我遇到的問題！至於大公司會遇到的隕石可能就會不太一樣，就請不要一概帶入囉。
在跟一些也是在老闆身邊工作的人聊過之後，我們大概可以將遇到的情況與背後的原因分成以下幾種。
1. 風險承受度的不同
身為一個員工，我喜歡東西事先規劃的妥妥的，東西一次改一點點，把高風險的東西拆開、分散，降低每次上線的風險。也許最後我們還是大改，但這樣的進程在我心裡是比較踏實跟舒服的，而這樣頻繁把改動丟到市場測試與滾動式調整，就是做產品中使用者中心的敏捷方法論嘛！
我通常覺得一次大改風險很高、突然天外飛來一筆說要做什麼都很可怕，因為如果方向錯了、如果出大包了、如果做白工了，都會讓團隊很痛苦。阿我就怕被罵嘛！
敏捷方法論、設計思考這種東西，就是讓沒經驗、比較不聰明的我們，有個系統化的方法可以快速學習跟做出像樣的東西，而不用在一開始就承受高風險 — — 自己太雷、太嫩的風險。
但是對老闆來說，他創業就已經承擔了超大的風險，這個產品改動對他來說可能是眾多決策的一個小部分而已，扛責任就是他的日常生活，他也不怕被員工討厭（但我怕），只在乎事情是不是有朝他認為對的方向前進。
講難聽點，甚至有些風險承受度高（有錢沒地方花）的老闆，他真的不在意產品做怎樣，他在意的是「我有沒有賭對」、「我的商業眼光是不是很準」，所以他願意十賭九輸，有其中一次賭對就可以拿去跟朋友說，「嘿、我的商業眼光很準！你看我們做了很棒的產品/功能成效很好。」他欣賞的是他自己，而不是欣賞這個市場、他的團隊、和我們服務的使用者。
2. 經驗與眼界造成的資訊落差
有些情況並不完全是因為老闆風險承受度高、我跟同事承受度低，而是因為我們各自評估出來的風險不同。
對跑第一線的業務、或是有多次創業經驗與商業頭腦的老闆來說，他看到某些新機會的當下，腦袋中已經有許多資訊與判斷在高速運轉，只是還來不及白紙黑字寫下來，或是跟對這個商業領域或產業還不熟的我解釋的時候我還無法徹底理解。
也因此他們眼中看到的風險是小的，他們覺得做這個東西絕對是穩的、是合理的，現在不做更待何時？所以這時我眼中的隕石才會下來。隕石來的時候我覺得天啊風險好高天要塌了怎麼突然要做這個什麼意思啊，但他們眼中看到的也許是一顆難得一見的流星。
這某種層面來看也可以說是資訊不對稱、資訊落差，但總歸來說，不管是誰提的意見，都應該要有明確的商業數據跟使用者研究的佐證才行，才能站穩利基點來互相說服。
3. 身為創業老闆的焦慮
老闆就是 CEO 或是創辦人本人，產業快速變動、業內競爭的產品多，可能老闆今天去跟投資人聊，投資人說做 A 市場很有機會；明天去參加一個老闆們的聚會，另個產業的老闆說我們可以來試試合作 B 商業模式；後天上網亂逛競爭品牌網站發現他們未來策略會主打 C 類型的使用者/功能，心裡想著我們可不能在這時候落後啊！
就是這樣，我每天都不知道老闆的工作到底是什麼，他到底哪來那麼多靈感，今天問 A 明天問 B 阿可是我們現在在做 XYZ 欸，誰有空突然做那麼多事情啦？
▍針對老闆型隕石的處理方法
1. 確認需求背後的目標與原因，以及老闆的期待
第一就是確認老闆為什麼想做這個？背後的想法是什麼？消息與數據來源為何？為何他深信做這件事情能達成那個目標？
就像前面提到的，老闆擁有的資訊通常比我們多很多，思想可能也很跳躍，當他提出需求的時候，先幫助他說出一般人在提需求時也應該要提供 PM 的脈絡與邏輯推論流程，至少讓我們是在差不多的資訊水平上再開始進行討論。雖・然・真・的・很・難！
2. 重新討論與排序優先級
第二就是跟處理其他部門的臨時需求的處理方式一樣，跟老闆好好討論優先級，大家判斷後真的覺得插件 A 是最重要的話那我們就看看是不是先做 A 然後把其他原本的優先事項先擱置暫緩，重新排序正在進行中專案的優先級。
3. 成立隕石專門機構
另一個作法就是安排一個專門做「機會研究」或是處理「新商業模式」的團隊，他們沒有固定的 roadmap 而是專門在找新的機會點，畢竟所謂隕石就是意料之外突然需要處理的議題嘛，如果有個團隊的使命就是處理這些事情，大家的工作都會順利一些。
▍迎接隕石撞擊的正確姿勢
如果已經確定自己的團隊要迎擊隕石、避不開了，代表有新的需求、時程變動、可能需要借助外部資源，要有被討厭的心理準備。
為什麼大家討厭隕石？臨時改東西就代表之前都在做白工，新的需求就代表可能要加班，同時無法做自己真的覺得有價值的事情，前面花好多時間討論的東西有說跟沒說一樣，很浪費時間。
在這種情況下，我認為有幾點要把握：
- 盡量不加班，如果必須要加班也要幫助團隊拿到相對應的回報（加班費、補休、被老闆在會議上大力表揚）
- 確保現在的新版本不再是在做白工，這次真的是最後一次改了！
- 讓團隊（包括我本人）在這次隕石結束後可以繼續做自己覺得有價值的事情一段時間（畢竟也很難保下次不會再有隕石）
▍待在充滿隕石的團隊真的很痛苦嗎？
其實我以前覺得還好。當自己沒什麼想法的時候，老闆很有想法就是個優點，我只要煩惱怎麼樣執行最有效率就好；另一方面是如果老闆夠強，隕石砸到的地方都正中紅心，產品是可以跑很快的。
如果原本就沒有一套明確的產品規劃、產品路線圖，那也根本不會有所謂的隕石，畢竟沒目標的時候往哪邊走都算是前進，這是一個相對的概念。
我過去待的其中一個團隊常有隕石需求，但團隊氣氛與產能還是很不錯，因為大家就是相信老闆英明，而且他也的確多次判斷正確，讓產品有所成長。當時的工程師設計師覺得只要需求明確、PM 跟老闆會幫忙揹責任、不用加班，那實際上開發什麼內容也都很好講話。所以真的就是看自己和團隊喜歡的工作方式跟對突如其來變動的承受度。
但有個重要依據是，老闆是不是有個明確目標，而那個目標跟你相不相同？
舉例來說，目標是發大財，大家都很明確朝著這方向前進。今天突然有一個新的大案子進來可以發大財，那大家放這個插件進來就是有共識的；最怕的就是目標是「老闆個人的自我實現」，也就是說他只是想要享受指揮大家、看大家為他辛苦為他忙的心態。
而如果你很討厭隕石，又剛好在一個充滿隕石的團隊，那我會建議你盡快轉換團隊。從 PM 本身的角度來看，比起精準執行老闆/團隊的想法，無論成果好或壞，有些人可能會更想試試看自己的方法、去驗證自己心裡的產品判斷跟商業決策，爽感會更高一些，也才能持續學習跟發揮長才。
此外，有些團隊會打著「敏捷」的大旗行「隕石」之實，這兩者所具備的「彈性」是很不同的。敏捷開發的彈性在於有個明確的目標與路線規劃，工作方法與執行內容都圍繞在目標之上，同時快速去測試不同的解法，每個小階段的結束都能調整產品開發方向、資源投入程度等等；隕石開發的彈性則在於，只要我說要做、要改，現在就要馬上生出人力來幫忙處理。
不過團隊就算跑真・敏捷也不代表這輩子就不會有隕石出現阿～～～
也許你看完這篇會覺得這離真正隕石到不行的團隊還差得多了，那可能是因為我待在太過隕石的團隊不久後就離職了。如果真的無法接受那樣的工作環境的話，建議還是快逃啊～～～
以上就是我過去面對隕石的經驗與心得分享。
這一次的【產品團隊甘苦談】系列在目前的規劃中一共至少會有三篇： (1) 該如何處理與面對團隊建立的磨合期？ (2) 如何處理各種「隕石開發」的緊急要求？ (3) 遇到雷隊友該怎麼辦？
如果有更多「甘苦」的事情也不排除新增更多文章（希望不要太甘苦） 喜歡的話還請追蹤我們並且拍手鼓勵鼓勵唷 👏
謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我們 📒
如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-30 個拍手；
如果想看更多團隊合作與溝通技巧分享，請盡情長按拍手（max 50）讓我們知道 👏🏻想要持續追蹤我們的最新文章，請記得追蹤「產品三眼怪實驗室」(◉◉◉)！
我們每週末都會認真更新文章唷！千萬別錯過了～