2021年開始在跨國集團擔任設計經理，團隊人數從個位數到雙位數，遭遇疫情遠端工作，建立設計系統與流程，導入敏捷開發，跨國團隊溝通等等艱辛過程都是成長的養分，激勵且陪伴著團隊持續進步，來到第三個年末，有感而發，整理了一些筆記與心得作為反思。
考慮到篇幅，分為上下篇，本篇為下篇，說明第三種法則， ARCI 法則，並進一步說明，三種法則融入既有工作流程的範例。上篇介紹團隊使用的前兩種法則， Milestone & Checkpoint 觀念的建立與例行會議的規劃。歡迎先看上篇更通暢：
3.導入 ARCI 法則，釐清每個人的角色與責任
在大型專案中，尤其是跨模組專案，容易出現三不管地帶的議題，發現問題卻沒人回報或處理，導致時程延後或是品質不如預期，或是兩位設計師互相客氣，反而掉棒。除了適時提醒，幫助設計師了解自身定位，促進主動溝通，更有效降低憾事(|||ﾟдﾟ)發生的機率。
當時剛好在上專案管理的課程，學習到了ARCI法則，試著對應到團隊與設計專案上，並新增了Support角色好讓協作者也可以融入到架構中:
🥸當責（Accountable）：對專案的成敗負責，擁有決定權與否決權。
🤓負責（Responsible）：執行該專案的人員，需回報進度與狀況。
😎諮詢（Consult）：提供諮詢，協助工作進行，可能是外部人員，像 BA 。
😉知會（Informed）：被告知專案的狀況與進度，但不直接負責該專案，像PM。
😘支援（Support）：支援工作，協助工作進行，像跨模組的設計師或實習生。
視每個專案情況，會有不同的權責配置，像是較小的專案 A,R 會是同一人， C,I,S 不需要每個專案都有等等調整。團隊習慣在專案開始前確保 A,R,C 是誰，後續再依細節展開(使用 M&C 展開)，補上需要的相關人員( I,S )。
給予明確的權責，提升設計師對於負責專案的專注度，以往較常發生的，遇到小問題會忘記回報，導入後，除了降低遺漏問題，還會預想可能有什麼問題，又該如何對應，需要何種協助，有效降低掉棒等問題。
M&C+Regular Meeting+ARCIS
三法則逐漸的融入既有的工作流程中，回顧脈絡，最初專案量變多，建立 M&C 概念，快速追蹤專案的狀況，而後時間切割破碎，內內外外的會議，一天8,9次討論常常發生，建立例行會議時段，內部大型議題能集中處理，而溝通層面上的遺漏，導入 ARCI 法則，建立明確權責關係，鼓勵團隊主動溝通。
實作
每個專案都有對應的當責人(Accountable)，當責人與PM討論交付節點(可調整)訂出 Milestone ，而每個M&C會有對應的負責人(Responsible)， M&C 以類似 Task & Sub-task 的形式，建立在專案管理工具中以便瀏覽。
在 Weekly 會議上，依 Milestone (對外交付)的時間先後，依序說明進度與狀況(由該項負責人)，而後依照 Checkpoint 預排當週會議。將三種方法依上述整併到專案管理工具中，即為團隊的工作流程框架『 MMA 模式』(為什麼要取名🤔)，根據不同專案管理工具，會有不同的顯示方式，但大致範例如下：
Critique(Tue):
Checkpoint_11/20：A 專案，R1，新增元件評估會議， A 專案設計師與設計系統設計師。
Checkpoint_11/20： B 專案，R2，問卷設計初稿 review ， B 專案設計師。
Team meeting(Tue):
Checkpoint_11/20： C 專案，R3， Workshop - 新模組的用戶體驗指標，全體設計師(有空請參加拜偷拜偷🧎)
Critique(Thur):
Checkpoint_11/22： A 專案，R4，權限設定邏輯議題討論， A 專案設計師。
Team meeting(Fri):
Sharing：Fang a 日本留學生活，全體設計師。
投遞者作品集討論：全體設計師(都來都來歡迎參加)
p.s. 因為 Milestone 是對外部的交付，所以都是另約會議，除非重疊時段，不然不會出現在設計團隊的例行會議中，或許可以再寫一篇關於 Milestone 如何對外對接的實踐之路(我可能不會寫)。
不是死板的規定，是觀念的養成
沒有100%完美的工作流程，永遠會有意想不到的問題出現，從第一天開始，持續的調整與溝通，向團隊清楚的說明遇到了什麼問題，接下來將如何調整，為什麼要導入這樣的流程，最終獲得了什麼，每次架構/流程調整的緣由與結果，慢慢形成一種團隊認知，不論什麼樣的框架，什麼樣的流程，最終都是要解決問題以達成團隊目標，方法可以改變，但其中精神不變，是一種習慣，一種默契，一種共識，是團隊文化的產生。
從制度到習慣，從認知到文化
之前閱讀了許多文章，知曉團隊文化的重要性，但對於如何建立，始終模糊，經過三年來的歷程，多少有點實感，從制度到習慣，從認知到文化，或許可以再寫一篇關於團隊文化的實踐之路(我可能不會寫)。
上述框架僅是針對設計團隊的內部流程，並非是產品團隊或其他團隊的工作流程，另外每個設計團隊的外部流程/文化不盡相同，團隊定位與人數也不同，本篇文章僅作經驗分享，不建議直接導入原本的工作流程。
