共计 5061 个字符，预计需要花费 13 分钟才能阅读完成。
我待过几个不同的产品团队，团队文化别离偏差台湾、香港、日本（陨石的故土），都是在公司走来走去看失去老板自己的小型团队。而不管我在哪个团队工作时，不免都会遇到天外飞来的「陨石」需要，识别陨石、面对陨石、击退陨石曾经变成一种日常防守战。
这篇文章我会分享我对陨石的定义、成因、起源，以及从产品经理的角度能够如何去面对。另外也心愿大家能够思考一下，陨石开发在任何情境下真的都是不好的吗？会不会有时候这种弱小的外在推力会将产品推到意想不到的轨道并进而带来成长呢？
本文章蕴含
✔什么是陨石开发？
✔陨石其实是很主观的：陨石的定义和可能的成因
✔为什么会有陨石呈现？老板就不能交给业余的来吗？
✔针对老板型陨石的解决办法
✔迎接陨石撞击的正确姿态
✔待在充斥陨石的团队真的很苦楚吗？麻利与陨石开发的不同？
什么是陨石开发？
陨石开发（MeteoFall、メテオフォール型开発）有别于瀑布开发（Waterfall）、麻利开发（Agile）等会呈现在教科书上的正规方法论，它是 2018 年时在日本工程师社群中以戏谑的模式呈现的一个名词，意指有一个「天神」般存在的老板，无论咱们先前布局地多残缺、开发地多顺利，只有他一声令下，后面所有的布局、开发都要因应而改，就像是陨石击落在地球上个别，本来的建设都会付之一炬、功亏一篑，所有货色都要从头来过。
陨石的类型和可能的成因
我遇到的陨石没有上述文章提到的这么恐怖与间接，或者应该说，在它还没击落任何货色时，通常就会被团队里的 PM 辨认出来并小心解决，试图将它疏导到其余轨道上，防止侧面迎击。
若用一句话来形容，我认为所谓的陨石开发、陨石需要就是「从天而降且意料之外的需要与改变」，在团队没有心理准备的情况下打乱打算，导致资源要重新安排。
我遇过的情况大抵上能够分成以下这几个类型。
类型一：针对开发中、已开发工作的长期改变
情境 A：接案公司遇到的白目客户
在接案团队中，有时候 PM 曾经跟客户的窗口前前后后屡次确认过需要与布局了，等到开发实现，才在最初验收关卡被退回说「欸起初咱们老板看了说心愿能够改 OOXX」「我很喜爱、然而老板感觉 OOXX」「我最初想再动一个小中央」那你们是不会之前就确认吗？！你不喜爱你要先讲啊！！！我当下除了傻眼外，也感觉很对不起本人的团队做了白工 🙄
我置信这个情境也不是只有网络或软件产业会碰到，这种状况能够透过在合约外面明确定义验收次数、验收工夫、能够修改的次数等等，只有自家公司老板是挺你的，就有机会能够防止。
情境 B：产品做到一半老板说「这个设计我不太喜爱，咱们改一个版本好不好？」
如果是自有产品的团队，也有可能会遇到产品经理布局好、进开发后，自家老板 / 主管某天测试或去看 spec、mockup 的时候说「这个怎么用这个办法解决啊？这个设计我不太喜爱欸咱们改一个版本好不好？」好，你说什么都好。
我还比拟资浅的时候，对本人的产品布局与设计能力不太有把握，也不相熟老板 / 主管喜爱的设计格调，因而解决办法就是在后期钻研与布局阶段就频繁的跟老板 / 主管探讨、沟通、确认，做好单方的期待治理。
等到比拟有教训了，对本人产品布局与设计能力比拟有信念、且跟老板 / 主管彼此间也有信任感之后，只管不会所有大大小小的布局都继续跟他们探讨，但还是会定期报告手上的工作，也因而这类型的陨石也就比拟少呈现了。
类型二：忽然提出紧急的新需要、插件
情境 C：在业务单位眼中，大型客户的需要总是重要且紧急
如果是 B2B 公司，业务、AM 常常就会带着客户的意见回来询问；B2C 公司中，则是客服会每天回报使用者遇到的问题，这都是久远来看对团队十分有价值的数据。
但怕的是所谓的重要客户（KeyAccounts）强硬的要求咱们在某个时限内做什么性能，否则他就要来到咱们换去应用竞争品牌；或者是新客户还没签下来，就说「你们如果有 X 性能我才要签约」，因而业务为了拿到这笔订单，就会急急忙忙地跑来找 PM 询问最近可不可以插入这个新的需要。
这种需要有一个麻烦的中央是，客户通常对于需要 / 性能的设想曾经十分明确，所以不像平时产品团队在工作时能够有屡次迭代、从 beta 版本开始测试与实作的机会。客户如果够大声（钱给得够多），就要小心业务单位照单全收。
情境 D：来自老板的陨石需要
我认为所有陨石之中最难解决的就是从「老板」来的需要，一来是因为我领他薪水、靠他升迁，要回绝他的需要的时候经常拿不出应有的骨气；二来是后面的那些陨石的出发点都有凭有据，业务的需要从客户来、营销的需要从社群来，但老板不像其余团队成员一样有明确的职务内容，因而老板的需要到底从哪来？兴许是他的鬼脑袋、兴许是投资人的一句话、兴许是看到竞品声势浩大防御。这样的未知才是最让人恐怖的。
常见的情况是老板忽然跑来问说可不可以钻研一下什么产品、什么性能、什么需要，或是忽然说「欸我感觉咱们当初应该来做这个，当初 OOXX 是趋势阿！」因而想要调动资源，或是公司方向要来个大改变，也是很让人头痛。这部分的起因跟解决办法比较复杂一些，容我用多点篇幅来分享我的想法～
为什么会有陨石呈现？
后面有提到我待的团队都是较小型的公司，公司 /BU 人数介于 10–100 人，因而我所提到的老板就是公司的老板，CEO 或是创办人自己，产业疾速变动中、业内竞争的产品也十分多，请大家在这个前提下来了解我遇到的问题！至于大公司会遇到的陨石可能就会不太一样，就请不要一律带入。
在跟一些也是在老板身边工作的人聊过之后，咱们大略能够将遇到的状况与背地的起因分成以下几种。
危险承受度的不同
身为一个员工，我喜爱货色当时布局的妥妥的，货色一次改一点点，把高风险的货色拆开、扩散，升高每次上线的危险。兴许最初咱们还是大改，但这样的过程在我心里是比拟虚浮跟难受的，而这样频繁把改变丢到市场测试与滚动式调整，就是做产品中用户核心的麻利方法论。
我通常感觉一次大改危险很高、忽然天外飞来一笔说要做什么都很可怕，因为如果方向错了、如果出大包了、如果做白工了，都会让团队很苦楚。阿我就怕被骂嘛！
麻利方法论、设计思考这种货色，就是让没教训、比拟不聪慧的咱们，有个系统化的办法能够疾速学习跟做出象样的货色，而不必在一开始就接受高风险— — 本人太雷、太嫩的危险。
然而对老板来说，他守业就曾经承当了超大的危险，这个产品改变对他来说可能是泛滥决策的一个小局部而已，扛责任就是他的日常生活，他也不怕被员工厌恶（但我怕），只在乎事件是不是有朝他认为对的方向后退。
讲好听点，甚至有些危险承受度高（有钱没中央花）的老板，他真的不在意产品做怎么，他在意的是「我有没有赌对」、「我的商业眼光是不是很准」，所以他违心十赌九输，有其中一次赌对就能够拿去跟敌人说，「我的商业眼光很准！你看咱们做了很棒的产品 / 性能功效很好。」他观赏的是他本人，而不是观赏这个市场、他的团队、和咱们服务的使用者。
教训与眼界造成的信息落差
有些状况并不齐全是因为老板危险承受度高、我跟共事承受度低，而是因为咱们各自评估进去的危险不同。
对跑第一线的业务、或是有屡次守业教训与商业头脑的老板来说，他看到某些新机会的当下，脑袋中曾经有许多信息与判断在高速运转，只是还来不及白纸黑字写下来，或是跟对这个商业畛域或产业还不熟的我解释的时候我还无奈彻底了解。
也因而他们眼中看到的危险是小的，他们感觉做这个货色相对是稳的、是正当的，当初不做更待何时？所以这时我眼中的陨石才会下来。陨石来的时候我感觉天啊危险好高天要塌了怎么忽然要做这个什么意思啊，但他们眼中看到的兴许是一颗难得一见的流星。
这某种层面来看也能够说是信息不对称、信息落差，但总归来说，不管是谁提的意见，都应该要有明确的商业数据跟用户钻研的左证才行，能力站稳利基点来相互压服。
身为守业老板的焦虑
老板就是 CEO 或是创办人自己，产业疾速变动、业内竞争的产品多，可能老板明天去跟投资人聊，投资人说做 A 市场很有机会；今天去加入一个老板们的团聚，另个产业的老板说咱们能够来试试单干 B 商业模式；先天上网乱逛竞争品牌网站发现他们将来策略会主打 C 类型的用户 / 性能，心里想着咱们可不能在这时候落后！
就是这样，我每天都不晓得老板的工作到底是什么，他到底哪来那么多灵感，明天问 A 今天问 B，可是咱们当初在做 XYZ，谁有空忽然做那么多事件？
针对老板型陨石的解决办法
1. 确认需要背地的指标与起因，以及老板的期待
第一就是确认老板为什么想做这个？背地的想法是什么？音讯与数据起源为何？为何他坚信做这件事件能达成那个指标？
就像后面提到的，老板领有的信息通常比咱们多很多，思维可能也很跳跃，当他提出需要的时候，先帮忙他说出个别人在提需要时也应该要提供 PM 的脉络与逻辑推论流程，至多让咱们是在差不多的信息程度上再开始进行探讨。虽・然・真・的・很・难！
2. 从新探讨与排序优先级
第二就是跟解决其余部门的长期需要的解决形式一样，跟老板好好探讨优先级，大家判断后真的感觉插件 A 是最重要的话那咱们就看看是不是先做 A 而后把其余本来的优先事项先搁置暂缓，从新排序正在进行中我的项目的优先级。
3. 成立陨石专门机构
另一个作法就是安顿一个专门做「机会钻研」或是解决「新商业模式」的团队，他们没有固定的 roadmap 而是专门在找新的机会点，毕竟所谓陨石就是意料之外忽然须要解决的议题，如果有个团队的使命就是解决这些事件，大家的工作都会顺利一些。
迎接陨石撞击的正确姿态
如果曾经确定本人的团队要迎击陨石、避不开了，代表有新的需要、时程变动、可能须要借助内部资源，要有被厌恶的心理准备。
为什么大家厌恶陨石？长期改货色就代表之前都在做白工，新的需要就代表可能要加班，同时无奈做本人真的感觉有价值的事件，后面花好多工夫探讨的货色有说跟没说一样，很浪费时间。
在这种状况下，我认为有几点要把握：
A. 尽量不加班，如果必须要加班也要帮忙团队拿到绝对应的回报（加班费、补休、被老板在会议上鼎力褒扬）
B. 确保当初的新版本不再是在做白工，这次真的是最初一次改了！
C. 让团队（包含我自己）在这次陨石完结后能够持续做本人感觉有价值的事件一段时间（毕竟也很难保下次不会再有陨石）
待在充斥陨石的团队真的很苦楚吗
其实我以前感觉还好。当本人没什么想法的时候，老板很有想法就是个长处，我只有懊恼怎么样执行最有效率就好；另一方面是如果老板够强，陨石砸到的中央都正中红心，产品是能够跑很快的。
如果本来就没有一套明确的产品布局、产品路线图，那也基本不会有所谓的陨石，毕竟没指标的时候往哪边走都算是后退，这是一个绝对的概念。
我过来待的其中一个团队常有陨石需要，但团队氛围与产能还是很不错，因为大家就是置信老板英明，而且他也确实屡次判断正确，让产品有所成长。过后的工程师设计师感觉只有需要明确、PM 跟老板会帮忙背责任、不必加班，那实际上开发什么内容也都很好讲话。所以真的就是看本人和团队喜爱的工作形式跟对从天而降变动的承受度。
但有个重要依据是，老板是不是有个明确指标，而那个指标跟你相不雷同？
举例来说，指标是发大财，大家都很明确朝着这方向后退。明天忽然有一个新的大案子进来能够发大财，那大家放这个插件进来就是有共识的；最怕的就是指标是「老板集体的自我实现」，也就是说他只是想要享受指挥大家、看大家为他辛苦为他忙的心态。
而如果你很厌恶陨石，又刚好在一个充斥陨石的团队，那我会倡议你尽快转换团队。从 PM 自身的角度来看，比起精准执行老板 / 团队的想法，无论成绩好或坏，有些人可能会更想试试看本人的办法、去验证本人心里的产品判断跟商业决策，爽感会更高一些，也能力继续学习跟施展长才。
此外，有些团队会打着「麻利」的大旗行「陨石」之实，这两者所具备的「弹性」是很不同的。麻利开发的弹性在于有个明确的指标与路线布局，工作办法与执行内容都围绕在指标之上，同时疾速去测试不同的解法，每个小阶段的完结都能调整产品开发方向、资源投入水平等等；陨石开发的弹性则在于，只有我说要做、要改，当初就要马上生出人力来帮忙解决。
不过团队就算跑真・麻利也不代表这辈子就不会有陨石呈现。
兴许你看完这篇会感觉这离真正陨石到不行的团队还差得多了，那可能是因为我待在太过陨石的团队不久后就到职了。如果真的无奈承受那样的工作环境的话，倡议还是快逃啊～～～
原文链接：https://medium.com/
作者：Anne Hsiao
不晓得你是否在文中找到了共鸣？后续咱们还会分享更多你须要的内容，比方……挡需要的5个小步骤&回绝客户需要的沟通模板这类干货……
感兴趣的小伙伴能够关注 LigaAI，浏览官网 LigaAI- 新一代智能研发治理平台~**
