為什麼要有管理的存在？是人就有不完美的地方，要讓一群不完美的人交付出有用的成果，推進專案，需要管理的藝術。

在一個理想的工作環境中，管理並非必要。

例如每個人都很清楚團隊想要前進的方向，對於產出抱持著 Egoless 的心態，只想一心一意把東西做好，團隊成員品味相近，在討論各個細節時可以放心交給彼此，沒有上下關係與階級。

要達到這個條件有諸多難處：

• 每個人工作的動機不盡相同
• 要找到符合條件的人，要嘛很貴、要嘛自己開公司做、要嘛已經在其他地方了，可遇不可求
• 專案裡每個細節都無條件同意的夥伴，能找到一個就是上輩子燒好香了，何況是多個

在這種情況下，找到懂得做事與開發的 Tech Lead 有其必要性以及經濟實惠性。

在名詞的定義上我比較傾向於 Tech Lead 而非 Team Lead。

兩者對我來說意義不太相同，一個是單純在技術上跟開發上做領導，一個則是有點偏向管理職還有帶團隊了，我在前公司的角色比較偏向 1。（當然名詞的定義因人而已，這邊只是點出我的想法）

我算是一個喜歡埋頭寫程式碼的工程師，倒也不是說 spec 什麼的就不去理解，而是比起解決人之間的事情，我更喜歡直接從架構上下手。

這也是我最大的弱點且需要改善的地方之一，就算自己一個人寫很快，但不提升團隊開發速度的話其實沒有什麼太大效果。

為什麼這樣說？假設你完成功能的速度很快、品質好、Bug 也很少；但是你的團員知道這個功能在幹嘛嗎？你的團員跟得上你的腳步嗎？你的團員寫程式碼都是類似的思維嗎？

如果這些問題都是否，那麼你很有可能在開發中後期開始遇到各種不符合 spec、當初沒考慮的 Bug 噴出、被其他團員的程式碼拖慢腳步，最後全部的開發都會卡在 QA。

發現問題比解決問題更重要

在某次專案開發中，我隱約感受到有人會堅持某些細微的實作細節，雖然這本身是好事，但如果花了兩個月還做不出任何東西，導致時程延誤的時候就是大事了；另外就是對品質與整體流程的不注重，什麼問題都想靠其他團員的 Code Review 來抓錯，導致後來 QA 回報的問題越來越多，整個開發團隊忙得不可開交。

那段時間我很失望，但也反省了很多事情：

• 開發上沒有英雄主義，別妄想成員們會一夕之間改變；也別妄想自己有能力解決所有問題
• 比起程式碼品質（當然這也很重要），先把問題的根源釐清再說
• 如果想要靠換技術框架或重寫來解決問題，有可能只是你還想不夠多
• 人的問題

上述提到的問題導致開發後期修 Bug 的成本增加很多，也因為時程的關係每個人情緒都很緊張，也要投入更多時間，整體的品質就會下降很多。也因此比起解決問題，早期發現早期治療這句箴言也應該被當作信條遵守才是。

把歸因總結到人的問題前，很多時候可以先從制度改善。至於人的問題我們留待下篇討論。

建立制度

身為 Tech Lead，通常你必須是最熟悉 Codebase 與需求的人。

隨著團隊成員的熟悉度提升，會慢慢演變成每個人都有能力負責中大型的功能模組，但在初期必須要靠著自己把制度建立起來。如果只有自己擅長的話沒有用，會自己忙到死，要讓其他成員知道業務場景的重要性以及需求才行。

如果團隊存在沒有你就做不到的事，就不是一個理想的團隊

我相信這個道理，也在上一間公司體驗到類似的事（在上一間公司並非 Tech Lead），當大家幾乎都擁有同樣的價值觀、技術力、個性時，不論經驗或是職位差距，合作起來就會非常順利。不需要特別跑 Scrum，開各種會議，大家就會準時甚至提早交出成果來。

當然這種團隊可遇不可求。所以大部分的時候我會透過在 Daily Meeting 的詢問，讓他們知道該設計的地方有哪些。這是最直接影響 Sprint 產出的要素之一，也是解決問題的好方法。

理解自己的優劣勢

我非常不擅長於說教跟改變一個人，也不是容易跟人打成一片的個性，所以一旦我希望成員做到某些事情，口氣往往聽起來會過於激進，或因為自己預期的事情無法順利完成時，會將失望、沮喪的情緒表露無遺。

要意識到自己的缺點很難，因為人通常是無法改變的。尤其在職場上，除非遇到非常坦率的成員，否則可能一輩子都不會意識到。

因此懂得內省是當 Lead 很重要的一點，在時常內省的情況下可以理解自己的優劣勢。從血氣方剛的年少時期，到逐漸累積經驗的磨合期，我開始釐清自己的優劣勢在哪裡。

優勢是可以很柔軟地面對各種制度與團隊內的流程，也善於在現有的條件下做出改善方案。我覺得自己算是相當願意傾聽，且在資訊不齊全的情況下不輕易做出評斷的人。

以前我可能比起產品本身，會更重視技術夠不夠有趣、好玩，有沒有做到 Clean Code 裡面的原則；現在我會綜合各個條件判斷，有時候需要在不完美的情況下逐步摸索。

劣勢大概就是自己有時候會想很多，有時候也會過於關注細節導致沒有從全局觀看待事情。再來可能就是太過理性。