敏捷團隊的精實秘訣

敏捷團隊的精實秘訣

近年來許多軟體開發相關企業導入敏捷管理,期望可以提升開發效率,事實上敏捷團隊之所以敏捷的主要原因來自於精實的運作 — 包含組織結構與需求範疇。後者可透過MVP ( Minimum Viable Product ) 的概念實踐,意思是將產品或功能切分至最小可執行的單位,開發完成後立刻放到市場上測試是否可行,並且反覆驗證調整。

由於專案範疇變小,自然有機會縮短完成時間,展現出敏捷的結果。

但是很多時候sponsor會抱怨敏捷團隊沒有發揮敏捷的功效,原因很多,其中之一便源自於「需求管理」,團隊被過多的雜訊(例如客訴、營運需求、會議...)牽絆,原本精實的團隊逐漸膨脹,降低了開發的能量。

通常產品團隊在初期開發階段相對容易保持精實的狀態,但是當第一個產品上線,即使是最小的MVP範疇,也會伴隨越來越多的客訴、改善建議等營運議題須處理,再加上原本排定的開發任務,此時便會開始出現排擠效應,在資源、時間有限的情況下,團隊必須當機立斷選擇最急迫也最重要項目來處理,以下是幾個可以評估的指標 :

1. 是否符合產品的核心價值

任何的產品或服務,通常會有特定的幾項主打、或者最受用戶好評的功能,這些項目常是用戶對產品的記憶連結,若能讓用戶有良好的體驗,用戶對產品的忠誠度就會漸漸提高。例如Samsung推出可折疊螢幕的手機,螢幕的耐用度、畫質就是產品需要特別著重的地方,反之,待機時間、相機畫素雖然也是普遍用戶的基本需求,但相形之下,可歸類為產品次要的功能。

但從另一個角度來看,或許有人會主張優先維護基本盤,再來處理那些差異化服務,此時團隊必須回頭檢視最初設定的產品定位為何? 提供給用戶的核心價值是什麼? 團隊必須對這些目標有一定的共識,才有辦法決定要將資源投放到何處。這個議題有時不是團隊內部論證就能獲得解答,必要的話,產品負責人必須召開會議佈達。

2. 是否直接影響用戶使用

一個新產品推到市場上,我們期望從使用者身上取得各種面向的回饋,藉以改善產品,這是敏捷管理一個重要的精神,然而,哪些需要加強關注,哪些有緩衝的時間,便需要做好區隔。

產品團隊不妨事先定義幾種問題類型,例如「錯誤產生,導致無法達成使用目的」、「不良的操作體驗,但仍可使用」、「特殊的使用情境造成錯誤」、「用戶的期許」...等,再依據這些類型的急迫性與重要性,給予適當的處理排序,一般來說,會直接影響用戶使用的問題,應該要被優先解決,但若是用戶透過「非常態」的操作方式所導致的錯誤,團隊或許可以思考用戶是否有額外的需求,或者是原本的設計會讓人產生誤解,先釐清問題背後的涵義再決定如何處理,以及何時處理。

有些產品團隊非常重視用戶的權益,只要是用戶提出的問題或建議,一定優先急件處理。這種服務至上的態度雖然很棒,但很容易影響團隊步調,甚至將產品的發展推向一個不同的方向。如同前述,產品所設定的核心價值是引導團隊前進的北極星,任何的改善及優化都必須確保與目標一致,尤其敏捷團隊的開發週期短,在切割範疇的時候,容易過度考量短期成果而忽略長期策略方向,此時Scrum Master與Product Owner必須要有良好的溝通,拿捏兩者之間的平衡。

敏捷團隊不像傳統專案團隊PM擁有相對的掌控權,團隊中更強調分工協作,其中Scrum Master主要權責在於維持流程運作、協助進行溝通協調、幫助團隊去除障礙,也包括控制每一次Sprint週期(註1)的需求範疇,確保團隊可以維持精實狀態。Scrum Master的容易出現的盲點,是過度限縮範疇,雖然這種做法能夠維持團隊穩定運作,但拘泥在過小的議題上,可能會誤將功能拆分過細,導致每次的產品改版都衍生更多待解的問題,或者讓產品變成七拼八湊的拼裝車。

由於Scrum Master分攤了PM的管理責任,因此敏捷團隊中的Product Owner將更著重在需求的掌控上,為了配合團隊的開發節奏,及避免上述過度限縮的問題產生,Product Owner如何定義MVP就顯得格外重要。較好的做法是需求先被適度分類,並且經過足夠時間的分析、規劃後,產生完整的規格(或至少能匡列完整的範疇),接著才去評估如何拆解成MVP。

當Product Owner沒有餘力環顧整體樣貌時,就會反過來被需求追著跑,久而久之就可能偏離原定的開發方向,我過去就曾有過這種「為了配合運作Sprint週期而每周都在趕製規格」的失敗經驗。

總結來說,敏捷團隊必須靠有效的需求管理來維持精實的狀態,而需求管理並非一味縮小範疇,還需要團隊成員共同努力,時時刻刻對齊核心價值與目標。

註1 : Sprint週期

Sprint指Scrum團隊完成一定數量工作所需的時間,又稱為衝刺期,每個Sprint結束後會有一定的產出(或者產品版更),緊接著又是下一個Sprint開始,周而復始。Sprint周期長,應變的彈性比較小,反之若太短,則不容易有成果產出。以6-8人的Scrum團隊為例,目前較常使用的周期為2-3周。

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
VictorHsu

曾經主修科學,也當過工程師寫過程式,其實最大的興趣卻是是寫文章說故事,目前在網際網路產業擔任PM工作。 自認只是職場上的小人物,但深知專案管理的知識應用廣泛,2011年取得PMP證照後,開啟對專案管理的學習之路,於是結合自身的經驗,以及大眾最熟悉的電影劇情,讓生活、理論與虛構的情節在專案管理的世界裡產生交集,期許能引領更多同好認識專案管理。