我就像是鬼遮眼一樣，竟然會認為隕石不隕石，說個笑話，我還突發奇想的說，這次開發是「流星」開發，超級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自己修，我相信負責的工程師都會願意修正問題，而我們要理解的是，工程團隊在一些問題修正上是需要時間解決的，保留一些緩衝是對於工程團隊開發上的特性(不可能零出錯)的尊重，也是我們在風險管理上面需要掌握的議題。以共同合作成事的思維看待，就會知道隕石砸向的不單是工程團隊，也是砸向自己的腳。讓我們和工程團隊好好合作吧！