管理 Management > 產品與專案
feature picture
4

敏捷團隊怎麼做?兩周一次「衝刺會議」,即時修正小錯誤

採訪‧撰文 盧廷羲
2020-09-23
分享
收藏
已完成
已取消

在 1969 年,美國阿波羅 11 號登月小艇成功登月,這個專案共計花費達 254 億美元(約新台幣 7620 億元),迄今仍是人類史上最貴、最大型的專案之一。這個專案能成功,除了各團隊的緊密配合,其中一個原因,是主事者、時任美國總統約翰.甘迺迪(John Kennedy)早在 1961 年 5 月宣布這個宏大夢想時,也向外界宣告明確的截止日,「在 1960 年代結束之前達成」。

期限,給了團隊努力目標。《專案管理革命》提及,時間是專案最重要的一項因素,如果不明確、堅定、正式並公開截止日,專案很可能會比原定計畫延遲完成。「重視時間」是企業設計一項新產品,能否順利完工、量產,很重要的關鍵,這有賴產品經理的掌控。

設定各個子任務截止日,追蹤各團隊進度

掌控進度最難的,是各個團隊能否在截止日前達到你的要求,如期交付。《專案革命管理》作者安東尼奧.羅德里格茲(Antonio Rodriguez)指出,在專案的初期,產品經理就要明確列出各種不同的截止日,包含什麼時候測試原型、預計何時上市,「不肯花一個星期討論時間範疇,最後只會延遲更久。」

Google 眼鏡(Google Glass)上市時,曾被《時代》雜誌(Time)評為「2012 年最有創新力的產品」但最後卻停產,原因就是團隊沒有明定產品的上市日期、銷售管道,直到 2014 年,才正式向全球發售。

甚至,Google 創辦人賽吉.布林(Sergey Brin)把 Google 眼鏡視為終端產品,但工程師們都知道,其實這只是原型,還需要修正。相較之下,蘋果(Apple)每年舉辦發表大會,替新產品創造話題,使團隊有紀律按照時間流程工作。

制定截止日的具體做法是,同步實施「由上而下」與「由下而上」的規畫。首先,產品經理決定完成專案的時間點,再把專案拆分成大小事項,由團隊的創意發想人員、工程師等部門,評估可行性,來回協商、確認最終版本。理想的情況,每 3~5 周就要設定一個「中間截止日」,也就是某個小的里程碑。

產品或專案領導人也要注意節奏掌控、檢查工作內容,因為每段時間並非「等值」。產品開發的第一周,與上市前的倒數一周,所有員工的心態一定不同,愈接近後期,人們愈容易緊張,也更可能犯錯。

兩周一次衝刺會議,及時修正小錯誤

然而,即便設定了截止日,還是有可能延宕。《騰訊產品法》指出,這可能是團隊成員被其他任務纏住,導致沒做重要的事;或是產品需求不斷變更,拖延進度。這幾個問題,都能用敏捷開發(Agile Development)的精神來解決。

國泰世華銀行數位銀行部經理李健輔認為,跑敏捷流程並不會使工作變得更快,但是能提高及時修正的能力。敏捷開發,能讓產品或專案以「小步快跑」的方式前進,因為能用這當中的衝刺會議(sprint)環節,每兩周討論一次,當務之急到底是什麼。

國泰 koko 數位帳戶推出記帳功能時,許多用戶反映,希望打開App能直接記帳,不要再花時間登入,但當時屬於產品開發前期,最重要的事是優化界面、確保系統穩定。用戶的這項期待,屬於次要需求,就要放到後期處理,「要確定之後有安排時間來做,」李健輔說。

更重要的是,當團隊在短期內,頻繁的開衝刺會議討論,不會等到各部門工作時,才出現「你有你的問題」「我有我的意見」,而是所有人都站在產品經理的立場,取得共識。

掌握 3 要點,確保工作按照進度走

國泰世華銀行數位銀行部經理李健輔於 2017 年接管國泰 KOKO App 時,評價只有 1.9 顆星,經過優化、改善介面,如今 App 有 4.8 顆星。

1. 提前統整跨部門需求

設計「free's貸」產品時,牽涉到15個橫向部門,各部門有不同要求,像是產品法規。在前期就向各部門溝通最重要的需求,後期才不會「卡關」。

2. 頻繁舉行衝刺會議

每兩周開一次衝刺會議,討論產品短期的修正路線,能迅速發現缺點,進而改善,不會等到3個月過後,發現市場動態改變,才重新調整大方向。

3. 召開回顧會議

這個會議上,請所有人針對工作流程提供意見,改善做事方法與達成更多共識。如此一來,下一次的衝刺會議才能更有效率。

相關文章
管理 Management > 產品與專案
feature picture
1

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

整理.撰文 陳彥丞
2018-03-12
分享
收藏
已完成
已取消

(本文出自《經理人月刊》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 不要求第一次就把產品做到位,而是透過短時間內重覆「產出、檢視、改善」的循環,找到滿足使用者與市場需求的方向。

相關文章
領導 Leadership > 團隊管理
feature picture
2

「每日立會」怎麼開? 15 分鐘追完進度、迅速決策的敏捷式會議,一次學會

《經理人》編輯部
2014-09-02
分享
收藏
已完成
已取消

開會時,你是坐著或站著?

坐著開會是再平凡且自然不過的光景,但是,站著開會卻能透過身體,協助與會者掌握時間、更快速地達成會議目的。根據密蘇里大學(University of Missouri-Columbia)商學院教授艾倫 ‧ 布魯頓(Allen Bluedorn)的研究指出,坐著開會雖然舒適,但也可能讓與會者忽略時間的流逝、拖慢會議效率,因而平均比站著開會多用上 34% 的時間;而且,坐著開會所得到的決策品質,和站著開會相差無幾。也就是說:

一個站立會議只要花 10 分鐘就能解決的問題,一旦讓所有成員坐下來,就必須花上 44 分鐘,才能得到同樣的結果。


站著開會(Stand-up meeting)
適合人數:5~10 人
所需時間:15 分鐘內
適合頻率:每日尤佳
採用企業:趨勢科技、福特汽車


但是,因應與會者的體力與精神,站立會議也有其限制。

1990 年代竄起的軟體開發方法──敏捷軟體開發(Agile software development),是第一個將站立會議原則化、方法化的實作理論。根據敏捷開發中 「每日立會」(Daily Stand-up Meeting) 的原則,站立會議主要被用來追蹤個人進度,每天必須在同一地點、同一時間內舉行,並盡量控制在 15 分鐘內結束。

與會者依照參與程度,被區分為「豬」(實際執行者)與「雞」(相關人士),只有「豬」可以在會議中發言;而在會中,所有的「豬」都必須回答 3 個問題:昨天做了什麼?從今天到明天開會前,打算做什麼?目前在執行上,遇到哪些困難?

由於站立會議只適用於簡單的進度追蹤,所以一次只限一個人發言,相關細節也必須留待會後私下討論,才能達成快、狠、準的高效率原則。

DOs

  1. 即使有成員遲到,也要準時開始
  2. 開會時間愈早愈好,當作一天的開始。
  3. 在記錄團隊工作狀況的白板旁開會。

DON'Ts

  1. 人數勿超過10人、時間勿超過15分鐘。
  2. 不要在會中處理問題,留待會後。
  3. 不要在會中作筆記,專心聆聽。
繼續閱讀 會議
相關文章
管理 Management > 人力資源
feature picture
3

想讓組織變敏捷,導入 Scrum 工作法只是開始!人資還該做的 2 件事

採訪‧撰文 陳彥丞
2018-07-31
分享
收藏
已完成
已取消

最近「敏捷」(Agile)二字當紅。為了提高順應市場的能力,愈來愈多組織拋棄舊有的工作方式,選擇擁抱敏捷管理,要用更短的時間找出最適合消費者的產品。不過,與產品關聯相對間接的人資、財會等後勤部門,又該怎麼做,才能跟上產品團隊的速度,提供強大的後援?

事實上,這些看似不容易快起來的部門,其實可以走得很前面。鈦坦科技組織發展部經理 Jasmine Huang 分享她們的研發團隊導入 Scrum 之後,人資部門如何調整既有的業務內容,以貼近敏捷管理的需求。

改變招聘流程:讓面試者試著加入團隊,提前了解適不適合敏捷

敏捷和過去的工作方法十分不同,對人資團隊而言,首要的任務就是招募到「對的人」。而達成這項目標的手法,是在面試過程就加以把關。

在鈦坦科技新加坡總部的做法,是把面試拆分為兩個階段,第一階段考驗面試者的技術,通過之後,再提供一段關於敏捷的影片,變成第二階段面試的重點:衡量他是否能理解敏捷的思維。

因此,申請者除了在第二階段面試時,分享他對影片的心得之外,「我很喜歡問一個問題,」Jasmine說,「問他有沒有不同意(敏捷)哪些地方?」藉此了解對方,是不是確實吸收了影片內容,並鼓勵對方思考自己是否合適。

特別的是,Jasmine 提到如果是應徵資深工程師、Scrum Master 等較高階層的員工時,還會邀請他進入團隊試做幾天,甚至給付日薪。她解釋,由於 Scrum 強調團隊合作,對面試者來說,能先了解未來要待的團隊有什麼樣的成員和風格,對原本的團隊來說,則可以判斷能否和對方合作。

鈦坦科技台灣分公司組織發展部經理杜秉蓉補充,台灣面試流程也有類似的做法,第二階段時會邀請現任團隊成員,和面試者介紹、溝通工作內容與方式,用意同樣是確保雙方都可以先了解彼此,降低未來出現不適任的情況。

改變升遷規則:要求員工主動申請晉升,藉此得到回饋

而升遷制度,則是人資在組織導入 Scrum 後,另一個會面對的關卡。由於 Scrum 團隊中極為強調自主性,主管的角色相對式微,那究竟是由誰決定每年的考績和升遷呢?

杜秉蓉回答,首先要區分為後勤部門和 Scrum 團隊。後勤團隊即使在組織導入敏捷,仍然維持個人考核的方式。不過, 個人考核並不是以分數衡量,也不完全與獎金連結,而是以整體團隊、部門的表現做為衡量標準。

至於 Scrum 團隊,則採用了一套新的升遷計畫,替換原本個人考核的制度。傳統考核會跟升遷機制綁在一起,大多是員工和主管一對一之討論後,便由主管單方面判斷是否可以晉升。

然而,在 Scrum 強調團隊和回饋的重要性之下,她們希望升遷制度可以符合相同的精神。因此在新的升遷計畫中改為員工可以主動申請、每半年提出晉升的要求。如果員工決定申請,接著會經歷以下 3 個步驟:

  1. 自我評量:公司會公布部分職等在各項能力的計分,像是撰寫程式、測試等方面。第一步,員工必須根據這些項目,衡量自己的程度。如果覺得自身程度已符合下一個職等的需求時,就能夠繼續申請。

  2. 技術評鑑:申請之後,會交由團隊內較為資深的同事,先檢驗申請者的能力是否確實進步。但杜秉蓉表示,技術檢驗的分數,和能不能走到最後一關,並沒有直接的關係。因為她們還是希望申請者,可以接收到技術以外更多的回饋,才能達到她們設計這種制度的用意。

  3. 團隊評估:最後由部門主管、一位主管挑選的團隊成員、一位成員挑選的團隊成員、產品負責人和人資,共 5 位組成類似評審團的角色,一起和申請者討論,並給予正面或需要加強哪些能力的回饋。而最終結果則由這 5 人進行投票,且全部人都認同時,申請者便可以成功晉升。

Jasmine 強調, 升遷不應該只是看最後的成功、失敗,重點是申請者能「自主」提出申請,並藉由不同人的角度,全方位了解自己在工作上的表現 ,還有未來能夠努力的方向。這也是為什麼即使技術評鑑分數不高,也能夠繼續到團隊評估的原因。

事實上這套升遷計畫,就像是放大 Scrum 流程中的衝刺檢視(review)和回顧(retrospective),等於你進行了一次為期半年的衝刺,需要暫停一下腳步,看看自己的方向,是否還在正確的道路上。

「我們必須要了解自己的客戶,」Jasmine 指出,「而人資的客戶,就是員工。」對她們來說,從來都沒有不跟上的選項,而是不排斥任何改善制度的可能,才有辦法回應這些「客戶」的需求。

相關文章
會員專區

使用會員功能前,請先登入

  • 台灣首款對話式 AI 職場教練,一次提升領導力
  • 會員專享每日運勢、名人金句抽籤
  • 收藏文章、追蹤作者,享受個人化學習頁面
  • 定向學習!20 大關鍵字,開放自選、訂閱
  • 解鎖下載專區!10+ 會員專刊一次載
追蹤我們