專案管理做些什麼？
專案，就是會有個明確的交付時間(Time)與工作範疇(Scope)，而為了在時限內完成範疇要做的事，就一定會有資源需求，例如要多少人，多少原物料等等，接著便會衍生成本的議題(Cost)，而範疇、時間、成本這就是專案管理中的金三角。
然而，不論是金三角或四角，專案管理的核心還是放在準時的交付價值。而要做到準時交付價值，在瀑布式管理方法中，我們一般會經過幾個步驟：
1.專案起始階段
專案不會平白無故而生，一定是因為某個需求而衍生，而需求背後通常是基於某種策略，可能是關於客戶、市場、產品、品質等等，而策略的形成則是源自於企業洞察了某些商業機會或危機，這部分我們在談論策略的時候就有提到了，在此便不多談。
在確認了專案形成背後的脈絡後，便開始針對專案的目標、範疇、時程與預算都面向進行初步的確認，包含「要解決什麼問題」、「要達成什麼目標」、「要做到哪些需求」、「何時要交付」、「有多少資源跟預算」等等進行初步確認。
當然了，如果要嚴謹一點可能還得寫章程(charter)跟召開啟動會議(kick-off meeting)，不過這並非所有的專案都會做，在此我就先略過不提了。
在這個階段容易遭遇到的問題有幾個：
1.專案啟動的原因不明，也就是缺乏上游資訊就動工
2.專案的期待與目標不明確
3.時程用壓的，範疇用喊的，預算一毛都沒有
假設一切都順利，那將會進入到第二階段-規劃階段。
2.規劃階段
在確認了目標、範疇、時間跟預算後，接著就進入了專案規劃階段。
專案規劃階段一般得探討幾件事：
做哪些事？怎麼做？
從目標與範疇往下展開後有哪些細節工作項目，然後做法是什麼。
誰來做？
這部分談的是人力資源的部分，每個工作項目都需要有人負責，而到底哪些人會確實的進這個案子。
何時做？要多少時間？
每個工作項目預計何時啟動，又要花多少時間完成，簡單的說就是timeline。
得什麼結果？誰驗收？
這是針對每個工作項目的交付物作探討，而這個交付物由誰確認是完成的，這邊談的是允收準則(acceptance criteria)
如果以瀑布式或PMP的術語來說，這個段落在做的就是展開工作分解結構(WBS, Work Breakdown Structure)，讓專案的計畫是清清楚楚展現在大家眼前。
如果你覺得這篇文章對你有幫助，歡迎訂閱商業思維學院 EDM！
然而，在傳統的專案管理中，最大的問題就出在這個階段，因為當你開始展開計畫後你可能會發現計畫中充滿了「不確定性」。
不確定是不是完成這些工作項目就能交付價值了；
不確定每個工作項目是否能準時啟動，又是否花3天的時間就能完成；
不確定我排了John 5/3日開始負責某工作項，並在5/4日交付，到時他時間上真的可以配合；
不確定會不會有人離職或請假；
不確定技術是否可行；
…..
面對這些不確定性，置之不理絕對是最愚蠢的方法，所以絕大多數的專案經理在此時就要展現「橋」事情的功力了，橋什麼？橋人、橋資源、橋分工，目的是確認所有的工作項目是否能準時完成，如果發現計畫與實際之間有落差，那你得進行計畫的調整。
例如你本來期待公司最厲害的技術專家能參加這個專案，但同一時間他還有另一個重要任務在處理，此時你得決定是否調整計畫配合他的時間，抑或你要考慮其他人選；又或者，這個專家跟你討論後告訴你，某個工作項你預估3天太樂觀了，該工作最少得7個工作天，若在深入討論後確定是預估的太樂觀了，那你也得進行計畫調整了。
當你將可以排除的不確定性先排除掉，此時便會產出一個比較真實可行的計畫(workable plan)，而無法排除或判斷的那些事，就會被視為風險列管。
規劃階段對傳統專案管理來說是個關鍵任務，但會遭遇到的困難也顯而易見，那就是得四處橋資源，專案經理並非全才，很多細節得仰賴專家，但這些專家的管理權又在他的主管手上，要分配任務人家還不見得要鳥你，一般都得仰賴很多的會議來溝通。
3.執行階段
在可執行的計畫完成後，若不確定性都已經進可能被排除了，那按理來說只要按表操課來執行，大概就萬無一失了。但是，我們都知道萬無一失的計畫大概只在卡通裡出現過，現實生活中幾乎不存在。
在執行階段有兩大核心工作：第一個就是按表操課，也就是好好落實計畫，讓每件事情準時發生，誰幾月幾號該投入某工作項目，並在幾月幾號把東西交出來，必須要盡可能讓一切按著計劃來；第二個核心工作就是做變更管理(change management)，也就是說當現實與計畫出現不一致的時候，我們會如何應變。
變更管理是專案管理中的重點工作，因為變更總是會發生，不論你規劃的有多縝密，你都很難控制外在環境，可能有人生病了，可能競爭對手出新招了，可能合作的夥伴爆出公關緋聞了，這些事情你基本上難以控制，只能盡可能因應。
執行階段的困難就是變更的可能來源太多了，若無法有效管理，且建立起變更管理的規範與邏輯，那一日三變的噩夢只會不斷發生。
專案管理的最後一個階段是交付驗收階段，這部分相對單純我就暫時不多提了，從上面這一整段下來，你會發現做好一個專案還真的不容易，接下來我來帶大家了解一下為何Scrum這個敏捷框架對於解決上述問題提供了一些很好的解法。
認識一下Scrum
首先先來認識一下Scrum Framework。
先介紹Scrum中的三個重要角色：
- PO，Product Owner，也可以說是產品負責人，基本上對產品的成敗負責任，主要的責任有與Stakeholder們進行良好、制定產品願景、溝通釐清需求、排出工作優先順序、設定允收準則、有權力決定啟動或終止sprint。
- SM，Scrum Master，有人說這個角色比較像是傳教士或促進者，協助團隊理解Scrum跟敏捷，並促進PO跟團隊間的溝通，引導團隊解決問題，創造一個能自我運作的組織。
- Team，也就是實際進行產品開發工作的那些人。
而有些專家提到，最理想的Scrum team是個featured team，也就是專職負責某個產品或關鍵任務，不會身兼多職，而且團隊中的每個成員最好水平接近，每個人都是能end-to-end的完成任務，讓彼此之間的dependency可以降到最低。
接著來談一下Scrum中的幾個重要名詞：
- Sprint，衝刺，或者說是交付或迭代，簡單的說就是一個迭代，在Scrum的框架中它建議每個迭帶最好在1-4週之間，能愈短愈好。
- Backlog，這可以視為需求清單或工作清單，在整個產品範疇中，有Product backlog，這個backlog中除了需求清單外，還需要針對需求的優先級做好排序；Sprint backlog則是在每個sprint時按團隊資源與sprint長短能完成多少需求，然後從Product backlog中按順序將需求一一提取出來，這樣子可以確保團隊總是做優先級最高的事，而且工作量不會超過團隊資源所能承擔的上限。
除了角色與backlog外，Scrum的會議也值得一提，Scrum中有幾種會議：
- Sprint Planning Meeting，顧名思義就是每次sprint開始前的規劃會議。
- Daily Scrum Meeting，簡單的說就跟我們先前提過的Daily Stand-up meenting是類似的。
- Sprint Review，主要針對sprint的產出進行檢視，可能會有一些成果的demo，目的是確認交付物與內容相符以及目前的進度狀況。
- Sprint Retrospective，放在sprint結束後，用來回顧整個sprint中做的好的地方與可以改善的地方，透過持續的lesson-learned讓管理過程愈來愈完善。
如果你想更了解Scrum，推薦各位可以看看幾位敏捷圈的大佬們的文章，推薦鈦坦科技戰略顧問Yves、KKTV PO Vince跟搞笑談軟工的Teddy。
那Scrum到底解決了專案管理哪些問題？
談完了傳統專案管理的困難以及Scrum的基本介紹，最後我們就來看看為什麼我說Scrum是一個不錯的框架呢？如果你不知道瀑布式專案管理方法的問題，那你就很難真正理解Scrum這種敏捷框架到底解決了什麼問題，往下就讓我一一為大家拆解。
針對起始階段，傳統的專案管理方法中，專案經理必須持續跟老闆還有眾多Stakeholder們溝通需求，設定目標與排定順序，而在Scrum中，這些事情會交由Product Owner去執行，並且有個具結構性的Product Backlog來管理，而開發團隊可以專注在交付這件事情上。
針對規劃階段，原先專案經理需要花很多時間釐清這個專案項目要做哪些事情，但在Scrum框架中，我們只要按著Product Backlog排出來的順序去決定Sprint Backlog就好，大幅簡化了這工作；
傳統的專案管理在規劃過程，最討人厭的橋人橋事，Scrum建議是以Featured team的形式讓團隊專注做一件事，而且建議團隊成員不應該常常變化，這樣便可大幅減少橋人、訓練人的時間，也可以減少新成員進入團隊要重新磨合的時間；
而若Scrum team中的每個人程度都相近，而且每個人都能end-to-end的完成自己的工作，那意味著兩個人之間工作的相依性會大幅降低，互相等待或干擾的頻率會下降，這也可以避免出現一個點出錯整個計畫都得調整的連鎖效應(cascading effect)。
而對於交期，Scrum建議將每個Sprint的週期固定下來，例如2週或3週，所以交付時間的部分也被初步約束了，這也可以避免掉被老闆們亂壓時間的議題；
Scrum將規劃階段最難搞的那些問題都用框架跟規範的形式給簡化掉了，你覺得管起案子會不會簡單許多呢？
除此之外，縮短週期這件事，某種程度就有助於降低不確定性，一個三個月的案子，過程中存在太多變因，因為你不知道一個月後的世界會有哪些改變，更無法預期三個月後的變化，你或許有把握這個月不會有團隊成員離職，但下個月呢？下下的月呢？愈遠的時間點我們愈看不見，這我們已經反覆提及多次，在此我就不多提了。
進入執行階段呢？傳統的專案管理，因為專案週期長，團隊的會議絕大多數也是以週或月為單位，對專案現況的掌握不易。Scrum的Daily Meeting讓團隊隨時獲知最新進度，盡快進行調整；Sprint Review讓我們每隔一段時間便可以做個更深入的溝通與對焦；Retrospective則讓我們有機會進行完整的覆盤與持續改善。
而且在執行階段，如果發現有更高價值的工作項目出現，那中斷正在執行的工作任務的沉沒成本也較低，做決策時相對比較不糾結。
降低決策複雜度、減少不確定性、掌握現況、頻繁交付予持續精進，這些都是企業非常重視的價值，而當你真正落實敏捷後，你便能收穫這些價值。
上面這樣談下來，相信大家已經能用比較宏觀的角度來看待專案管理、敏捷與Scrum，應該也比較能理解敏捷方法是更以價值導向的管理方法了。
先思維，後框架、工具
在學習專案管理或其他知識時，我非常建議大家一定要先建立思維，先了解我們要解決的問題，也就是背後的「Why」，例如要確保工作能如期如質的交付。並圍繞著為什麼去找尋別人是用什麼樣的框架與方法去解決的，也是就「How-to」，例如PMP或Scrum，而在框架與方法之下，又分別選用了什麼樣的工具，這就是「What」，例如WBS、user story等等。
學習過程，一定要先搞懂要解決的問題，並進一步思考為何框架的設計與工具能解決我們遭遇到的問題，並思考它的適用範圍。
唯有如此，我們才能跳脫框架與工具的限制，而不為物所役。
