編者按：CTO、項目經理、軟體工程師……各種軟體開發相關的職位琳琅滿目，很多人並不清楚各個職位之間的共性和差異。需要清楚的是，國內的這些職位其實都是「舶來品」，大多是模仿矽谷技術企業而設立的。本文由外國專家撰寫，詳細分析了技術人員的職位職責和職業路徑。需要注意的是，本文針對的是國外的軟體開發行業，與國內環境略有不同。編譯自medium原題為Software Roles and Titles的文章，作者Eric Elliott。
近來，我注意到在業內對很多與「軟體」相關的職位存在很多角色和頭銜方面的混淆，即使是公司創始人、招聘經理或者團隊建設者都很容易分辨不清。今天我們就來談一下，軟體團隊中各種職位的角色和職責分別是什麼，以及哪些職位更傾向於涵蓋哪些角色。
在深入研究這個問題之前，我想強調的是，每個團隊都是獨一無二的，某種責任往往會在不同時間段在各個成員間浮動，或由團隊的不同成員共同承擔。任何人都可以出於各種原因將責任委託給其他人，畢竟每個團隊都有自己的運作方式。
如果你的團隊不完全符合我接下來的描述，也歡迎交流指正。事實上，我認為確實只有很少一部分團隊和特定軟體工作者的角色能夠與我們即將要探討的內容完美匹配——相比於特性，這只是一個更傾向於平均化的通用框架。
我將從管理職稱開始，按資歷由深至淺地分析各種角色。不過開始之前強調一點，永遠不要被你的職稱所束縛。在我看來，
技能比職稱重要；持續不斷有成果輸出比死盯截止日期重要；支持比責備重要；協作比競爭重要；總之，我喜歡以更高的責任來作為主動性的獎勵。如果某位員工有主動的意願和相應的技能去承擔超過他們頭銜的責任，我會更願意去提拔他，這是一個很不錯地培養潛力員工的機會。
下面進入正題。軟體開發角色包括：
工程院士CEOCTO首席信息官/首席數字官/首席創新官工程副總裁/工程總監首席架構師軟體架構師工程項目經理/項目經理技術主管/工程主管/團隊負責人首席軟體工程師高級軟體工程師/高級軟體開發人員軟體工程師軟體開發師初級軟體開發人員實習軟體開發人員我們還將討論這些角色與其他角色的關係，包括：產品管理副總裁/產品負責人產品經理營銷副總裁注意：有時也會有「主管」或「總監」等頭銜用來表示介於技術管理人員和「首席」之間的中層管理人員。 通常，「首席（Chief）」頭銜表示一套比較高級的職稱，高級管理人員通常會直接向執行長報告。 在非常大的公司中，「主管」或「總監」通常扮演著與高層管理人員類似的角色，區別在於他們是向相當於大公司中一個較小的業務單元的負責人（類似於這個單元內的CEO）進行匯報。不同的業務部門有時像獨立的公司一樣運營，完成自己部分的獨立會計工作，擁有自己部門專門的財務人員等。不同的業務部門也可以有副總裁，商務運營部的工程副總裁」。
工程院士
「院士」是軟體工程師成就的巔峰之作，它通常是為了表彰那些為計算機領域做出傑出貢獻的人而頒發的，並且通常在工程師撰寫一些暢銷書籍，獲得圖靈獎，諾貝爾獎等獎項後頒發。換句話說，院士通常在組織外已經很有名，此時公司試圖通過更有影響力的、值得敬仰的人來強化自身的品牌。
在我看來，組織不應該試圖聘請「院士」角色。相反，我認為應該去找到最好和最合適的人，僱用他們。如果工程師具有相應能力，再授予這份頭銜作為榮譽和獎勵。
一位工程院士通常還會在公司擔任另一個頭銜。通常是CTO、架構師、工程副總裁等。他們能夠領導、指導或作為組織其他成員的榜樣和靈感。
CEO
執行長是組織中最具有權威的職位。通常情況下，他們為公司設定了願景和目標。圍繞著對於公司使命、戰略和核心價值觀的共識，CEO將每一位員工團結在一起。
一般來說CEO也是公司的公眾形象，在某些情況下，還會成為品牌的代名詞（例如，Steve Jobs與Apple，Elon Musk與Tesla / SpaceX等）
在某些情況下，執行長也是軟體組織的技術創始人，在這種情況下，他們也經常擔任CTO角色，並可能擁有運營，銷售，戰略和營銷副總裁，幫助解決其他一些常見的CEO職責。當然，一家小公司的執行長經常頂著很多其他的頭銜。
無論如何，如果要做出重要的組織決策，責任的核心就在於CEO。
如果你是執行長，請記住：你最終要對自己負責。雖然你應該相信自己的直覺，但不要忘記，即使是大多數有名的CEO都會有定期諮詢的導師和顧問。因此，相信直覺的同時，也要尋找聰明、有見地的人來幫你尋求進步。
CTO
與CEO角色一樣，CTO角色隨著時間的推移而變化。在年輕的創業公司，CTO通常是有遠見或領域驅動的CEO的技術聯合創始人。他們通常還不具備在一家大公司獲得高級頭銜的資格，希望隨著公司的發展而成長。通常，創業公司首席技術官更喜歡更多技術工程師的角色，並同時兼任其他角色，如首席工程師，工程副總裁或首席架構師。
在許多組織中，成熟的CTO角色是面向外部的。他們參加業務發展會議，經常幫助建立大型合作夥伴關係或推廣銷售業務。他們中的許多人都會出席很多會議，花費很多時間將組織的發展活動傳播到更廣闊的世界：分享公司的創新，發現市場中與公司核心競爭力相匹配的機會。CTO經常與產品團隊在產品戰略上密切合作，並且通常會擔任工程方面面向內部的對應職位，例如工程副總裁。CTO還經常設定工程團隊的願景和目標。
首席信息官/首席數字官/首席創新官
首席創新官（CIO）跟CTO很類似，但通常由一家通常不被視為「科技公司」的公司僱用。首席信息官的目標是將公司重塑為消費者認為精通技術和創新的公司：向世界展示行業的未來。例如，家庭改造超市連鎖店可能有一位CIO負責與科技公司合作，建立一個混合現實應用程式，向購物者展示他們在客廳中特定的沙發或牆壁顏色，或使用區塊鏈和加密貨幣來增強供應鏈物流的安全性和效率。
不要把首席創新官（CIO）與首席信息官（CIO）混淆，後者通常用於那些更加脫離技術的公司，或者是只對某項技術感興趣、抑或是需要某種技術支持的公司。與首席創新官不同，首席信息官更有可能領導技術集成和數據遷移項目，而不是構建新的應用程式。首席信息官的行為更像首席創新官，但在我看來，他們根據不同的職責還是應該使用不同的頭銜。
工程副總裁/工程總監
雖然CTO經常面向外部，但工程副總裁往往面向內部。工程副總裁經常負責建立工程團隊並建立工程文化和運營。CTO可能會告訴工程團隊需要在大規模上完成哪些工作，例如「成為人/計算機互動的領先創新者」。工程副總裁則偏重於幫助培養管理「如何」的文化，最好的工程副總裁善於在無形中幫助團隊進行更有效工作。項目過程中，團隊中的開發人員協作良好，互相指導，有效溝通，所有人都覺得，「嘿，我們是一個偉大的團隊，我們在一起工作非常愉快！」大多數時候，團隊成員會認為這份順暢是一種「幸運的偶然事件」，自然而然就發生了。
事實是，這種情況幾乎不會自發地出現。之所以能有這份順暢，是因為工程副總裁會不斷監控團隊的進度、流程、文化和溝通基調。他們鼓勵開發人員使用某些工具，在特定時間舉行特定類型的會議，以便通過更少的中斷促進更好的協作。無論是功能失調的團隊還是功能強大的團隊，最好的工程副總裁是工程師，因為他們了解有效軟體開發工作流程的模式和反模式。
他們與產品和產品經理的負責人合作，以確保有一個良好的產品發現過程（他們不會引導它或負責它，只是確保有人在跟進並且做得好）；以及，產品在實施交接之前，工程師會對設計可交付成果進行充分的審查。
許多創業公司規模太小，無法聘請全職工程副總裁，但儘早建立起良好工程工作文化仍然非常重要。
首席架構師
在小型組織中，首席架構師可以成為技術聯合創始人。他們不太想承擔CTO偏向管理部分的職責。也許他們不喜歡到處出差，又或者是比起會議談話、業務發展和滲透到許多CTO生活中的銷售電話，他們只是單純對軟體設計更感興趣。 首席架構師可能負責選擇技術堆棧，設計計算系統之間的協作和接口，評估計算服務產品（AWS，Azure，ZEIT Now等）等。 首席架構師可以評估各種行業產品，並提供預先批准或贊成的建議，以便與特定供應商合作。
隨著公司的成熟，首席架構師可能還需要與CTO密切合作，有時還需要與夥伴組織合作來開發一些集成類的服務。 在許多公司，CTO也擔任首席架構師。
軟體架構師
軟體架構師需要實現首席架構師的許多目標，但通常負責較小的功能橫截面。軟體架構師經常與首席架構師合作，實施他們對更大建築願景的切面。軟體架構師經常為特定應用程式或功能選擇技術堆棧，而不是在整個公司範圍內做出決策。
工程項目經理/工程經理/項目經理
工程項目經理（也稱為「工程經理」或簡稱「項目經理」），負責管理工程團隊的工作流程。一些大公司同時擁有工程經理和項目經理。在這種情況下，工程經理通常在本地團隊範圍內扮演工程副總裁的角色，而項目經理則承擔此處所述的職責。
項目經理通常與產品負責人和工程副總裁（如工程副總裁，CTO或中層經理）進行交流，以添加或刪減工作細節，跟蹤項目流程，完成詳細的進度報告等。
最好的項目經理需要花費大量時間對問題和錯誤進行分類，以便分析每個特徵點的錯誤密度，導致最多錯誤（設計錯誤，規範錯誤，邏輯錯誤，語法錯誤，類型錯誤等）的指標等等。這些指標可用于衡量各種計劃的有效性，並指出可以對工程流程進行哪些改進。
工程經理需要充分了解各個團隊成員的優勢，並善於為相應的責任方分配工作單，但這應該是一項協作工作，尋求個別開發人員對他們的職業目標的反饋和他們想要關注的是，也在項目經理的工作範圍內。
如果存在時間壓力或工作積壓，項目經理應與工程和產品負責人合作，找出根本原因並儘快讓項目按計劃運行。
理想化的情況下，項目經理應該是唯一直接將任務委派給個別工程師，以避免「多個老闆」問題的人。工程師應該清楚地了解他們直接向誰報告，以及誰負責委派工作給他們。如果你是一名不同類型的工程領導者，並且你一般直接委派工作給工程師，那麼在你和工程師之間設置一位工程經理來進行協調並通過他們進行工作委派可能是一個好主意。
在非常小的組織中，工程經理通常也是由CTO和副總裁兼任。
一個常見的誤區是，由於工程團隊與產品團隊緊密合作，因此，工程經理會直接向產品經理報告。我看到過很多這樣的情況，這是一個錯誤。下文還會更詳細地探討這個問題。
技術主管/團隊負責人
技術主管或團隊負責人通常是少數開發人員的領導者。 他們通常是高級工程師，他們的行為就像團隊其他成員的導師，範例和指南。 通常，工程師向項目經理或工程經理報告，但技術負責人可能負責團隊的代碼質量把控，例如確保正在進行充分的代碼審查，以及確保團隊的技術標準（如TDD）。
工程師職業上升路徑
通常，工程師有以下兩種職業道路：進入管理層，或繼續走技術路線。
管理職位並不適合所有人。很多工程師都喜歡堅持技術道路。這種路徑可能會經歷多種方向、曲折和轉彎，整體看起來像這樣：
實習生——初級軟體開發人員——軟體開發人員/工程師——高級軟體工程師——首席軟體工程師——軟體架構師——高級軟體架構師——首席架構師——首席技術官——工程院士
而對於那些對人員領導角色感興趣的工程師，進展可能看起來像這樣：
實習生——初級軟體開發人員——軟體開發人員/工程師——團隊負責人/技術主管——工程經理/項目經理——高級工程經理——工程總監——工程副總裁
避免組織功能失調
IMO，工程副總裁，首席技術官，產品副總裁和營銷副總裁都應直接向執行長匯報。他們每個人都需要掌控自己這一部分的過程。面向外部的CTO不應該有直接的報告（如果他們這樣做，通常意味著他們正在填補CTO和工程角色副總裁）。相反，工程領導者應該向工程副總裁報告，這是為了避免「兩個老闆」的功能失調，也是因為這些角色根本不同：一個側重於客戶以及讓組織更加適應更廣闊的世界，一個側重於內部的日常運營。他們是兩種截然不同的技能組合，這些技能在每個人、每個職位上會有相互競爭的優先級。
我曾經看到過很多工程團隊的功能失調，就是因為他們混淆了哪些工程領導者應該對哪一塊業務負責，而這往往會導致災難。無論什麼樣是組織結構是適合你當下公司的，都需要確保責任和權限鏈清晰，以避免工程師在兩個或三個不同的「老闆」之間感到掙扎。
同樣，在規模足夠大的組織中，產品和工程需要由兩個獨立的團隊組成。也就是說，產品經理應該擁有產品路線圖，他們應該成為用戶的傳達者，他們應該真正深入挖掘用戶，並深入了解他們的工作流程和痛點。他們應該是市場需求的專家，他們應該非常熟悉公司滿足這些需求的優勢和能力。
換句話說，工程副總裁（或任何正在充當這一角色的人）需要負責交付和生產節奏。雖然產品經理應該擁有路線圖，但工程經理需要負責制定路線圖優先級，將其與工程能力相匹配，並報告時間安排。產品和營銷團隊對於什麼時候應該交付有強烈的意見，但只有工程管理層能夠根據路線圖要求很好地判斷這些交付時間表是否可行。工程團隊需要的權力不僅僅是縮短時間，而且在大多數情況下，要完全擁有時機，與CEO，產品和營銷團隊合作以確定優先級，了解公司的戰略需求，然後幫助塑造一個可以滿足這些需求的開發節奏。
我參與過的最佳表現團隊採取了無截止日期的方法。我們在不事先通知的情況下構建出色的產品，然後讓營銷團隊推廣已經完成的工作。
或者，當你在相對開放的環境中工作時，透明度是一個很好的解決方案。使用項目管理軟體積極分享你的進度，製作圖表來清楚地查看工作的進度、速度和剩餘範圍，以及隨時間變化做出相應的調整。就算項目無法按時交付，與項目相關的人也可以親眼看到實際的進程，階段性的成果相對容易接受。
目標、產品、營銷和工程常常是相互競爭的獨立角色，且需要直接向CEO報告。如果你的團隊有加班加點的壓力、或者最後期限之前匆匆忙忙地交付一些東西，那麼肯定是出於這兩個原因：要麼工程經理正在向錯誤的人報告，要麼團隊缺乏強大的工程領導者。一個強大的工程領導者，應該了解軟體估算的無效性以及工程和產品之間協作交換的必要性，以確保最小化目標的靈活性。
產品應該擁有持續的發現過程。工程應該擁有持續的交付流程。市場營銷應與產品團隊攜手合作，確保向更廣闊的世界傳達產品信息。整個事情應該像管道一樣融合在一起，創造一個平穩流動、積極的反饋循環。像流水線一樣，流程中最慢的瓶頸必須為流程的其餘部分設定步伐，否則會導致積壓項目不斷增加。
產品團隊如果感覺到項目進度有問題，則應首先關注項目交接質量。問自己這幾個問題：我們做過充分的設計審查嗎？工程師是否有機會在交接之前提供建設性的反饋？ 80％的軟體錯誤是由規範或UX設計錯誤引起的，其中許多錯誤可以在項目交給工程團隊之前捕獲。如果已經對該過程進行了精細調整，就要問問自己是否對產品進行了足夠充分的設計，包括這些問題：是否構建了一個UX並將其調用完成，或者嘗試了多種變體（構建和測試用戶工作流程的變體是產品團隊可以做出的最有價值的貢獻之一）？是否擁有一組可信賴的用戶來進行A / B測試？
軟體團隊最大的功能障礙之一，就是產品團隊生產低於標準的可交付成果（有時只是一些匆忙的、有缺陷的模型），並且在交付之前未能交由客戶或工程師測試。這種功能障礙導致了工作團隊的重複工作和工程積壓，這往往歸咎於工程團隊。
良好的開發團隊必須確保責任分配有意義，不給工程施加不必要的時間壓力，並且有一個優秀的產品團隊參與產品開發過程，並與真實用戶進行合作。
如果一個開發團隊存在這些功能障礙，那麼項目經理有責任通過產品、營銷和業務領導來解決這些問題，並提出工程交接的要求。保護團隊的高效節奏也是項目經理的責任，如果團隊壓力大，項目經理要尋找額外的資源，清楚地報告工作節奏和項目積壓情況，演示已完成的工作，並確保團隊做的事情被老闆賞識。
原文連結：https://medium.com/javascript-scene/software-roles-and-titles-e3f0b69c410c
編譯組出品。