專案規劃與產品管理從 Output 到 Outcome 從 Persona 到 SCRUM 評估

什麼是成功的產品管理與專案規劃？

產品管理 (Product Management) 是一種平衡價值、可用性、可行性與商務生存能力的決策藝術；而 專案規劃 (Project Planning) 則是將該決策落實為可執行任務的策略。其核心在於「以終為始」：從定義明確的商業目標（Objective）出發，透過 Persona (人物誌) 識別使用者痛點，並在眾多解決方案中進行智慧取捨（Trade-off）。成功的管理不應只追求 Output（產出程式碼量、解 Issue 數），而應聚焦於 Outcome（產生的實際商業結果，如營業額提升）。透過敏捷迭代與減少無效溝通成本，規劃者能確保團隊在有限資源下，始終朝著正確的戰略方向穩定前行。

在過去幾年的工作經驗中，有機會參加了一些不同的活動，其中包括均一的教育設計工作坊、矽谷阿雅分享的專案管理經驗談以及 Marty Cagan 分享的 Product Is Hard，這些經歷讓我能以不同的角度來看待我的職業生涯和參與的專案。

產品一次一次的迭代，職涯中一次次的轉換，人生一次一次的嘗試，在長大的過程，選擇了什麼? 放棄了什麼? 如果把生涯當成一個產品，我們當時相信的那些事情，如今是不是有成為了人生路途中的美麗風景?

這段影片探討了專案管理與產品管理的精髓，深入解析了規劃到執行的迭代流程，是理解高效職涯規劃與團隊合作的絕佳資源。

從專案演變的角度來看，整個故事線應該會是從規畫走到執行，現在讓我們來深入了解看看整個迭代流程該是什麼樣子。

• 規劃: 定義目標 → 定義問題 → 選擇準則 → 解決方案 → 取捨
• 執行: 專案時程評估 → 專案難度評估 → 專案成效評估

定義目標 (Objective)

首先，我們需要確定我們的目標是什麼，以及如何做出決策？我的職涯旅途中目標可能包括每天七點前回家吃晚餐、轉向純前端工程師職位、回台南休養生息、到大城市體驗生活並利用其學習資源快速成長。

對於一個網站的每個活動或專案，目標可能是增加曝光和使用者黏度或增加行銷活動營業額。在教育科技領域，目的可能是討論新型態的教學工具對學生的影響與成效，參與人員包括實際在使用線上教育平台的老師和開發者。

定義問題 (People Problem)

明確了解需要解決的問題是什麼？可能需要解決的問題包括求學和工作遠離家鄉太久，需要更多家庭時間，或者不擅熬夜無法常態性加班。在網站設計方面，我們可能需要將設計和工程師置身於使用者的角度，體驗使用者的痛點，使用工具如 Persona (人物誌) 或 User Journey Map (用戶旅程)。

以電子商務網站為例，問題可能包括網頁速度很慢、使用者不容易找到自己想要的東西或購買流程複雜。

Persona 人物誌

目的是讓人真實的感受到使用者，增加開發團隊的同理心，協助解讀行為和需求，更關注在使用者和產品互動的方式與情緒。與其說是定義目標對象，倒不如說是過程中的一個資訊視覺化工具，協助大家在討論的過程中，盡量進入人物的感受與體驗。

我們直接從教育的角度切入，底下是當時均一歸納出來的 Persona：

• 學習態度
  • 快速學習: 像是考古題、速解，想得到考試成績不用懂也可以。
  • 慢速學習: 解決問題的方法。
• 學習動機
  • 理解差異: 理解到每個人都可以有自己的學習速度，可以用不同的速度前進。
  • 找到自信: 學著從容易的部分開始一步一步前進，找到阻力最小的方式累積成就。
  • 維持專注: 乾淨的引擎才有力量，心靈也是，心思有空間也才可以放進去新東西。
  • 重要貢獻: 從接受知識的人成為分享知識的人。
  • 自主選擇: 學習成為一種選項。
• 學習環境
  • 講者互動、同儕互動、自己學習（依照進度各自學習，藉由導入資訊系統，前後測評估，自行選擇難度）。

選擇準則 (Selecting Criteria)

當我們確定了各種問題之後，在有限的資源和時間內，我們需要決定首先解決哪個問題。

• 釐清個人價值觀與願景、考量薪水、考量可點的技能、考慮未來職涯發展。
• 專案上，要考慮的可能會是: 專案是否符合公司的願景、用戶族群年齡、使用情境 (能夠離線使用嗎)、成本 (會需要跟其他團隊來回溝通嗎)。

解決方案 (Solution)

接下來，我們需要列出各種可能的解決方案，並以最簡單的方式驗證這些方案是否能夠解決我們定義的問題。無論解決方案是什麼，我們都需要清楚地了解我們的預期結果 (Outcome)，並確保結果能符合我們當時選擇的準則。

儘管過程很重要，但結果更重要，重要的是要確保結果符合我們的目標，否則就只是一堆隔靴搔癢無意義的成果 (Output)。

• Output 是發現了然後解決定義的 People Problem，程式上只是解 Issue 跟 Commit code。
• Outcome 是透過理解問題並決定我們想要得到，增加 5% 的營業額透過擺平某幾個 People Problem 來解決。

取捨 (Trade-off)

為什麼會需要取捨，因為功能不是越多越好，多了必定有其他是下降的，定目標時，要有另外一個可能減少的項目來評估。

工作、睡眠、運動、家庭、朋友，五選三，人生會好過一點。

各種可能方法除了依照 Selecting Criteria 外也要綜合的去評估，有能力的員工只會知道最終的 Outcome，剩下的就要靠員工們自行去尋找與實作，最終這個團隊就會變成一個 Accountable 的團隊。

以教育來說，從學生行為、思考方法、來分析問題：

1. 學生行為優化: 透過引導的方式，讓問題是被發現而非被指出。例如：垃圾無法投到垃圾袋中，請大家討論出好的方案；排隊去科任課，上課前班長集合困難，大家一起想出可以講話又可以準時到的方法。
2. 思考方法優化: 協助 XXX 在 XXX 情境達成 XXX 的目的，將討論的結果，用八格漫畫去說好一個完整的故事。
   • 偏鄉學生: 家庭功能不足，從陪伴與較低侵入感的學習系統開始培養學習習慣與信心。
   • 城市學生: 有資源，可以藉由提供工具、給予機會進行組織溝通、口語表達的機會。

在解決問題之前，不急著修復，首先分析可能的問題，並將問題範圍縮小到最小，接著是建立問題的漏斗，並理解背後的動機。數據可以告訴我們問題出現在哪裡，但無法解釋為什麼是問題。

雖然還不能明確知道未來的樣子，但還是要為自己在短期內找到一個理想的樣貌，這樣也才會知道還缺少什麼，在目前和接下來的人生中也才知道要培養什麼。

滿分的解決方案並不會出現，所以我們需要去做取捨，最重要的事情是，我們的 Objective 是什麼？

專案時程評估

時程評估問題，在工作初期就開始被主管要求，但那時無法合理的評估。在讀了**《人月神話》**之後，發現除了沒有先後關係也不需要討論的任務，其他專案時程確實會有時程估計上的困難，尤其在溝通成本過高的團隊中，這樣的問題會更明顯。

專案難度評估

後來看了另外一本書 《SCRUM：用一半的時間做兩倍的事》，裡面建議不是去評估時間，而是用斐波那契數列去評估難度(2 3 5 8 13)，這種數列好處是可以差異化分差。在決定難度的過程中，可以用投票的方式，其中比起舉手表決使用牌卡進行投票，會是一個比較不會受他人影響的方法。

工時的估計可能不是重點，大家共同決定的點數才是，同類型的專案在團隊經過一段時間的磨合後，大概就可以看出團隊可以在一段時間內解掉多少的點數，時程的預估也才有參考的依據也更為真實。

專案執行成效評估

在個人的成效管理上，要儘可能去減少溝通成本。缺乏軟體開發團隊經驗的人，很可能會以為在口頭分配並得到口頭回覆後，就只需要心裡想著發大財或時不時的走去詢(打)問(擾)成員作事，所有待解問題就會迎刃而解，專案就會自動完成發大財然後放眼台灣、征服宇宙。

網路上也就出現了下面的玩笑話：

Go away or I will replace you with a very small shell script.

處理一件事情的流程通常包括以下步驟：完成、刪去、分派、延後。

• 完成： 評估正在處理的事情是否可以立即完成，如果有時間和資源就盡早完成。
• 刪去： 在清單上的任務但不再需要處理或不再追蹤就可以刪除。
• 分派： 任務更適合他人處理，則可將其分派給適當的人。
• 延後： 若需要更多時間、資源或資訊或不是優先事項，可將其延後。

流程管理的 PDCA 循環 Plan → Do → Check → Action → Plan：

• Plan (計畫): 在開會前就該把相關的資訊整理清楚，跳過只需要閱讀的部分，需要討論的才進行討論。
• Do (當天要做的事項): 每次討論的目的在能快速的修正及同步訊息。
• Check (確認): 大家的進度、方向、遇到的問題。
• Action (更好的方法): 能夠趁今天試看看? 怎麼找出答案? 可優化的有哪些?

就好像鐵人賽三十天一樣，過程中每天不斷計畫、修正然後持續不斷的閱讀和寫作。三十天過後不論成果如何，最後成長的一定會包含你自己。

FAQ：專案規劃常見問題

Q1：如果團隊成員對「難度點數」的認知落差很大怎麼辦？

A：這正是估算會議最有價值的時候。落差大代表「資訊不對稱」。請最高分與最低分的人各自解釋觀點：高分者可能預見了隱藏的技術坑，低分者可能知道更簡單的解法。討論後的共識比點數本身更重要。

Q2：如何將個人職涯當作一個「產品」來管理？

A：定期定義您的「個人 Objective」。每一季盤點自己的 Outcome（我學會了什麼新技能？我解決了什麼核心問題？），而非只是 Output（我寫了多少行 Code）。如果發現長期只有 Output 而無個人價值的 Outcome，就是該進行「產品重構」（轉職或學習）的時候。

Q3：為什麼說 100% 的解決方案不存在？

A：因為資源（時間、金錢、人力）永遠有限。追求完美往往會導致超時或錯過市場先機。產品管理的精髓在於「優雅的妥協」，在有限的錯誤預算中交付最重要的核心價值。

• ← 上一篇
• 下一篇 →