[转]资深CTO：关于技术团队打造与管理的10问10答
一、你如何衡量軟件工程師個人的工作表現？如何衡量整個工程師團隊的工作表現？
主要從兩方面：
任何績效管理的最重要的前提就是針對這個人的合理期望達成共識，這里既包括顯性期望和隱性期望。顯性期望是指，要求對方在滿足特定要求的情況下在規定時間內完成一個特定項目的交付。隱性期望是指，不管他們做什么項目，你對他們的表現所擁有的期待。
如果員工在負責開發一個功能，那么這里的“What”應該包括以下幾個方面的內容：
這里的“How”應該包括以下幾個方面：
你可以使用類似的方法來評估整個團隊的表現。在評估團隊的表現時，你可以問下面這兩個問題：
二、你的工程團隊成員的角色和職責分工是怎樣的？你有指定專門的軟件架構師或技術主管嗎？
我首先需要說明的是，我不喜歡在團隊中擁有指定的架構師角色或明確的架構師頭銜。我認為，設計一個系統是所有工程師的責任，所有工程師都必須負責開發和維護這個系統，而不是讓某一個個人或團隊來專門負責并讓他們在那光指揮別人做事而不自己親自開發這個系統。
我知道這么說可能會得罪很多架構師領域的朋友，但是我還是要說。我之前在大公司里有過親身體會。舉個例子，Intuit 擁有一個非常強大的架構師團隊，也擁有非常成熟的架構師職業發展通道，我知道這群人中有一些非常出色的人才，包括 Intuit 現在的首席架構師。然而，Amazon 是沒有架構師這個職位頭銜的，作為一個工程師，你可以走 IC 這個職業發展通道，或者技術管理的職業發展通道，不管你選擇哪一種，你都需要能夠負責設計非常龐大和復雜的系統。
我打造和運營的每一家公司和每一個團隊采用的都是第二種方式。當然，任何時候都需要有人來負責架構方面的責任，但我希望這個人是工程團隊的一名能自己親自寫代碼的成員。
現在再說說技術主管。在我看來，“技術主管”應該是人們所應承擔的一個職責，而不應該是一個具體的職位等級。
對于我自己而言，技術主管意味著需要在一個項目上領導其他工程師（而不是單純的人員管理工作），既要在技術決策上發揮領導作用，也要在不同成員之間的分工協作上發揮領導作用。
我不認為必須要達到一定的職位級別才能成為一個項目的技術主管。例如，只要有能力，即使是一名只有一年工作經驗的工程師也可以領導一個由一個或多個工程師/實習生參與的項目。我的團隊中也有一些經驗非常豐富的優秀工程師，他們是思想領袖和專業領域的專家，但是卻不喜歡去領導其他人。因此，盡管技術主管中更多的是那些更資深的人員，但技術主管本身并不是一個職位等級。
在 LendingHome，我們在公司內確定了不同的職位級別，并定義了每個級別所要承擔的角色和職責。在這方面，我們一直努力與行業的通常做法保持一致，這樣我們公司的職位級別和頭銜也能適用于其它優秀的科技公司。我們公司提供了兩條職業發展路徑：一種是 IC 職業發展通道，另一種是技術管理職業發展通道。這樣你可以在不用做管理人員的情況下也能繼續在公司得到成長和晉升。
如果走技術路線，我們公司的工程師等級分為工程師、資深工程師、高級工程師、首席工程師、高級首席工程師、杰出工程師、高級杰出工程師。在級別上，他們與經理、高級經理、總監、副總裁和高級副總裁是平行的。你在任何一個級別上都可以扮演一個首席架構師或技術主管的角色。實際上，我希望每一個技術主管都能負責他們手里項目的架構工作。
三、你用來確定產品優先級的流程是怎樣的？
每一年，我們在公司層面只設定少數幾個關鍵目標。然后根據公司的宏觀目標，每個業務線為自己制定未來 6 個月的階段性目標。然后，我們再制定符合半年目標的季度目標路線圖。這些路線圖就是我們定期沖刺的參照標準。就這樣，公司整年的宏觀目標被分解成一個個短期的目標。
制定路線圖總是從每個產品經理開始，產品經理負責制定一個需要與跨職能合作伙伴一起協作完成的優先任務清單。我們將所有這些優先任務清單整合到一起，并創建一個我們希望在下個季度完成的整體優先任務清單。這個任務清單列表也包括我們上個季度延續下來的任務。
一旦我們就這些優先任務清單達成一致之后，產品經理與工程技術部門合作，對各個項目做大概的評估。工程技術部門也需要提供一個本季度的明確的工作目標。利用這種方法，團隊可以進行有效的權衡，并制定該季度最終的產品工作優先級清單。這不是一個項目計劃，而是一個我們想要完成的任務清單。
我們就從這個優先任務列表中選擇任務分別進行沖刺，并在整個季度持續執行。我們努力在這里做足前期調研工作，這樣我們就不需要在季度中途改變這個優先任務清單。但是，如果出現了需要修改的東西，那么我們就強迫自己對優先任務列表中的任務進行權衡取舍，而不是直接在列表中添加更多的任務條目。這說起來容易做起來難，但卻是至關重要的。
四、如何讓設計師完美地適應產品開發流程？如果能在項目早期就讓設計師參與其中、同時又不會浪費設計師的時間？
在理想狀態下，在公司業務的各項不同的產品工作中都應該有設計主管或指定的設計人員參與其中。這個設計主管應該在項目早期階段就參與其中，這樣他們就可以在整個項目進行的過程中從設計團隊中為該項目獲取所需的其它資源。
我們過去遇到的挑戰是我們的設計團隊中沒有足夠多的人員來肩負起這樣的角色。我們的目標是建立起這樣一種架構，讓設計團隊能盡早參與到所有項目中去。但是這也要看項目的性質，例如，我們不希望讓設計師參與到一些專注于純粹的后端服務和基礎設施的項目中。但是另一方面，對于那些直接面向客戶的項目，尤其是那些與品牌、營銷和應用流程直接相關的項目，我們應該在項目剛開始的時候就讓設計師參與其中，而且通常情況下都會有多個設計人員同時參與其中。
如果你已經將項目人員數量降到了最低，你就不應該擔心浪費設計師的時間。
這里需要著重強調的一點是，我不認為設計是純粹的外觀和視覺設計。如果是純粹的外觀和視覺設計，完全可以等到項目后期階段、在所有其它重要工作都完成之后再做設計方面的工作。對我而言，設計是一項非常宏觀的工作，它涉及到幾個方面的工作：交互、調研、視覺等等。要想不浪費設計師的時間，最好的方式就是在每一個階段讓合適的人員加入進來，而不是在每一個階段讓所有人都參與進來。例如，當需求還沒有確定的時候，我是不會讓視覺設計師參與進來的。但是，我會盡早地讓交互設計師參與進來，因為他們可以在早期定義需求和解決方案的時候發揮很大的作用。
五、在打造工程技術團隊的過程中，有哪些常見的錯誤想法？
常見的錯誤想法有很多，我這里主要強調以下三個常見的錯誤想法：
1、招聘最聰明的人，把他們放在一起，你就能組建一支高效的團隊。
你應該始終努力招聘比你自己更聰明的人加入團隊。但是，把一群聰明人放在一起不一定就能組成一支高效牛逼的團隊。要想打造一支真正高效的團隊，你需要一群真的愿意在一個團隊中共事合作的聰明人，而且這些人需要關心團隊的成功勝過自己的成功。
解決后面這個問題比招到聰明人要困難得多，而這也是決定你的團隊能否成功的關鍵因素。因此光招聘一群聰明人是不夠的。為了確保加入團隊中的人都是具有團隊合作意識的人，你可以在面試中使用 STAR 法則（Situation-情形、Task-任務、Action-行動、Result-結果），因為你可以通過根據應聘者過去的行為表現來預測他未來的表現。如果一個應聘者在之前的工作中并沒有表現出能夠和團隊成員很好協作的一面，或者沒有表現出團隊的利益和成功是高于個人的利益和成功的，這時，如果你招他進來，他在未來的工作中很有可能會有類似的表現。
2、只招聘那些與你自己或團隊中其他人員很像的人員。
我曾經非常希望能夠多克隆幾個我團隊中的一些非常出色的人員。幸運的是，對于我來說這個選項是不存在的。
因為，如果我真的克隆了很多團隊中最出色的人，讓團隊中的所有人都差不多，這只會讓團隊喪失想法的多樣性，最終喪失了所有的創新能力。經驗和思想的多樣性是激發新的、創造性的解決方案的源動力。從長遠來看，一個多元化的團隊將會變成一個更好、更強大的團隊。
3、將一群聰明人放在一起，他們就能解決任何問題。
很抱歉又強調了一遍這個問題，但是在某種程度上，這確實是事實。聰明的人喜歡解決富有挑戰性的問題，他們往往會能夠想出一個非常不錯的解決方案。但這并不是打造一個強大團隊的基礎。其中的關鍵不僅僅在于找到一群聰明的人，同時要確保這些人是真正有激情去解決你要解決的問題的。如果這些人對要做的工作缺乏真正的興趣和熱情，你可能在早期階段還能將工作完成的不錯，但是從長遠來看，你最終面對的將是一個個無法全身心投入工作的員工和一個表現不佳的團隊。
六、你面試工程師的流程步驟是怎樣的？你為什么認為這樣的流程步驟很重要？
我們在 LendingHome 采用的工程師面試流程是非常直接的。第一步，面試官可能會對候選人人做一次電話面試。是否進行電話面試取決于：是我們在積極挖一個比較被動的候選人，還是候選人在積極地申請應聘我們的崗位？如果是前面這種情況，我們就不會進行電話面試了。如果是后面這種情況，我們可能要做一輪電話面試。
最開始要進行一輪電話面試篩選，主要有兩個目的：
通過電話面試的候選人將會被邀請參加最后的現場面試。現場面試有有幾輪，要持續一整天時間，需要和 6 個面試官面試——3 個工程師、2 個技術經理（我們會從總監、經理、VP、我自己和首席技術官中選取兩個人）和 1 個產品經理。我希望每一個工程師招聘小組里都能有一個非工程師人員，這樣我們在招聘中就能獲得一個完全不同的看待候選人的視角。
在現場面試中，我們要考察的內容包括專業能力、領導能力和行為技能。專業能力考察內容包括架構、系統設計、解決問題的能力和編碼能力。我自己非常喜歡使用 STAR 法則來評估候選人的非技術方面的能力。
每一位面試官在面試結束后都需要在面試追蹤系統 Greenhouse 中填寫對應聘者的詳細評價和反饋。采用的是匿名評價的方式，這意味著你在評價之前是看不到其他面試官對應聘者的評價的。然后，我們會在應聘者現場面試結束后的當天，對每一位候選人進行 30 分鐘的總結評估，并決定是否給該候選人發 Offer。如果決定給 Offer，我們就會盡快給候選人發出 Offer。
七、什么時候招聘產品 VP 合適？招聘什么樣的產品 VP 合適？
這個問題主要看公司的發展階段，以及你想通過招聘一個產品 VP 來解決什么樣的問題。根據公司和技術團隊規模的不同，產品 VP 的職責也會有所不同：
要問答上面這個問題，需要根據各個公司的不同情況。對于那些想招聘一個產品 VP 來負責公司的所有產品工作的公司而言，下面是我的建議。在公司發展初期，CEO 自己通常是公司的首位產品經理。隨著公司規模的發展壯大，其他一些人開始以兼職的形式分擔部分產品工作。在創業公司，首先發展壯大的通常是工程師團隊，CEO 會與工程師團隊緊密協作。如果公司里沒有一個技術聯合創始人的話，這時公司首先招聘的通常是一個技術 VP。招到技術 VP 后，CEO 可能會招聘一個全職的產品經理來做一些產品戰術方面的工作，比如制定產品說明書、與工程師協調等等，產品路線圖和產品愿景還是由 CEO 親自把控。在這個過程中可能會陸續加入幾個產品經理，進而組成一個松散的產品團隊，這個團隊需要直接向 CEO 匯報。
這時，CEO 應該認識到，除了產品工作外，自己身上還要肩負起很多其他職責，這時他們必須認識到必須要招聘一個產品 VP 了。通常情況下，很多 CEO 都是被迫做出這個決定的，因為他們通常認為自己是會一直負責產品方面的工作的。
如果你是公司 CEO，面對需要招聘產品 VP 的情況時，你必須回答這樣一個關鍵問題：新招聘的產品 VP 是只需負責執行 CEO 的指示、管理產品功能和產品經理團隊？還是需要讓他來整體負責產品愿景的把控和產品路線圖的制定工作？
這是一個很難回答的問題，你對于這個問題的答案將決定需要招聘什么樣的產品 VP。作為 CEO，你不應該自己獨自做這個決策，你需要向你的董事會、投資者、團隊中你信任的成員征求意見。讓大家群策群力，看看究竟是什么樣的產品 VP 才是真正滿足公司的整體發展需要的。
八、你用來管理技術債的框架是什么？
在很長一段時間里，公司增長得非常快，也開始受到很多資源方面限制，因此，我們積累了大量的技術債務。所以我們已經重構了系統的幾個部分。是否要對系統進行重構，從而償還技術債，主要要看以下幾個方面：
然而你還需要問自己下面這幾個問題：
隨著時間的推移，我們越來越擅長評估這些問題，但并不是總是有一種可行的方法。舉個例子，我們現在正在重寫一個項目，我想讓團隊并行地構建一個新系統去徹底替換舊的系統。因為如果對原有的系統進行循序漸進地改進，會花費太長時間，而且整個過程會讓人感到非常痛苦。于此同時，我們還有一些正在進行的技術改進項目，循序漸進地改進一些現有的系統。
九、你是否曾在面試過程中使用過編碼測試？如果有，具體是怎么測試的，為什么使用這種方法？
我們確實在面試過程中使用了編碼測試。我們對編程語言沒有限制，候選人可以選擇任何語言編寫代碼。我們想要評估的是：
進行編碼測試的時候，需要設置一個場景問題，這樣我們就可以評估應聘者是否能有效地解決問題。
十、在一個技術經理招聘比他自己更有經驗的人的時候，你有什么建議？
理想情況下，你雇傭的每一個人都應該在某些方面比你做得更好。這也適用于招聘比你經驗更豐富的人。在招聘比你經驗更豐富的人時，你需要考慮的主要問題是你如何為他們增加價值，以及你將如何從他們的經驗中受益。
了解這個人在哪方面能夠為你帶來價值，以及他能從你這里得到什么幫助。例如，他們可能是在技術上比你更好的工程師，在設計和構建復雜系統時不需要你提供任何幫助。但是，他們可能沒有你了解公司業務的相關背景、公司的客戶等。你可以通過幫他們更快地熟悉所有這些東西來增加他們的價值，這樣他們就能更好地完成工作。類似地，你也可以幫助他更好地了解公司的組織架構，從而更快地改善他們與其他團隊的協作。
所有這些點在面試過程中就應該提到，而不是在他們接受了這份工作之后才告訴他們。當他們的這些需求和利益得到承認和滿足時，說服他們加入就會更容易。
雇傭比你更有經驗的人的最重要的方面在于你可以從他們那里學到東西。一定要保持一個開放的心態，并對能從他們身上學到知識表示感謝。相信我，當你向他們學習的時候，你仍然會給他們增加價值，所以不要擔心這點。在我職業生涯中的很多時候，我總是不得不雇傭比我更有經驗的人。我非常喜歡從他們那里學習，如果沒有他們教給我的所有東西，就不會有今天的我。
轉載于:https://www.cnblogs.com/lurenjiashuo/p/7865370.html
總結
以上是生活随笔為你收集整理的[转]资深CTO：关于技术团队打造与管理的10问10答的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： flask开发问题小记
- 下一篇： 邮件MIME格式分析