别开会,搞个工作坊

别开会，搞个工作坊

Cooltran

现在很多企业里的“密集会议文化”使项目团队的项目目标很难达到预期的进度要求，特别是在增强产品的用户体验的方面。通常来说，会议中充斥着太多的项目议程，态度不冷不热的头脑风暴与偏离会议的闲谈，如果你在那种会议文化的环境中工作，试着用为期一天的工作坊可能是个绝佳的方式摆脱老套的会议。

在一个典型的合作团队的环境里，对线上或者移动端产品用户体验的改进流程就像以下所示：

⏹某人制定并安排了一个会议

⏹大家在会上讨论一些问题以及可能改进的方面（这些改进的方面可能又不一定和会议前准备讨论的问题相关）

⏹接着有些人就开始跑题并且脱离了会议开始提出的问题

⏹然后大家就散了又去参加另一场会议

⏹此时有人又开始安排后续会议

⏹接下来在会议里老问题改头换面继续讨论，新问题又被加了进来

上述的流程看起来就这样无限的循环下去，导致解决的问题很少，能采取的行动就更少。假如改变这个无限循环是可以有更好的方法，但是在这为期一天的会议时间内，如果你能在全部的改进提议中提炼出

的有意义的焦点，大家伙能准确定义出问题所在，头脑风暴有能提出解决问题的方法，然后提出优先的决绝方案，也不一定让大家参加一整天的工作坊。

然而为什么要组织大家参加工作坊？

工作坊有几点优于会议的地方：

⏹良好而积极的动机

⏹产生共同的目标感

⏹一天内集中涵盖了会议需要几周或数月完成的事情

⏹使得每个人都能在解决方案上参与合作

如何开展工作坊？

这里是一个基本的把为期一天的工作坊划分为三个相等时间段的方案：

为了验证这个方案，让我们找一个假设性的问题——一家健康保险公司拥有一个独立的网站，这家公司发现在在线登记的过程中出现了问题，因此公司要搞清楚如何在下一次在线登记上线之前及时做出更好的流程改进方案。

发现问题

多数的企业在正确定义那些需要解决的问题方面做得都很糟糕，常有强烈的欲望直接跳到“修复”阶段，这样做就直接导致大量的心血花在短期的改进或是解决了错误的问题。在这个健康保险公司的网站的案例中，建立“解决一些用户体验问题”工作坊是个新的开端与好的方式来证明这些真实存在的问题，获取这些问题的途径大概有：

⏹通过收集一些呼叫中心代理人员分享的关于消费者预约中遇到各种问题的故事

⏹打印通话日志、调查结果与页面点击流数据在一个大幅面报告上并贴在墙上

⏹让那些对这个产品不熟悉的用户（比如你的朋友、家人、来自别的不相关部门的同事等）使用你的产品然后让他们谈谈对产品的体验

⏹收集有参考性的以前关于可用性会议的视频或可用性报告的副本

发现以用户的角度的工作坊参与者在体验网站时出现的问题（尝试让他们注册自己家庭的成员）采集工作坊参与人员的一些相关的传闻轶事（例如：“我听到人们抱怨在确认页的时候不知道怎么再点击下一步”）

当工作坊的参与人员产生了关于“产品为何不依据用户习惯来设计？”产生的“怨念”与想法时，不需要花太多的时间在细节问题上（例如:"为什么不在这一块多些留白？”或“我不喜欢绿色”），而是使用挂图与便签让参与者捕捉这些“怨念”，并保证在随后的时间里解决这些问题。一旦把这些采集到的问题制成列表，优先考

虑这些问题的严重程度同时选择出重要度第一和第二位的问题为工作坊的下一阶段的主要关注点，问题的严重程度反映在设定的问题优先级与预定目标内。

头脑风暴解决方案

头脑风暴阶段在整个工作坊部分是比较轻松的环节，参与者大多数在的思考如何解决这些问题，以下有一些关于如何让这一阶段更有效率的小贴士：

⏹优先考虑并解决一两个问题强于试图解决所有的问题

⏹把参与者分解成跨学科的小组并汇总各个小组的讨论的结果

⏹鼓励每个参与人员贡献想法，越多越好

⏹推迟关于解决这些问题需要付出多少成本这类话题的讨论，允许这些讨论出的解决方案是耗时且高成本的，并且在理想的源配置内就能实现这个方案

⏹提供草图等的材料，鼓励每个参与者视觉化解决方案

如果头脑风暴会议环节开始证实了正确的方向，那么从发现问题到解决方案这条道路就会异常的顺畅，但值得注意的是，在头脑风暴环节中会出现这样的陷阱，也就是经常会接受第一个可行性方案、发出最响亮声音者的那个方案以及地位最高者提出的方案，可是这些往往不是最好的对问题的回答，所以分小组讨论能很好的避免这一问题，同时一个好的主持人有更多的方法能保证所有的想法能得到彻底的平等对待。

按大小与优先级排列解决方案

这里有个基本的矩阵，你为了得到一个特定的方案，可以用这个矩阵来权衡对它投入的成本大小与这对这个优先级方案会产生的潜在利益，最终希望能选择出最可能的解决方案：

例如下表中开始列出你的潜在的解决方案的矩阵列表。

工作坊中的这个阶段是比较困难的，经常会在例如“我们貌似知道的方案还不够多”这样的疑问中停滞不前，为了更有效率的方案的大小与优先级进行权衡，有以下几个小贴士：

⏹在T恤大小的区域内对这些可能的解决方案进行影响力与投入成本大小排名（例如最大、中等、最小）

⏹如果技术团队对某一方案猛烈抨击，那就得承认这方案的实际工作负载可能存在问题，同时得承认

技术团队以最小投入的那个方案是最可能往前推进的方案

总结你的工作坊

从定义发现的问题到列出可能新的解决方案这条路并不是一帆风顺的，如果你一天内仍然没得出集体的决定，不要灰心，这也是常事。如果你用完了规定的时间发现还是没有任何决议产生，试着从“产生决议”转变到再次分配任务与再进行下一个步骤。所以在工作坊的结尾，常会有很惊喜的输出分享给大家：

⏹收集了更多的问题（例如“用户在登记的过程中在哪里流失的？”）

⏹探索了替代的解决方案（例如“尽管我们最喜欢的这个提案，但是耗费资源太大，还是在下一次用户线上登记时期之前采用更快速的改进方案可能更好”）

⏹研究范围更细致（例如“IT研发团队在两个备选方案中需要知道哪一个的开发成本更低”）

工作坊的基本要素

哪些人来参加：最好尽可能请跨学科的人员参加，比如说，邀请话务中心代理人员、项目经理、销售团队的人员、设计师、文案人员以及工程师团队人员参与工作坊来共同解决问题。

关掉手机电脑设备：在开始工作坊之前确保参与人员不在发短信、收发邮件以及与本次工作坊无关的事情，如果大家不能全身心的参与，他们是根本没必要来参加这个工作坊的。

时间安排：给工作坊的寻找问题——解决方案——权衡方案三个阶段各分配两个小时的时间，还要确