为了更好地阅读体验，欢迎访问博客原文
循序渐进的偶然
有些事情单独看起来有点偶然，仔细回想起来却是循序渐进的过程。去年在北京一次偶然的应届生培训，让我向培训师又靠近了一步，紧接着顺水推舟，借着微服务的一阵学习分享的东风，我偶然地负责了一起面向北京Office的微服务技术实践的Workshop，而就在此前不久，我偶然被选为公司微服务培训的目标学员，恰好我所在的项目又采用了微服务的那些技术实践...
作为组织者以及培训师，我难免会遇到一系列问题，在摸爬滚打的尝试过程中积累了一些心得，结合了我所在组织的特色（敏捷），我将Workshop视同一个Sprint，并提炼了一个框架模型，希望能够帮助一些新的组织者更好地开展Workshop。
VD CAST模型
做任何事情之前，我们都要考虑其背后的价值，定义清楚价值，如何去实现价值，比如在这里我们如何通过Workshop达到这些目的。为了促成最终的交付，我们还要考虑影响交付的一些外在因素，最后，在成功交付之后如何将我们所交付的价值持续产生更多的价值也是等待我们去思考的。我把这些关注点提炼为VD CAST 模型（价值交付投射模型）：
最左边起点是我们做这件事的价值，中间则是影响价值落地的外在因素，主要涵盖了当前面临的约束、培训的目标受众、所能获得的支持以及课程交付后的跟踪五大方面。最右边是我们要落地的交付。能否落地以及如何建立价值与交付之间的投射？落实到操作层面，我们需要深入到各个方面中去探讨一些关键性的问题，我以提问的方式罗列出每个环节要解决的主要问题：
从这些待解决的问题中不难看出，每个环节存在一定的关联性，比如价值，我们给组织带来什么会决定我们能从组织上获得什么支持，而给讲师和学员带来什么会影响我们会影响讲师和学员的招募，价值 在很大程度上决定了我们所获得的支撑，支撑 则为成功交付 提供了强有力的保障。约束 会在一定程度缩小受众，并且很可能阻碍交付。最后，有效的跟踪 能够更好的突显价值 以及帮助改进下一次Workshop。我把它们之间的关系概括为：
它们之间关联性能够帮助我们理清这些问题的依赖顺序，让我们集中Focus在优先级更高的问题上，同时尽可能避免去解决一些根本不需要解决的问题。
As a Sprint
回到实际操作中，我们可以邀请有经验的讲师或组织中的Key Member一起头脑风暴，这样有助于捕捉那些由于个人思维限制而被遗漏但很重要的问题。一旦挖掘出了关键性问题，我们接下来如何干掉它们，难道必须一次性给出全部问题的答案吗？
如果把一次Workshop视同敏捷开发中的一个Sprint（即迭代，请参阅 我在ThoughtWorks中的敏捷实践），我们需要做的是在Sprint的不同阶段中去解决对应的问题：
我把Sprint划分为5个阶段，每个阶段针对问题所提供的答案除了影响本阶段的进展，还会直接影响下个阶段的进展。比如在需求分析 的时候我们没法排除约束，可能会导致Sprint失败。而在架构搭建 中如果没有服务器资源，就会影响课程设计，而课程设计则会增大交付的风险（因为缺少特定的服务器资源，增加了环境的复杂度）。
所以在每个阶段，我们要试图去给出合适但不一定十全十美的答案，这些答案能够推进Sprint，并有助于实现价值即可。
写在最后
VD CAST 模型提炼出我们在Workshop中需要关注的核心点，它能帮助我们分离关注点（经常出现在软件架构设计中），让我们能够提前识别风险，进而评估Workshop能否落地且实现我们预设的价值，如若不能落地，它能帮助我们挖掘出不能落地的真实原因。
针对VD CAST 模型中关注点的关键性问题不局限于前文所提出的那些，你需要把握住一个核心原则：
依据你所处的真实环境，针对VD CAST 模型的关注点提出关键性的问题，并试图给出合适的答案。
在一个分享氛围浓厚的学习型组织中，不乏各类Workshop，在我司尤为突出。如果你参加过一些Workshop，且有意愿尝试组织一次Workshop，希望VD CAST 能给你注入能量。
为了让学员保持较高的参与度，我们需要在课程设计上多下功夫，在课程中整合目标、反馈、挑战 等元素，更多精彩内容请阅读邱大师的 反馈拯救世界。
网友评论