[轉]資深CTO：關於技術團隊打造與管理的10問10答

　1、你如何衡量軟件工程師我的的工做表現？如何衡量整個工程師團隊的工做表現？

　　主要從兩方面：

1. 這個員工作的工做是否是他贊成作的或者應該作的？（What）
2. 他們是如何完成本身的工做的？（How）

　　任何績效管理的最重要的前提就是針對這我的的合理指望達成共識，這裏既包括顯性指望和隱性指望。顯性指望是指，要求對方在知足特定要求的狀況下在規定時間內完成一個特定項目的交付。隱性指望是指，無論他們作什麼項目，你對他們的表現所擁有的期待。

　　若是員工在負責開發一個功能，那麼這裏的「What」應該包括如下幾個方面的內容：

1. 這個功能在產品中是否表現良好？
2. 這個功能是否是按照規範開發出來的？
3. 這個功能有沒有按時發佈？
4. 這個功能是否能知足往後規模化擴張的需求？

　　這裏的「How」應該包括如下幾個方面：

1. 他們是否與團隊中的其餘成員進行了很好地合做？
2. 他們有沒有由於走捷徑而開發了一個很難維護的系統？
3. 他們是否遵循了全部正確的步驟並開發了可擴展的耐用產品？
4. 他們是否在工做過程當中破壞了其餘人的系統？
5. 他們在作本身的工做時有沒有指導別人?
6. 他們在這個過程當中是否學到了一些新的東西？
7. 他們是否具備創新意識，並能以一種創新的方式解決問題？
8. 他們是否強制將以前的解決方案應用於新的、徹底不一樣的問題上？

　　你可使用相似的方法來評估整個團隊的表現。在評估團隊的表現時，你能夠問下面這兩個問題：

1. 這支團隊是否交付了他們應該交付的工做成果？
2. 你從此是否願意再讓他們從此以相同的工做方式完成相似的工做？

2、你的工程團隊成員的角色和職責分工是怎樣的？你有指定專門的軟件架構師或技術主管嗎？

　　我首先須要說明的是，我不喜歡在團隊中擁有指定的架構師角色或明確的架構師頭銜。我認爲，設計一個系統是全部工程師的責任，全部工程師都必須負責開發和維護這個系統，而不是讓某一個我的或團隊來專門負責並讓他們在那光指揮別人作事而不本身親自開發這個系統。

　　我知道這麼說可能會得罪不少架構師領域的朋友，可是我仍是要說。我以前在大公司裏有過親身體會。舉個例子，Intuit 擁有一個很是強大的架構師團隊，也擁有很是成熟的架構師職業發展通道，我知道這羣人中有一些很是出色的人才，包括 Intuit 如今的首席架構師。然而，Amazon 是沒有架構師這個職位頭銜的，做爲一個工程師，你能夠走 IC 這個職業發展通道，或者技術管理的職業發展通道，無論你選擇哪種，你都須要可以負責設計很是龐大和複雜的系統。

　　我打造和運營的每一家公司和每個團隊採用的都是第二種方式。固然，任什麼時候候都須要有人來負責架構方面的責任，但我但願這我的是工程團隊的一名能本身親自寫代碼的成員。

　　如今再說說技術主管。在我看來，「技術主管」應該是人們所應承擔的一個職責，而不該該是一個具體的職位等級。

　　對於我本身而言，技術主管意味着須要在一個項目上領導其餘工程師（而不是單純的人員管理工做），既要在技術決策上發揮領導做用，也要在不一樣成員之間的分工協做上發揮領導做用。

　　我不認爲必需要達到必定的職位級別才能成爲一個項目的技術主管。例如，只要有能力，即便是一名只有一年工做經驗的工程師也能夠領導一個由一個或多個工程師/實習生參與的項目。個人團隊中也有一些經驗很是豐富的優秀工程師，他們是思想領袖和專業領域的專家，可是卻不喜歡去領導其餘人。所以，儘管技術主管中更多的是那些更資深的人員，但技術主管自己並非一個職位等級。

　　在 LendingHome，咱們在公司內肯定了不一樣的職位級別，並定義了每一個級別所要承擔的角色和職責。在這方面，咱們一直努力與行業的一般作法保持一致，這樣咱們公司的職位級別和頭銜也能適用於其它優秀的科技公司。咱們公司提供了兩條職業發展路徑：一種是 IC 職業發展通道，另外一種是技術管理職業發展通道。這樣你能夠在不用作管理人員的狀況下也能繼續在公司獲得成長和晉升。

　　若是走技術路線，咱們公司的工程師等級分爲工程師、資深工程師、高級工程師、首席工程師、高級首席工程師、傑出工程師、高級傑出工程師。在級別上，他們與經理、高級經理、總監、副總裁和高級副總裁是平行的。你在任何一個級別上均可以扮演一個首席架構師或技術主管的角色。實際上，我但願每個技術主管都能負責他們手裏項目的架構工做。

　　3、你用來肯定產品優先級的流程是怎樣的？

　　每年，咱們在公司層面只設定少數幾個關鍵目標。而後根據公司的宏觀目標，每一個業務線爲本身制定將來 6 個月的階段性目標。而後，咱們再製定符合半年目標的季度目標路線圖。這些路線圖就是咱們按期衝刺的參照標準。就這樣，公司全年的宏觀目標被分解成一個個短時間的目標。

　　制定路線圖老是從每一個產品經理開始，產品經理負責制定一個須要與跨職能合做夥伴一塊兒協做完成的優先任務清單。咱們將全部這些優先任務清單整合到一塊兒，並建立一個咱們但願在下個季度完成的總體優先任務清單。這個任務清單列表也包括咱們上個季度延續下來的任務。

　　一旦咱們就這些優先任務清單達成一致以後，產品經理與工程技術部門合做，對各個項目作大概的評估。工程技術部門也須要提供一個本季度的明確的工做目標。利用這種方法，團隊能夠進行有效的權衡，並制定該季度最終的產品工做優先級清單。這不是一個項目計劃，而是一個咱們想要完成的任務清單。

　　咱們就從這個優先任務列表中選擇任務分別進行衝刺，並在整個季度持續執行。咱們努力在這裏作足前期調研工做，這樣咱們就不須要在季度中途改變這個優先任務清單。可是，若是出現了須要修改的東西，那麼咱們就強迫本身對優先任務列表中的任務進行權衡取捨，而不是直接在列表中添加更多的任務條目。這提及來容易作起來難，但倒是相當重要的。

　　4、如何讓設計師完美地適應產品開發流程？若是能在項目早期就讓設計師參與其中、同時又不會浪費設計師的時間？

　　在理想狀態下，在公司業務的各項不一樣的產品工做中都應該有設計主管或指定的設計人員參與其中。這個設計主管應該在項目早期階段就參與其中，這樣他們就能夠在整個項目進行的過程當中從設計團隊中爲該項目獲取所需的其它資源。

　　咱們過去遇到的挑戰是咱們的設計團隊中沒有足夠多的人員來肩負起這樣的角色。咱們的目標是創建起這樣一種架構，讓設計團隊能儘早參與到全部項目中去。可是這也要看項目的性質，例如，咱們不但願讓設計師參與到一些專一於純粹的後端服務和基礎設施的項目中。可是另外一方面，對於那些直接面向客戶的項目，尤爲是那些與品牌、營銷和應用流程直接相關的項目，咱們應該在項目剛開始的時候就讓設計師參與其中，並且一般狀況下都會有多個設計人員同時參與其中。

　　若是你已經將項目人員數量降到了最低，你就不該該擔憂浪費設計師的時間。

　　這裏須要着重強調的一點是，我不認爲設計是純粹的外觀和視覺設計。若是是純粹的外觀和視覺設計，徹底能夠等到項目後期階段、在全部其它重要工做都完成以後再作設計方面的工做。對我而言，設計是一項很是宏觀的工做，它涉及到幾個方面的工做：交互、調研、視覺等等。要想不浪費設計師的時間，最好的方式就是在每個階段讓合適的人員加入進來，而不是在每個階段讓全部人都參與進來。例如，當需求尚未肯定的時候，我是不會讓視覺設計師參與進來的。可是，我會盡早地讓交互設計師參與進來，由於他們能夠在早期定義需求和解決方案的時候發揮很大的做用。

　　5、在打造工程技術團隊的過程當中，有哪些常見的錯誤想法？

　　常見的錯誤想法有不少，我這裏主要強調如下三個常見的錯誤想法：

　　一、招聘最聰明的人，把他們放在一塊兒，你就能組建一支高效的團隊。

　　你應該始終努力招聘比你本身更聰明的人加入團隊。可是，把一羣聰明人放在一塊兒不必定就能組成一支高效牛逼的團隊。要想打造一支真正高效的團隊，你須要一羣真的願意在一個團隊中共事合做的聰明人，並且這些人須要關心團隊的成功賽過本身的成功。

　　解決後面這個問題比招到聰明人要困可貴多，而這也是決定你的團隊可否成功的關鍵因素。所以光招聘一羣聰明人是不夠的。爲了確保加入團隊中的人都是具備團隊合做意識的人，你能夠在面試中使用 STAR 法則（Situation-情形、Task-任務、Action-行動、Result-結果），由於你能夠經過根據應聘者過去的行爲表現來預測他將來的表現。若是一個應聘者在以前的工做中並無表現出可以和團隊成員很好協做的一面，或者沒有表現出團隊的利益和成功是高於我的的利益和成功的，這時，若是你招他進來，他在將來的工做中頗有可能會有相似的表現。

　　二、只招聘那些與你本身或團隊中其餘人員很像的人員。

　　我曾經很是但願可以多克隆幾個我團隊中的一些很是出色的人員。幸運的是，對於我來講這個選項是不存在的。

　　由於，若是我真的克隆了不少團隊中最出色的人，讓團隊中的全部人都差很少，這隻會讓團隊喪失想法的多樣性，最終喪失了全部的創新能力。經驗和思想的多樣性是激發新的、創造性的解決方案的源動力。從長遠來看，一個多元化的團隊將會變成一個更好、更強大的團隊。

　　三、將一羣聰明人放在一塊兒，他們就能解決任何問題。

　　很抱歉又強調了一遍這個問題，可是在某種程度上，這確實是事實。聰明的人喜歡解決富有挑戰性的問題，他們每每會可以想出一個很是不錯的解決方案。但這並非打造一個強大團隊的基礎。其中的關鍵不只僅在於找到一羣聰明的人，同時要確保這些人是真正有激情去解決你要解決的問題的。若是這些人對要作的工做缺少真正的興趣和熱情，你可能在早期階段還能將工做完成的不錯，可是從長遠來看，你最終面對的將是一個個沒法全身心投入工做的員工和一個表現不佳的團隊。

　　6、你面試工程師的流程步驟是怎樣的？你爲何認爲這樣的流程步驟很重要？

　　咱們在 LendingHome 採用的工程師面試流程是很是直接的。第一步，面試官可能會對候選人人作一次電話面試。是否進行電話面試取決於：是咱們在積極挖一個比較被動的候選人，仍是候選人在積極地申請應聘咱們的崗位？若是是前面這種狀況，咱們就不會進行電話面試了。若是是後面這種狀況，咱們可能要作一輪電話面試。

　　最開始要進行一輪電話面試篩選，主要有兩個目的：

1. 爲候選人提供有關咱們公司和相應招聘崗位的相關信息。
2. 評估候選人的解決問題能力和編碼能力。

　　經過電話面試的候選人將會被邀請參加最後的現場面試。現場面試有有幾輪，要持續一成天時間，須要和 6 個面試官面試——3 個工程師、2 個技術經理（咱們會從總監、經理、VP、我本身和首席技術官中選取兩我的）和 1 個產品經理。我但願每個工程師招聘小組裏都能有一個非工程師人員，這樣咱們在招聘中就能得到一個徹底不一樣的看待候選人的視角。

　　在現場面試中，咱們要考察的內容包括專業能力、領導能力和行爲技能。專業能力考察內容包括架構、系統設計、解決問題的能力和編碼能力。我本身很是喜歡使用 STAR 法則來評估候選人的非技術方面的能力。

　　每一位面試官在面試結束後都須要在面試追蹤系統 Greenhouse 中填寫對應聘者的詳細評價和反饋。採用的是匿名評價的方式，這意味着你在評價以前是看不到其餘面試官對應聘者的評價的。而後，咱們會在應聘者現場面試結束後的當天，對每一位候選人進行 30 分鐘的總結評估，並決定是否給該候選人發 Offer。若是決定給 Offer，咱們就會盡快給候選人發出 Offer。

　　7、何時招聘產品 VP 合適？招聘什麼樣的產品 VP 合適？

　　這個問題主要看公司的發展階段，以及你想經過招聘一個產品 VP 來解決什麼樣的問題。根據公司和技術團隊規模的不一樣，產品 VP 的職責也會有所不一樣：

1. 在一家大公司，產品 VP 可能只負責一個特定業務線的產品工做。
2. 在一家小公司，產品 VP 可能會負責整個公司的產品工做。

　　要問答上面這個問題，須要根據各個公司的不一樣狀況。對於那些想招聘一個產品 VP 來負責公司的全部產品工做的公司而言，下面是個人建議。在公司發展初期，CEO 本身一般是公司的首位產品經理。隨着公司規模的發展壯大，其餘一些人開始以兼職的形式分擔部分產品工做。在創業公司，首先發展壯大的一般是工程師團隊，CEO 會與工程師團隊緊密協做。若是公司裏沒有一個技術聯合創始人的話，這時公司首先招聘的一般是一個技術 VP。招到技術 VP 後，CEO 可能會招聘一個全職的產品經理來作一些產品戰術方面的工做，好比制定產品說明書、與工程師協調等等，產品路線圖和產品願景仍是由 CEO 親自把控。在這個過程當中可能會陸續加入幾個產品經理，進而組成一個鬆散的產品團隊，這個團隊須要直接向 CEO 彙報。

　　這時，CEO 應該認識到，除了產品工做外，本身身上還要肩負起不少其餘職責，這時他們必須認識到必需要招聘一個產品 VP 了。一般狀況下，不少 CEO 都是被迫作出這個決定的，由於他們一般認爲本身是會一直負責產品方面的工做的。

　　若是你是公司 CEO，面對須要招聘產品 VP 的狀況時，你必須回答這樣一個關鍵問題：新招聘的產品 VP 是隻需負責執行 CEO 的指示、管理產品功能和產品經理團隊？仍是須要讓他來總體負責產品願景的把控和產品路線圖的制定工做？

　　這是一個很難回答的問題，你對於這個問題的答案將決定須要招聘什麼樣的產品 VP。做爲 CEO，你不該該本身獨自作這個決策，你須要向你的董事會、投資者、團隊中你信任的成員徵求意見。讓你們羣策羣力，看看到底是什麼樣的產品 VP 纔是真正知足公司的總體發展須要的。

　　8、你用來管理技術債的框架是什麼？

　　在很長一段時間裏，公司增加得很是快，也開始受到不少資源方面限制，所以，咱們積累了大量的技術債務。因此咱們已經重構了系統的幾個部分。是否要對系統進行重構，從而償還技術債，主要要看如下幾個方面：

1. 在系統不斷規模化擴展的過程當中出現的問題數量。
2. 維護這個系統的複雜性。
3. 須要將這個系統分解成獨立的、更易於管理的服務或系統。
4. 因爲系統中存在太多的相互依賴的地方，所以沒法快速開發系統中的某個部分。
5. 現有系統沒法知足日益增長的業務複雜性。

　　然而你還須要問本身下面這幾個問題：

1. 如何平衡好「爲了使業務向前發展而須要開發新的功能」 與 」對可能不會馬上帶來明顯效益的系統進行重構「這二者的關係？
2. 你在這兩個方面投入的資源佔比分別是多少？
3. 你是會在不影響系統正常工做的狀況下對其進行按部就班地改進，仍是會重寫系統並完全替換原有系統？

　　隨着時間的推移，咱們愈來愈擅長評估這些問題，但並非老是有一種可行的方法。舉個例子，咱們如今正在重寫一個項目，我想讓團隊並行地構建一個新系統去完全替換舊的系統。由於若是對原有的系統進行按部就班地改進，會花費太長時間，並且整個過程會讓人感到很是痛苦。於此同時，咱們還有一些正在進行的技術改進項目，按部就班地改進一些現有的系統。

　　9、你是否曾在面試過程當中使用過編碼測試？若是有，具體是怎麼測試的，爲何使用這種方法？

　　咱們確實在面試過程當中使用了編碼測試。咱們對編程語言沒有限制，候選人能夠選擇任何語言編寫代碼。咱們想要評估的是：

1. 他們是否能寫良好可行的代碼？
2. 他們是否能正確地解決手裏的問題？
3. 他們是否能進行良好的測試？
4. 若是代碼中有問題，他們是否會接受反饋？

　　進行編碼測試的時候，須要設置一個場景問題，這樣咱們就能夠評估應聘者是否能有效地解決問題。

　　10、在一個技術經理招聘比他本身更有經驗的人的時候，你有什麼建議？

　　理想狀況下，你僱傭的每個人都應該在某些方面比你作得更好。這也適用於招聘比你經驗更豐富的人。在招聘比你經驗更豐富的人時，你須要考慮的主要問題是你如何爲他們增長價值，以及你將如何從他們的經驗中受益。

　　瞭解這我的在哪方面可以爲你帶來價值，以及他能從你這裏獲得什麼幫助。例如，他們多是在技術上比你更好的工程師，在設計和構建複雜系統時不須要你提供任何幫助。可是，他們可能沒有你瞭解公司業務的相關背景、公司的客戶等。你能夠經過幫他們更快地熟悉全部這些東西來增長他們的價值，這樣他們就能更好地完成工做。相似地，你也能夠幫助他更好地瞭解公司的組織架構，從而更快地改善他們與其餘團隊的協做。

　　全部這些點在面試過程當中就應該提到，而不是在他們接受了這份工做以後才告訴他們。當他們的這些需求和利益獲得認可和知足時，說服他們加入就會更容易。

　　僱傭比你更有經驗的人的最重要的方面在於你能夠從他們那裏學到東西。必定要保持一個開放的心態，並對能從他們身上學到知識表示感謝。相信我，當你向他們學習的時候，你仍然會給他們增長價值，因此不要擔憂這點。在我職業生涯中的不少時候，我老是不得不僱傭比我更有經驗的人。我很是喜歡從他們那裏學習，若是沒有他們教給個人全部東西，就不會有今天的我。