為何需要專案管理？

在高速成長的新創公司和科技巨頭中，由各級工程師領導工程專案是常見的做法。作為一名工程師，培養這方面的技能對於成長為資深及專家級角色至關重要。

作為技術負責人或擔任類似角色的工程師，領導專案是一項常規任務。那麼，如何高效且自信地完成這項工作呢？

為何需要專案管理？

「專案」一詞是被許多組織用來協調努力，以期推動特定業務目標的詞語。儘管少數專案可能只需幾週時間，通常，一個專案從開始到結束長達數月，長期專案甚至可能耗時數年。然而，在具有良好工程文化的科技公司，工程師每天都在交付業務價值，並且每隔幾個月就會完成被視為「完整」的專案。

但我們能否不進行任何形式的專案管理就完成工作呢？如果你是獨立工作，不依賴其他團隊，也沒有團隊依賴你的工作，那麼當然可以！

然而，當有更多人一起工作時，這時就需要：

▪ 目標：清楚確認你要透過這個專案解決什麼問題。

▪ 規劃：對如何解決這個問題有一個大方向的構想。在某些情況下，可能需要在計劃之前制定更正式的規格說明。

▪ 協調：確認由誰來做哪些工作。

▪ 保持所有人步調一致：隨著工作進展，讓所有團隊成員了解情況。

▪ 管理風險、變更和延遲：軟體開發充滿風險，因為我們經常以新的、未經驗證的方式建立解決方案。

專案管理方法為上述所有方面提供了策略，並幫助回答我們工程師常常害怕的問題：「這需要多長時間？」

無論我們工程師是否喜歡，日期和截止期限對專案來說都很重要，特別是在以時程來協調和溝通各個職能部門的公司。

專案啟動和里程碑

我觀察到，專案失敗的一大主因是一開始就存在期望不一致的問題。這種不一致通常到了專案接近尾聲時才浮現，而這恰恰是工程團隊認為他們已經完成工作的時候。

啟動會議有助於確保在專案初期就消除可能的誤解，否則這些誤解可能導致大量工作被棄置或需要徹底重做。我將啟動會議視為一個釐清重大問題的場合，所有相關的利益相關者都應參與其中。

降低任何專案風險的最佳方式是舉行啟動會議。在會議中，所有專案利益相關者確認他們了解專案的目標和方法，並認可大方向規劃。

啟動會議的籌備方式取決於專案的複雜程度和利益相關者的數量。我認為，準備一份書面文件至關重要，可以提前分發給大家加入意見。這種做法在任何遠距或混合工作模式的組織中都是不可或缺的。

產品需求文件（PRD，Product Requirements Document）是描述專案「為什麼」和「是什麼」的常見格式。雖然工程團隊應該在某種程度上參與，但在這個階段並不涉及工程細節。相反，這份文件旨在讓所有產品、工程、設計、資料科學和業務利益相關者達成共識。你可以參考各大科技公司的PRD範本。

　專案啟動會議　

專案啟動會議旨在讓所有人對「為何而做」和「做什麼」達成共識。在這個會議中，參與者將審視計劃並解決問題。一個成功的啟動會議應以專案負責人詢問：「關於這個專案是什麼、我們為什麼要做以及如何進行，還有任何疑問嗎？」作為結束。

理想情況下，基於已有的資訊，每個人都會回答一切清楚明瞭。但實際上，我曾見過會議室突然迸發出一連串問題——這正凸顯了啟動會議的價值。在團隊開始著手建設之前解決問題，遠比之後才發現問題並可能導致前期努力付諸流水要好得多。

我建議啟動會議採用面對面或視訊形式。安排十分鐘的時間閱讀提案文件，或由專案負責人向與會者進行簡報。如果是線上會議，可以考慮要求參與者開啟視訊，這樣會議主持人可以透過視覺線索察覺人們可能存在意見分歧的時候，適時鼓勵這些人表達意見。

雖然聽起來有些違反直覺，但我建議邀請所有相關的利益相關者參加啟動會議。這意味著邀請業務部門的所有人，包括客服團隊。更多的人參與會議確實會增加時間成本，但這是值得的，因為它提供了一個及早發現誤解並避免日後浪費心力的機會。

　工程啟動會議　

工程啟動會議緊接專案啟動會議之後舉行。其目標是讓工程師們就「如何執行」達成共識，參與者包括工程團隊和相關的工程利益相關者，如資料科學、機器學習或基礎架構團隊。一旦業務目標和整體方向明確後，工程師們就會深入規劃具體的實施細節。

這個過程因團隊而異，有些團隊會進行白板討論——有時使用虛擬白板。大多數科技巨頭和許多新創公司都會以工程規劃文件作為起點，這些文件會像RFC（徵求意見稿）、ERD（工程需求文件）或ADR（架構決策記錄）一樣被傳閱討論。

我非常贊同將商定的工程方法以書面形式記錄下來，因為這樣做有諸多好處。它迫使工程師清晰地描述提議的方法，從而減少誤解。計劃可以被傳閱徵求意見，擴大其影響範圍。而且，規劃文件在日後仍可供專案參與者參考，有助於他們快速上手並理解已做出的決策。

　設定里程碑　

這一步驟的目標是讓工程團隊就「何時完成」達成共識。許多工程團隊會將他們的規劃與專案里程碑和估算合併在一起。但我更傾向於將這兩者分開。原因是如果你在規劃階段就設定了工程的日期和里程碑，團隊很可能會立即尋求捷徑並做出造成技術債的決策。透過單獨進行工程規劃，團隊應該制定一個能為系統和服務的長期健康做出最佳決策的計畫——而不僅僅是為了眼前的專案。

有了工程計畫後，就該對可交付的里程碑有一個概念了。這些里程碑越細緻越好。這是因為所有的估算都會有一定程度的偏差，而唯一真正知道偏差有多大的方法就是達成一個里程碑。此外，每達成一個里程碑，都會使專案的最終目標更為接近，這件事本身就有價值。

一旦對里程碑達成共識，團隊就會對每個里程碑所需的工作進行細分，並粗略估算時間。有些團隊使用T恤尺碼作為時間單位，有些則喜歡使用規劃撲克方法，以費波那契數列（1、2、3、5、8、13等）作為複雜度的估算，而另一些團隊則偏好使用工程天數。最終，無論你在一個以時程為導向的公司選擇哪種方法，你都需要為每個里程碑的預計完成時間給出一個粗略的日期估算。

我更傾向於將里程碑設定得足夠小，以便能在不超過幾週的時間內完成。如果里程碑涉及長時間的工作，我會鼓勵團隊去設定中間里程碑，以掌握較小的部分。

軟體專案充滿未知數和種種風險，任何人能合理要求團隊做的，就是根據最佳資訊對完成時間有一個大致的概念。隨著專案進展，會出現增加複雜度並改變估算的風險和挑戰。

當然，業務方會想知道最終的交付日期。作為專案負責人，你有幾種方式可以分享這個估算的期限。許多負責人會增加緩衝或擴大估算時間，然後向外部溝通。

我總是傾向於增加一些緩衝時間，但同時也教育業務方沒有所謂的「固定日期」。向業務方承諾他們會定期獲得專案進度更新，然後隨著專案通過各個里程碑，你可以給出越來越有把握的日期。

在這個意義上，軟體工程和營建工作是相似的。任何承包過房屋建造或翻修的人都知道，日期和預算充其量只是估算，你總是會比預期花費更長時間。軟體專案也不例外。（本文摘錄整理自《軟體工程師的晉升之路》，碁峰資訊提供）

圖片來源_碁峯資訊

 書名  軟體工程師的晉升之路（The Software Engineer's Guidebook）

Gergely Orosz／著；沈佩誼／譯

碁峯資訊出版

定價：700元

圖片來源_Amazon

 作者簡介 

Gergely Orosz

是一位軟體工程師與作家，撰寫知名的The Pragmatic Engineer Newsletter，這是Substack上訂閱數排名第一的科技類電子報。出版多本著作，包括《The Software Engineer's Guidebook》、《Building Mobile Apps at Scale》以及《The Tech Resume Inside-Out》。

曾任職於Uber擔任工程經理與工程師，也曾在Skyscanner、Microsoft、Skype與JP Morgan擔任工程師。