阅读提示： 如果你对故事不感兴趣，可以直接跳到第三部分——如何利用讲故事的方式来设计一个工作坊
一、 咨询观察
在咨询现场必定会遇到的情况是会议——各种类型的会议。在见过无数次会议之后，给大家抽象出如下一个故事。
- James（请不要介意我使用这个常见的名字来背锅~）因为某种原因计划在团队里发起一次会议
- James发出了一个会议邀请，有会议名字，也许没有地点（因为会议室太紧张），给出了会议日程，还邀请了10位同事（会议邀请见下图）
- 会议那天，所有人进场，James发起了讨论，大家围坐在一起开始讨论
- 在讨论过程中，不断的跑题，没有记录，James尝试把大家拉回到日程上来，可是发现大家七嘴八舌，很多假设“如果……我们该怎们办……？”，根本没发阻止（这里面的碎碎念，各种跑火车我就不详细描述了，大家自行脑补也许发现你的周围就有这种情况）
- 一个小时结束，James发现好像大家也发言了，但是没有任何结果
- 结论是下次再开个会来讨论
James' meeting invitaion:
Title：How to on board our team's new member？
Time: 23 Jul. 2017 10:00 am - 11:00 am
To: xxx-team@abc.com
Where: no meeting room can be booked, let's use break-out
Agenda:
1. The current status
2. What shall we do in the future？
二、James到底遇到了什么问题？
简单分析一下这个让James沮丧的会议到底存在什么问题
如果你阅读过一些高效会议的书籍或者参加过相关培训，你会发现这里面有很多问题，比如：
- 会议前期准备不充分，会议室没有，去break-out的讨论也许没有合适的文具，而且来回走动的人可能会影响讨论
- 会议目标不明确，比如Agenda设置很模糊
- 对于与会者了解不够，他们对于要讨论的问题认同度如何没有充分了解，因而在设计会议流程和讨论中出现失控
- 引导者存在问题，不能很好的协调会议进程，时间把控缺失
- 会议开始没有设定有效的产出期望导致没有产出
- 后续行动是草率的决定下次再开个会，如何为下次会议进行准备，谁去准备都没有明确
本质上，这个会议James的出发点是组织大家群策群力研究一下未来怎么更好的on-boarding团队新成员，这是一种开放讨论的方式，针对特定问题寻找解决方案。
三、用讲故事的方式设计workshop
Workshop的设计可以理解为制定一个游戏规则，让一群人来解决某个特定的问题，最终产出游戏成果。
首先介绍一个简单的Workshop框架。市面上有很多书籍或者文章讲述高效会议、工作坊设计（比如我推荐的文章末尾两本书），他们很深入很全面，但是内容比较多。我设计的这个框架做到尽量简单、刚好够用，特别是对于还在采用传统开会方式的团队来说值得尝试。
我把工作坊设计分为如下7步，每一步骤都有其目标和需要考虑因素（参考下图详细内容）。
如何操作：
- 设计工作坊时，请找一个白板，先把这个框架抄上去（只需要写橙色背景部分），然后按照1到7的步骤，用贴纸来描述每个步骤内容，如果有多个设计者可以边讨论边写，用sticker贴在白板上。
- 将贴好的sticker，用讲故事的方式来从第1步到第7步完整讲述一遍，在讲述过程中做出调整。
（有没有发现上述过程有点像敏捷需求分析写用户故事的过程？最后产出的是用户故事地图。这样做的好处是设计过程很流畅，而且随着自己对自己讲，或者有人一起pair时就给对方讲，很容易发现设计缺陷，整个过程也比较有意思。）
我尝试将James的会议用上述方式做了一遍，如下图（我在重庆机场等飞机的时候用25分钟做完的，没有白板，用的咖啡厅的桌子）：
我来讲一下故事： 引号内是上图sticker上的内容
作为我们XXX团队的成员，每个月都有新人加入团队，“因为业务与技术复杂性，如何让新人在一个月后开始贡献”，我们希望通过这个工作坊“梳理出一个明确的on-boarding过程遇到的挑战列表”以及“提出针对每一个挑战的具体应对方法”。
前期准备的时候需要“一个有白板的可以容纳15个人左右的会议室”、“投影仪和电脑”、“收集全组对于第一个月ob-boarding要达到的目标”并“提前整理统一要达到的目标分成不同组，用sticker提前写好”；还有……
工作坊进行时，我们这么操作，第一步用5分钟“介绍整个工作坊的目标与流程，让参与者容易认识”，第二步用20分钟“确定第一个月on-boarding要达到的目标Top5”，第三步……
……
最后，在工作坊结束后，我们还需要第一“James发出一个wiki page的模板用于记录讨论成果”，第二“各小组选出一名代表在以上wiki page记录各组的讨论成果”；
NOTE
我已经将上述框架用于我的日常工作，刚开始采用时你会发现最大的挑战在于第1、3、4三步，因为很容易直接跳到解决方案上去。不能界定清楚要讨论的问题以及很难考虑清楚可度量的工作坊目标。我只能说，这种思考方式与平常写代码有很大不同，需要刻意练习。希望以上这个简单的框架可以帮助你提高工作坊设计效率与执行效果。
