還有印象最近一次活動開會的狀況嗎？「我們必須要先寫完整的企劃，要把我們需要的東西都列上去，等到把所有東西都準備好，這樣之後才不會出問題...」很大部分的大活動都需要先有一個完整的企劃書，等到企劃書與完整架構完成後，才能繼續下一步。然而，有時會遇到—些意外...像是：「這個表演看起來不太行啊，可能需要砍掉重練。」「那活動時間會不夠用耶？」「但是我們最後看完還是覺得有必要大改或大修，不然這樣的表演沒辦法拿上台。」而我們只能回：「喔...好吧我們會改。」
明明中途都會有許多的檢驗點，怎麼還是會出包呢？
造成活動不斷改動的可能原因如下：
原因１：溝通成本與責任歸屬，累積爭吵的因素
我們並沒有去審視我們要的東西有沒有一致性，當文件或企畫審核從上而下時，時間拖了一陣子，這時我們就會發現——焦點其實被模糊了。主管或是幹部群的所關注的重點，從原本的整個專案的架構，看到了裡面的每個細節，結果。最後誰也不記得原來的目標。
更常發生的是，在這樣一來一往的過程中，時間就被慢慢消耗了，時間在這個世代，無論在公司或是在社團，都是最珍貴的資源，然而最珍貴的資源，往往就消耗在高昂的溝通成本上。
我們以往都是採用一個幹部管理下面好幾個活動或是專案的負責人，幹部上面會再有一個活動總負責人。然而，當下面對於活動的意見以及改善，傳到上面的總負責人時，許多的意見非但沒有改善，反而因為中途的意見傳達不一致，導致每一次的更正都與大家的理想有落差。此外，因為中途多了一些新的要求與目標，而溝通的標準又不一致，導致最後真的發現專案 fail 了，卻沒有一個人可以出來即時善後。
原因２：不人性化的要求，導致產出水準下降
我們常常依據舊的模式來執行新的想法，認為這樣的風險最小：就像我們最常採用的 Waterfall（瀑布式） 。Waterfall 是先由一群活動計畫者（業界稱為 PM）來規劃整體的流程，交由下面的活動執行人（工程師等等）來執行活動，再由執行人開出要求讓一些美宣、器材（後端部分的部門）可以開始製作產品，最後整合後端與活動執行人的產出做出最後的產品。顯而易見的優點是，這是大家都可以接受的方式，以及可以降低一些成本；缺點是，一開始的規劃，在最後很容易就趕不上現實的改變。
大家看到這邊，發現到問題了嗎？如果前面的活動計畫者對於要求理解不明確，或是雙方理解有落差，一來一往產生的溝通成本會高到不可想像。你曾經遇過為了一份企劃的內容修了一個月，結果出來實際演出時，還是有一半需要改掉，後來只能默默在角落畫圈圈...再舉個例子，當老闆問你：「這個專案給你一個月的時間可以做出來嗎？」如果使用 Waterfall 的方式只能預估「剛剛好」在期限內完成，那勢必就得加班（我們會在之後的文章談論加班的壞處）導致產出的活動與產品，會出現有人「剛剛好到標準」、「不要出錯就好」的水準，長久來看拉低了整體產出的水準，導致只能產出平庸的結果。
原因３：問題修正的速率過久，無法在時限內完成產品
根據我們最常用的 Waterfall 流程，我們都會在最後才進行改善但是這樣的方式對於一些需要快速改善的活動或專案所需要的時間成本相較之下太高了，每一次的更改就需要開一次會。導致問題修正的速率嚴重下降，也難怪到最後的成品很多時候都是趕出來的。如果讓這樣的情況繼續惡化下去，就會讓階層間產生資訊不對稱，進而讓不良的組織文化慢慢盛行。
每一個人對於「做好」的理解不一樣，因而影響了最後的目標不一致，這個部分就牽涉到 KPI（key point index, 關鍵績效指標） 的設定不明確——很多人只會說：「我要看到成品。」卻沒有人明確指出底要什麼產出什麼樣的產品，不明確的指示甚至會造成負面的影響。舉個例子來說，如果活動負責人要求你在器材部門的 KPI 是「成本越低越好」，你會為了表演而負擔被預算審核部門罵的風險嗎？
那麼，要怎麼解決這件事？
現代的扁平化流程就是為了解決這些問題而生：
現在的產品需要因應顧客的要求，快速改正所需要的內容，所以需要有更短的流程與測試回饋，這裡就就介紹現今扁平式管理的主流方式——Scrum 工作法（這個工作法會在之後有更詳盡的介紹）。
這個流程最主要改善的有下列幾點：
優點１：流程透明化，每個人知道自己的負責範圍
Scrum 透過白板與便利貼的方式，讓所有人都知道目前的專案進度，進而加速整體的工作速率，也透過透明化，降低活動無法順利完成卻隱瞞不說的狀況。並讓每一個都可以知道並互相監督彼此的工作，提升整體的工作效率。
也解決「責任越大，權利越大」的問題，位在團隊內，每一個人都是缺一不可的，因此在這個專案裡，只有負責每個 Task 的人，沒有上下位者的指示問題。這也代表，可以減少主管偏心而導致專案概念的不一致，進而減少內部的爭吵，因為 Scrum 本身就是建立在大量溝通的基礎上。
也解決「責任越大，權利越大」的問題，位在團隊內，每一個人都是缺一不可的，因此在這個專案裡，只有負責每個 Task 的人，沒有上下位者的指示問題。這也代表，可以減少主管偏心而導致專案概念的不一致，進而減少內部的爭吵，因為 Scrum 本身就是建立在大量溝通的基礎上。
優點２：解決彼此分工不明確，降低整體成本
Waterfall 的一大弊病就是為了規範權責相符，所以某 A 會的技能，雖然可以解決 B 的大問題，卻因為沒辦法有適量溝通與討論，而白白浪費了這樣的技能。現在，因為 Scrum 依靠大量的溝通基礎，可以利用每日極短期例會的方式，快速提出每個人面對到的問題，讓團隊的其他人能夠利用自己的能力，幫忙解決其他隊員所遭遇的問題。
而這樣的方式優點還有一個，就是能在籌備的過程中，隨時加入一些好的活動或是修正內容，隨後馬上進行測試，此舉解決了 Waterfall 只要更改需求或是文件，就需要重新跑一次流程，能夠大大減少重新執行流程中，重新編寫文件的資源浪費。
優點３：極短期的產品週期，快速推出並更新產品
Scrum 採用衝刺（sprint）的方式，快速測試並修正產品。衝刺就是在一個固定的時間區間內（例如兩個禮拜），迅速完成一次的原型（prototype）開發，原型是指可以拿出來給客戶或是觀眾的實體產出，讓客戶與觀眾快速的給予回饋與修正。這個模式可以解決 Waterfall 更改初始文件（像是活動企劃）時，所需付出的高昂時間與財務成本，而且過長的審核流程會拖慢整體產出的進行，很多時候，專案會做得很趕、做不完，不是因為時間不夠，而是大多數的時間都在等待，或是做完了才開始花時間修改。
這樣還有一個最棒的優點，就是可以借由這個方式，估算每一次衝刺時所需的時間，就能平均估算出整個專案所需要的完成時間，且就能較精準的估算整個時程。只是 Scrum 並不會把整個專案非常詳細的規劃出流程，由此延伸出的優勢就是：更能彈性調整流程，不會因為圖突發性的意外，就必須重新撰寫時間規劃。
結論：
看完 Waterfall 與 Scrum 的規劃，好像扁平式的管理似乎就完美的贏過瀑布式的管理流程？其實，沒有這麼簡單。首先，大家最習慣的還是瀑布式的流程，因此就算引入了新的方式，大家還是會習慣用舊的思維去做事，反而造成事倍功半，還讓別人覺得管理不佳：再來，如果之前有留下好的文件（當然這個很難啦），的確是可以減少下面帶活動或是做事的人的困擾，因為只需要照著指示做，很少需要指示，更不用說需要 Scrum 複雜的分工模式，還會牽涉到在上面的管理者需要釋放許多的權力，更會讓已經習慣這套模式的人感到反感。
要使用這套新式的工作方式，需要的就是——有一顆想學習的心，以及接納改變的勇氣。他是一個需要我們挑戰舊有思維的方式，如果願意去嘗試新的方式，省下的不只是成本，還有屬於你寶貴的人生。現在，就開始改變吧！
之後還會持續推出 Scrum 相關的文章，歡迎大家多多指教以及更正！
沒有留言:
張貼留言