板友大家好，我跟朋友一起在网络上分享产品管理、专案管理相关知识与经验，
最新一篇文章是分享新加入的 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 团队来支援核心的产品团队和产品经理。如果有专人负责，那当然是最好的啦！
如果有兴趣看我们直接拿一个实际案例来跑完这五个步骤、或是最后实际导入哪些解决方案，欢迎留言或私讯跟我们说！有其他想看的文章主题也欢迎跟我们许愿～
以上。