陨石需求指的是「突如其来且意料之外的需求与改动」，在团队没有心理准备的状况下打乱计划，导致资源要重新安排。如何辨认陨石、面对陨石、击退陨石，已经成为产品经理的一种日常防卫战。产品经理可以如何面对“陨石”呢？本文作者对此进行了分析，希望能给你带来帮助。

产品经理难免都会遇到天外飞来的「陨石」需求，辨认陨石、面对陨石、击退陨石已经变成一种日常防卫战。

这篇文章我会分享我对陨石的定义、成因、来源，以及从产品经理的角度可以如何去面对。

另外也希望大家可以思考一下，陨石开发在任何情境下真的都是不好的吗？会不会有时候这种强大的外在推力会将产品推到意想不到的轨道并进而带来成长呢？

本篇文章包含：

• 什么是陨石开发？
• 陨石其实是很主观的：陨石的定义与可能的成因
• 为什麽会有陨石出现？老板就不能交给专业的来吗？
• 针对老板型陨石的处理方法
• 迎接陨石撞击的正确姿势
• 待在充满陨石的团队真的很痛苦吗？敏捷与陨石开发的不同？

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 本身的角度来看，比起精准执行老板/团队的想法，无论成果好或坏，有些人可能会更想试试看自己的方法、去验证自己心里的产品判断跟商业决策，爽感会更高一些，也才能持续学习跟发挥长才。

此外，有些团队会打着「敏捷」的大旗行「陨石」之实，这两者所具备的「弹性」是很不同的。敏捷开发的弹性在于有个明确的目标与路线规划，工作方法与执行内容都围绕在目标之上，同时快速去测试不同的解法，每个小阶段的结束都能调整产品开发方向、资源投入程度等等；陨石开发的弹性则在于，只要我说要做、要改，现在就要马上生出人力来帮忙处理。

不过团队就算跑敏捷也不代表这辈子就不会有陨石出现。

就聊这么多。