一、你如何衡量軟件工程師個人的工作表現(xiàn)？如何衡量整個工程師團隊的工作表現(xiàn)？

　　主要從兩方面：

這個員工做的工作是不是他同意做的或者應(yīng)該做的？（What）

他們是如何完成自己的工作的？（How）

　　任何績效管理的最重要的前提就是針對這個人的合理期望達成共識，這里既包括顯性期望和隱性期望。顯性期望是指，要求對方在滿足特定要求的情況下在規(guī)定時間內(nèi)完成一個特定項目的交付。隱性期望是指，不管他們做什么項目，你對他們的表現(xiàn)所擁有的期待。

　　如果員工在負責開發(fā)一個功能，那么這里的“What”應(yīng)該包括以下幾個方面的內(nèi)容：

這個功能在產(chǎn)品中是否表現(xiàn)良好？

這個功能是不是按照規(guī)范開發(fā)出來的？

這個功能有沒有按時發(fā)布？

這個功能是否能滿足日后規(guī)模化擴張的需求？

　　這里的“How”應(yīng)該包括以下幾個方面：

他們是否與團隊中的其他成員進行了很好地合作？

他們有沒有因為走捷徑而開發(fā)了一個很難維護的系統(tǒng)？

他們是否遵循了所有正確的步驟并開發(fā)了可擴展的耐用產(chǎn)品？

他們是否在工作過程中破壞了其他人的系統(tǒng)？

他們在做自己的工作時有沒有指導(dǎo)別人?

他們在這個過程中是否學(xué)到了一些新的東西？

他們是否具有創(chuàng)新意識，并能以一種創(chuàng)新的方式解決問題？

他們是否強制將之前的解決方案應(yīng)用于新的、完全不同的問題上？

　　你可以使用類似的方法來評估整個團隊的表現(xiàn)。在評估團隊的表現(xiàn)時，你可以問下面這兩個問題：

這支團隊是否交付了他們應(yīng)該交付的工作成果？

你今后是否愿意再讓他們今后以相同的工作方式完成類似的工作？

二、你的工程團隊成員的角色和職責分工是怎樣的？你有指定專門的軟件架構(gòu)師或技術(shù)主管嗎？

　　我首先需要說明的是，我不喜歡在團隊中擁有指定的架構(gòu)師角色或明確的架構(gòu)師頭銜。我認為，設(shè)計一個系統(tǒng)是所有工程師的責任，所有工程師都必須負責開發(fā)和維護這個系統(tǒng)，而不是讓某一個個人或團隊來專門負責并讓他們在那光指揮別人做事而不自己親自開發(fā)這個系統(tǒng)。

　　我知道這么說可能會得罪很多架構(gòu)師領(lǐng)域的朋友，但是我還是要說。我之前在大公司里有過親身體會。舉個例子，Intuit 擁有一個非常強大的架構(gòu)師團隊，也擁有非常成熟的架構(gòu)師職業(yè)發(fā)展通道，我知道這群人中有一些非常出色的人才，包括 Intuit 現(xiàn)在的首席架構(gòu)師。然而，Amazon 是沒有架構(gòu)師這個職位頭銜的，作為一個工程師，你可以走 IC 這個職業(yè)發(fā)展通道，或者技術(shù)管理的職業(yè)發(fā)展通道，不管你選擇哪一種，你都需要能夠負責設(shè)計非常龐大和復(fù)雜的系統(tǒng)。

　　我打造和運營的每一家公司和每一個團隊采用的都是第二種方式。當然，任何時候都需要有人來負責架構(gòu)方面的責任，但我希望這個人是工程團隊的一名能自己親自寫代碼的成員。

　　現(xiàn)在再說說技術(shù)主管。在我看來，“技術(shù)主管”應(yīng)該是人們所應(yīng)承擔的一個職責，而不應(yīng)該是一個具體的職位等級。

　　對于我自己而言，技術(shù)主管意味著需要在一個項目上領(lǐng)導(dǎo)其他工程師（而不是單純的人員管理工作），既要在技術(shù)決策上發(fā)揮領(lǐng)導(dǎo)作用，也要在不同成員之間的分工協(xié)作上發(fā)揮領(lǐng)導(dǎo)作用。

　　我不認為必須要達到一定的職位級別才能成為一個項目的技術(shù)主管。例如，只要有能力，即使是一名只有一年工作經(jīng)驗的工程師也可以領(lǐng)導(dǎo)一個由一個或多個工程師/實習生參與的項目。我的團隊中也有一些經(jīng)驗非常豐富的優(yōu)秀工程師，他們是思想領(lǐng)袖和專業(yè)領(lǐng)域的專家，但是卻不喜歡去領(lǐng)導(dǎo)其他人。因此，盡管技術(shù)主管中更多的是那些更資深的人員，但技術(shù)主管本身并不是一個職位等級。

　　在 LendingHome，我們在公司內(nèi)確定了不同的職位級別，并定義了每個級別所要承擔的角色和職責。在這方面，我們一直努力與行業(yè)的通常做法保持一致，這樣我們公司的職位級別和頭銜也能適用于其它優(yōu)秀的科技公司。我們公司提供了兩條職業(yè)發(fā)展路徑：一種是 IC 職業(yè)發(fā)展通道，另一種是技術(shù)管理職業(yè)發(fā)展通道。這樣你可以在不用做管理人員的情況下也能繼續(xù)在公司得到成長和晉升。

　　如果走技術(shù)路線，我們公司的工程師等級分為工程師、資深工程師、高級工程師、首席工程師、高級首席工程師、杰出工程師、高級杰出工程師。在級別上，他們與經(jīng)理、高級經(jīng)理、總監(jiān)、副總裁和高級副總裁是平行的。你在任何一個級別上都可以扮演一個首席架構(gòu)師或技術(shù)主管的角色。實際上，我希望每一個技術(shù)主管都能負責他們手里項目的架構(gòu)工作。

　　三、你用來確定產(chǎn)品優(yōu)先級的流程是怎樣的？

　　每一年，我們在公司層面只設(shè)定少數(shù)幾個關(guān)鍵目標。然后根據(jù)公司的宏觀目標，每個業(yè)務(wù)線為自己制定未來 6 個月的階段性目標。然后，我們再制定符合半年目標的季度目標路線圖。這些路線圖就是我們定期沖刺的參照標準。就這樣，公司整年的宏觀目標被分解成一個個短期的目標。

　　制定路線圖總是從每個產(chǎn)品經(jīng)理開始，產(chǎn)品經(jīng)理負責制定一個需要與跨職能合作伙伴一起協(xié)作完成的優(yōu)先任務(wù)清單。我們將所有這些優(yōu)先任務(wù)清單整合到一起，并創(chuàng)建一個我們希望在下個季度完成的整體優(yōu)先任務(wù)清單。這個任務(wù)清單列表也包括我們上個季度延續(xù)下來的任務(wù)。

　　一旦我們就這些優(yōu)先任務(wù)清單達成一致之后，產(chǎn)品經(jīng)理與工程技術(shù)部門合作，對各個項目做大概的評估。工程技術(shù)部門也需要提供一個本季度的明確的工作目標。利用這種方法，團隊可以進行有效的權(quán)衡，并制定該季度最終的產(chǎn)品工作優(yōu)先級清單。這不是一個項目計劃，而是一個我們想要完成的任務(wù)清單。

　　我們就從這個優(yōu)先任務(wù)列表中選擇任務(wù)分別進行沖刺，并在整個季度持續(xù)執(zhí)行。我們努力在這里做足前期調(diào)研工作，這樣我們就不需要在季度中途改變這個優(yōu)先任務(wù)清單。但是，如果出現(xiàn)了需要修改的東西，那么我們就強迫自己對優(yōu)先任務(wù)列表中的任務(wù)進行權(quán)衡取舍，而不是直接在列表中添加更多的任務(wù)條目。這說起來容易做起來難，但卻是至關(guān)重要的。

　　四、如何讓設(shè)計師完美地適應(yīng)產(chǎn)品開發(fā)流程？如果能在項目早期就讓設(shè)計師參與其中、同時又不會浪費設(shè)計師的時間？

　　在理想狀態(tài)下，在公司業(yè)務(wù)的各項不同的產(chǎn)品工作中都應(yīng)該有設(shè)計主管或指定的設(shè)計人員參與其中。這個設(shè)計主管應(yīng)該在項目早期階段就參與其中，這樣他們就可以在整個項目進行的過程中從設(shè)計團隊中為該項目獲取所需的其它資源。

　　我們過去遇到的挑戰(zhàn)是我們的設(shè)計團隊中沒有足夠多的人員來肩負起這樣的角色。我們的目標是建立起這樣一種架構(gòu)，讓設(shè)計團隊能盡早參與到所有項目中去。但是這也要看項目的性質(zhì)，例如，我們不希望讓設(shè)計師參與到一些專注于純粹的后端服務(wù)和基礎(chǔ)設(shè)施的項目中。但是另一方面，對于那些直接面向客戶的項目，尤其是那些與品牌、營銷和應(yīng)用流程直接相關(guān)的項目，我們應(yīng)該在項目剛開始的時候就讓設(shè)計師參與其中，而且通常情況下都會有多個設(shè)計人員同時參與其中。

　　如果你已經(jīng)將項目人員數(shù)量降到了最低，你就不應(yīng)該擔心浪費設(shè)計師的時間。

　　這里需要著重強調(diào)的一點是，我不認為設(shè)計是純粹的外觀和視覺設(shè)計。如果是純粹的外觀和視覺設(shè)計，完全可以等到項目后期階段、在所有其它重要工作都完成之后再做設(shè)計方面的工作。對我而言，設(shè)計是一項非常宏觀的工作，它涉及到幾個方面的工作：交互、調(diào)研、視覺等等。要想不浪費設(shè)計師的時間，最好的方式就是在每一個階段讓合適的人員加入進來，而不是在每一個階段讓所有人都參與進來。例如，當需求還沒有確定的時候，我是不會讓視覺設(shè)計師參與進來的。但是，我會盡早地讓交互設(shè)計師參與進來，因為他們可以在早期定義需求和解決方案的時候發(fā)揮很大的作用。

　　五、在打造工程技術(shù)團隊的過程中，有哪些常見的錯誤想法？

　　常見的錯誤想法有很多，我這里主要強調(diào)以下三個常見的錯誤想法：

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

　　你應(yīng)該始終努力招聘比你自己更聰明的人加入團隊。但是，把一群聰明人放在一起不一定就能組成一支高效牛逼的團隊。要想打造一支真正高效的團隊，你需要一群真的愿意在一個團隊中共事合作的聰明人，而且這些人需要關(guān)心團隊的成功勝過自己的成功。

　　解決后面這個問題比招到聰明人要困難得多，而這也是決定你的團隊能否成功的關(guān)鍵因素。因此光招聘一群聰明人是不夠的。為了確保加入團隊中的人都是具有團隊合作意識的人，你可以在面試中使用 STAR 法則（Situation-情形、Task-任務(wù)、Action-行動、Result-結(jié)果），因為你可以通過根據(jù)應(yīng)聘者過去的行為表現(xiàn)來預(yù)測他未來的表現(xiàn)。如果一個應(yīng)聘者在之前的工作中并沒有表現(xiàn)出能夠和團隊成員很好協(xié)作的一面，或者沒有表現(xiàn)出團隊的利益和成功是高于個人的利益和成功的，這時，如果你招他進來，他在未來的工作中很有可能會有類似的表現(xiàn)。

　　2、只招聘那些與你自己或團隊中其他人員很像的人員。

　　我曾經(jīng)非常希望能夠多克隆幾個我團隊中的一些非常出色的人員。幸運的是，對于我來說這個選項是不存在的。

　　因為，如果我真的克隆了很多團隊中最出色的人，讓團隊中的所有人都差不多，這只會讓團隊喪失想法的多樣性，最終喪失了所有的創(chuàng)新能力。經(jīng)驗和思想的多樣性是激發(fā)新的、創(chuàng)造性的解決方案的源動力。從長遠來看，一個多元化的團隊將會變成一個更好、更強大的團隊。

　　3、將一群聰明人放在一起，他們就能解決任何問題。

　　很抱歉又強調(diào)了一遍這個問題，但是在某種程度上，這確實是事實。聰明的人喜歡解決富有挑戰(zhàn)性的問題，他們往往會能夠想出一個非常不錯的解決方案。但這并不是打造一個強大團隊的基礎(chǔ)。其中的關(guān)鍵不僅僅在于找到一群聰明的人，同時要確保這些人是真正有激情去解決你要解決的問題的。如果這些人對要做的工作缺乏真正的興趣和熱情，你可能在早期階段還能將工作完成的不錯，但是從長遠來看，你最終面對的將是一個個無法全身心投入工作的員工和一個表現(xiàn)不佳的團隊。

　　六、你面試工程師的流程步驟是怎樣的？你為什么認為這樣的流程步驟很重要？

　　我們在 LendingHome 采用的工程師面試流程是非常直接的。第一步，面試官可能會對候選人人做一次電話面試。是否進行電話面試取決于：是我們在積極挖一個比較被動的候選人，還是候選人在積極地申請應(yīng)聘我們的崗位？如果是前面這種情況，我們就不會進行電話面試了。如果是后面這種情況，我們可能要做一輪電話面試。

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

為候選人提供有關(guān)我們公司和相應(yīng)招聘崗位的相關(guān)信息。

評估候選人的解決問題能力和編碼能力。

　　通過電話面試的候選人將會被邀請參加最后的現(xiàn)場面試。現(xiàn)場面試有有幾輪，要持續(xù)一整天時間，需要和 6 個面試官面試——3 個工程師、2 個技術(shù)經(jīng)理（我們會從總監(jiān)、經(jīng)理、VP、我自己和首席技術(shù)官中選取兩個人）和 1 個產(chǎn)品經(jīng)理。我希望每一個工程師招聘小組里都能有一個非工程師人員，這樣我們在招聘中就能獲得一個完全不同的看待候選人的視角。

　　在現(xiàn)場面試中，我們要考察的內(nèi)容包括專業(yè)能力、領(lǐng)導(dǎo)能力和行為技能。專業(yè)能力考察內(nèi)容包括架構(gòu)、系統(tǒng)設(shè)計、解決問題的能力和編碼能力。我自己非常喜歡使用 STAR 法則來評估候選人的非技術(shù)方面的能力。

　　每一位面試官在面試結(jié)束后都需要在面試追蹤系統(tǒng) Greenhouse 中填寫對應(yīng)聘者的詳細評價和反饋。采用的是匿名評價的方式，這意味著你在評價之前是看不到其他面試官對應(yīng)聘者的評價的。然后，我們會在應(yīng)聘者現(xiàn)場面試結(jié)束后的當天，對每一位候選人進行 30 分鐘的總結(jié)評估，并決定是否給該候選人發(fā) Offer。如果決定給 Offer，我們就會盡快給候選人發(fā)出 Offer。

　　七、什么時候招聘產(chǎn)品 VP 合適？招聘什么樣的產(chǎn)品 VP 合適？

　　這個問題主要看公司的發(fā)展階段，以及你想通過招聘一個產(chǎn)品 VP 來解決什么樣的問題。根據(jù)公司和技術(shù)團隊規(guī)模的不同，產(chǎn)品 VP 的職責也會有所不同：

在一家大公司，產(chǎn)品 VP 可能只負責一個特定業(yè)務(wù)線的產(chǎn)品工作。

在一家小公司，產(chǎn)品 VP 可能會負責整個公司的產(chǎn)品工作。

　　要問答上面這個問題，需要根據(jù)各個公司的不同情況。對于那些想招聘一個產(chǎn)品 VP 來負責公司的所有產(chǎn)品工作的公司而言，下面是我的建議。在公司發(fā)展初期，CEO 自己通常是公司的首位產(chǎn)品經(jīng)理。隨著公司規(guī)模的發(fā)展壯大，其他一些人開始以兼職的形式分擔部分產(chǎn)品工作。在創(chuàng)業(yè)公司，首先發(fā)展壯大的通常是工程師團隊，CEO 會與工程師團隊緊密協(xié)作。如果公司里沒有一個技術(shù)聯(lián)合創(chuàng)始人的話，這時公司首先招聘的通常是一個技術(shù) VP。招到技術(shù) VP 后，CEO 可能會招聘一個全職的產(chǎn)品經(jīng)理來做一些產(chǎn)品戰(zhàn)術(shù)方面的工作，比如制定產(chǎn)品說明書、與工程師協(xié)調(diào)等等，產(chǎn)品路線圖和產(chǎn)品愿景還是由 CEO 親自把控。在這個過程中可能會陸續(xù)加入幾個產(chǎn)品經(jīng)理，進而組成一個松散的產(chǎn)品團隊，這個團隊需要直接向 CEO 匯報。

　　這時，CEO 應(yīng)該認識到，除了產(chǎn)品工作外，自己身上還要肩負起很多其他職責，這時他們必須認識到必須要招聘一個產(chǎn)品 VP 了。通常情況下，很多 CEO 都是被迫做出這個決定的，因為他們通常認為自己是會一直負責產(chǎn)品方面的工作的。

　　如果你是公司 CEO，面對需要招聘產(chǎn)品 VP 的情況時，你必須回答這樣一個關(guān)鍵問題：新招聘的產(chǎn)品 VP 是只需負責執(zhí)行 CEO 的指示、管理產(chǎn)品功能和產(chǎn)品經(jīng)理團隊？還是需要讓他來整體負責產(chǎn)品愿景的把控和產(chǎn)品路線圖的制定工作？

　　這是一個很難回答的問題，你對于這個問題的答案將決定需要招聘什么樣的產(chǎn)品 VP。作為 CEO，你不應(yīng)該自己獨自做這個決策，你需要向你的董事會、投資者、團隊中你信任的成員征求意見。讓大家群策群力，看看究竟是什么樣的產(chǎn)品 VP 才是真正滿足公司的整體發(fā)展需要的。

　　八、你用來管理技術(shù)債的框架是什么？

　　在很長一段時間里，公司增長得非常快，也開始受到很多資源方面限制，因此，我們積累了大量的技術(shù)債務(wù)。所以我們已經(jīng)重構(gòu)了系統(tǒng)的幾個部分。是否要對系統(tǒng)進行重構(gòu)，從而償還技術(shù)債，主要要看以下幾個方面：

在系統(tǒng)不斷規(guī)模化擴展的過程中出現(xiàn)的問題數(shù)量。

維護這個系統(tǒng)的復(fù)雜性。

需要將這個系統(tǒng)分解成獨立的、更易于管理的服務(wù)或系統(tǒng)。

由于系統(tǒng)中存在太多的相互依賴的地方，因此無法快速開發(fā)系統(tǒng)中的某個部分。

現(xiàn)有系統(tǒng)無法滿足日益增加的業(yè)務(wù)復(fù)雜性。

　　然而你還需要問自己下面這幾個問題：

如何平衡好“為了使業(yè)務(wù)向前發(fā)展而需要開發(fā)新的功能” 與 ”對可能不會立刻帶來明顯效益的系統(tǒng)進行重構(gòu)“這兩者的關(guān)系？

你在這兩個方面投入的資源占比分別是多少？

你是會在不影響系統(tǒng)正常工作的情況下對其進行循序漸進地改進，還是會重寫系統(tǒng)并徹底替換原有系統(tǒng)？

　　隨著時間的推移，我們越來越擅長評估這些問題，但并不是總是有一種可行的方法。舉個例子，我們現(xiàn)在正在重寫一個項目，我想讓團隊并行地構(gòu)建一個新系統(tǒng)去徹底替換舊的系統(tǒng)。因為如果對原有的系統(tǒng)進行循序漸進地改進，會花費太長時間，而且整個過程會讓人感到非常痛苦。于此同時，我們還有一些正在進行的技術(shù)改進項目，循序漸進地改進一些現(xiàn)有的系統(tǒng)。

　　九、你是否曾在面試過程中使用過編碼測試？如果有，具體是怎么測試的，為什么使用這種方法？

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

他們是否能寫良好可行的代碼？

他們是否能正確地解決手里的問題？

他們是否能進行良好的測試？

如果代碼中有問題，他們是否會接受反饋？

　　進行編碼測試的時候，需要設(shè)置一個場景問題，這樣我們就可以評估應(yīng)聘者是否能有效地解決問題。

　　十、在一個技術(shù)經(jīng)理招聘比他自己更有經(jīng)驗的人的時候，你有什么建議？

　　理想情況下，你雇傭的每一個人都應(yīng)該在某些方面比你做得更好。這也適用于招聘比你經(jīng)驗更豐富的人。在招聘比你經(jīng)驗更豐富的人時，你需要考慮的主要問題是你如何為他們增加價值，以及你將如何從他們的經(jīng)驗中受益。

　　了解這個人在哪方面能夠為你帶來價值，以及他能從你這里得到什么幫助。例如，他們可能是在技術(shù)上比你更好的工程師，在設(shè)計和構(gòu)建復(fù)雜系統(tǒng)時不需要你提供任何幫助。但是，他們可能沒有你了解公司業(yè)務(wù)的相關(guān)背景、公司的客戶等。你可以通過幫他們更快地熟悉所有這些東西來增加他們的價值，這樣他們就能更好地完成工作。類似地，你也可以幫助他更好地了解公司的組織架構(gòu)，從而更快地改善他們與其他團隊的協(xié)作。

　　所有這些點在面試過程中就應(yīng)該提到，而不是在他們接受了這份工作之后才告訴他們。當他們的這些需求和利益得到承認和滿足時，說服他們加入就會更容易。

　　雇傭比你更有經(jīng)驗的人的最重要的方面在于你可以從他們那里學(xué)到東西。一定要保持一個開放的心態(tài)，并對能從他們身上學(xué)到知識表示感謝。相信我，當你向他們學(xué)習的時候，你仍然會給他們增加價值，所以不要擔心這點。在我職業(yè)生涯中的很多時候，我總是不得不雇傭比我更有經(jīng)驗的人。我非常喜歡從他們那里學(xué)習，如果沒有他們教給我的所有東西，就不會有今天的我。

轉(zhuǎn)載于:https://www.cnblogs.com/lurenjiashuo/p/7865370.html

總結(jié)

以上是生活随笔為你收集整理的[转]资深CTO：关于技术团队打造与管理的10问10答的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。