板友大家好，我跟朋友一起在網路上分享產品管理、專案管理相關知識與經驗，
最新一篇文章是分享新加入的 PM 如何幫助團隊改善工作流程。
Medium 好讀版（我會複製幾乎全文過來，想看一些參考資料/延伸閱讀再點吧！）
https://pse.is/3h3egl
上篇文章《身為團隊第一個 PM 好難！我的辛酸血淚史與生存之道》中提到擔任團隊內第一個 PM 除了要肩負起做產品的責任外，優化團隊的工作流程也是很重要的一環。一來是團隊中多了 PM 這個角色加入後，大家的工作方法一定會有所不同；二來是要建立好的產品文化，一套好的工作流程絕對是不可或缺的。
【文章內容】
- 用服務設計的心態來開啟「改善工作流程」的專案
- 使用設計思考的五個步驟來執行
- 其他Q&A：歷時多久？誰該負責這種專案？
這篇文章一樣適用於小型團隊，當團隊足夠彈性且前期加入團隊的 PM 想要改善工作流程時。給大家一些靈感參考～
// 正文開始 //
▍用服務設計的心態來啟動「改善工作流程」專案
什麼是服務設計（Service Design）？根據 NNGroup 服務設計是一套工作方法，用來規劃和整合商業上的資源（人、資產、流程）來改善使用者的體驗、以及其他間接利害關係人的體驗。
聽起來好籠統跟抽象，讓我換一種方式解釋！
對於網路與軟體產業的產品經理來說，其實「產品」也是構成「服務」的一種方式，我們在設計產品的時候，使用者並不是單點式的在使用產品，而是會經過一個流程，產品設計常用顧客旅程地圖（Customer Journey Map）來做使用者研究前的梳理，設計產品其實一部份也是在設計服務與流程。
服務設計的範圍則比產品設計更廣了一些，運用的場景也更多，並會把利害關係人、各方資源也包含進去。在做 B2B 或 B2B2C 產品的產品經理應該也會很熟悉「利害關係人很多」的議題，例如買產品的決策者跟實際使用產品的是不同人。
而在做服務設計時常用的工作方法之一為設計思考方法論（Design Thinking），它其實跟做產品設計時常見的雙鑽石模型（Double Diamond Design Model）非常雷同，都是透過兩階段的「發散」「收斂」來解決問題。這篇文章我就來與大家分享如何運用產品設計/服務設計的心態來改善內部工作流程。
▍使用設計思考的五個步驟來執行
Peter Su《產品經理加入團隊的正確姿勢》中有提到剛加入團隊時，產品經理在理解與決定要從哪些面向開始改善時，團隊優先（People）、產品次之（Product）、流程最後（Process） — —
很多產品經理喜歡加入團隊後，就立刻按照過去的經驗或偏好調整開發流程，然而，除非開發流程有明顯瑕疵外（例如沒測試就上線），我非常不建議一開始就去動開發流程。原因是每個產品狀況都不同，每個團隊也都有自己習慣與偏好，產品經理應至少完整經歷一次產品開發上線的過程，了解流程的問題後，再提出改善方案。
我非常同意，因為當團隊跟產品的目標確立後，我也稍微理解現有流程的概況後，才有辦法好好研究大家遇到的挫折與問題，並透過流程的改善來解決這些挫折與問題。
那如果你已經決定（或被指派）要來改善團隊流程，就讓我們開始吧！
設計思考五步驟
[發散] ① 理解使用者（Empathy）
[收斂] ② 定義問題（Define）
[發散] ③ 發想解決方案（Ideate）
[收斂] ④ 製作原型（Prototype）
[收斂] ⑤ 進行測試（Test）
⓪ 第零步：匡列主要問題的規模
主管給我的任務是先接下一些會議的主持工作，包含 Dev Daily Standup、Sprint 相關會議、跨部門的產品會議；再來是希望我可以調整目前我們使用的專案管理工具的架構、Boards、Tickets 本身、以及使用方式與流程。
我自己退一步來看的話，其實大概就是兩大塊議題，第一塊是實際產品開發與專案管理，第二塊是跨部門溝通。
① 第一步：理解使用者（Empathy）
▼ 觀察法
參與目前所有的會議，觀察哪些人參與這些會議、會議流程為何、會議中做了什麼，記下看到的問題和實際狀況。最重要的是，這個會議的目的是什麼，以及思考這個會議有沒有真的達成目的。
線上觀察目前使用的專案管理工具，了解團隊使用了哪些功能，有哪些 Boards、Tickets 以及彼此層級與細節程度為何，Product Backlog、Sprint Planning Board 的現況，以及誰負責管理、又是如何使用這個工具來管理專案。
觀察目前使用的溝通工具、文件工具，了解誰負責發起專案、需求從哪裡來，互動模式與流程為何。
▼ 焦點訪談：按照團隊、角色
我將現有團隊簡單區分為四種角色：工程師、設計師、需求方、管理者。
可以視情況單獨找個別的人訪談，或是一群人、一整個團隊來訪談與討論遇到的問題。 我自己遇到滿有趣的情況是設計師團隊想要全部一起討論，工程師卻比較傾向個別跟我分享。
需求方就是任何會提出產品改動需求的人，比較直觀的可能是業務（B2B 產品）或是客服（B2C 產品），但廣義來說，公司老闆或管理階層的人也算，設計師跟工程師有時候也會在這個角色裡面。
管理者就是各個團隊的主管，雖然他們可能會跟著自己的團隊一起被訪談，但從管理和領導的角度來說，他們還是會有另一塊不一樣的需求。他們遇到的問題不一定能由我們第一線的工作流程解決，但聽聽無妨，也許可以挖掘到一些公司內部的矛盾之處。另一個將管理者納入訪談的優點是，讓他們參與這個訪談流程，之後如果要做什麼比較大的改動、需要花錢買新工具，他們也比較有機會快速理解跟買單。
【訪綱參考】
- 目前的 ＿＿ 工作流程為何？
- 誰/哪個團隊負責 ＿＿ 工作/決定 ＿＿ 事情？實際執行細節為何？你認為這是該團隊的責任嗎？
- 你理想中的 ＿＿ 工作流程會是什麼樣？為什麼？
- X部門跟Y部門目前如何互動？X部門何時會加入Y部門的討論？目前這樣的互動方式你覺得如何？
- 有哪些事情是目前你認為重工的/該做但沒人做的/流程不順暢的/很有意義OR沒有意義的/浪費時間的？為什麼？
- 能否分享最近一次覺得跟內部其他團隊溝通（自己部門/其他部門）比較不順暢的經驗？那有很好的經驗可以分享的嗎？
- 你目前在工作上有沒有遇到什麼困難，是你認為我可以協助的？
＊＿＿ 內可以填入跟當下受訪者相關的工作流程，例如：提需求的流程、QA驗收流程、提出設計到開發的流程。
▼ 個人訪談：尋找極端使用者
在團隊訪談時，可能會發現有些人的話特別多、想法特別多（狂抱怨！）或想法跟別人特別不一樣，這時候就可以特意拉出來做一次單人的訪談，延續之前在多人訪談或比較發散的訪談中無法深入聊，或不好意思在大家面前說的議題。
我遇到的其中一個狀況是，在我加入前團隊沒有 PM，當時部分設計師、工程師就會擔任各自領域的小小專案管理者，但因為專案管理工具沒有統一規範的使用方式、大家對工具的熟悉程度也不一，造成有些人用的很隨便（甚至沒在用！真的！）、有些人則做的超認真（甚至可以說是過分複雜了）。這就是兩種不同的極端。
儘管最後可能無法找到能夠完全滿足所有人需求的解決方案，但我們至少可以看到光譜的兩邊有什麼樣的限制與挑戰。
【使用時機】這種個人訪談會比較花時間，所以我的建議是當心裡已經有個底要解決哪個問題（從大部分的人提出的問題來、在下個階段定義清楚）後，再來挑選合適的人選進行個人訪談。同時，進行一般訪談外，如果心裡已經對於解法有些初步想像，也可以在這個中間階段的個人訪談來試水溫，就是一個靠嘴巴的小型 Prototype & Test！
最後來說說為什麼訪談很重要？
其實我在最一開始上工的時候跟我主管就開了一個表單請大家填寫遇到的問題、希望我可以幫忙的部分，但很多都解釋的不清楚 — — 例如目前的流程是如何、他為何在意他提出的這個問題等等；再者就是填寫的人也不夠多，有些人會說他沒意見，PM 想怎麼改他都可以配合，但這本身也是一種意見，而且我也不相信他完全沒遇到任何問題。
訪談中不但可以了解團隊遇到的問題、期望達成的目標，也可以知道他們過去已經做過哪些嘗試 — — 那些嘗試當時成功或失敗了？為什麼？以此作為接下來提出新方法的參考與靈感來源，也先避開已知雷點、避免自己重蹈他們的覆徹。
除此之外也可以來比對訪談到的內容跟自己默默從旁觀察到的狀況或流程是否一致，還是有些矛盾跟衝突。
最後就是透過訪談找到對流程優化也有熱情的團隊成員，未來說不定能一起合作，或是請他作為他在該部門的暗樁來幫忙推動一些改變。
② 第二步：整理訪談資料並定義問題（Define）
在搜集了很多使用者的想法與回饋後，下一步就是想辦法將這些臨亂的原始資料轉譯成「使用者想要解決的問題」、「使用者的需求」。
在產品設計流程中我們可能會用使用者故事（User Story）、JBTD（Jobs To Be Done / Job Story）來定義問題，而在設計思考中也有一個類似的框架叫做 POV（Point of View），這幾種框架都是使用一句話 [ 使用者/情境 + 問題/需求 + 洞見/原因 ] 的方式來描述問題或需求。
不過在這次的專案中，我直接拉了一個表單來記錄，包含兩個部分：
- 【原始資料】提出者、相關單位、問題/需求描述、目前作法、可能的解法（受訪者如果有提到）
- 【主觀資訊】註解、分類、優先等級
原始資料就是將蒐集到的內容整理好；主觀資訊則會包含一些自己的解讀。
值得注意的是，「提出者」有時候是寫我本人，因為有些問題、需求可能沒人直接直白的提到，但卻是我自己推論出來可能現有的隱性問題。這部分可以仰賴第二輪訪談來試探，或是在進行 Prototype & Test 的時候偷偷包進去當成相關議題來訪談。
「註解」可能包含提出的人在意的原因為何、做這件事時是否有一些限制（金錢、時間、老闆價值觀）、是否有些關鍵人物加重這個問題發生，或是一些未來可以幫助發想解決方案的切入點。
「分類」則是會幫每個問題下幾個標籤（tags），在分類與下標籤的過程中，可能會發現有些問題是有機會一起處理的，屆時就能夠快速的透過標籤來篩選並檢視。這些標籤可以是：
- 問題類別（產品、流程、人/團隊）
- 問題根源（需求管理、專案管理、溝通、利害關係人）
- 解法方向（流程、工具、文件）
- 相關團隊（工程團隊、設計團隊、業務團隊）
- 相關會議（Standup、Sprint、Kickoff、Retro、跨部門會議）
「優先等級」會簡單分為 High、Medium、Low，就是我認為這個問題是否重要、有多值得被處理。
- 除此之外還使用了一個 Easy 標籤，主要會出現在問題的規模很小、且有直覺又容易處理的解法時，在這種情況下不管問題本身的重要性如何，也還是可以考慮隨手先做做看。
- 最後是 Not My Business 標籤，適用於當對方提出的問題超出我本人的職能範圍，無論多重要都不會在我這次的專案範圍內。
在這個定義問題的階段，其實將原始資料轉譯成問題描述的過程不會太難，難的是好像什麼都想做、什麼都該做，所以有兩點很重要。
一是辨認哪些是假的問題與需求，訪談有時候會流於許願，或是看到專案管理工具有什麼強大的功能就覺得我們可以使用（反正有新 PM 來嘛不用白不用）但其實根本沒麼人遇到有關的問題或提出相關需求；
二是如何挑選出第一批最值得解決的問題，從真正重要的、有影響力的做起。
在一般設計思考的流程中，通常會透過團體投票來選出一個最值得解決的問題，也就是第一階段的「發散 」「收斂」的結束時會收斂在一個問題/需求上，然後再從這一個問題/需求進入下一個階段來發想出很多不同的解決方案。
不過我在做這個專案的時候想像中解法方向就是三個部分：流程、工具、文件，很多問題的解決方案說不定是會在同一個區塊中被解決，因此我這邊並沒有收斂到只剩一個問題，而是將所有 High Priority 的問題都一起打包到下一個階段，來個發想大亂鬥，鬥完再好好整理跟排出解決方案的優先等級。
③ 第三步：針對不同問題發想解決方案（Ideate）
既然 High Priority 的問題不只一個，我們還是得分區塊來進行解法的發想。還記得前面的「分類」標籤嗎？這時候就可以好好來善用它！
先來看看【分類 > 解法方向 > 工具】這個類別，這很直接對應到了一開始提到的我主管希望我處理的一環。畢竟換工具的成本很高，因此其中的「工具」解法可能就明確侷限於團隊正在用的專案管理工具（例如 Trello）、文件整理工具（例如 Notion），因此在發想解決方案的時候，可以把所有提到該工具的問題都篩選出來，一併思考如何優化、整頓。
（啊不過如果你們現在用的工具很難用，想要說服老闆換工具的話，也可以試試看。）
我也會去發想，使用 Trello/Notion 以外的其他替代解決方案，而不是全部都只用現有工具 Trello/Notion 來作為發想的限制。俗話說的好，不要手上拿著錘子，就覺得什麼都是釘子！
其他不是工具類的問題，如果很難分類，就一個一個來發想。我會盡量每個問題都提出 1 到 3 個解決方案，最後再來挑選跟排序。
挑選的原則跟做優先等級排序的原則大同小異，建立一個點子分類排序矩陣，把每個解法用兩個指標「真的能解決問題/滿足需求」「可行性」來分類到四個象限中。可行性兩側分別為「容易改動」「很難推動」，這代表的除了是我本人做不做得到以外，也隱含了是否容易改變同事的習慣、使用的工具等等。
④ ⑤ 第四步、第五步：小規模執行與測試（Prototype & Test）
最後兩個步驟就是用低成本、小規模的方式來執行並測試 — — 所謂的低成本，可能是如果你想要用一個新的工具，可以先辦一個測試帳號做一個 demo 給大家看；所謂的小規模，是可以先在一個部門/團隊試試看，如果沒問題再慢慢推到其他團隊。
其實最低成本跟小規模的作法，就是想好一些解決方案後，再找同事來進行第二輪的訪談，分享新的作法，看看他們覺得可不可行、會不會造成新的問題，更棒的是，也許在你分享解決方案的時候，他們也能夠提供新的靈感！
∞ 重複這些步驟（Iteration）
做完 Prototype & Test 若得到的回饋很正向，那就可以順勢推動到團隊中；如果回饋不盡理想，就回到前面的步驟重新發想點子、重新定義問題、甚至重新做更深入的訪談與問題研究。
直到我們辨認出的重要問題都被解決了、新的工作流程與專案管理工具都順利在跑了，這個專案就算告一段落啦！
▍其他 Q & A
1. 怎麼會想到要用這個方法來改善工作流程？
我一開始的想法只是要詢問意見、了解限制、快速測試。
當時在做這個專案的時候其實沒有特別想說我要用服務設計、設計思考的方法。其實是做完後，跟朋友聊天時才發現，欸，這其實好像就是運用我平常習慣的工作方法嘛！所以為了讓這篇文章更有架構更好懂，不如就直接套用其他方法論來看看我在各個階段做了什麼。
前陣子剛好去帶了一場設計思考工作坊，回來後跟三眼怪們聊天，我們都認為設計思考/產品工作方法中的以人為本、快速嘗試、頻繁修正的心態冥冥之中是種信仰，而擁有這種信仰的人自然而然就會把它運用在生活與工作中的方方面面。
2. 這種改善工作流程的專案通常歷時多久？
不一定，看問題的規模大小。短則兩週、長則兩年（？）或從另外一種角度來看，這種改善流程的專案其實沒有結束的一天。
這篇文章也是要提醒我自己很久沒有重新去了解同事的需求了，新人加入、使用者變多（導致需求變多）等等，都會導致公司內原本的工作方法、工具不再適用，其實本來就應該偶爾再去檢核。同事會主動提出是最好囉～但有時候大家會覺得那是某某某的責任，默默的就沒人去思考這件事了。
3. 改善工作流程算是產品經理的工作內容嗎？
所以說到底，改善工作流程這件事到底是誰的責任呢？其實大家都有責任。至少，有責任跟自己的主管說明自己目前工作上遇到的問題，讓管理階層來處理。
而上述這個專案由我來發起的理由很簡單，就是一開始提到的，因為我是新加入的 PM，不管原本工作流程有多完美，有我的加入之後肯定會需要微調。更何況很多團隊找新 PM 加入的原因就是他們目前工作流程一團亂，需要找個人來解決溝通和專案管理的問題。
其實這樣的專案有一群人一起討論會更好，設計思考方法論也很強調不同文化背景的人在討論中激發不同的想法與切入點。所以前面訪談的部分也有提到，如果可以辨認出有心想一起做的人，真的會超級開心的！
至於到底是誰的責任呢 … 前陣子在跟我以前公司同事討論到他們的現況才發現，雖然他們現在團隊人變多了，但問題也更多了，而會主動跳出來處理的人卻比以前更少了。這就是責任分散效應。在這種情況下，最好的方法還是把責任具體落實到特定的人身上。一般公司內常見的就是由管理階層發起，或是有些大公司會有專門的 Product Operations 團隊來支援核心的產品團隊和產品經理。如果有專人負責，那當然是最好的啦！
如果有興趣看我們直接拿一個實際案例來跑完這五個步驟、或是最後實際導入哪些解決方案，歡迎留言或私訊跟我們說！有其他想看的文章主題也歡迎跟我們許願～
以上。