這件事站在我的角色，其實往往有兩種不同的角度該思考。
1. Coaching, 透過提問與引導，讓大家發現目前可能有什麼問題，讓大家決定可以怎麼解決。
目的是為了讓所有人參與、思考、找解決方案，這是團隊養成重要的一步。
2. 偶爾會發生的情況，是「團隊最後的共識，是會潛藏付出極大代價的。」
在我上次的客戶那邊，case 是 error handling，團隊討論決定完了作法，大家都達成了共識。但我聽到作法時感到十分詫異，這樣作法在實務運營上的成本風險太巨大了。
也就是當出現 P0/P1 issue 時，會害死那個 support 的人，他會很難追問題的根源在哪。
#我對ErrorHandling處理很龜毛的
公司跟服務可扛不了這樣的浪費跟損失。
我立馬暫停了眼前的 coaching, 請人召集了該 team (其實是 2 個 feature team) 所有人，告訴大家針對這件事我想多了解一點。
過程大概是：
- 能不能請你們告訴我，針對該問題你們決定怎麼做了呢？
- 為什麼我們需要怎麼做？在這樣做之前的問題跟造成的影響是什麼？
- 這樣做需要改那些東西？這樣做之後的影響跟好處是什麼？
- 如果發生了某個情況（岔出來問，這種你們歸類在P幾的issue, 讓他們知道重要性), 在這樣的方案下該怎麼處理 issue? 這樣的情況發生的可能性有多高？
- 所以，原本的作法可能會有什麼問題是我們之前沒留意到的？
- 那我們還可以怎麼做？
這其實是 technical coach 重要的工作，不只是把人跟團隊帶起來（讓他們能自己自走砲），我還需要站在客戶公司產品服務的角度考量，常見的就是運營、架構、技術引入、重要基礎建設服務這類重要的骨幹。
——
不該是所有東西都讓團隊自己決定，讓他們自己跌倒再自己爬起來就好。
至少 external technical coach 不該這麼幹，因為我不是一直跟在這團隊身邊。而即使是 fulltime 的 Scrum Master, 該怎麼拿捏到讓大家都參與了，每個人意見都很重要，還要找出方案的盲點，幫助大家進一步成長跟思考，也是很重要的。
#因為我們不只是引導者，#我們同時也是團隊的一員，#我們都得為產品跟使用者負責
以上建議也給一些朋友參考，千萬不要只戴著一頂引導者的帽子角色，讓團隊自我探索跟組織既是第一步也是我們的目標，但實務上不能只有這樣，而且每次都只戴這帽子，長久以往之後，自己容易變成一個不用擔負運營跟責任，只出張嘴的局外人。
#光講都可以很瀟灑啦
#中立不一定得變成局外人
#你也是團隊一份子也要為決定負責
Coaching & Training 並重，在團隊學習跟自我成長，與公司運營產品服務價值之間，最大化價值。
#工程師往往打從心裡賭爛那個只出張嘴的雞
#漸行漸遠後的SM可能還洋洋得意團隊已經不需要我了
