【專案管理】你可能沒注意到的專案管理與克服技巧
還有印象最近一次開會的狀況嗎？
「我們必須要先寫完整的企劃，把我們需要的東西都列上去，等到把所有東西都準備好，這樣之後才不會出問題…」很大部分的大活動都需要先有一個完整的企劃書，等到企劃書與完整架構完成後，才能繼續下一步。
然而，有時會遇到一些意外（甚至很多）…像是：「這個企劃看起來不太行啊，老闆可能不會給這麼多資源。」「那準備時間完全不夠耶？怎麼可能來得及」而我們通常只能回：「喔…好吧我們會改。」或是高階推託：
我們也很想改，但是老闆說不行（誤）
明明中途都會有許多的檢驗點，怎麼最後還是會出包呢？
實際可能是：雙方存在資訊不對稱
1. 溝通成本與責任歸屬，累積爭吵的因素
通常我們在執行一項專案或任務時，並沒有去思考這項任務背後的目的。主管（或老闆）想要達成的目的是什麼？他們可能會考量哪些要素？要如何使提案有證據支持等等問題。
當時間越拖越久，我們就會發現 — — 焦點不知不覺被模糊了。
每個人開始關注細節，從 banner 設計不好看，到我想要一個斑斕炫麗的黑色等奇怪的要求。然而，我們卻忘記最初的目標。更糟糕的是，當時間資源越來越少，做出更動的成本就會越來越大，常常一個原本能輕輕鬆鬆完成的專案，最後加班加到爆炸都做不完。
另一個，則是管理制度造成的問題。
多數公司都是採用一個幹部管理一群人，最後再由這群經理人上報給老闆。但對於經理人跟下屬來說，他們很有可能完全關注不同的 KPI。舉個例子，像是經理人的業績可能是總營業額，但下面的業務可能是跑單數。
因此就會出現業務瘋狂接小單；但經理人一直罵下屬業績沒到的詭異畫面。因為兩者角色的目標根本不一樣，因此總是會不停的出現衝突。
2. 僵化的時間規劃，無法處理突發狀況
根據人類的習慣，我們常常依據舊的模式或經驗來執行新的想法。認為這樣的風險最小。就像最常採用的 Waterfall（瀑布式） 。
Waterfall 是先由一群活動計畫者（業界稱為 PM）來規劃整體的流程，交由下面的執行者（設計師、工程師等等）來開始製作產品，最後整合後端與活動執行人的產出做出最後的產品。顯而易見的優點是，這是大家都容易接受與理解的方式，以及能降低初期規劃與發包的成本。
然而，最糟糕的是計畫往往趕不上變化。
如果 PM 或 Product Planner 對於使用者的需求理解不明確，或是對於完成的定義有落差，一來一往的溝通成本就會高到直破天際。兩個小時的任務可以修個兩天。
加上主管通常都會希望下屬允諾期限，而下屬為了避免做不出來開天窗，通常都會「灌水」避免出現臨時狀況做不完。因此就會出現整個開發期被預期拉長；如果時間押的剛剛好，一個溝通失誤就會直接讓專案時程 delay。
最後的產品品質，就只會落在「剛剛好的水準」、「不要出包就好」的程度，導致 output 總是和預期相差甚遠。
3. 修正速率過長，無法在時限內完成產品
根據 Waterfall 的流程，都會在最後才進行調整與改善。但許多產品的細節，往往在開發的過程中才會發現，或是需要經過使用者測試後才能調整（例如 A/B Testing）。如果每改一次，就需要開一次會（而且是那種抓大家來的會）來進行調整，無疑會花很多的時間在討論、開會，再討論、再開會的循環。最後，變成全部的時間都在開會，反而沒時間投入在開發。
這也是為什麼很多經理人很喜歡開會（因為感覺有在做事），但下屬卻討厭到不行（因為會議根本沒有解決問題）。
那麼，要怎麼解決這件事？
關鍵在於––––對產品是否有快速遞進的概念。
現代的扁平化流程，例如 Scrum 和 Agile 就是為了解決這些問題而生：
現在的產品需要因應顧客的要求，快速改正所需要的內容，所以需要有更短的流程與測試回饋，這裡就就介紹現今扁平式管理的主流方式 — — Scrum 工作法（這個工作法會在之後有更詳盡的介紹）。
這個流程最主要改善的有下列幾點：
優點１：流程透明化，每個人知道自己的負責範圍
Scrum 透過白板與便利貼的方式，讓所有人都知道目前的專案進度，進而加速整體的工作速率，也透過透明化，降低活動無法順利完成卻隱瞞不說的狀況。並讓每一個都可以知道並互相監督彼此的工作，提升整體的工作效率。
也解決「責任越大，權利越大」的問題，位在團隊內，每一個人都是缺一不可的，因此在這個專案裡，只有負責每個 Task 的人，沒有上下位者的指示問題。這也代表，可以減少主管偏心而導致專案概念的不一致，進而減少內部的爭吵，因為 Scrum 本身就是建立在大量溝通的基礎上。
優點２：解決彼此分工不明確，降低整體成本
Waterfall 的一大弊病就是為了規範權責相符，所以某 A 會的技能，雖然可以解決 B 的大問題，卻因為沒辦法有適量溝通與討論，而白白浪費了這樣的技能。現在，因為 Scrum 依靠大量的溝通基礎，可以利用每日極短期例會的方式，快速提出每個人面對到的問題，讓團隊的其他人能夠利用自己的能力，幫忙解決其他隊員所遭遇的問題。
而這樣的方式優點還有一個，就是能在籌備的過程中，隨時加入一些好的活動或是修正內容，隨後馬上進行測試，此舉解決了 Waterfall 只要更改需求或是文件，就需要重新跑一次流程，能夠大大減少重新執行流程中，重新編寫文件的資源浪費。
優點３：極短期的產品週期，快速推出並更新產品
Scrum 採用衝刺（sprint）的方式，快速測試並修正產品。衝刺就是在一個固定的時間區間內（例如兩個禮拜），迅速完成一次的原型（prototype）開發，原型是指可以拿出來給客戶或是觀眾的實體產出，讓客戶與觀眾快速的給予回饋與修正。這個模式可以解決 Waterfall 更改初始文件（像是活動企劃）時，所需付出的高昂時間與財務成本，而且過長的審核流程會拖慢整體產出的進行，很多時候，專案會做得很趕、做不完，不是因為時間不夠，而是大多數的時間都在等待，或是做完了才開始花時間修改。
這樣還有一個最棒的優點，就是可以借由這個方式，估算每一次衝刺時所需的時間，就能平均估算出整個專案所需要的完成時間，且就能較精準的估算整個時程。只是 Scrum 並不會把整個專案非常詳細的規劃出流程，由此延伸出的優勢就是：更能彈性調整流程，不會因為圖突發性的意外，就必須重新撰寫時間規劃。
好了，來個結論吧：
看完 Waterfall 與 Scrum 的規劃，好像扁平式的管理似乎就完美的贏過瀑布式的管理流程？其實，沒有這麼簡單。首先，大家最習慣的還是瀑布式的流程，因此就算引入了新的方式，大家還是會習慣用舊的思維去做事，反而造成事倍功半，還讓別人覺得管理不佳：再來，如果之前有留下好的文件（當然這個很難啦），的確是可以減少下面帶活動或是做事的人的困擾，因為只需要照著指示做，很少需要指示，更不用說需要 Scrum 複雜的分工模式，還會牽涉到在上面的管理者需要釋放許多的權力，更會讓已經習慣這套模式的人感到反感。
要使用這套新式的工作方式，需要的就是 — — 有一顆想學習的心，以及接納改變的勇氣。他是一個需要我們挑戰舊有思維的方式，如果願意去嘗試新的方式，省下的不只是成本，還有屬於你寶貴的人生。現在，就開始改變吧！
之後還會持續推出 Scrum 相關的文章，歡迎大家多多指教以及更正！
