不足的豐富資源

未依團隊性質配置的資源，會製造資源不足的假象

在IT團隊最大的時候，有11人，分別是前端工程師3名、全端工程師2名、前端實習生1名、後端實習生1名、UIUX設計師1名、AI工程師2名和我，暫且先將職務內比較迥異的UIUX、AI工程師和我先忽略，7位工程師這樣的職務配置方式，先不提Scrum，在BAU的任務安排上，就已經造成很大的限制：配置任務有絕對的分水嶺，必須依據前/後端來進行安排，在我們的IT業務中，BAU中，屬於前端的問題和屬於後端處理的問題比例並不對等，發生時間點也不一樣，造成閒置人力的可能性增加。那時候，對於職務配置並不敏銳的我，沿用著資深工程師的想像，配置了一組團隊各功能員額，分出前後端、還要SDET，這樣的配置並不適合需要高度協作、補位的新創團隊，而造成「IT團隊人力資源永遠不夠，而對整體事業體來說，IT已經是大單位」的現象。再者，從管理的角度來說，人力運轉率應該是要一直被觀察的指標，在安排實習生執行BAU上，雖然有劃分前端與後端實習生，但前端實習生所取得的任務中，也涵蓋後端實習生的部分任務，顯示在職務配置的設計上有根本的問題，這樣的訊號也被我忽略了。因此，光是從BAU的視角來看，我犯了兩個錯誤：1. 以大公司的團隊設計思維，套用在新創團隊；2. 忽略管理指標的訊息，沒有查找出根本原因。現在這樣說有點馬後砲，但是這是我們自己團隊會說的，防線一路失守，該做好的環節沒做好，到後面可以拯救的環節，也跟著也被放棄，保持高度警覺和不要太容易放過自己，希望不要都是用失敗經驗讓自己深刻。

減少換位補位障礙

人人都可以做，資源彈性最大化，才能敏捷

為了將Scrum運作順利，公司曾安排讓我們徵詢具有豐富導入Scrum經驗的講師，Scrum是種文化、一種心態的體現，這位講師舉手頭足之間，都透露著Scrum已內化成他工作方式的一部分，當時的我，只能聞其形，但不明其意。在和他初步說明一下人員配置之後，他點了一下我，Scrum中的團隊補位的精神，「在Scrum裏每個人都有其擅長的事情，但是裡面的任務，是每一個人都能做的」。基於此，所以在人員配置上，已經很不符合Scrum的精神了，對於執意繼續進行Scrum的我，講師可能心裡覺得很無言。在我們這樣的人員配置之下，Scrum的進行出現了2個障礙：

• 前後端無法相互支援
  前後端之間，存在必然的先後關係，這個先後可能是職務上設計的後端為先或前端為先的決定，也有可能是某端能力不足造成的先後，在Scrum運行時，如果發生問題，因為人力資源的彈性受限，最後只能兩手一攤，落後的人覺得壓力大，趕不出來，接棒的人也受影響，想到我竟然讓這樣的事發生，我真的是覺得害怕。
• 習慣性以功能分工
  因為用前後端分，所以整體團隊思維也變成是如此，當有新的需求的時候，例如：QC，大家的第一個反應都是要直接切割一個個體去專門處理這件事，就像BAU一樣，QC的性質又不同，不是同時可以排程的項目，又會在Scrum內拉出一條先後順序的產線，越變越像瀑布式開發。

Reflection

我可以體會講師並沒有全力阻止我們硬要用這樣方式運行Scrum，因為Scrum是一種文化，要如何被落地實現，依據不同團隊，就會有不同的可能，然而，這一路新創走來，我知道所要面臨的變動性與挑戰實在是太多了，所以盡可能減少障礙，會是第一要務，不要硬要為自己「製造挑戰」，所以，若要再來一次，我會選擇都配置一種類型的職務，讓彼此可以相互支援。