[討論] 我怎麼在一個 Startup 中擔任 Tech Lead
網誌好讀版: http://blog.norman-chen.me/post/26
這篇是個人在一個startup這幾個月來，擔任 Tech lead 的一些心得
分享給各位，希望版上各位大德能給我一些意見，或是討論(鞭打?)自己的 Tech lead
===========================分隔線=============================
我在一個 Startup 裡擔任某一 Project Team 的 Tech Lead，
以下是我這幾個月以來的心得
>> WARNING: 以下是個人心得，或許不適合於你/妳的環境
#主要的職責是
關於 Tech Lead，我想這篇解釋的很清楚，主要的職責就是以下三項：
1. 技術決策者
2. 流程監督者
3. 干擾過濾器
#技術決策
無疑問的，技術決策者一定是技術背景，但做決定時不能單考慮技術角度
必須是以產品的角度來看， 用什麼樣的技術會對產品的發展最好，負債最少。
影響決策的最大因素通常會是時間，但我會建議你別因為時間而忽略了品質，
在經驗上，一旦你忽略品質，之後你必須用更多時間補破網，就長期來看不是明智之舉
>> Mitsubishi怎麼改都不會變成BMW
因此綜觀來說
產品 > 技術決策
品質 > 時間
有次在某一個開發週期，我們為了趕上某個 milestone，多塞了一些Task給某個RD，
Planning 時看起來只超出原本的開發時間幾個小時，看起來還好，至少當時是這樣想的。
結果因為某個Task需要比原本多的開發時間，把Buffer都吃掉了，
結果該名RD只好在星期六加班，但是QA的狀況依然不佳，
所以我們把整個時程往後延了一天，但還是有一個bug不能解決，
於是只好先延後這個Feature的開發。
事後PO問我為何事後多給了一天進行開發，狀況卻仍然沒有改善，
我的回答是：因為時間的壓縮，RD沒辦法做最好的規劃，
所以既使事後多用了一些時間，也不足挽救原本不良的設計
>> 一旦發生火災，再精良的設備都是亡羊補牢
#關於流程
用任一種敏捷式的流程，無論你的團隊採用那種理論 (Scrum, Kanban or...)，
然後依照實際需求調整，流程的設計需根據5W1H
以下有三項最高原則可以遵循：
1. 有SOP就照樣執行
2. 沒有SOP盡早建立
3. 有問題的SOP討論修改
Tech Lead 應時時緊盯流程，確定每個人都按照流程的原則工作，一旦有出軌的情況，
越早拉回來越好，以防造成更嚴重的災情。
不過有時我會故意放點小火，這樣大家就知道原則是需要被嚴格執行的，
沒有足夠強烈的理由，就不應調整流程。
#持續集成、定期發佈
包括 TDD 及 CI 之類的，以下我打算只專注在為什麼要這麼做，
我假設每個開發人員都知道這些是在幹嘛的。
你應該要經常並自動化的測試你的程式，
這不只是為了當次的開發，也是為了之後的重構，
如果你能夠早點發現錯誤，那為什麼不做呢？
或者這樣問，你打算什麼時候做呢？QA的時候，或是Release的時候嗎？
這些工具都是為了及早發現程式的邏輯錯誤而產生的，
星星之火，足以燎原，問題越快處理越好。
定期發佈也是一樣的道理，沒有任何一個方法或工具能夠找出所有的問題，
因此應嚴格管控版本發佈的時間，萬一在這次發佈產生問題的話，
抓蟲的範圍可以比較好定義及回溯，不管你用的是什麼樣的版控工具，都應該這樣做。
#搬開石頭
這裡的石頭指的是在開發過程中，任何可能會造成障礙的東西。
身為 Tech Lead 應該主動，確保你的成員能完全專注在他應該做的項目上，
舉凡spec不清、經常性的被interrupt、頻繁的 context switch 等…
>> 為什麼搬開石頭很重要，因為軟體開發跟睡覺一樣，是有階段性的
>> 你沒辦法每次一躺下就進入熟睡狀態。
題外話，我一直覺得純粹用時間管理軟體人員是很愚蠢的事，
因為我們每天的狀況不一樣，有時我們工作了八小時，真正專注的時間不到二小時；
有時狀況很好，可以專心做很多事，但不會一直都狀況很好。
#溝通、和更多的溝通
一個團隊，特別是 Project Team 是包含各種不同功能的成員，
身為 Tech lead 應該盡量耐心擔下溝通的工作。
呼應上一段，這也可以避免你的技術人員經常被無意義的打斷。
雖然溝通很重要，但不代表你的工作也是可以被隨意打斷的，
應該盡早使整個團隊建立溝通管理的原則，
以同樣的準則分辨這個問題的重要性及緊急性。
#Load Balance
Tech Lead 非常忙碌，同時要兼顧開發及管理，以我淺薄的經驗看來，
Tech Lead 必須及早建立起團隊文化，文件化執行細項及原則，
讓每個團隊成員按照團隊準則行事。
#關於外包
很不幸的我們團隊中有外包人員 (且非 on-site)，
所以在溝通上，耗費了很大的成本，我在外包的 Lesson Learned 包括：
1. 一定要配合團隊的流程
2. 最好是 on-site，如果不行的話，退而求其次，至少在 QA時要 on-site
3. 及早建立好溝通管理及路徑
4. 清楚的文件
以下是個人的偏見，除非你真的沒辦法，不然不要找外包，因為：
1. 外包通常專注在 Delivery，而非品質
2. 外包 (尤其是公司) 通常同時接了一個以上的案子，
也是之所以外包只能專注在 Delivery
3. 外包的開發經驗不能累積
4. 好的外包像特效藥，但藥效一過經常會有反彈；
壞的外包像包著糖衣的瀉藥，吃下去就是要落塞的
#透明化
PM要讓RD知道整個計畫的 roadmap；
RD應該盡可能讓PM以白話的方式知道目前的工作狀況，
RD之間應每天用5~10分鐘review目前的狀況，
透明化是避免驚喜最好的方式，沒有之一。
#結論
最好的 Tech Lead 就是沒有 Tech Lead，盡可能的讓自己容易被取代。
--
◆ 你不夠資深喔！ <囧>
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.245.65.133
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1422708970.A.53A.html
→
01/31 20:59, , 1F
01/31 20:59, 1F
→
01/31 20:59, , 2F
01/31 20:59, 2F
→
01/31 21:00, , 3F
01/31 21:00, 3F
→
01/31 21:08, , 4F
01/31 21:08, 4F
我解釋一下，我所在的 project team 是從 0 打造產品的，所以一開始的確是以 mvp
的概念快速打造 prototype，但當商業模式確認了之後，
我們大概花 2 ~ 3 個星期，重新設計了架構，這時才正式引進 tdd
推
01/31 21:08, , 5F
01/31 21:08, 5F
→
01/31 21:16, , 6F
01/31 21:16, 6F
推
01/31 21:38, , 7F
01/31 21:38, 7F
推
01/31 21:40, , 8F
01/31 21:40, 8F
※ 編輯: Ageis (123.194.110.8), 01/31/2015 21:49:09
推
01/31 21:52, , 9F
01/31 21:52, 9F
→
01/31 21:58, , 10F
01/31 21:58, 10F
推
01/31 22:00, , 11F
01/31 22:00, 11F
推
01/31 22:01, , 12F
01/31 22:01, 12F
※ 編輯: Ageis (123.194.110.8), 01/31/2015 22:35:30
→
01/31 22:49, , 13F
01/31 22:49, 13F
→
01/31 23:02, , 14F
01/31 23:02, 14F
方便給我進一步的建議嗎？
※ 編輯: Ageis (123.194.110.8), 01/31/2015 23:05:00
→
01/31 23:27, , 15F
01/31 23:27, 15F
→
01/31 23:28, , 16F
01/31 23:28, 16F
→
02/01 07:17, , 17F
02/01 07:17, 17F
推
02/01 07:27, , 18F
02/01 07:27, 18F
推
02/01 10:31, , 19F
02/01 10:31, 19F
→
02/01 10:32, , 20F
02/01 10:32, 20F
推
02/01 12:55, , 21F
02/01 12:55, 21F
→
02/01 13:52, , 22F
02/01 13:52, 22F
推
02/01 21:47, , 23F
02/01 21:47, 23F
其實我覺得這意見滿有趣的
我想問另一個問題，怎樣的 tech lead 會讓各位覺得對 career 有幫助呢？
※ 編輯: Ageis (123.194.110.8), 02/02/2015 00:44:20
→
02/02 12:29, , 24F
02/02 12:29, 24F
→
02/02 12:29, , 25F
02/02 12:29, 25F
→
02/02 12:30, , 26F
02/02 12:30, 26F
→
02/02 12:30, , 27F
02/02 12:30, 27F
我在下一篇回文有提到，這裡指的"純粹"指的是覺得每小時產出的code數量
應該一致/穩定的產線式管理
實際上我們知道這不可能做到
能盡量穩定的方法，是保持一定的時間節奏，問題是這節奏每個人不太一樣
所以 tech lead 應盡量幫助成員排除意外的干擾
但也不是事情交待下去就顧收成就好
每天應該利用 5 ~ 10 分鐘口頭溝通一下這天的進度，tech lead 視問題處理
這個其實也是一種干擾，但因為是固定的，所以對 rd 而言的影響相對不大
關於外包，一般開發遠端還好，這個開發週期該做什麼功能
早在 spec 中清楚說明，有事用 skype 聯繫，每天也會去了解當天的進度，影響不大
可是例行的 qa 就不是這麼回事了，通常我們是 qa 後接著 release
而 qa 無法事先不知道有什麼問題，萬一有 bug 不能被馬上修復的話
非常有可能會影響 release，事實上我們發生過幾次這樣的情況
被迫要再做時程的調整，所以才會提到，希望 qa 時要 on site
※ 編輯: Ageis (61.62.212.217), 02/02/2015 14:18:36
→
02/02 23:55, , 28F
02/02 23:55, 28F
推
02/04 19:43, , 29F
02/04 19:43, 29F
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 3 篇)：