同理心拯救世界

敏捷在設計團隊中的實踐

本文將分享從無到有建立團隊的經驗:一個以敏捷為基礎的體驗設計小組。

全文將分為三個部分:

  1. 為什麼是敏捷
  2. 如何建立並維繫敏捷的設計團隊
  3. 確切用了什麼方法

為什麼是敏捷

好的職場是工作者氣色都普遍不錯,經常期待上班的地方。
但要如何形塑甚至維持這樣的團隊,就必須從雇傭關係的原始驅動力去拆解。

公司期待的是:員工為公司創造價值(因此公司才能維持運作,甚至有更多反饋給員工)
員工期待的是:快樂的工作 (雖有點籠統,但需搭配下方服用)

這兩者間的交集,便是淨土。

快樂?

自我認同與肯定、良好的家庭關係和社會支持、健康飲食與規律運動、豐富的休閒生活

除了理想的設計團隊外,從以往設計師工作的歷史也可看出和軟體開發相似的痛點:環境快速變化的不確定性、頻繁的需求變更、產品完整交付過程中跨專業的溝通落差

以往這些軟體業的痛點被歸咎在採用了工業時代瀑布式的開發方法,敏捷的出現希望可以一定程度的協助團隊優化這些問題。
既然痛點如此相似,那又如何不能深入理解後,嘗試跨出工程團隊做應用呢?

如何建立並維繫敏捷的設計團隊

首先,我們需要對敏捷精神有所了解,因此配置至少一位具備 Scrum Master 能力的成員,隨時留意成員狀況,適時提供任何人協助,會是比較好的開始。

敏捷有很多的方法和框架,但基本精神就是為了讓大家可以「有效率並開心的創造價值」


浪費,是商業損失,更是社會犯罪。

— 大野耐一,豐田生產管理


在這個精神之下,我們採用最廣為應用的敏捷框架:Scrum

不管過程中如何應用框架的建議活動達成運作,都必須確保所有人具備下列概念:

如何做到確保大家有這些觀念?觀察力 很重要。

例如,缺乏透明度的現象:部分成員不喜歡在大家都在的場合講問題,常私底下兩三個討論。
處理方式是,挑一個內容在大家都在的場合引發討論,並當場集結眾人智慧嘗試解決或優化此問題。事後,打鐵趁熱幫大家回顧「透明度」這根柱子。
當然問題沒有辦法馬上處理也沒關係,剛好可以趁機強化大家對「檢視、調適」的理解。

在有了三大支柱概念後,加上有隨時強化他們的觀察和調整,就可以加入一些更實際的內容:「敏捷宣言」。

不管何種職能的人,工作久了都會因為過程中遇到的一些小困難,而建立某些很堅硬的觀念。
但所有事物都是一體兩面,能夠保護他的,就可能傷害別人。
我們為了維持創造力,不需讓所有人變成標準品,但我們有一些大家可以一起隨時提醒自己的原則,讓團隊成立的目的能持續達成。

「重視個人與互動大於流程與工具」:
越成熟的工作者,會有越多提高效率的流程或工具。
但團隊的合作中,若是有橫跨不同專業的成員,彼此所謂的最佳作法,一定會對另一方造成某種不便。而這種時刻的協調結果,就會大大的影響到整體的產出價值。
但若是所有成員都有「重視個人與互動大於流程與工具」的觀念,那麼在「以最佳效率達成本案團隊共同目標」的前提下,不論何種複雜情況,一定都能一起找出解決辦法。

確切用了什麼方法

理解那些是敏捷基礎功後,就可以更順利的應用好框架。
甚至在理解每個方法的本質後,可以彈性調整滿足不同情境。

整個 Scrum 框架在做的就是用一個流程,幾個簡單的活動,讓團隊可以面對複雜(Complex)的環境與需求。

簡單(Simple)
感受→歸類→反應(Sense-Categorise-Respond)

繁雜(Complicated)
感受→分析→反應(Sense-Analyze-Respond)

複雜(Complex)
試探→感受→反應(Probe-Sense-Respond)

混亂(Chaotic)
行動→感受→反應(Act-Sense-Respond)

我們的 Scrum Team 分成兩種:設計團隊專案團隊

設計團隊內的 Product Owner 是組長,Product 是內部系統設計規範,Product Goal 是「協助公司所有內部系統打造視覺一致、體驗一致、員工用起來省時有效率的軟體介面」。
在團隊產品的遠中長程策略中,更包含了「易維護的永續系統」願景。

專案團隊內的 Product Owner 是專案經理,Product 是特定資訊系統,Product Goal 是專案 KPI/OKR。

接下來我們用假設的角色情境來讓大家更容易明白整個運作方式。

設計團隊:共 8 人。
每日 9:15-9:30 開設計小組站立會議,同步工作內容和問題,有問題馬上或會後處理,組長隨時觀察同仁狀況提供協助。
每 2 週一個 Sprint,約一個月開一次 Review(團隊內),一季開一次深度 Retro(團隊內)

專案團隊:共 12 個,設計團隊中每個設計師負責 1-2 個專案的 UIUX。
每週「固定時間」開 1-5 次不等的例會,頻次依經驗判定(產出相依性、時程緊急度、需求穩定度等),例會上成員同步工作內容和問題,有問題馬上或會後處理,Scrum Master 隨時觀察成員狀況提供協助。
每 2-4 週一個 Sprint,1-2 個 Sprint 開一次 Review (團隊+利害關係人),2-4 個 Sprint 開一次 Retro (團隊+主管)

設計專業的內容和問題在設計團隊中揭露和處理,專案相關的內容在專案團隊中處理,彼此之間形成有效率的正向循環。
組長也需要適時參與專案的會議,實際了解組員的執行狀況,甚至觀察到更多可優化的問題。



發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料


向上滑動