我就像是鬼遮眼一样，竟然会认为陨石不陨石，说个笑话，我还突发奇想的说，这次开发是「流星」开发，超级ridiculous，我都忘记怎麽阐述这件事给工程团队知道，又快速？又有价值？更别提，後面还有登月计划、登火星、比喻团队是太空团队的，一系列花拳绣腿，不论身为一个主管，或身为一个产品经理，真的是难以启齿的过往。承认就是陨石吧！我会对自己这样说，即便再怎样的仿照Scrum的元素，走了sprint planning, standup meeting，形式模仿再多，请承认就是陨石吧！不承认是陨石，然後要求工程团队要下commitment，工程团队迟早会被压垮。

陨石1: 这个很重要

第一类陨石：「现在这个很重要！」身为一个打带跑的团队，我们一定同时有开发也有BAU要进行，在业界里面，其实不少见，在某个程度上，当然是一个多工的工作能力。所以这一类的陨石，之所以会是陨石，是因为没有考量「trade-off」，只要一句很重要，就会取代掉sprint正在进行的事，或是必须并行前进两边都要达成。不能trade-off，就是因为不知道sprint价值，所以无法判断。

陨石2：我想要另一个结果

第二类陨石：「这个不是我想要的！」在定义解方这件事，工程团队是最後才收到结论，仅能依据这个结论选择要套用的技术，如果解方是经过强大的使用者需求收敛与验证结果之後，当然不会是太大问题，会变成陨石，就是花了太少时间厘清问题，所以当工程团队将功能完成後，还没进入UAT，就要改变原本的规格了。我们那时候知道很不该，也在会议里面说要引以为戒，但是问题从来没有被解决过。花了太少时间想清楚，即便花了时间，也没有认真将问题解构成足以sprint表现的小规模价值。

陨石3：Bug赶快解

第三类陨石：「这个Bug就是现在解！」认定Bug绝对是工程团队成员要负责的事，并且必须肩负起修正，且不能影响原本开发。我认为，Bug是工程团队产出要负责修正的，就如同非工程工作一样，我们要对产出的结果负责。会变成陨石，主要有两种原因：原始范畴(Scope)、trade-off，在单位时间内，能做的事情是有限的，所以当Scope和单位时间技术套用程度，没有妥善被连结的时候，Scope会被自由扩想，期待没有被控管好，所以Bug真的是bug吗？另外，就是trade-off，当bug需要时间来修正的时候，孰轻孰重、孰先孰後不清楚的情况下，并没办法让成员能安心提出好的方案。

Lesson Learn

花时间厘清问题与价值、架构小故事出来，并以问题与价值做为桥梁，使用者与工程团队的双向沟通，是最核心的一件事，沟通是双方都须向前踏向一步的，使用者要尊重并了解工程团队的开发需求与方式，工程团队要在意使用者的痛点是否被解决，并尽可能提供多元解方。问题被好好厘清、解方被审慎考虑pros and cons後，我们的角色就是要随时确定优先顺序，让每一次的变化，都是具备合理且客观的评估，并且是整个部门团队共同理解每个决定带来的效应。最後，自己产生的Bug自己修，我相信负责的工程师都会愿意修正问题，而我们要理解的是，工程团队在一些问题修正上是需要时间解决的，保留一些缓冲是对於工程团队开发上的特性(不可能零出错)的尊重，也是我们在风险管理上面需要掌握的议题。以共同合作成事的思维看待，就会知道陨石砸向的不单是工程团队，也是砸向自己的脚。让我们和工程团队好好合作吧！