多次創業皆全身而退，資深CTO為你詳解創企最難解決的12大困惑

【獵雲網（微信號：ilieyun）】11月25日報道（編譯：堆堆）

上周，我們採訪了LendingHome的首席技術官Adil Ajmal，這是一家員工人數達到300人、變革貸款行業的出色創企。在採訪中，他分享了自己是如何為團隊挑選最優秀的工程師的。

在建立和管理實力雄厚工程團隊的問題上，Ajmal給出了很多高明的建議，這著實讓我們感到震驚。Ajmal的經歷可以說是非常傳奇。他是我們認識的人中唯一一位在7家公司成功將小型工程團隊打造成大型團隊的人。他在TenMarks任職首席技術官和工程部高級副總裁一職，後來公司被亞馬遜收購了。他還在Posterous（後被Twitter收購）以及Homestead（後加入Intuit）等公司任職過。如今，他任職於LendingHome。除工程以外，他還負責產品、設計、數據科學。

為了便於更多創業者從Ajmal的經驗中加以學習，我們邀請他參加了「問我任何事」（AMA）這種新型問答方式。他給出的建議高質且明確，因此我們想要和更多在創業的人進行分享。我們列出了Ajmal在AMA中回答的問題以及他對於12個難題的回復——這12個問題是我們常年聽很多創始人和技術型領導者提到的。

1.如何衡量工程師的績效？

2.工程團隊的角色和責任是什麼？

3.如何確定產品優先順序的順序？

4.何時將設計融入開發？

5.關於工程團隊組織架構的常見錯誤觀念有哪些？

6.工程師面試流程？

7.何時要招募一個產品高級副總裁？

8.如何管理技術債務？

9.什麼值得全部重寫？

10.如何和非技術型部門共事？

11.如何在面試中採用編程測試？

12.如何招募到更有經驗的工程師？

1.你如何去衡量軟體工程師個人的績效表現？又該如何從團隊層面去衡量績效？

雖然工程師的職責與設計、營銷、產品等職能部門裡同事的工作大相徑庭，但是績效管理的基本原理卻是相同的。不管職能部門是什麼，團隊績效表現的衡量原理也是一樣的。儘管管理績效有很多框架方式，但在我看來，這歸根到底就是兩點：

1）他/她有無完成他們答應要做的事情或是負責人期待他們要完成的事情？（目標）

2）他們會怎樣去做這件事？（方式）

任何績效評估的關鍵前提在於，雙方對於該員工表現的期待值應當達成一致看法。這既包括顯性層面，也包括隱性層面。顯性層面包括基於某一些特定要求，要在一個特定的時間內上線項目。而隱性層面則包括不管項目如何，該員工在其工作角色中預期要做到什麼。

舉個例子，對於工程師來說，這可能是要求他寫出高質量、能夠通過測試的代碼。當你進一步深入了解項目的細節內容時，你就無需再去提醒他們代碼必須要保證質量。這一部分就是隱性層面的期待值。當有人開始著手工作、崗位發生變動或是進行績效檢查時，你應當就顯性和隱性期待值，向員工傳達清楚這些內容，雙方達成一致看法。

期待值的部分，合理是關鍵。舉個例子，如果你期待經驗相差較大的人完成同樣的工作量，那這就是不合理的。你可以期待一個有經驗的工程師負責好一個大項目、獨立設計以及建立一個複雜、可拓展的系統等等。與此同時，你不應當期待一個初級工程師去負責同類型大規模或複雜的項目。

因此，如果一個有經驗的工程師沒能很好地完成一個大型複雜項目，那麼他們也許是表現不佳。另一方面，如果一個初級工程師完成了高級工程師預期要完成的任務，那麼初級工程師的表現就屬於超出預期。我發現很多人都會忘記這一點，這就錯失了幫助員工成長的機會。當你和員工對工作期待值達成一致看法時，就「對象」和「方式」來衡量績效就變得很容易了。

但如果他們正在開發一個功能，那麼「對象」就應當包括以下這些內容：

1）這一功能在產品中是否運行順利？

2）該功能的開發是抱著投機的目的嗎？

3）它是否按時上線了？

4）它的規模是否合適？

「方式」的問題應當包括：

1）這名員工是否能和團隊其他成員合作密切？

2）他們是否採取捷徑、設計了一個無法維護的系統？

3）他們是否按照正確的步驟、開發可擴展且長久的產品？

4）他們能夠一直打敗別人的系統嗎？

5）他們是否會在完成自己工作的同時教導其他人？

6）他們一直以來有沒有學到點新知識？

7）他們是否是以一種新穎的方式創造性地解決了問題？

8）他們是否強行使用之前的方案來解決一個新的但卻性質不同的問題？

很多評估績效的經理關注的內容僅僅是「對象」——其實「方式」也同樣重要。如果一位工程師上線的產品很出色，但他卻是浪費了很多人力或資源才做到這一點的話，那麼我是不會給他很高的評價（從個人層面來說）。

你可以用類似的方式衡量一個團隊的績效。尤其是，你可以詢問這些問題：

1）他們是否完成了預期要實現的目標？

2）他們做事的方式是否會讓你想和他們在類似的任務上繼續合作？

2.工程團隊的角色和責任是什麼？你的團隊擁有指定的軟體架構師嗎？技術負責人呢？

坦白說，我對於在團隊中設置一個指定架構師的角色或是一個明確的架構師頭銜並不感興趣。我相信，系統架構的設計是所有打造以及維護這個系統的工程師的責任，這並非是某一個人的責任或一個團隊的責任（後者指的是那些只會告訴別人去做什麼、但自己根本不參與系統構建的人）。

我知道這句話也許會冒犯一些我的架構師朋友。我在大公司任職的經歷讓我了解了架構師問題的兩個極端。舉個例子，Intuit擁有一個非常強大的架構師社區，公司還為架構師制定了成熟的職業生涯規劃，我也認識一些很厲害的架構師——其中一位是公司的首席架構師。另一方面，亞馬遜則完全沒有設置架構師的崗位。作為工程師，你也許會選擇集成電路或工程管理髮展路線，但是不管是哪個方向，你都要負責設計大型複雜的系統。

我建立或管理的每一個團隊都選擇的是後者。但請不要將其理解為是什麼委員會式的架構——我個人是抵制這種的。有人需要擔起領導架構的責任，但是我希望這個人能夠是工程團隊里可以做出實際編程貢獻的人。

關於技術負責人：「技術負責人」應當是一個人所具備的功能或肩負的責任，而不是特定的職位級別。

對我來說，這就意味著在技術決策以及團隊成員協調工作的問題上，技術負責人需要領導項目里其他的工程師。

我不認為你必須到達某一個層級才能成為項目的技術負責人。舉個例子，就算是第一年工作的工程師也可以領導一個項目，只要他們有能力就行。我的團隊里也有一些非常有經驗的工程師，他們都是思想領袖或是一些問題上的專家，但他們不願意領導別人。所以，儘管資歷高的人更可能會成為技術負責人，但這本質上並不是一種職務級別。

在LendingHome，我們明確了公司內不同的職務級別以及每個級別對應的角色和責任。我們多方努力，試圖保證公司與大行業保持一致，這樣其他優秀的科技公司也能輕鬆理解我們的職務級別和頭銜。我們的工程團隊也分為兩種成長途徑：一種是集成電路，一種是工程管理。在公司里，你不必成為經理才能獲得晉陞。

我們的工程師層級是工程師、高級工程師、主管工程師、首席工程師、高級首席工程師、傑出工程師以及高級傑出工程師。從主管工程師級別往後，這就相當於是經理、高級經理、總監、副總裁以及高級副總裁。你也許是上述職務層級中任何一個級別，這樣你就可以擔任架構負責人或技術負責人的角色。事實上，我期待的是技術負責人能夠負責項目的架構。就組織結構來說——這不同於職務級別以及角色——我們的工程和產品團隊將被細分為三個高級別聚焦領域：獲取和消費者體驗、起源平台、投資者管理。

上述三個領域都是由大團隊組成，每個領域都有自己的子團隊。我們之前也嘗試過不同的變體，比如說基於公司所處的不同發展階段，依據業務線或是完全按照大方案進行安排等。我認為我們現有的組織結構是非常高效的，短期時間內它也不會變成公司發展的阻礙。這實際上意味著，我根本不知道什麼完美的組織結構。不管你如何定義它，這些結構都會存在各自的優缺點。

當你在規劃組織結構時，你需要明確自己要解決的問題以及如何應對一些不可避免的負面因素。

3. 你是如何確定產品優先順序的順序的？

每年，我們只會設定幾個關鍵的公司目標。這幾個大目標之下是每個業務線為自己設定的為期六個月的目標。之後，我們會按照這些目標創建每季度的路線規劃圖。這些路線圖會推動我們平時的做事進程。在這種方式下，所有事情都是基於公司一整年需要完成的目標細分出來的。

創建我們的路線規劃圖通常開始於產品經理列出目標優先順序，這是他們想和跨職能合作夥伴一同實現的目標。我們將這一切同業務線整合在一起，按序創建出下一個季度我們想要完成的目標。這通常還會包括上一個季度就一直在做的事情。

一旦我們對優先順序順序達成一致意見，產品經理就會和工程部進行合作，對於優先順序最高的項目進行「T恤尺寸」的估計（即小、中等、大或超大碼的估計）。工程部也會為每個季度提供清晰的生產能力數據。利用這兩樣工具，團隊就可以具體討論平衡利弊的有效方法並且為本季度設定最終的產品優先順序。這並非是一個項目計劃，而是要列出我們想要實現的目標。

我們會從這份列表中挑選目標來完成，整個季度都會持續這樣做。我們會做好盡職調查，這樣我們就不會在季度中期過多修改這份列表。但如果必須要進行調整的話，那麼我們就會迫使自己在列表中進行權衡，而不是僅僅往裡面添加更多的項目。這一點說起來容易做起來難，但這卻是非常重要的一環。記住，交易從來都不是公平的。

4. 如何將設計完美融入到產品開發流程呢？如何在不浪費時間的情況下將設計儘早融入到項目里呢？

理想狀態下，設計團隊里應當安排設計負責人來負責系統和業務的不同部分。這些負責人應當在早期就參與到項目中，這樣他們才能夠從團隊中按需調動資源。

過去我們面臨的挑戰是設計團隊里沒有足夠的人可以擔任領導人/協調人的角色。我們的目標是建立起這樣的組織結構，這樣設計團隊才能發展。設計應當儘早融入項目——但是這一時間取決於項目的本質。舉個例子，我們的部分工程項目如果是專註於後端服務和基礎設施的話，我們在任何階段都不會想將設計融入其中。另一方面，如果項目是面向顧客的話——尤其是關係到品牌、營銷、應用流程等，我們就應在項目開始之初就融入設計。通常，設計團隊里會有很多人在早期就參與到這類型的項目中。

如果你將參與人數減小到最低，那你就不用擔心會浪費設計團隊的時間了。

最糟糕的情況是，設計團隊的人員不會很認真得對待項目的一些重要信息。有一點必須要指出，我從不認為設計單單指的就是視覺方面，也不認為在其他事情都弄明白之後才需要將設計融入項目。在我看來，設計是整體性的，它包含很多方面：交互、研究、視覺等。不浪費設計團隊時間的最好方式就是要在合適的階段讓合適的人參與進來，而不是讓所有人參與到每一個階段中。舉個例子，當需求還不確定的時候，我就不會想讓視覺設計團隊參與其中。但是我會儘可能早得將交互設計納入其中，因為他們對早期確定需求和解決方案會產生很大影響。

5.建立工程團隊有哪些常見的錯誤認知？

我確信有很多錯誤的認知，但以下三種是我腦海中立即浮現出來的：

1）招募最聰明的人，將他們聚集在一起，你就能組建一支高績效的團隊。

你應當致力於招募那些比你聰明的人。但是僅僅將一群聰明的人聚集在一起還不足以組建成一支高績效的團隊。組建這種團隊需要的是一群聰慧的人真心誠意想要和團隊里其他人合作並且比在意自身還要多得關心團隊能否取得成功。

後者要比找到聰慧的人困難得多，但這正是團隊成功的關鍵。因此，你可以這麼說，聰慧僅僅只是一種籌碼。就第二部分來說，你可以在面試中採用STAR方法（情境、人物、行動和結果）——這種方法的前提在於，過去的行為是最能準確預測未來行為的工具。如果有人之前就不適合團隊協作或是有自私的表現，那麼他/她很有可能還會出現這種情況。

2）招募所有和團隊相像的人。

我曾經多次希望自己可以克隆出團隊里一些出色的成員。不過幸好還不存在這樣的可能。

如果我僅僅是克隆出團隊里最出色的人才，那麼最終團隊里大家的思維就不會存在任何不同，也就不會迸發出任何創意。經驗和思維的差異性才會催生新的、有創造性的解決方案。從長遠角度來說，一個有差異性的團隊才會成為一個出色且強大的團隊。

3）將一群聰慧的人聚集在一起，他們最終會解決任何問題。

每次說這句話我都心懷愧疚。在一定程度上，這句話其實是很正確的。聰慧的人喜歡解決具有挑戰性的問題，他們通常可以想出一個很好的解決方案。但這不是團隊強大的原因。關鍵在於，你召集的人不僅要聰明，還要對團隊試圖解決的問題懷揣熱忱。沒有真正的興趣和激情作為支撐，你也許能在早期階段完成一些工作。但從長遠角度來說，員工最終會變得閑散，團隊效率也很低。

6. 工程部面試流程是什麼？為什麼這些步驟很重要？

在LendingHome，我們的流程簡單明了。第一步，招聘人員會有選擇性得決定是否要對求職者進行電話面試。這取決於我們招募的人是否是一個被動型求職者或者說該求職者是否是積極申請的。

面試流程從一個手機屏幕開始，這有兩層目的：

1）向求職者介紹關於公司和崗位的相關信息。

2）評估求職者解決問題以及編程的能力。（我們會讓他們在CoderPad或者Collabedit上進行測試、寫出解決方案。）

通過手機屏幕測試的求職者會被邀請參加最終的現場面試。面試持續一整天時間，面試官有6位——三位工程師、兩個工程經理（我們會從總監、經理、副總裁以及首席技術官中挑選出兩位）以及一位產品經理（或是從設計、營銷等跨職能部門找到的一個合作夥伴）。我總是希望有一個非工程師角色的人加入工程師招聘小組中，從而提供一個與眾不同的視角，這也可以讓求職者有機會見見未來將會一同工作的、來自其他部門的人。

現場面試中，我們會嘗試考察工作能力、領導力以及行為技巧。技術方面包括架構、系統設計、解決問題以及編程能力。我非常熱衷於使用STAR方法來評估非技術性的技能。我是這麼考慮的，過去的行為是最能準確預測未來行為的工具。

小組內每一位面試官都會在求職者追蹤系統Greenhouse里錄入他們詳細的反饋。在輸入自己的意見之前，他們看不到其他人的反饋情況。之後，每位求職者會在現場面試當天被提問30分鐘時間，我們會決定是否要為其發放工作offer。

如果我們在詢問過程中決定提前接受求職者，那麼我們很快就會為其發放offer。有些時候，offer的發放會取決於背景調查，但這多是為高級崗位準備的。

7. 何時應僱傭產品高級副總裁？你應當關注哪方面？

這一問題主要取決於公司所處的發展階段以及你想通過引進一位產品高級副總裁來解決什麼問題。公司規模以及技術部門不同，那麼高級副總裁的角色也會包含不同的內容：

1）在一個較大的部門內，高級副總裁只需要負責某一個職能部門或業務線的產品。

2）在較小的公司或部門內，產品高級副總裁就需要引領整個公司的願景和運營——未來成為首席產品官。

回答這個問題確實依賴於這些細節，但如果有公司想要通過引進第一位產品高級副總裁，從而讓其管理公司所有的產品部門，那麼我可以就這個問題提供另一種答案。

很早之前，首席執行官通常會擔任公司首位產品經理的職責。之後，隨著公司發展壯大，其他人也偶爾會肩負起產品經理的職責。工程團隊通常是第一個發展起來的團隊，它和首席執行官聯繫密切。如果公司不存在技術型聯合創始人的話，那麼公司第一位要僱傭的高管就是工程高級副總裁。之後，首席執行官會引進一位全職產品經理來完成戰術方面的工作，比如說設定規格、協調工程師等等——這仍然要基於首席執行官的產品願景。這並不是一個管理者的角色。有一些產品經理無法很好地融入團隊，團隊依舊要向首席執行官彙報工作。

此時，首席執行官應當感覺到公司內還有其他地方需要他們去負責管理。這時候，他們將意識到自己需要一個產品高級副總裁。

通常，許多首席執行官是被迫做出這樣的決定，因為他們通常認為自己會永遠負責管理產品。

如果你是一位需要負責管理產品的首席執行官，你應當問問自己這樣一個關鍵的問題：未來的產品高級副總裁在執行首席執行官命令的同時，是否只需要負責運營產品部門並且管理產品經理呢？還是說他們也可以有自己的產品願景、設定產品開發方向呢？

這實際上是一個非常困難的問題，答案將會決定你需要為這個崗位引進何種類型的人才。這不應當是你單方面的決策，從董事會、投資者、團隊信任的成員那裡徵求意見。你可以期待他們來明確產品高級副總裁的職責，從而使其最大程度有益於公司目標的實現。

8. 管理技術債務，你通常使用的是什麼框架？

這方面是我們仍然要改進的地方。有很長一段時間，我們發展速度非常快，資源受限，以至於累積了大量技術債務。自此，我們重構了系統內會受到以下屬性影響的部分：

1）系統擴大規模隨之帶來的問題數量

2）維護系統的複雜性

3）將這一系統拆分為獨立、更易管理的服務或系統的需求

4）由於相互之間太過依賴，以至於無法快速發展某一部分系統

5）現有系統無法滿足日趨複雜的業務

不過，之後也帶來了一系列的問題：

1）你該如何平衡業務發展帶來的新功能開發需求與不會立即帶來商業利益的現有系統重構需求？

2）你會給這兩者分別投資多少比例的資源？

3）你會在開發時逐漸優化系統還是會重寫代碼、然後全部替換掉舊系統？

一段時間之後，我們變得善於評估這些問題，但還沒有一個一直有效的方式。舉個例子，我們手頭上目前就有一個大型的重寫項目，我想讓團隊開發一個新系統來替換掉之前的——因為現有系統的逐步優化會花費太長時間、令人痛苦不已。與此同時，我們手頭上還有一些其他技術性的優化項目，它們可以改進現有的系統。

9. 你是如何決定有些事情太過費力、還不如重寫的呢？

我要重申一遍，這沒有什麼通用的辦法，但是通過評估以下兩個因素，這可以幫助你做出決定：

1）逐漸做一件事情的成本VS重新開發的成本。我通常會將這裡的成本理解為時間和辛苦程度，你也可以添加其他的因素。

2） 這項業務能夠擔負起你在一段時間內停止其他新項目開發帶來的影響嗎？

對大型重寫項目來說，當你在開發一個新的系統時，你同時去給舊的系統添加新功能，後者是毫無意義的——你需要停止或者減緩新功能開發的進程。否則，這不僅會花費兩倍的資源，還會不斷延遲你遷移到新系統的步伐。目前，你的業務能夠承擔這一成本嗎？

不要讓非技術型的人來決定第二個因素，因為他們的認知非常有限，他們是無法做出一個合理的決策的。而你作為工程負責人或團隊成員，必須要確保業務的合作夥伴充分了解其中的成本和利益平衡。

舉個例子，如果你只是要求他們在開發新功能或重寫項目之間進行抉擇，那麼他們的默認答案就是進行新功能開發，我也不會為此指責他們。畢竟在他們看來，這個答案是顯而易見的。

但是，如果你能真正讓他們了解不重寫項目會帶來的風險和成本損耗時——即系統會在未來幾個月時間內出現大規模崩潰、安全性會受到嚴重影響、可能導致公司關門大吉、工程師不願再留下來因為他們憎恨這個系統、你無法快速為新員工進行入職介紹、功能開發的速度開始減慢、產品支持需求不斷增加等等——他們在了解更多情況之後才會做出有依據的決策。

10. 你的技術部門是如何與公司內其他運營部門合作的？

全公司內，我們讓技術部門和其他不同的職能部門達成了密切的合作關係，包括運營部門，比如說貸款運營、銷售、資本市場等等。我們首先是安排了一個產品經理，他/她會負責同每個部門進行合作並且針對該職能部門設定產品路線規劃圖。

舉個例子，我們會單獨安排產品經理專註於顧客獲取、貸款管理（這個內容細分下還有很多子職能部門，會由多個產品經理負責）、服務、投資管理等等。這些產品經理會和團隊密切合作、跟著他們學習技能、認同並且接受他們的需求和痛點，然後利用這一切來明確合適的產品功能和優先順序順序。

我們每周還會和公司內不同職能部門進行會面，參會人包括產品經理、工程經理和總監、跨職能部門的合作夥伴，有時候還包括業務線的總經理。會議是要了解產品開發的最新情況、剛上線的內容等等。但是其主要目的還是要明確該職能部門的需求、確定解決方案和項目的優先順序順序。

一些情況下，當我們推出大量內部工具時，產品團隊就會為公司的運營團隊提供培訓。我們還會採用一個正式的流程來接收運營人員的運行支持需求。如果最終發現問題是技術方面的，那麼負責此問題的工程師就會和有疑問的運營團隊成員直接聯繫。

當我們在開發新功能時，產品經理和工程師正與運營團隊成員合作確定合適的解決方案，這時也會出現相同的情況。對於小型團隊來說，我們會提供Slack渠道讓其和工程師、產品經理以及團隊成員進行溝通。這種渠道在一段時間內是有效的，但是當你發展成為大規模團隊時，Slack協作工具是無法擴展的（比如說我們的貸款運營和銷售團隊）。最終，我們需要推出一個更加正式的溝通流程。

儘管說了這麼多，但實際上技術團隊和運營團隊之間的合作關係並非一直是這樣和和美美的，有些時候情況也會基於不同的非技術型團隊發生改變。這很大程度上取決於非技術型團隊是否會認為技術團隊是為他們服務的部門——他們可以直接下達指令，抑或是他們是否認為自己是技術團隊的合作夥伴，雙方可以共同解決問題。我們的目標通常是後者，現階段我們已經很接近這種狀態了。人們曾嘗試過前者，結果通常不太順利，且成本花費極高。

11. 你有沒有在面試過程中採用編程測試？如果有，你是採用什麼方式？又是為何如此呢？

我們確實會在面試中採用編程測試。我們是語言不可知論者，求職者可以按照自己選擇的編程語言編寫代碼。我們試圖評估的是他們能否：

1）寫出運行順利的代碼

2）考慮到極端情況

3）正確解決手頭上的問題

4）編寫出色的代碼測試

5）在代碼出錯時接受反饋意見

編程測試本身不會非常複雜。在此之前，我們會讓其解決一個問題，從而用此來評判求職者能否高效解決問題。一旦他們通過了問題解決能力這一關，我們就會要求他們寫出自己剛剛解決的問題的代碼。

12. 就工程經理僱傭比自己經驗更豐富的人這件事上，你能否分享一些建議呢？

理想情況下，你僱傭的所有人都應當至少在一個方面比你出色。在我看來，這句話同樣適用於招募那些比你經驗更豐富的人。關鍵你要弄明白你可以如何為他們帶來更多價值、你又可以如何從他們的經驗中受益？

一個好的開始意味著你需要坦誠相待、確定合適的期待值。了解這個人在什麼地方會給團隊帶來價值以及他們從你的幫助中又能獲得什麼益處。舉個例子，也許有一個比你出色很多的工程師，在設計和開發複雜系統方面他不需要你的任何幫助。但是他們也許不像你那麼了解公司的業務、顧客、傳統系統等。你可以幫助他們熟悉這方面內容來為其帶來價值，這樣他們就可以更好地完成自己的工作。與之類似，你可以幫助他們了解公司架構，從而讓他們更快速地與其他團隊達成合作。

除了接受工作後需要考慮到的因素，你在招聘過程中也還需要留意幾點。當人們的需求和興趣得到認可之後，他們就會被說服並且從中得到一定慰藉。

僱傭比自己經驗更豐富的人，最神奇的一點其實在於你可以向他們學習。

對此別心懷芥蒂，在他們拓寬你知識面的時候記得表示感激。相信我，當你向他們進行學習時，你其實仍在為他們帶來價值，所以別擔心這一點。從我職業生涯早期開始，我一直負責領導團隊。這麼多年來，我時常需要僱傭一些比我經驗更為豐富的人。我非常喜歡從他們身上學習到新知識，如果不是他們教會我那麼多事，我可能現在也不會取得成功。

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