Managertoday 經理人

專案總是「加預算」還做不完?試試Apple、Google都在用的敏捷式工作法

2018-08-21 12:28:11
Managertoday
https://bnextmedia.s3.hicloud.net.tw/image/album/2018-03/img-1520836460-43302@900.jpg
回想一下你的組織的工作方式,是不是都會先做好所有規畫、工作細節,再分派成員按部就班地執行?結果卻總是無法按照計畫走,一個部門的延宕導致下一個環節卡住,整個計畫延期不說,趕在最後交出來的成品,卻還是錯誤百出?

(本文出自《經理人月刊》2018 年 3 月號,封面故事:圖解SCRUM工作法

回想一下你的組織的工作方式,是不是都會先做好所有規畫、工作細節,再分派成員按部就班地執行?結果卻總是無法按照計畫走,一個部門的延宕導致下一個環節卡住,整個計畫延期不說,趕在最後交出來的成品,卻還是錯誤百出?

到底這種工作方式,出現了哪些問題?我們以美國聯邦調查局(FBI)的例子來說明。

先擬定完整計畫再執行,容易導致工作時程拖長

由scrum發明人傑夫‧薩瑟蘭(Jeff Sutherland)撰寫的《SCRUM:用一半的時間做兩倍的事》一書提到,在美國發生九一一恐怖攻擊事件之前,聯邦調查局當時有一套自動化歸檔資料的系統,卻因為系統速度遲緩,多數人仍採用紙本歸檔,每項資訊需要經過層層主管簽核,導致效率低落。

九一一事件之後,這樣的資訊系統就遭到世人詬病,明明當時各方消息都指出有恐怖組織成員進入美國,卻因為資訊系統未能串接,導致無法提前利用有效情報。

因此,為了改善既有資訊系統的缺點,聯邦調查局於 2006 年啟動了名為「哨兵」(Sentinel)的系統開發計畫,預計要花 4.51 億美元,並於 2009 年正式上線。但直到 2010 年 3 月,該計畫已花了 4.05 億美元的經費,卻只完成一半的進度,至少得再進行 6 至 8 年才能完成,預算更需要追加 3.5 億美元。

當時接手這項計畫的聯邦調查局主管,發現無法如期上線的原因, 並非團隊成員不夠專業,而是這套系統的開發流程太緩慢 :團隊成員先找出系統有哪些需求,接著決定這些需求要透過哪些功能滿足,並排定每一項功能的執行與完成時間。擬定非常完整的計畫之後,才能開始進入開發、測試階段。這種一定要先做好完善的流程規畫,再開始分頭執行工作稱做「瀑布式」(waterfall)工作法。

瀑布式的工作方法聽起來合理,也符合多數工作者與組織做事的邏輯,但它為什麼會成為失敗的主因?最大的問題,出在 我們並不能確定一開始擬定的計畫,百分之百符合未來使用者、市場需要的產品功能。

計畫表假設「完美進度」,無法應付突發狀況

過去設計一項產品,可能得花上好幾個月的時間,進行市場分析、調查,才得以規畫產品功能。這時候往往會用工作者熟悉的甘特圖(Gantt Chart),畫上每個階段的任務與完成時間。不過,甘特圖並不能告訴你,實際的工作流程出了哪些問題,多數時間它的功用,只會顯示「完美情況」下的進度表。

加上從計畫到實際推出產品的時間,通常存有一大段落差,當時的假設、預測是否仍有效力,沒有人可以準確預測。

再回到聯邦調查局的哨兵系統,2010 年他們更換了新的技術長與資訊長,還把專案參與成員從 400 人刪減至 40 人。不過,他們竟在一年之內,只花了 3000 萬美元,等於節省了 90% 原先預計要增加的預算,便完成剩餘一半的進度,更在 2012 年正式上線。

哨兵計畫能在短時間、低成本內完成的關鍵,在於他們導入 scrum 工作方法,以兩個禮拜為周期專注在開發,稱為「衝刺」(sprint)。每次衝刺結束之後,都要求團隊做出能替產品增加價值的功能或服務,也就是所謂的「增量」(increment),改善了過往走到最後一步,才能看見產品全貌的方法。

同時,他們會邀請未來實際使用的探員、其他政府單位的代表,每次衝刺期後就給予這些產出回饋,如此一來,就能避免瀑布式無法跟上使用者需求的缺陷。開發團隊接著便可以利用這些回饋,在下一次的衝刺中,即時調整開發方向。

完成、未完成進度都公開,促使團隊一起排除困難

瀑布式工作方式的另外一個缺點,則是它的工作銜接方式,由一個環節接著一個環節推進。換句話說,當上一個階段的人拖延進度時,接手的人也無法開始動作,導致計畫延誤。

要突破這些困境,擁抱「敏捷」精神(agile)是最有效的解決方法之一。2001 年,由 17 位軟體開發相關的學者、專家共同提出了《敏捷軟體開發宣言》,內容提到 4 個重點: 團隊互動重於流程與工具、創造可用的軟體重於詳盡的文件、與客戶合作重於合約協商,以及回應變化重於遵循計畫。 不難看出敏捷精神,圍繞在團隊溝通以及擁抱改變。

而在敏捷精神之下,更發展出各式各樣的工作方法,根據 scrum 的主要認證機構之一 Scrum Alliance 於 2016 年的調查,其超過 2000 間的企業會員,就採用了scrum、kanban(看板)、lean(精實)等不同的敏捷工作方法。

其中 scrum 可說是最為廣泛採用的工作方法,有超過 89% 的企業,選擇用它做為唯一或其中一種工作方法。

在 scrum 的流程中,團隊會增加彼此溝通、互動的頻率,規畫產品需求、排列任務優先順序的需求,也都是團隊互相討論的結果,成員還必須公開說明每個人的考量與工作內容。

衝刺期間利用「每日立會」(daily scrum)的方式,掌握彼此的進度,成員可以從中充分知道,哪些事情拖累速度,可即刻對彼此伸出援手。最後,便能在短時間內產出一定價值的產品,供市場、使用者提供回饋,再利用這些回饋,精進自身產品。

讓顧客感受提出的要求,能快速有效地被滿足

回到哨兵計畫的結果,scrum 可加速開發的進程,但這不僅是 scrum 的功用,重要的是它協助組織應對改變時,能更加靈活。由於 scrum 的每一次衝刺期之後,都需要和客戶或未來的使用者溝通,了解他們的需求或價值是什麼,這次衝刺的成品是否有切中他們的痛點,並在下一次修正。

所以,當團隊能夠靈活反應快速變動的需求時,前期開發的時間降低,因此才造成採用 scrum 之後,工作速度加快的感覺。而在 Scrum Alliance 的報告中也顯示,超過 7 成的企業認為,採用 scrum 之後,能把企業創造的價值有效傳遞給使用者。

或許你還有個疑惑,scrum是否只適用在科技、軟體開發領域?從國外企業採 用scrum 的實際案例來看,不只是 Goolge、Apple 等大型科技公司採用,包括銀行、數位行銷公司等都有採用 scrum。

Scrum Alliance 的報告中也提到,在一間接納scrum的企業中,平均已有 21% 非 IT 性質或部門的專案使用 scrum 完成。其中,又以製造、研究、行銷和人資部門為大宗,代表不只是開發部門,任何性質的團隊,都有可能透過 scrum,改善過去沒有效率的工作方法。

因此,想要打造出更具有團隊合作精神的組織,scrum 就是你最好的選擇。如果你也希望可以變得更加靈活,就跟著我們的腳步,一步步學會怎麼善用它。

瀑布式 vs SCRUM 工作法

瀑布式工作法與 scrum 有著非常不同的流程,前者透過事先完整的計畫,成為後續執行的依據,但由於執行時程較長,無法因應中間變化,完成品可能已與市場需求有落差。scrum 不要求第一次就把產品做到位,而是透過短時間內重覆「產出、檢視、改善」的循環,找到滿足使用者與市場需求的方向。