什麼是技術項目經理？

什麼是技術項目經理 (TPM)？ 經驗豐富的 IT 顧問和業務運營專家安迪布萊克威爾說，答案取決於你問誰。 作為 Toptal 的項目和產品管理首席總監，Blackwell 領導的團隊負責將 Toptal 的自由職業者網絡中的高技能項目經理與為特定計劃尋求頂尖人才的組織進行匹配。 近年來，她看到對 TPM 的需求激增。

“整個科技行業對於這個詞的實際含義肯定存在一些爭論，”布萊克威爾說。 “有很多人稱自己為技術項目經理，因為他們與工程團隊密切合作，或者從項目管理的角度領導技術團隊，但這不是我們想要的。”

Toptal 的定義更為具體。 Toptal 網絡中的所有項目經理都是傳統項目管理技能的專家，例如範圍界定、預算和管理時間表，以及與迭代交付和持續改進相關的敏捷軟件開發實踐。 他們總是與工程師密切合作，如果需要，他們可以指導和指導 Scrum 團隊。

然而，為了獲得 TPM 的資格，除了管理敏捷流程和與開發人員協作之外，他們還必須具備額外的經驗：他們自己必須是開發人員。

珍貴的組合

大大小小的組織對這種特殊的技能組合越來越感興趣。 “大多數初創公司不能僱傭一個只會做一件事的人，”布萊克威爾說，如果他們正在招聘一個工程項目，大型企業希望在候選人的個人資料中看到“開發人員”或“架構師”。

即使在客戶沒有特別要求具有技術背景的項目經理的情況下，選中“開發人員”框也是一個主要賣點。 可以計劃和執行軟件項目、實施和優化敏捷流程和代碼的人？ 這是一個巨大的福音。

然而，實際上，TPM 並不期望編碼——許多人已經多年沒有編碼了。 那麼，為什麼需要編程經驗呢？

需要 TPM 來做出技術決策，Blackwell 說：“如果您至少沒有一些相對較新的現代技術堆棧、SDK（軟件開發工具包）、架構或測試自動化平台的實踐經驗，那麼您”可能不會做出正確的決定。 你不會得到客戶的信任，因為你以前沒有使用過這些東西。”

與團隊合作

向潛在客戶展示可信度是確保參與的重要因素，但這只是第一個障礙。 一旦分配給一個項目，TPM 必須迅速贏得技術團隊的信任和尊重。

Michael Poythress 十幾歲時就開始編程。 16 歲時，他為與父親一起創辦的房地產廣告業務建立了一個商業網站。 從那以後，他一直是多家初創公司的首席執行官和創始人。 2018 年，他作為 TPM 加入 Toptal 網絡，現在與工程團隊密切合作。 “如果我沒有編碼經驗，程序員會接受的，”他說。 “他們不會直接對我開槍。 但如果我挑戰他們並作為同齡人與他們交談，就會有尊重和融洽的關係。”

技術經驗比頭銜更重要，加利福尼亞州奧蘭治縣 Toptal TPM 的 Allen Takatsuka 說：“據我所知，TPM 中的‘T’對工程師來說並沒有真正的意義。 他們認為只是另一個項目經理會安排他們的會議並要求他們填寫電子表格。”

然而，一旦建立了共同點，“互動的味道就會大不相同。 這更像是與工程的合作，”他說。

高塚在其職業生涯的早期花費了數十年時間領導工程團隊。 他認為這段經歷提升了他的軟技能。 “這是一種不同的同理心技能，”他說。 “你必須證明你會說這種語言。 你可以說，'我明白為什麼你會根據正在發生的技術問題而面臨這些挑戰。'”

來自弗吉尼亞州維也納的技術顧問 Dan Allen 將他的職業發展描述為“從小隔間程序員到技術主管再到架構師、總監、副總裁、首席技術官、首席信息官”。 自 2019 年作為 TPM 加入 Toptal 網絡以來，他一直很忙，參與了 14 次客戶活動。

“我很少閱讀代碼。 我幾乎從不寫代碼，”他說。 “但在某些情況下，開發人員會陷入困境。 他們可以引導我了解架構，我可以準確地看到他們想要做什麼以及邏輯。”

他發現動態不僅在極端情況下有用，而且在更廣泛的情況下有用。 “你的團隊知道他們可以來找你談話，而且你真的理解他們在說什麼，”他說。 “你可以幫助他們考慮所有的複雜性，以防他們遺漏了什麼。 你可以成為一個共鳴板並提供反饋。”

乘數效應

這種反饋和洞察力比建立關係更重要。 TPM 為組織提供了不同的價值主張。 它們較少用作信息的渠道，而更多地用作知識的來源。 是的，他們計劃、協調和溝通，但他們也幫助客戶和團隊完成複雜的技術決策。

“你有能力在技術上固執己見，”高塚說。 “這為組織增加了價值，因為現在你有了更多的乘數效應，而不僅僅是組織和協作。”

Takatsuka 指出，TPM 必須跳過更少的環節來解決問題。 尤其是在較大的組織中，非技術項目或項目經理可能會通過識別相關參與者和利益相關者、提供背景、匯總信息，然後篩選結果來做出決定來應對技術挑戰。 TPM 可以運用他們自己的知識。

“您可以更有效地應對風險，”東京 TPM 的 Oana Ciherean 說。 “而這些風險可能來自很多地方。 它們可能來自團隊的錯誤估計。 所以你可以說，'好吧，我確信這段代碼不會花一周時間來寫'，因為它真的需要兩天時間。 因此，您實際上可以取消阻止人們。 因為你已經發現他們被卡住了，這就是為什麼他們需要五天的時間。 你知道這一點，因為你去過那裡，你自己也被困住了。”

尋找平衡

Ciherean 的職業生涯始於開發人員，但出於參與大局的願望，她很快進入了項目管理領域。 然而，在這些角色中，她發現自己錯過了編碼。 她說，技術項目管理提供了兩全其美的優勢：“它讓我能夠真正親身體驗技術，同時也能高水平地了解業務和客戶以及他們想要的功能。”

Poythress 也覺得自己找到了最佳位置。 “我是一名翻譯，或者是有遠見的人與知道如何構建並實現它的技術人才之間的聯絡人，”他說。 “我能流利地說兩種語言。 我說‘正常人’，我說‘技術語言’。”

迷你 CTO

為初創公司和小型企業工作的 TPM 在商業和技術的交叉點上佔據著特別重要的位置。 在這些項目中，TPM 通常是項目開始時第一個加入的人。 然後，他或她負責評估產品的可行性，定義技術範圍和要求，並幫助客戶（有時是一個有想法的創始人）選擇技術堆棧，評估供應商的服務交付，實施 DevOps 最佳實踐，並組建合適的團隊。

Takatsuka 將這些參與視為“迷你 CTO”角色，其中 TPM 將業務和技術領域聯繫起來，以使事情順利進行。 一些客戶對開發軟件幾乎一無所知，他說：“我如何開店？ 我讀過關於敏捷的文章。 我怎麼做？”

Poythress 認為這兩個角色是重疊的，在某些情況下甚至無法區分。 “有很多異花授粉，”他說。 “小型組織的 CTO 可以很容易地進入大型組織的高級技術 PM 角色，並感到賓至如歸。”

啟用敏捷性

儘管幾乎所有具有軟件開發經驗的項目經理都掌握敏捷的機制，但具有技術才能的人可以為管理流程帶來更細緻的視角。

Ciherean 發現本書從未嚴格實施敏捷方法。 它們必須針對團隊和項目的特定需求進行定制、混合和調整。

“您必須確保您所設計的流程不會干擾開發人員的工作，並且實際上會使其更有效率或生產力，”她說。 “有時這意味著深入了解 GitHub 工作流程，例如，了解他們如何進行提交，了解他們如何為代碼創建分支，以及了解您的流程是否適合他們的工作流程。 然後你要么糾正你的流程，要么糾正他們的工作流程。”

TPM 的專業知識還可以為特定的敏捷工件和實踐提供信息，例如產品積壓和相對大小估計。

“如果你了解技術，你就會知道待辦事項的大致複雜性，”高塚說。 “否則，你只有這份清單，你很難知道第一件是不是比第二件大的 T 卹。 您可能認為一個更難，但您並不真正知道幕後是什麼。 他說，一個“極端”的 TPM “可以自己調整大小，但需要注意的是，當團隊加入時，他們將擁有自己的速度。”

Poythress 使用他對尺寸估計的理解作為衡量他為項目考慮的技術主管和工程師的標準。 如果他期望某件事是一項小任務，但其他人認為它是巨大的，那就是一個危險信號：“我會聽取他們的意見，看看是否有我不知道的複雜性，但如果這不成立，我想，'好吧，好吧，那不合適。 我們需要一個非常了解這一點並且不會被應該是一個簡單的功能嚇倒的人。”

TPM 還有助於向客戶介紹非功能性需求。 如何處理高可用性？ 您如何處理災難恢復？ “沒有技術上的理解，我不知道你們是怎麼討論的，”高塚說。 “你可能會停留在 Scrum 需求級別，直到技術人員出現為止。 好吧，那麼你就有了這個巨大的鴻溝。”

保持最新

儘管他們在鍵盤上的時間在他們今天的工作中發揮著重要作用，但 TPM 不能依靠過去的經驗來保持相關性。 鑑於技術變化和發展的速度，很容易落後。

Poythress 在加入 Toptal 之前的 5 年窗口期中學到了這一點，當時他完全專注於經營自己的公司。 “我肯定停滯不前，”他說。 “在那段時間裡，出現了許多不同的語言並解決了我一無所知的問題，因為我們擁有我們的技術堆棧，而這正是我們所需要的。”

如今，他將多達 10% 的時間用於閱讀文檔、觀看 YouTube 和沙盒，以“了解最新和最偉大的事物”。

“我幾乎總是涉足一種新的語言或技術，這樣我才能保持敏銳，”他說。 “因為如果我不這樣做，這個行業就會繼續發展。 我以前也有過這種情況。 而且，補習比保持最新要難得多。”

高塚還積極填補自己的知識空白：“如今，谷歌很棒。 YouTube 很棒。 你必須做你的功課。 但這項工作是建立在自身之上的。”

他還依靠廣泛的顧問同事網絡提供支持和知識共享。 “我遇到過客戶想要使用 Google 的情況，但我碰巧更了解 AWS 平台，”他說。 “我可以打電話給朋友說，‘嘿，我們將使用 Firebase。 你有沒有這樣做的客戶？ 可擴展性怎麼樣？

即使在企業工作了 30 多年並擔任過多個高管級別的職務後，Dan Allen 也不怕弄髒自己的手。 在過去的三年裡，他自學了在亞馬遜和谷歌云上單槍匹馬的部署。 “我這樣做是為了理解它並幫助一個 Toptal 客戶，”他說。 “他們沒有技術團隊。 他們只有我。 所以我去了 YouTube 大學並完成了它。”

自 1985 年 Allen 開始擔任開發人員以來，情況發生了很大變化。但他樂於迎接每一個新機會帶來的挑戰。 “這是我熱愛這份工作的一部分，”他說。 “總有一些你沒有做過的事情，一些新的事情。 而且你總是帶著額外的羽毛離開，你可以在下一次參與時加以利用。”