自己在工作中，時常同時扮演著技術PM與Solution Lead的角色，主要是拿到部門老闆們（自己老闆與工程師各自老闆）的授權，與需求單位討論需求，與公司內外stakeholder協作，在數週或是數月的開發期間，帶著團隊持續把東西交付出來。
我覺得MTa L2 非常適合像我這種職能的人來參加，讓自己有機會拉高視角，重新檢視團隊的運作方式
團隊＆任務
日常工作中，會由需求單位發起需求，接著分派資源，把東西做出來，一切看起來都是這樣的熟悉。
但真的如表象這樣單純嗎？在Mta闖關活動，讓我有機會重新思考在這樣看似理所當然的運作方式背後，還有哪些細節需要考慮
任務開始之前
1. 先消化需求，釐清各種限制
2. 想好實做方向，決定大致分工方式，該有哪些角色進來，確認團隊成員的能力要求
1.消化需求＆釐清限制
本次的任務為何？因為什麼原因要做，是要解決什麼問題？達成什麼目標？
是滿足公司重點策略？是小規模的驗證功能？是讓團隊內有更多練兵機會？
限制是專案不能花太多錢？是無論如何都要在時限內把所有功能做完，並在兩個禮拜後的記者會當天同時上線？還是團隊內老手都卡在其他更重要的案子了，剩下能調動的都是新手？還是以上皆是？
2.團隊分工與角色
依據釐清的任務與限制，預先想好可能的分配方式：
譬如說MTa最後一關，前兩個任務相對單純，可以採用一個人來聽需求，然後帶回去分工做出來的模式就好。
但最後一個大魔王任務，要在時間內把又大又複雜的成品做出來，只靠一個人接需求是不夠的，光是翻譯需求就要花費好多時間，這種任務就需要有更多事前的規劃，包含事先想好分工，實做順序，如何檢查，最後才有可能做的出來。
任務開始之後
1. 實際拿到資源後，了解團隊成員的背景屬性，以及在專案任務中能夠發揮的價值，並適時做出調整
2. 團隊內實際的運作與調整
1.了解成員
如果能夠在任務開始之前，就能知道團隊所有成員是誰，會有助於前期分工規劃，但工作上常只能想辦法先抓住幾個關鍵角色人選，其餘成員多半是由各team老闆指派，也不見得每次都會派有合作過的人出來。
最一開始，也許大家對手邊的任務還不是這麼熟習，那該如何了解團隊成員屬性？
在團隊初期運作一陣子之後，可以逐漸了解成員的能力與特質，以及能怎麼用
譬如說，有的人很會辨識核心問題，有的人吸收消化資訊特別快，有的人可以看分工，有的人可以盯細節，有的人什麼都可以做。
然後依據實際狀況，盡量把適合的人擺在對的地方，並視情況調整任務分派與驗收的方式。
2.團隊內實際運作與調整
每個人個性與歷練都不一樣，想法自然也不一樣，但一個團隊就是由這些人組成，要如何才能把團隊跑得更好，能更順暢的把東西產出交付？
在我們MTa這組，透過組員們自發在每次任務後的反省檢討，共同擬定下一次該如何改善，在這樣的過程下，我們的運作越來越流暢，相較於上午剛組隊彼此還有些生疏，但隨著一次次檢討，我們在往後的任務產出越來越好。
舉例來說，在MTa闖關過程，我們就討論過以下議題，並且逐一改善：
a. 在團隊內會有許多不同聲音，但哪些是優先的，哪些是可以暫緩的？
b. 資訊傳遞是丟出去之前是不是要先喊聲，還是與溝通對象早已非常有默契，對方拿到就自動會往下做了？
c. 時間分配要怎麼運用？分工體系是什麼？誰負責實做？誰可以幫忙檢查？
後記
一同闖關，闖很多關，藉由每次的回顧會議，讓團隊運作得更好。在每次賦予的任務中，難度及限制都不太一樣，藉此考驗小組的協作能力，以及能否因應不同類型的任務彈性做出調整。
這是上過兩次MTa的我，感受到明顯相同的課程進行方式，在這樣的遊戲過程中，學員可以藉此回顧自己在工作上與別人協作的方式，找出是否還有可以改進的地方。
我覺得MTa 非常好的一點，是不會以方法論掛帥、強制大家必須在某個方法框框裡運作，而是以開放的方式，給你任務，給你回饋量表，裡面列出了各種指標因素，幫助自己更有機會從每次的任務與回顧中間悟出團隊本質上的問題。
以下是我個人領悟的L1與L2課程差異，也給大家做個參考
MTa L1 幫助我們更多以個人的視角，重新檢視自己在不同團隊任務上所展現出的模樣
MTa L2 幫助我們更多以團隊的視角，重新檢視團隊本身的各種運作方式