這週末去上了 Nor 神老師的課程: 服務設計進階實戰之驗證與權責. 主要是在講述 RACI, KANO 和 六頂思考帽等方法. 身為棒球迷的我, 怎麼能錯過 KANO. 因此, 二話不說就報名上課了.
RCAI 用來了解組織中, 某個工作流程中, 其各個角色及其相關責任的關係. 他用一個表格來表示這個關係. 其中, 縱軸代表工作流程的步驟. 橫軸代表參與此工作流程的各個角色
表格中的 RCAI, 其意義如下:
A: Accountable, 對整件事情的成敗負上責任. 只有經其同意或簽署之後, 項目才能得以進行
R: Responsible, 負責執行該項工作的人員, 負責回報進度與狀況
C: Consult, 代表諮詢, 提供資訊或者諮商, 協助工作進行
I: Informed，代表知會, 會被告知工作的狀況與進度, 但不直接負責該項工作.
從這個表格中, 你可以觀察到一些有趣的事情. 例如
有個橫軸沒有角色扮演 A, 也就是只有做事的人, 但沒人負責
有個橫軸有多個角色扮演 A, 多頭馬車事情能做得好嗎?
R 都集中在某些角色上面, 這代表他的工作量太多
A 都集中在某些角色上面, 這代表他的管太多, 這個團隊太不自組織了
這讓我想到 kanban board 這設計, 我們在設計 kanban board 時, 會放一段時間, 觀察其流動狀況, 知道那邊被阻塞, 那邊很閒, 然後再調整流程, 或是訂出 policy 來改進.
但是這需要花一段時間後, 大家才能看得到其變化. 另外, 也有人會說, 即使過了一段時間, 從 kanban board 中, 還是看不出門道. 這有可能是你 kanban board 設計得不好. 但是, 不管怎樣, 總是要花段時間後才會知道.
但是, 如果一開始能搭配 RACI 表格, 你就可以很快看到有問題的地方, 然後就進行修正. 例如, 如下表所示, 每次高階架構設計, 都要 architect 和 JM 批准, 那開會時就要這兩個角色都在, 有些時候還蠻麻煩的. 如果只是讓某個人做最後決定, 或許會有效率些.
JM architect UX FED Backend QA
高階架構設計 A A I R
UI mockup AC R IC I IC
撰寫程式 I C I R R I
測試 I
或者你可以先放著不理, 但是你至少知道哪些地方要注意, 你可以在 kanban board 上, 特別注意這些地方 task 的流動, 是否會你想的那些問題發生.
例如: UI mockup 設計, JM 需要確認是否這是他想要的產品, FED 要從可行性上來確認是否做得到, QA 會需要建議各種情況是否考慮到, 因此, 可以想像這個活動會很沒效率. 但是目前如果沒有更好的做法, 或許只能留校觀察, 看看 kanban board 的流動, 是否也是呈現這樣的現象.
See, 有 RACI 的幫助, 是不是讓事情變得簡單了. 有時候異業交流, 可以帶來很多靈感, 來改善你目前的工作.
課程資訊: 服務設計進階實戰之驗證與權責 – Kano與RACI方法
全站熱搜
留言列表
