你有沒有思考過專案是為了什麼而做？做什麼、為誰做、怎麼做？

你有沒有參與過這樣的專案，不斷開會、不斷投入資源，團隊忙得焦頭爛額，卻沒有人能說清楚這個專案的目標。這種沒有靈魂的專案，始終走不出正確的方向。

有些團隊在啟動專案時，急著編列預算和時程，甚至已經開始找設計師畫稿、叫工程師寫程式，但卻沒有人能清楚回答「專案要達成什麼目的？到底是為誰做的？最後要交付什麼？」。其實多數失敗專案，不是因為團隊執行力不足、不是因為技術不到位，而是因為在一開始就沒有問對問題。

當你啟動一場沒有地圖的旅行，不管你走得再快，只要方向不確定，結果就是「需求改來改去、時程一再延宕」，最後交付的東西並非真正需要的。

這些，都是典型的專案風險。降低風險的方法，其實就是在專案正式開始前，先花時間把「做什麼？為誰做？怎麼做？」三個問題問清楚。幫助團隊在專案規劃階段先建立共識，避免後續不必要的重工與混亂。

為什麼要先問「做什麼、為誰做、怎麼做」

在專案管理流程中，任何成功的專案都會經歷「啟動 → 規劃 → 執行」三個主要階段，決定後續是否順利的關鍵，就是啟動階段把「為誰做、做什麼、要幹嘛」三題問清楚，接下來的規劃與執行才有明確目標。

這些問題如果在一開始沒有被釐清，最終一定會在執行階段爆發。

因此，順序非常重要，先釐清專案的存在意義與商業目標「做什麼」。目標明確後，就能判斷這個專案應該「為誰做」，確保所有利害關係人都被納入考量。最後再來思考「怎麼做」，將願景轉化為具體交付項目。

做什麼：用 SMART 與 KPI 把成果綁到商業目標

很多專案之所以陷入混亂，是因為一開始就把「做什麼」理解成「要做哪些功能」，但事實上，專案要追求的不是「交付功能」，而是「交付成果」。

功能是手段，成果才是目標，成果通常會設定營收、留存率、收集資訊等。

SMART 設定專案目標

要讓「做什麼」真正有意義，第一步就是把願景轉化為具體可衡量的專案目標，推薦使用 SMART 方法，包含 Specific（具體）、Measurable（可衡量）、Achievable（可達成）、Relevant（相關）、Time-bound（有時限）。

如果「做什麼」是「提升客戶忠誠度」，那 SMART 目標可以是「六個月內將每月客戶流失率降低至 1% 以下」。
如果「做什麼」是「增加潛在客戶」，則 SMART 目標可能是「一年內讓官網瀏覽量成長 30%」。
如果「做什麼」是「提升營收」，則 SMART 目標可以設定為「年底前透過網站帶來的銷售額增加 20%」。

這樣的具體目標，能幫助團隊在後續的規劃與執行中保持聚焦。

KPI 驗證目標

專案規劃時，除了設定目標，還要定義能驗證成果的 KPI。例如客戶流失率、官網轉換率、平均客單價等。這些數據能檢視結果，更能在過程中提醒團隊是否走在正確方向。

不作為的代價

另一個檢視角度可以是「如果我們不做這個專案，會付出什麼代價」，透過「不作為的代價」來校準專案價值，能幫助團隊更清楚這件事為什麼非做不可。

不推出新會員系統，可能意味著持續高流失率。
不更新網站，可能失去被競爭對手搶走潛在客戶的機會。
不導入自動化流程，可能讓人力成本逐年攀升。

為誰做：利害關係人的影響力地圖

專案找到「為誰做」的重要性，經常被低估，剛開始就要面對使用者或決策者的需求，避免忙了好一陣子最後又被翻盤。找對人、講對話，專案的阻力就能少一半。

都是一樣的「做什麼」，「為誰做」有差嗎？有差喔！假設一家傳產企業要做電商網站，「為目標受眾設計」和「為總經理設計」兩種情境的成果會一樣嗎？

新專案先畫「誰」的清單

啟動專案的第一步是確定「我們到底在為誰服務」，做一次完整的利害關係人盤點。

贊助人：握有預算或資源的人，例如 CEO、部門主管。
決策者：能拍板專案方向的人，例如專案經理、產品負責人。
使用者：最終會使用產品或服務的對象。
阻擋者：可能因專案推進而利益受損的角色，例如某些習慣舊流程的部門。

確定「誰」之後，還需要期望管理，你必須把專案的「做什麼」翻譯成每個利害關係人能理解的語言。

對 CFO 來說，這代表 ROI 與成本控制。
對 工程團隊 來說，這代表清楚的需求與技術可行性。
對行銷來說，這代表品牌推廣與銷售成長。
對 終端使用者 來說，這代表能解決他們的實際痛點。

當每個利害關係人都聽到與自己相關的價值時，專案才會真正被買單。

問對問題才有對的需求

弄清楚「誰」真正需要什麼，提供幾種問問題的方法。

訪談：與決策者或使用者對話，了解需求背後的動機。
問卷：在大範圍內收集意見，找出共通的需求趨勢。
使用者故事：從「身為一個ooo，我希望xxx，這樣我就能ooxx」的角度出發，將需求具象化。
情境任務：模擬真實操作流程，觀察使用者卡在哪裡。

建議以下幾個問題一定要釐清。

我們最重要的使用者是誰？
他們遇到的最大痛點是什麼？
如果只能解決一個問題，那應該是哪一個？
這個解決方案對公司業務帶來什麼好處？
如果失敗了，會對誰造成影響？

當「為誰做」被釐清，需求也被驗證後，接下來才有可能進入「怎麼做」的範疇，讓專案落地。

怎麼做：從規格說明書到 WBS 的精準落地

知道「做什麼」與「為誰做」之後，就輪到「怎麼做」才能讓專案落地，就是把抽象的願景轉換成可管理、可驗證的交付清單。

專案範疇定義：寫一份會保護團隊的文件

「專案範疇說明書」、「規格書」或「合約書」就像是專案的憲法，它能清楚界定邊界，避免後續陷入無止境的加需求循環。至少應該包含以下項目，才能保護團隊不受到無限需求影響。

交付項目：專案完成時必須產出的具體成果。
驗收標準：什麼條件下，成果才算合格。
排除事項：明確列出「不做的事」，這是防止範疇潛變最有效的盾牌。
限制：列出時程、預算、人力等外在條件。

有了這份文件，團隊就能在遇到需求變更時，可以快速判斷是否落在專案範疇內，避免因為「順手加一點功能」而讓整個專案失控（這個是從我的血淚經驗中汲取的教訓）。

WBS：拆分細項才能評估時程與資源

範疇確定後，還需要透過工作分解結構（Work Breakdown Structure, WBS）把大願景切割成小任務。

從上而下，把專案拆解成階段、模組，再拆到最小的「工作包」。
每個工作包的範圍應該明確，能分配給團隊成員執行，也能估算時間與成本。
WBS 之外的工作，不屬於這個專案，這能幫助專案保持專注。

這樣做的好處是，團隊不僅能更精準地安排時程與資源，也能避免遺漏關鍵工作。還有專案進行到一半時，不幸遇到人員異動，有做到 WBS 的方式也比較好交接。

專案啟動文件

最後，所有定義都需要一份正式文件來承接，就是「專案啟動文件」。這麼做除了確立規則之外，如果你是乙方，還能夠顯德你很專業！

向高層與利害關係人說明專案的目標與價值。
建立單一事實來源，讓所有人對專案的背景、範疇與目標有共同理解。意思就是說「我這份文件代表官方，請以我為準」，其他人說的都不算數。
最好再附上驗收單，從專案啟動時就確認驗收標準。

專案過程中反覆校準

專案沒有辦法一次把話說完、一路照做到終點，過程中一定會有人遺忘制定好的共識，或者提問重複的問題。穩定的專案流程，會設定一些節點，可以是時間（例如每週）、可以是階段（例如完成某功能），在這些節點重新把「做什麼、為誰做、怎麼做」拿出來回答與檢視。

我知道當專案忙起來的時候，很不想做這些事情，但這就是為了避免你忙你的、我忙我的，最後才發現根本是各忙各的，算是很重要的風險管理機制。

你就把「每個節點」當做是「每段衝刺」，引入 Sprint 的概念。

Sprint Planning 規劃

這次衝刺為誰服務？優先做什麼？為了哪個 KPI（做什麼）？

衝刺的規劃會議，把「做什麼、為誰做、怎麼做」縮到「本次衝刺」的範圍。

做什麼：待辦清單中，最能影響 KPI 的1至3個交付是哪些驗收標準？
為誰做：主要受益者是誰？新訪客？回流會員？內部客服？
怎麼做：重新梳理規格說明書和 WBS。

Sprint Review 檢視

是否真的為對的人創造價值？制定的 KPI 有進展嗎？

要記住，每次檢視都不是「做了哪些功能」，而是「做了哪些功能之後帶來的成果」。

對象準不準：此段衝刺的成果是否被目標對象採用？有沒有漏網的利害關係人？
成果對不對：用事先定義的 KPI 觀察真實變化（如轉換率、流失率、CS 工單量等）。

結尾

專案流程的「準確」比「快速」要更重要得多，先把目標談清楚再開始動手，每個階段都重新檢視一遍，幫助專案規劃更聚焦、防堵範疇潛變，盡可能降低潛在風險，。

當以上流程都能夠嚴謹回答並寫進文件，你的團隊會從「憑印象做事」進步為「以證據進行決策」，穩定地交付商業成果。

所以你可以這樣做

複習一下，假設你今天就要開始啟動專案，你可以這樣做。

開一場 30 分鐘啟動前會議，專注於討論「做什麼、為誰做、怎麼做」，先對齊目標與對象，把討論出來的共識留下會議記錄。
產出「專案啟動文件」和「範疇說明書（包含排除事項）」兩份文件，作為單一事實來源，明確驗收標準，守住專案邊界。
建立 Sprint 制度，每段衝刺會議都重問三題，並對 KPI 做實測回饋，確保方向沒有偏離航道。

PlayPlus 可以怎麼幫助你

如果你現在就有專案需求，並且想套用這套框架，把你的需求目標與現況丟給我們，PlayPlus 會在一場會議裡，帶你把三題問清楚，節奏先跑起來。