稱職的技術leader相當於100名工程師！

關鍵時刻，第一時間送達！

CSDN編者友情提示：本文約總共12739個字，完成本篇閱讀至少需要消耗半小時能量，請提前備好乾糧~~~

來自美國科技公司Webflow一名技術經理Leonard Souza 的良心製作。

【編者按】拋開這個誇張的騙點擊量的標題，我希望告訴你：稱職的技術主管確實是擁有普通工程師10倍功力的麒麟之才。不過，這位技術主管在技術之外還需要將強有力的開發能力傳授給隊伍中的每個成員。在技術主管的指導下，幸運的工程師會感覺自己擁有了10倍的能力，並可以享受前所未有的強大支持。

而且，我希望告訴你，技術主管用頭上的白髮換來的這種神奇的10倍魔力的光環，並不一定會犧牲任何人的幸福。技術主管扛下了所有工作中的「雜項」，大大加快了重要工作的生產力，從而確保團隊成員可以盡情享受工作和生活的樂趣。對於那些擁有一個稱職的技術主管的團隊成員來說，這是莫大的幸福。

在稱職的技術主管的指導下，幸運的工程師會感覺自己擁有了10倍的能力。

我是Webflow的一名技術經理。我們相信團隊之幸即用戶之幸，所以我們在團隊上付出得越多，用戶的受益就越多。我們堅持做有意義的工作。我們追求長期快樂的工作，我們將此視為長遠的目標。我們深信，工作應該與生活快樂並存，我們認為工作與生活相輔相成。

技術主管可以幫助我們實現這些信念。因此，我撰寫了一份技術主管指導手冊，用以支持這一具有挑戰性的領導角色，並在這裡一字不差地複述。我們希望即便身處一個慣於標榜傲慢與荒誕的世界裡，你也可以盡情地追求激情與成功。

下面請盡情享受我們的技術主管指南（點擊此處查看全文目錄）：https://github.com/webflow/leadership/blob/master/tech_lead.md）

▌Webflow技術主管指南

歡迎

你好！歡迎你閱讀此文。很榮幸你能閱讀此文。

如果你接受了技術主管之職，那麼首先恭喜你，這證明你擁有卓越的技術力和領導才能，實屬罕見的人才！也許，你對技術主管一職感到好奇，想弄清楚這個職位是否適合自己，那麼你來對地方了。

不瞞你說，技術主管所承擔的責任與普通工程師的日常工作相比有著驚人的跨度。這本指南可以幫助你迅速掌握如下內容：

什麼是成功的技術主管

如何從純粹的技術角色轉而兼顧管理與技術，以及如何達成這一職位的期望

應對常見挑戰的戰略

Webflow的「管理職位」所呈現的立場（提示：這裡說的是如何更好地服務團隊，而非專權）

▌那麼究竟什麼是技術主管？

技術主管最基本的定義是，「全權負責項目的成功，30%的時間寫代碼，其他70%的時間管理項目。」主管的稱號並非浪得虛名，因為你需要在波濤洶湧的職場上為你優秀的工程師團隊指明方向，指導他們，引導他們遠離危險，並為他們排除困難，讓他們充分享受有意義的工作。

說起來容易做起來難。

技術主管必須擁有和培養各種的技能，但是最重要的是待人真誠，清晰的溝通，以及卓越的技術力。這些品質缺一不可。身為技術主管，你必須一手掌握管理，一手掌握技術，充當項目預期目標與開發任務之間的聯絡人。一個項目的成敗很大程度上取決於技術主管，而Webflow公司的責任是確保他們能夠獲得成功所需的一切支持。

Webflow的管理有何不同。

在大多數公司內，管理層並不受員工的待見。在員工心目中，管理層不過是把員工當成「勞力成本」，是可以隻手遮天的專權者。但Webflow並不是這樣的。我們尊重每個團隊成員，而才華是其次的。人與人之間可以建立理解和協作的關係。技術主管需要為培養這樣的環境而負責，且技術主管只有本著為人民服務的態度才能建立這樣的環境。

技術主管的工作不僅是微觀管控，更需要為大家服務，他們需要站出來支持團隊，為團隊成員服務，而團隊成員則為技術主管工作（而不是相反的方式）。技術主管可能要對項目的成敗負責，但技術主管與團隊的協作才能成就項目。

下面是關於如何為團隊提供最佳服務的兩點提示：

直面項目需求。不要害怕挑戰你的團隊，只要你是發自真心的關心他們。

如果項目成功，要大膽地讚賞團隊，給予他們一切的榮譽，因為沒有他們就沒有成功。

▌為什麼想成為技術主管？

也許你並不想成為技術主管，這也無可厚非。Webflow旨在為工程師提供許多不同的機會來發展他們的職業生涯，包括個人貢獻獎，他們與高級管理職位一樣對公司做出了卓越的貢獻。技術主管要比普通工程師承擔更多壓力，尤其對新手技術主管來說，在管理團隊和貢獻代碼之間尋求平衡本身也是一項挑戰，這也完全正常。

即便如此，升任管理職位的好處還是很多的。首先可以有機會參與公司更高層的決策。對Webflow用戶群的影響力也會提高。在業績考核中擁有更多話語權，並在今後擁有更多職業發展的機會。這個職位經常被視為「高級」工程師頭銜的墊腳石，也是榮升工程經理的先決條件。技術主管需要指導並幫助其他工程師成長。對於有些人來說，這將帶來更加令人興奮的挑戰，並促使他們挑戰更高的極限。

▌怎樣才能成為技術主管？

只要你開口！其實很簡單。找個單獨的機會，跟你的經理表明你有興趣成為技術主管。你的經理有責任將下屬推上新的職位，根據你目前的經驗，他們可能提升你為下個項目的技術主管，或者提供機會讓你發展技術力，將你培養成技術主管。

▌管理團隊的時候，需要做些什麼？

技術主管主要負責以下幾方面的工作（沒有特定順序）：

與產品經理密切合作，在最後期限前設置合理的預期目標，並確保項目不會出意外。

將項目內容分解成可以消化的任務，將這些任務關聯到迭代周期的交付產物中，並時刻關注交付產物。

為團隊提供充沛且不間斷的工作時間，確保他們的工作狀態持續流暢，並為團隊保駕護航，不受任何阻礙與分心。

確保團隊成員在任何時候都有充足的工作，確保沒有人「無所事事」。

勤勉地審查代碼，力保一次性通過QA測試，並儘可能的貢獻代碼。

根據團隊任務的需要，隨時提供支持與幫助。（既要拿出儘可能多的時間來埋頭苦幹，還要在團隊需要的時候給予支持和幫助。）

不定期地與其他們部門合作。

與其他們部門合作

產品經理負責將用戶的期望落實到產品功能中。市場營銷部分負責宣傳這些功能。售後團隊確保Webflow的產品在承諾的功能上有出色的表現。每個部門對Webflow的持續成功和發展都至關重要。工程部門則是重中之重，而技術主管擔負著與這些部門之間的聯絡。

技術主管負責以下列兩種主要的形式將項目的狀態傳達給其他部門：

每周與其他們部分召開一次例行會議，其中產品經理或售後聯絡員[1]也可以參加。無論產品經理或客服聯絡員參加與否，這個會議都是必須的。

每周一次向全公司彙報「所有進程」。

有些項目可能沒有產品經理或售後聯絡員，在這種情況下，需要由技術主管向工程經理彙報團隊的狀況和需求。有時候，市場營銷部門也可能就何時可以開始宣傳某項功能，徵求技術主管的意見。

跟進任務的進展狀況

優秀的技術主管知道如何將項目分解成有意義且易消化的任務（易消化指的是大約3天左右可以完成的任務）。這可以讓團隊成員全面了解項目以及最後期限，也確保技術主管可以每周為團隊成員分配任務。將項目分解成小任務是一個很耗時的過程，且是一項持續性的工作，但卻對培養團隊成員的成就感十分重要。還有助於技術主管在通往未知結果的道路上創建路標，並將這些未知的結果控制在小範圍內。

ISSUE

在項目剛啟動或著手一個持續性的里程碑時，技術主管必須徹底審查項目規格，並儘力將規格分解為便於跟進的任務，每個任務為期大約1-5天（審查代碼和QA工時不包含在內），最佳時間安排為3天。然後，將這些任務劃分到里程碑中。每個裡程碑都是帶有截止日期的交付產物。

專家建議：可以讓團隊幫忙將里程碑分解成任務。如果團隊中有人比你更加了解某個專業領域的知識的時候，這是唯一的選擇。這種情況下，委派團隊成員處理這項工作更加合理，但是務必審查所有的任務，並驗證任務的範圍或做出的假設。

Webflow目前的做法是在GitHub中為每個任務創建issue，然後在issue中跟進這些問題。

這個issue在GitHub上提供了集中且清晰的問題概覽圖，其中列出了里程碑、預期的交付日期，以及相關任務。這些任務：

可以很容易地將任務分配給團隊成員，由他們負責提交解決該問題的PR。

顯示任務的GitHub問題編號，解決該問題的PR，以及問題的標題。最好以表格的形式呈現這些內容。

提供每個裡程碑的預計完成日期，以及里程碑中每個問題的狀態。

任務

每個問題（或1-5天的任務）必須明確指出問題所需要實現的規格部分，以及所涉及的Webflow代碼庫（如果有代碼的話）。我們發現每個問題最好包含以下內容：

清楚地指出問題所需要實現的原始規格，以及一些圖形化內容幫助工程師完成任務，包括來自規格或Webflow本身的截圖或視頻。

列出最有可能的待辦事項，幫助工程師構劃他們必須解決的問題。

以下是一個任務模板。你可以將其保存在GitHub的問題中，並把它的名字加入到issue中。

好難啊

創建issue會花費太多時間，讓人不免懷疑是否在做最有效的工作。請相信我們，這一步至為關鍵，issue越清晰，項目成功的可能性就越大。根據項目的規模不同，這項工作可能需要花費一周或更長的時間。沒關係。制定嚴密的計劃，並嚴格地執行。你的團隊會為此心存感激。幫助團隊建立成就感至關重要。

專家建議：在開始創建主問題之前，針對具體的規格建立一個文檔記錄下任務列表會很有幫助。當你寫出了所有任務之後，創建一個問題，寫下基本的描述並重點強調規格要求，然後進入代碼庫找到問題所涉及的代碼。

在issue中顯示進度

可以將issue看作儀錶盤，上面顯示了與項目相關的每個問題的進度狀況。這反過來也凸顯出了整個項目的狀態，以及整個交付產物。例如，下面的例子展示了一個issue的進展狀況：

產品經理（或其他相關人員）可以根據上圖，快速評估項目的進展狀況。例如，當人們看到BETA里程碑大約完成了75%，並且由於任務分解成了大約1-5天的量，因此很容易判斷項目是否可以按照計劃完成。

技術主管理應負責維護上述issue的狀態，儘管可能他們更希望讓每個團隊成員分別更新各自負責的問題的狀態。每個任務應當顯示下列重要信息：

項目及截止日期

其下所有的任務

其下所有的PR

簡短的描述

進展狀況

專家建議：如果某個主問題列表過長且不易操作，那麼可以將其分解成多個主問題。

項目（即交付產物）

技術主管必須向產品經理（如果沒有產品經理的話，就向工程經理）彙報各個項目的進展狀況，以及每周提交完整的報告。項目和各自的任務由技術主管決定，並經過了產品經理、工程經理及其他人的確認。

所謂「項目」是：

一個主要的交付產物，通常擁有六周的時間跨度。

負責推動一系列的任務和問題，且當所有任務和問題在正式產品環境中落實完成時，里程碑完成。

根據交付產物類型命名，例如根據階段、上線次數或版本等命名。

指定了截止日期。

大型項目的計劃結構應該只包含兩層：項目>任務。項目本身應屬於某個功能的範圍，例如富文本編輯器、交互2.0等，這些功能可能需要數月（或數年）才能完成。里程碑是可以持續交付工作的「塊」，通常按照一定順序完成。除非里程碑之間有很高的相關性，否則一般情況下，團隊不會並行開展多個裡程碑的工作，但是從一個里程碑轉到另一個時，可能會有一段時間需要同時兼顧兩個。

專家建議：請時刻警惕範圍的擴張。範圍的蔓延在所難免。一旦範圍發生變化，一定要重新審核里程碑的截止日期，並清晰地傳達新範圍的影響。

項目類型

項目是主要的可交付產物，儘管從語義上可以將它們按照階段、上線次數或版本劃分，但是它們的功能都是相同的。無需過多地關注這些差異，但對產品經理和市場營銷來說，相應的命名會很有幫助。

針對未知的方向劃分任務

儘管很難估計里程碑的截止日期，但Webflow要求技術主管儘可能地指定比較現實的日期。這個限制起初看起來似乎很有限，但是我們只是希望大家多多關注截止日期，而並不是說截止日期不可動搖。

與其依賴項目模糊的截止日期，還不如「針對未知的方向劃分任務」。我們的功能需要締造全新的產業領域，一個JavaScript世界裡前所未有的領域，因此通常不可能清楚地預知即將面臨的工作。雖然其中有一些很明確，但是即便是最好的技術主管也會對一部分規格束手無策，他們可能會說，「呃，我不知道這需要多長時間才能完成。」要想打破這種局面，只有將這些未知的結果分解成小任務，儘快揭開這些未知之謎。

要堅定地對任務進行優先順序排序。等到掌握了更多信息的時候再進行調整。通知產品經理團隊當前正在做的任務。當未知的任務完成到一定程度時，里程碑的截止日期會浮上水面。

專家建議：有時在做未知的任務的時候，原本主問題的列表中沒有的一些新任務會湧現上來。沒關係，如果這些任務是實現里程碑必須的，那麼儘管加進來就好。如果因此影響了里程碑的截止日期的話，請務必通知經理。

會議

技術主管應當每周組織一次最長30分鐘的項目會議，最好選在周一早上，議程大致如下：

1. 簡單的回顧：

1.1 上周哪些任務進展順利？

1.2 上周哪些任務進展不順利？

1.3 如果進展不順利，我們應當如何改善？

2. 每個成員彙報：

2.1 當前任務的狀態？

2.2 遇到了什麼困難？

2.3 如何幫助你解決困難？（技術主管）

3. 向每個團隊成員分配新任務

4. 向產品經理彙報項目的狀況

5. 回答大家的問題，開個小玩笑帶動氣氛

除了上述每周的例會外，不應再開展任何別的全員會議。Slack上的對話或結對編程不能算作「會議」，團隊成員根據需要自由組織。

每周的狀況

可以要求每位工程師每天向#status-front-end和#status-backend頻道，彙報自己是處於「按計划進行」還是「落後於計劃」，而技術主管可以相應地確認每天的狀況（簡單地在Slack上為大家點贊）。這可以迫使每位工程師為自己每周的任務負責，如果出現任務大幅落後或落後超過5天的情況，技術主管可以及時介入。

專家建議：幫助團隊成員一次專註於一到三個並行任務。如果超過三個任務則不利於跟進，所以請幫助他們減少或合併任務，並找出任務過多的原因。

敏捷開發？項目經理？

你可能在想，「這種管理項目的方法屬於哪種？」它可能類似於敏捷開發，它擁有兩周的迭代周期和類似於「Scrum」的每周例行會議，但是它沒有Scrum主管。雖然我們喜歡敏捷方法論，我們的目標是儘快交付，根據需要隨時調整，但是Webflow並沒有採用具體的方法論。目前我們一切進展順利，而且隨著項目的發展，我們隨時可以重新評估。

▌技術主管可以管理哪種類型的團隊？

Webflow將其有才華的工程師安排到僅有一位技術主管負責的Action和Permanent團隊。

加入什麼規模的團隊？

團隊的規模不盡相同（甚至可以只有一個人），但一般來說，團隊包含3名成員，其中包括技術主管。管理共同參與解決同一個問題的兩個人相對容易，但是一旦開始管理第3個、第4個或第5個人，所產生的交流成本就會急劇增加。這種情況不僅發生在技術主管與成員之間，團隊成員之間的兩兩交流也是同樣的。雖然較大的團隊也可以良好地工作，但是3個成員是一個好的開始。

並不是說每個團隊都必須而且只能包含3個成員。一個Action團隊可以包含7個成員，包括技術主管，他可以將團隊劃分成兩個或三個小組，每個小組集中完成功能內的任務。然後技術主管可以為每個小組指定組長，為本組的工作負責。請記住各個小組都應該有效地關注功能，並互相協作解決問題，才能減少並行使用單個資源時所引發的阻塞延遲。

上述的團隊結構可以由後台和前端開發工程師組成。Webflow不希望明確區分這些工程上的分工，以及非工程之間的分工，比如設計師。組建全能的團隊是有效實現功能的終極階段；請根據個人意願和項目需求決定是否要這麼做。

團隊的效能與組織

組織團隊基本上有兩種方式。第一種是根據「功能」劃分團隊，這種方式有利於團隊合作解決密切相關的問題，另一種是根據「資源」劃分團隊，這種方式有利於個人並行從事完全不相關的任務。這兩者都有自己的優勢，但我們要求技術主管儘可能採用功能方式劃分。

專家建議：並行工作需要定義明確的範圍。如果領導的項目中，設計規格的迭代推進的同時，開發迭代也在並列進行的時候，最好只根據功能劃分團隊。

▌救命！項目進度落後了！

沒關係，真的。去喝點咖啡，或者曬會兒太陽，等到內心的波瀾恢復平靜的時候再回到辦公桌前。

幾乎每個項目都會遇到一些未知的因素影響到交付日期。並不需要拚命避免這種情況，可以試著做好心理準備。你需要在做預估的時候考慮到這一點。這再正常不過了，而且所有的技術主管都有這樣的經歷，是不是覺得很安慰？這不過是好與出色的區別。

如果因為不能如期交付項目而感覺傷心內疚，那麼就會極大地抹殺士氣。士氣是團隊最寶貴的資源。最好把這種「延誤」想成是「延期」，並作相應的處理。Webflow認為軟體開發是一項艱難的工作，所以我們有一些技巧可以幫助你將延誤的截止日期轉變為進展。

關於項目管理的一句話

在深入討論這個最終期限模型——我們稱之為「變更/推遲/放棄」的模型——之前，我們先介紹項目管理中兩個關鍵的概念，幫助你掌握我們採用這種模型的原因。

首先，我們必須強調為交付產物指定固定期限的必要性。如果沒有一個明顯的目標，我們很難衡量進展狀況。我們必須依照一個目標衡量進展狀況，即使這個目標只是一種猜測。而進展是工作積極性的最主要的因素。

其次，我們可以通過以下四項指標評價項目進程：

隨著項目的發展，這四項指標可能會發生變化。項目經理可以通過四項指標調整項目。話雖如此，但是Webflow旨在創建最高品質的產品，所以斷不會因為時間、資源或範圍犧牲質量，所以只剩下其他三根槓桿可供使用，我們將在下節中詳細介紹。

專家建議：因業務需要團隊不得不追趕截止日期的時候，技術主管通常會在第一時間成為眾矢之的。技術主管的決定必須符合一個問題：「這個決策如何能保證公司健康發展？」如果你沒有商業頭腦，可以參考Josh Kaufman的《The Personal MBA》一書。這是本很棒的關於現代商業實踐的書，可以幫助你在考慮Webflow和團隊需求時更好地做出決策。

變更/推遲/捨棄（進度延遲的緩解策略）

遇到無法嚴守截止期限的時候，有三個方式可以與產品經理商討。這三種方式的考慮順序應當為：

變更交付產物

推遲最後期限

放棄這個項目

變更

變更包含以下兩個問題：

是否可以向項目追加資源追趕最後期限？

是否可以變更交付產物以達成最後期限？

在評估如何挽回最後期限的時候，首當其衝應該考慮資源和範圍。首先考慮追加資源是否有助於解決目前的情況，但通常情況下這個方法行不通，除非項目最初就有人手不足的問題。在後期追加資源只會讓項目更加落後！所以，下一個應當考慮的是縮小範圍。

專家建議：只要嚴守最後期限還能提供商業價值，縮小範圍通常就是首選。一般來講，只有10%的項目會選擇加派人手挽回最後期限，90%的情況下會選擇縮小範圍。

縮小範圍通常是可行的。作為充滿激情的軟體開發人員，我們情不自禁會接下能力範圍之內的工作。我們可以利用這個機會，將交付產物分成更切合實際期望目標的小塊，並將這些期望目標傳達給其他利益關係人。

推遲

如果不可以削減範圍，且追加資源不可行的時候，那麼我們只能考慮延遲截止日期了。沒錯，你沒看錯。我們需要推遲截止日期。你可能會問，「如果我們可以強制更改截止日期，那麼當初指定截止日期還有什麼意義？」別急，我們理應儘可能避免更改截止日期，但是有時候也是迫不得已而為之，其實這也沒關係。如果我們試圖努力達成不切實際的截止日期，那麼風險更大，其中包括團隊過度疲勞、產品質量低下、士氣低落，等等。

最重要的是我們不能忽視交付日期。這才是關鍵所在。如果放任無法嚴守的截止日期不管，那麼項目將會陷入僵局，而項目的發展方向也未可知，這豈不是更糟？所以還是重新指定一個期限吧！

放棄

最後一個，也是最不可能發生的情況是放棄項目。如果你認為此次交付會給公司帶來負面影響的話，可以考慮放棄項目。扔了它吧！注重高效的工作，而非盲目的工作。

第四種戰略：密切關注

還有第四種選擇，如果錯過期限所帶來的後果無關痛癢，那麼只需密切關注。如果直覺上覺得有什麼不對的地方的時候，就要多加註意。搶先解決問題非常重要，必要時刻應當先發制人。讓你的項目經理意識到這一點。

專家建議：為了讓自己和其他人的生活更加輕鬆，掌握管理期望的藝術很關鍵。少承諾多交付是明智的做法，當然前提是保持坦誠和誠實。坦白一切。擔心無法嚴守截止期限或丟失關鍵資源的時候，就要大聲說出來。會哭的孩子有奶吃，大聲說出來有助於儘早完成工作。對未知事物持有懷疑的時候一定要誠實。

▌怎樣才能做出更好的估算？

在撰寫本文的時候，還沒有人發明類似於魔法8號球（一種占卜類的小玩具）的預估方法，用於預測軟體開發的時間表。有些人可能會跟你說一堆空話，而有些人會說根本不可能。你最好接受現實：軟體開發中的估算基本不準。迭代與發現，然後交付再改善，這不正是敏捷開發理論的核心嗎？這是一種發現的藝術，而不是交付的藝術。Webflow遵循的迭代過程我們在其他章節有所交代，儘管估算很重要，但是沒有探索未知重要。雖說如此，我們還是想在這裡介紹一些幫助估算任務的策略：

為意外情況留出餘量

開發的過程很少按照計划進行。我們不建議給出精確的估計，而應針對給定的任務儘可能地猜測，並將結果乘以4，特別是如果該任務涉及未知信息。聽起來有點瘋狂，有時候也確實是有點過。技術主管的經驗有助於改善最後的預估，但是以防萬一起見初步估算還是應該為未知的信息保留一定餘地。

探索未知信息的任務

在創建了主任務之後，你就可以大致了解項目可能需要多長時間。一定要確認哪些任務涉及探索未知信息，而哪些任務已經有了具體的定義。在完成所有任務之後，就可以更加準確地掌握截止期限。

八二原則

我們往往很容易忽略實際耗時的細微差別，從而導致項目最後20%的進度落後。在全面審查項目的時候，請使用80/20的原則分解項目，我們可以認為項目最後20%的工作可能會佔據整個時間表80%的時間。造成這種情況的原因有很多，但是最後的20%往往牽扯到交付成果最後的完善，而綜合性的功能需要完善每項功能，並涵蓋各種極端情況，而這種綜合性的功能需要在項目最後才能組織起來。

這對你意味著什麼？ 當項目完成80%的時候，我們只能將其視為只完成了一半。這樣才能正視額外的工作量所帶來的細微差別，準確地掌握項目的整體進度。

永遠別忘了QA

在估算截止日期的時候，設置一個代碼完成日期，如此QA才有時間找bug或用戶體驗的問題。估算的時候必須將QA的工作當成額外的階段，並考慮當前QA的工作量。

放鬆：交付後改bug

交付完前一個功能，在開始下個裡程碑之前，我們需要留出一些時間來修改緊急的bug。這部分工作的時間因交付功能的複雜程度而異，通常留出一周的時間比較合適。可以利用這個機會，讓團隊在進入下一組任務前放鬆一下，並讓技術主管有時間抓緊做下個項目的主任務列表。

▌項目需要多長時間？

雖然功能的範圍可能需要數月的工作，但是下一個項目應該以6周的時間為基準，其中包括QA的工作，所以每個裡程碑寫代碼的時間大約是4周左右。如此，市場營銷人員可以評價一套的功能並收入囊中，根據市場的動態隨時準備發布。起初，將一個大功能分解成6周的時間表可能會很有挑戰性，但是我們這麼做的幾個重要原因是：

較小的範圍和時間表易於管理

如果功能所帶的業務價值微薄，那麼隨時可以調整項目

6周的時間表更利於三人團隊的快速作業

為期6個月的項目的主要里程碑可能大致如下：

Alpha版發行（6周）

Beta版發行（6周）

功能發行v1.0（6周）

功能發行v1.0.1（6周）

▌是否應該建立功能分支？

不要。好吧，可能有其他分支提交到長期分支的情況。也有可能，1%的可能我們需要重構基礎設施中重要且應用廣泛的部分。除此之外，基本上不需要建分支。如果需要建分支，那麼請告知整個團隊，產品經理，以及工程經理。你可能有點驚訝如何將工作組織成小規模，且不斷合併分支。

請不要在feature-branches建立分支。技術主管應該要求團隊成員將各自的feature-branches直接提交到dev分支上，而非其他feature-branch上，從而保證dev分支上擁有最新的代碼。長期的feature-branches分支往往會引起代碼間的依賴性，而且其他編程模式可能需要選擇性的提交代碼，並引發很難與其他分支保持同步的問題。所以，技術主管應該將整個項目歸類到一個功能標記下，並持續將代碼合併到dev分支中。

總體來說，Webflow有兩個主分支：

dev

master

而每個feature-branch：

可以從dev分支上創建

必須合併回dev分支

功能標記

我們鼓勵所有的工程師養成每天推送代碼的習慣（如果可能的話），並且為了防止新功能流入最終用戶，我們建議技術主管將這些新功能歸類到一個功能標記之下，並由ShortcutHelper控制。

▌怎樣才能保持注意力集中？

保持「注意力集中」意味著首先要照顧好自己，而且最重要的是找到一種解決問題的「快樂」方式。生活就是要做有意義的工作，同時也要有意義的生活。這意味著你需要從忙碌的工作中抽出時間來放鬆一下，參加一些業餘活動，讓自己保持精力充沛與專註。可以讀本書，也可以觀看一些電視節目，鍛煉身體，或者去戶外呼吸新鮮空氣。找到一種方式可以讓你高效的工作與生活，不要害怕向經理表達這方面的需求，也不要害怕抽出些時間來放鬆自己，即便感覺這會降低你的工作效率。

如果你不能保持注意力集中，那麼你的團隊也做不到。記住以身作則。

▌如何良好地組織時間？

新晉技術主管往往感到不知所措，如果不是這樣，那麼可能說明他們沒有好好工作。（好吧，有些人可能可以泰然處之，但是大多人會覺得不適應）。對付壓力過大的關鍵是學習管理時間的藝術。管理時間的方式多種多樣，你可以根據自己的喜好選擇。如果你從未接觸過關於時間管理的書籍的話，我們建議你可以讀一讀David Allen的著作《儘管去做》（Getting Things Done）。這是學會如何清除心中雜念的第一步。如果他的方法不適合你，那麼你可以找別的方法，並與大家分享。

▌我應該在編程上花多少時間？

雖然根據項目不同而異，但是我們可以大概地將技術主管的工作時間劃分成：30%的時間寫代碼（或者更少），30%的時間審核代碼（或者更多），剩下的時間服務你的團隊。

審核代碼

既然最終要對交付成果的質量負責，那麼你需要審核代碼並首肯每個PR。對於大型團隊來說，這項工作耗時巨大，所以最好鼓勵團隊成員互相審核代碼。也就是說，你需要進行大量的代碼審核，並趁機指導初級團隊成員，然後多向高級團隊成員討教，磨練自己的技術能力。

▌怎樣向全員用Lattice彙報進度？

每周四早上11點，Webflow都會舉辦「全員」會議，管理團隊將在會上傳達所有進行項目的狀況，以及公司的大型目標和倡議。技術主管負責在會前將各自的項目進展狀況提交到Webflow的項目跟進Google文檔中。本文檔共享到了Slack的＃全員頻道中。該Google文檔的最後給出了彙報模板。請按照模板進行彙報。模板的內容包括：

項目概要：項目狀況的簡短介紹。

按計划進行/偏離計劃的里程碑：彙報每個有效里程碑的狀況，它們的進展百分比，上周以來的進展百分比（這些是猜測）。還需列出團隊接下來兩周的工作內容以及預計的交付日期。

關鍵決策：交代所有可能涉及時間表變更、範圍變更、以及其他關係到客服/市場、或資源變更的關鍵決策。

風險、未知因素、以及困難：交代上周以來出現的風險、未知因素或困難。

Lattice

Webflow使用Lattice來跟進更高的公司目標。除了每周的全員彙報外，公司還要求在Lattice中更新與你相關的目標。如果你沒有帳號，請找工程經理幫忙。

▌如何保持團隊的積極性？

營造成就感，保留足夠的空間，不要提示解決方法，讓團隊成員創造性地解決問題，激勵人類的不僅僅是金錢，或胡蘿蔔加大棒。簡單地啟發就可以激勵內在的動力：你只需將現實的目標擺在面前，並提供工具，以及解釋清楚其中的緣由，我們就可以創造奇蹟。

科學向我們揭示了激勵人類的關鍵因素。本文中的很多概念都建立在這些科學見解之上，所以不知不覺中你已經開始使用戰術來保持團隊的積極性了！雖說如此，我們還是想在這裡介紹一些流程中的基本機制。

自主、專精與目的

Daniel Pink在他的著作《驅動力》中否定了人類外部動力的秘密，或者說金錢、更好的辦公室、職位等外部因素激發的動力。相反，他揭示了人類內在動力的因素，例如歸屬感、提高技能的機會、以及按照個人的方式做事。這三方面的內在因素可以歸納為自主、專精與目的，解剖動力的基本知識是個良好的起點。

Webflow公司負責提供這些關鍵的激勵因素，但是聰明的技術主管也可以使用它們來產生很大的影響。所以，每個星期都問問自己以下幾個問題：

我是否給予了我的團隊足夠的空間，讓他們用自己的方式解決問題？在我應該提供方向和目標時，我是否下達了命令？自主

我是否給成員們分配了合適的任務，幫助他們成長？專精

我們是否在為什麼要建立這個功能，以及Webflow希望怎樣幫助這個世界上達成了一致？目的

提供反饋

在Google和蘋果擔任過執行官的哈佛畢業生Kim Scott，曾在她的著作《Radical Candor》中總結了如何以最好的方式管理與團隊每個人的關係與期望。事實證明，我們不應該淡化我們的感受以及彼此間的對話，相反，我們應該以個人和關心的方式討論難題。這項原則的基本前提是「關心個人，直接挑戰」，這意味著你必須體諒團隊成員，並向他們表達你關心他們，但是仍然可以提供重要的反饋（甚至是直接的反饋，可能會傷害到對方）。

儘早並經常提供重要的反饋，並表達你十分關心團隊成員，可以幫助你在今後的道路上迴避悲慘的挑戰。不僅可以提供負面的反饋，更要提供積極的反饋。兩方面都很重要。如果你想了解更多信息，請參閱她的書籍。

專家建議：表達反饋的方式可能直接影響到對方是否肯接納。我們要做到對事不對人。可以使用情況-行為-影響的模式來表達反饋。首先提出事情發生時的情況，然後強調行為，最後指出造成的影響，例如，「在今天的會議中，你多次打斷Brian，讓Brian感覺直到會議快結束時他才能發言。這拉長了整個會議。」如果你想了解更多這方面的信息，可以參閱這篇文章：https://www.mindtools.com/pages/article/situation-behavior-impact-feedback.htm

圈子

強調每個團隊成員都有足夠的機會加入圈子很重要。這本身足以讓大多數人快樂地工作與生活。這是激勵和有效工作的關鍵因素，因此我們在此列出來提醒大家。

▌如果有人表現欠佳，我該怎麼辦？

有一句老話說，「沒有差勁的員工，只有差勁的經理？」這句話大部分屬實。Webflow擁有才華橫溢的工程師，所以在你得出有人表現欠佳的錯誤結論之前，請先確定你是否為團隊提供了100%的服務。

請確保每個團隊成員都有足夠的動力，有充分的機會自主地做有意義的工作，擁有足夠的成長空間，並掌握了足夠的目標。另外，持續提供反饋也是很重要的部分。

你還必須考慮團隊成員的內在工作生活。大膽地問他們，「最近怎麼樣？工作之外一切都好嗎？」經常問這些問題，但是記住不要八卦。允許團隊成員討論個人問題，但是要記得這是他們的私事。

如果你已經盡了最大努力，為團隊成員營造了最佳工作環境，但他們的表現依然不盡人意，那麼請跟你的經理談談下一步該怎麼辦。

▌如何避免團隊承擔過多工作？

如果一個團隊無法嚴守截止日期，那麼這是管理上的問題，而不是團隊的問題。這意味著，在項目的進行過程中，某些環節沒有按照計划進行，且沒有得到及時調整。因此，避免承擔過多工作的第一個原則是「良好地管理項目和預期結果」。

第二個原則：永遠不要將自己都無法完成的工作分配給團隊成員（而且不能算你加班的時間）。有些公司或組織會在遇到難關時要求員工加班。對於高效團隊來說，這將導致人員流失和長期的效率降低。Webflow非常關心我們的團隊，不僅在工作中，還有個人方面，所以我們必須盡最大努力管理好自己的時間。

時間緊迫

哦，時間緊迫，你已經擁有了最好的團隊，但是還是不可避免緊急情況的發生。

作為技術主管，你將不可避免地遇到一個即將來臨的截止日期，可能需要稍微付出一點額外的努力才能在最後階段完成所有工作。稍微的意思是說，團隊可能要在每周40個小時的工作時間之外再加會兒班。沒錯，我們所說的「時間緊迫」並不是瘋狂地加班到深夜或周末。就幾個小時而已。最多的時候，有人每天加班2-4個小時，若非萬不得已他們不能再有更多的加班。他們已經盡了全力工作了，如果要求更多勢必造成效率低下，也會對他們個人和Webflow公司造成不利影響。

時間緊迫是真的。但是時間緊迫可能是管理不善的一個表象。我們必須盡最大努力將這些過度活躍的時期控制在每年一到兩次。

注釋：[1] 穩定的團隊應當與客服聯絡員密切合作，專註於修復對用戶影響巨大的bug。

原文：https://hackernoon.com/the-effective-tech-lead-is-a-100x-engineer-fe49c0372a63

作者：Leonard Souza

譯者：彎月

責編：琥珀

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！