Posts

在大部分时候，我们讨论API的设计时，会从功能的角度出发定义出完善的，易用的API。而很多时候，非功能需求如安全需求则会在很晚才加入考虑。而往往这部分会涉及很多额外的工作量，比如与外部的SSO集成，Token机制等等

Web站点的响应速度 雅虎在2006年就发布了一份提升Web站点响应速度的最佳实践指南。该指南包含了35条规则，分为7个类别。这些规则已经被广泛使用，并指导人们在新的站点设计时更有针对性的考虑问题。这份指南已经成了Web前端性能度量的一个事实标准了。 YSlow是一个基于这份指南的测试工具，它可以测试一个站点是否“慢”，以及为什么“慢”？你可以通过很多方式来使用YSlow，比如Firefox，Chrome的插件，命令行工具，甚至PhantomJS这样的无头（Headless）浏览器。YSlow会检测你的站点中的资源是否没有压缩，是否缺失了超时设置，更进一步，它还会检测你的JS/CSS是否已经压缩/精简化，图片的尺寸，是否使用了CDN等等很多的维度。它还可以生成很多格式的报告，比如打分信息，TAP协议的输出，以及junit测试报告的格式。 我们这里讨论如何在持续集成服务器上设置一个YSlow任务，这个任务会在每次构建之后，测试你应用的性能指标，以帮助你更快的发现和定位问题。当然，我推荐你在staging环境，很多开发者在测试环境，本地开发环境都会启动很多对Debug友好的设置，比如未压缩的JS/CSS，没有超时设置的响应等，这会导致该构建任务的打分不够准确。 搭建CI环境 按照传统方式，如果要搭建一个这样的CI任务，我们需要至少做这样一些事情： 安装JDK 安装Jenkins 安装PhantomJS 安装YSlow.js脚本 然后设置环境变量，在Jenkins上创建任务，并运行YSlow.js脚本。这个任务很简单，只需要设置好参数，然后将结果输出为Jenkins上的报告即可。比如： $ phantomjs /var/share/yslow.js -i grade -threshold "B" -f junit \ http://bookmarks-frontend.s3-website-us-west-2.amazonaws.com/ > yslow.xml -i grade 展示打分（grade）信息（还可以是basic/stats/all）等 -threshold "B" 指定失败的阈值为B -f junit 输出为junit识别的XML格式 这里的阈值可以是数字（0-100分），字母（A-F级别）或者一个JSON字符串（混合使用） -threshold '{"overall": "B", "ycdn": "F", "yexpires": 85}' 上面的命令会测试站点http://bookmarks-frontend.s3-website-us-west-2.amazonaws.com/的各项指标，并应用雅虎的那35条规则，并最终生成一个junit测试报告格式的文件：yslow.xml。 但是维护CI环境是一个比较麻烦的事情，而且既然每个项目都可能会用到这样的基础设施，一种好的做法就是将其做成一个镜像保存起来，以方便其他项目的复用！这里我们使用docker来安装和配置我们的CI环境，配置完成之后，我们可以将docker的镜像分享给其他团队，也可以供我们在下一个项目中使用。 基于docker/docker-compose的环境搭建 在docker出现之前，我们要搭建一个测试或者staging环境，往往需要很多个不同角色的机器：有专门的数据库服务器，文件服务器，缓存服务器，Web服务器，反向代理等等。这样在成本上显然是个不小的开销，如果将所有不同的组件部署在同一台机器上，则又可能互相干扰，只需要一个小小的失误，整个系统就需要重新配置。更可怕的是，这个环境和生产系统不一致，那么很可能真实的错误要等到系统上线之后才会被发现。 比如在2012年，我所在的一个项目中，客户的系统采用传统的J2EE架构。本地开发中，我们使用了Jetty作为容器，而测试和Staging环境使用了Tomcat。由于Tomcat对空格的处理和Jetty有所不同，我们在本地测试通过，并且运行良好的代码，在Staging变得完全不能工作。这个问题花费了团队很多时间来排查错误。 在docker出现之后，我们可以在一台物理机器上运行多个互不干涉的容器，每个容器可以是一个组件（比如运行数据库的容器，Web服务器容器等等）。这样不但缩减了成本，而且可以让我们的环境尽可能和生产环境一致（有的项目甚至直接将CI出来的镜像应用到生产中）。不过对多个容器的管理是一个很麻烦的事情，好在docker提供了docker-compose工具来解决这个问题。使用docker-compose可以定义一组互相独立，但是又可以协作在一起的容器，这样我们可以很容易的搭建一个仿生产环境。 比如我们可以定义个docker-compse.yml app:build:.links:- db:postgresports:- 8000:8000volumes:- .:/appworking_dir:/appentrypoint:/app/start.shenvironment:JDBC_DATABASE_URL:jdbc:postgresql://postgres:5432/bookmarksDATABASE_USER:bookmarks-userDATABASE_PASS:bookmarks-passworddb:image:postgres:9.3ports:- 5432:5432environment:POSTGRES_DB:bookmarksPOSTGRES_USER:bookmarks-userPOSTGRES_PASSWORD:bookmarks-password这个docker-compose定义了两个组件，app和db。db使用了postgres:9.3镜像，并设置了自己的环境变量。app则从当前目录.构建一个新的镜像，app与db通过links属性连接起来。 如果在当前目录执行docker-compose build命令，docker-compose会找到本地的Dockerfile，然后构建出一个docker的镜像，并启动该容器，同时，它还会启动postgres:9.3容器作为数据库组件。这样我们的环境就被完整的搭建好了。 搭建CI环境 app:build:.ports:- 8080:8080- 50000:50000volumes:- ./data:/var/jenkins_home这个配置，表明我们会根据当前目录的Dockerfile来构建一个镜像。 通过命令volumns，我们将本地目录./data映射为jenkins_home，这样我们定义的job信息，以及插件的安装都会放到本地的目录中，方便管理。配置完成之后，构建并启动该容器： FROM jenkins:latest # Env ENV PHANTOMJS_VERSION 1....

知识漩涡 只需稍加留意，我们就会发现自己被各种技术，工具包围。ThoughtWorks的技术雷达差不多每隔半年就会更新一次，而项目中更是会遇到很多已经从技术雷达上消失的技术，项目上的旧技术/旧框架还在服役，新的技术/工具/语言/框架又在迅速的出现，有些昙花一现，迅速被新的后来者取代，有的留下来了，不过也都在不断的演化，改变（不兼容的API，不同的版本等等随处可见）。 如果你不幸是一个前端工程师，那么这个更新速度还要更加迅速。三年前Backbone是主流，两年前是Angular.js，去年是React，紧接着Flux，Reflux等作为React的扩展而成为了新的主流；Grunt流行过一段时间，很快被Gulp替代，而新的Webpack又依稀有大一统的趋势。每周几乎都能看到新的框架涌现，双向绑定，虚拟DOM，事件代理，同构，后端渲染，更友好的语法糖，更快的执行速度等等等等，几乎任何一个方向都有无穷无尽的变化。 而后端也好不到哪里去，容器技术，Web框架，ORM，构建脚本，自动化测试工具，依赖管理，应用服务器等等，你总有很多的选项，却又无法在事先区分到底哪个技术/工具更靠谱，更适合项目。 置身其中，往往有眼花缭乱，应接不暇的感觉。知识工作者当然需要终身不断的学习，但是像目前这种节奏，我很怀疑这是一种健康的状态。周围经常有人抱怨，好不容易上手了一个前端的MVC框架，一看周围的项目，大家已经在spike另外的框架/工具了（这意味着你在项目上无法使用该框架了……）。仅仅从学习的速度上来讲，我们已经远远无法跟上科技演化的节奏了，这是人类自身的一种限制。 知识的陷阱 假设你在一个Ruby项目上，学习了Rails/ActiveRecord/RSpec/MySQL。如果下一个项目还是Ruby，同样的技术站，你会觉得这是一种重复，因为除了业务逻辑、业务对象变化了之外，并没有新的内容，还是同样的技术。如果下一个项目是Python，技术栈变成了Django/nose/PostgreSQL，你可能会觉得有所提升，因为学到了不同的技术，框架，共建工具，测试工具等等，其实仔细观察，这还是一种重复，古人云：“换汤不换药”者，是也。 在目前我们所处的时代，信息以远远超过人们能接受的速度不断的被创造出来，一方面信息传播的速度大大提升了，另一方面是信息传播的渠道也极具多样化。我们无时无刻不被过载的信息包围着，即使你不主动的去尝试获取新的信息，手机App里的微信，微博，Flipboard，Pocket，知乎，开发者头条，Feedly，果壳，丁香园等等的推送已经足以提供给你足够的信息（大部分甚至都来不及消费就变成了历史信息而被忽略）。 以我自己为例，从2015年10月到现在（2016年2月），我学习了很多东西，看一下下面这张图： 图中的灰色方框中的内容是项目要求的知识，另外的则是我根据自己的兴趣学习的（两者基本上各占一半）。事实上有很多内容（尤其是根据自己兴趣学习的）在真正要使用时，可能还需要学一遍。这些内容可能让我产生了我学到了好多东西的错觉。其实这个在另一个角度显现了技术人员的一个误区：以为自己可以掌握所有软件开发相关的知识（或者说太过于纵容自己的好奇心和兴趣）。 过载的信息 身处这样的信息过载环境，我们很难不为自己对信息的缺乏而感到不安，担心自己错过了什么重要的信息，这种担心和焦虑会促使我们进一步将时间消耗在对信息的获取上，从而更无暇思考什么是真正重要的。 《如何阅读一本书》将书分为两类：一种是提供资讯/信息（known）的，一种是帮助你理解（understand）信息的。相对于理解来讲，资讯本身其实并不那么重要。我们大部分人目前采用的碎片化的阅读方式无法提供给我们足够的“理解力”。我们都有这样的体验，有些书特别耗费脑力，读起来很累，而另一些书则非常轻松，易于消费。碎片话的阅读方式易于消费，只需要很少的思考就可以读懂，但是危害严重，它们并不会让帮助你提升理解力。 但是直觉上我们会选择容易的事情来做，虽然这种浅层次的阅读只对扩展信息/资讯有帮助，对提升理解力则几乎无用。而我们在处理日常工作中的问题时，能真正帮助的，只有理解了的那部分知识。我在2014年，曾经有几个月屏蔽了所有微信，微博，内容聚合类的应用，也尽量少的去技术论坛，每天就是写代码，读纸质书，除了最初几天的忐忑之外，整个过程的收获非常大（而且也没有漏掉任何重要的信息）。 知识框架 技术人员有时候会有一种想要把所有技术都掌握的执念，这在局外人来看是一种荒诞不经的想法，但是置身其中，你很难看出这一点。毕竟，有意思的东西是在太多了，各种范式的编程语言，编译器技术，人工智能，数据可视化，地理信息系统，嵌入式设备，软硬件结合，大数据，自动化测试等等，每一个方向都有无穷无尽的有意思的东西。 但是在知识规模如此巨大的今天，一个人是无法掌握所有技术的（更不用说新的技术还在不断的涌现出来）！这就要求我们有节制的来聚焦在某些技术上，而视其他技术如无物。当然这需要很大的勇气和魄力，不过唯有如此，技术人员才有可能有真正的长进和成就。 我基于自己的经验，绘制了一个Web开发方面的知识框架，这个框架上包含了一个比较全的技能/知识集合，也是我认为一个Web开发人员应该掌握的一些知识点。 在成为一个专家之前，你需要先对要学习的领域有一个全面的认识。也就是说，做Web开发，需要尽可能覆盖到这个框架上的所有点。一旦完成了这棵树上的所有节点，就不用再去做第二次了，这时候你可以尝试找到树上的某一个分支，深入下去。这个听起来好像和我之前文章中的观点有所矛盾，其实不然。我在《我们真的缺前端工程师》一文中提到过，工程师不应该将自己束缚在前端开发上，要了解整个软件开发的全生命周期。这里的观点其实是一致的，即首先要了解软件开发全生命周期中的所有节点，然后再有所侧重的去找自己的兴趣点来发展，即：先建立广度，再建立深度。 应对方法 对于知识的陷阱 当因自己的兴趣（而不是项目驱动，也就是没有实际的土壤来验证）而想要学习一个新的知识时，对照知识框架，如果发现你已经在历史上学过它了，那就强迫自己放弃这个念头。比如如果你很熟悉用rspec来编写测试，忽然有一天心血来潮，想要学习JUnit，正确的做法就是泡杯茶，等这种冲动自己过去。相信我，一旦有了Java项目，你可以非常快速的掌握JUnit，而且很快会找到对应的feature，就像一个长期工作在Java技术栈上的同事那样！ 对于过载的信息 实践中，首先要令自己相信：你无法掌握所有的知识，即使仅仅在软件开发领域。有了这个大前提之后，你只需要采取先建立广度，再建立深度的原则即可： 做减法（在建立了知识框架之后，有针对性的学习） 主动，深度阅读经典 为那些有趣但非自己关注方向的知识赋予较低的优先级 另外，还可以尝试将微信，微博关闭一段时间，或者至少可以不去点那些朋友圈里的《老X聊微服务》或者《12个你不知道的Sublime技巧》文章，保持专注，保持简单。

成为咨询师 本文旨在帮助开发完成向咨询师的转变，内容不但涉及向UX学习，还包括思维方式的转变。我尽量采用一些亲历的例子来说明该如何做，也会适当的解释为什么需要这样做。不过在展开详细讨论之前，首先来澄清这里提到的三种角色。 开发（Developer）角色 开发是指那些喜欢写代码，享受写代码，喜欢纯粹，讨厌办公室政治，永远穿T恤的有些偏执的程序员。跟他们打交道，有这样一些注意事项： 不要让他们帮你盗QQ号 不要让他们帮你修电脑或者装Windows系统 不要跟他们讨论人文/政治类的问题 开发往往还单纯的可爱，除此之外，他们还有这样一些特点： 逻辑清晰 与人争辩时往往可以通过清晰的逻辑而获胜 单身 业界已经有很多关于开发的描述了，我这里也有一个描述开发的列表： 当然，要严格界定一个人是不是`开发`是非常困难的，大多数情况下，他们沉默寡言，遇到程序中的bug或者在调试某些库的问题时眼神呆滞，口中念念有词，他们不太喜欢和陌生人说话，在晚上精神充沛，白天则显得有些呆滞，喜欢喝咖啡，相信世界上有绝对的正确和错误，往往会带着非黑即白的二分法来看待事物，生活很难自理，喜欢机械键盘/电子设备，周末宁愿宅在家里写代码也不去做社交…… 用户体验设计师（UX） UX是指用户体验设计师，在本文的上下文中，更偏向与非视觉设计的那些设计师（产品设计师）。在项目中，他们会做用户调研，竞品分析，信息架构简历，交互设计（纸上原型，低保真）等活动，并负责开发纸上原型，验证这些原型等。 和UX打交道，也有一些应该注意的点，比如： 不要叫他们美工 不要对他们说诸如：“帮我美化一下这个页面”，“这个颜色得再亮一些”之类的话 不要跟他们讲关于程序员的笑话 事实上，人们对UX的误解很深。提到UX人们的第一反应是PhotoShop，P图/切图。这仅仅是他们日常工作中很小的一部分。大部分UX还要做很多用户研究，信息架构整理的事情。老实说，我在去年5月之前的对UX的认识和大部分开发的认识是一样的，但是在后来的项目上和多个UX合作过之后，我彻底改变了原先那种偏见，开始敬佩他们，并向他们学习。 设计工作可以细分为这样一些不同的方面（图片来源网络）： UX的一项特别的技能在于能从复杂的现实世界中抽象出清晰的信息（用户画像，体验地图甚至最后的用户故事）。这项技能不但重要，而且还很牛逼。 知识的诅咒 《反脆弱》里有个有意思的例子：人们仅仅创造了非常有限的词汇来描述颜色，比如蓝色，红色，而任何一个视觉正常的人都可以轻松的识别出数百种不同的颜色。也就是说，人们可以很轻松的理解相当复杂的事物，但是很难向别人描述该事物（想象一下向别人描述一只章鱼的颜色）。 人们对于现实世界中的事情（特别是复杂的业务场景）往往只能意会而很难言传，再加上知识的诅咒（我在《如何写一本书》里，详细讨论了这种常见的陷阱）的存在，当用户在描述A的时候，在没有上下文的人听来，很可能是B或者C。这种情况在软件开发中非常常见，也是很多项目之所以延期的原因（大量并无必要的返工，需求澄清等）。 在项目前期，UX需要和客户坐在一起，将客户的需求分析清晰。分析细节包括业务场景，用户画像生成，信息架构，体验地图等等，这些信息并不是天然就显现的，恰恰相反，它们需要UX经过很多轮的辛苦引导，从用户的脑海里提取出来的。 这里需要UX的核心能力是： 有目的的抛出问题，引导客户进行发散 有节奏的收敛，形成共识 不断修正过程中的错误 可视化能力（这可能是大部分人觉得唯一和UX相关的点） 咨询师 咨询师是指那些根据自己的丰富经验来帮助客户解决具体问题的人。这些问题并不一定局限在技术上 —— 比如架构的设计，具体前端/后端技术的选定，还包括一些流程的改善。比如引入新的工程实践来缩减项目的周期时间，帮助团队发现问题，建设团队的能力，作为各个团队间的润滑剂帮助项目成功等等。 咨询师工作中的一个常见的场景是： 列出目前遇到的问题 确定各个问题的优先级（和各个利益方） 制定方案 给方案加上时间，形成计划 细化计划中的条目，并促成它 引导/启发 我在印度的某一期TWU当教练的时候，发现了一个很有意思的现象，国外的同事在组织培训时更强调用引导/启发的方式，让学生们自己得出结论，并在课堂上进行讨论，以期教学相长。只有在过程中有启而不发的情况出现时，教练才会适当抛出自己的开发，并再次启动讨论。 与我一直的认识不同的是，这种方式效果很好。通过一些适当的启发，学生很容易自己讨论出一些有趣的看法，然后教练在这个基础上做一些总结，并帮助他们分析不同看法/想法之间的优劣。 我非常认同这种模式，后来自己组织的其他培训/workshop也都尽量采取这种方式。咨询师在客户现场，也应该采取这种引导的方式帮助团队来完成能力建设，而不是事必躬亲。 角色转化 从开发者视角切换到咨询师的第一要诀就是：让团队解决自己遇到的问题！乍听起来，咨询师好像变成一个多余的角色了：既然团队自己可以搞定，还要咨询师干什么呢？咨询师的职责是让团队意识到问题，理清思路，制定解决方案，并逐步实施。 使能/赋能 我们来看一个简单的例子：在客户现场，你发现团队往往在集成时会花费很多额外的时间和返工，开发过程中大家各自为政，没有人知道一次commit会给软件包造成什么影响。 如果你是一个咨询师，应该如何解决这个问题？一个常犯的错误是，直接上手帮助团队搭建持续集成（CI）环境，并设置CI纪律（比如build红了不许过夜，红的时候其他人都不许commit等）。 一种更好的做法是：做为咨询师，首先需要帮助团队认识到这个问题，你需要让所有人都知道，我们现在的问题是什么。在所有人都清楚了这一点之后，你需要提出（或者引导出）持续集成的概念（因为根据经验，这是一种可以很好的解决集成时额外的返工现象的好办法）。 但是对于不熟悉持续集成的团队来说，搭建一个持续集成环境是一个非常复杂的任务。因此你需要分解这个任务为一些更小的，可以被解决的问题。 申请虚拟机资源 安装jenkins（包括安装JVM，创建用户等） 配置本地构建脚本到jenkins（构建脚本，自动化测试等） 申请显示器资源（作为CI Monitor） 将结果显式在CI Monitor上 有了任务之后，你需要分别为这些子任务分配owner。对比搭建持续集成环境这样的大任务，这些小的任务已经非常具体，更重要的是，他可以被团队中任何人理解并解决。...

什么是引导（facilitation） 引导（facilitation）的词根来源与拉丁语“facil”，意思是“让……更容易”。而负责引导的引导师（facilitator）的核心职责是，通过一系列的活动、技巧，保证引导会议顺畅的进行，并解决整个过程中的问题，使得参与者就问题产生一个共识，达成一个结论。 其中可能涉及很多具体的问题，比如几乎在每个会议中都可能看到的： 如果有人尝试将会议变成一言堂，如何处理？ 如果参与者不愿意分享自己的观点，如何处理？ 过程中，两个参与者产生了争执，如何处理？ 如何把握节奏，刺激与会者发散？ 如何在收集到足够信息后，进行收敛？ 显然，这是一个技术活儿。一次好的引导可以将与会者的众多想法，信息聚合起来，形成对团队下一步要做什么有极强指导意义的方案。 日常的引导活动 在平时的工作中，我们其实已经在频繁的使用引导活动，但是很少有人将其作为体系来关注，也很少有人能将这个能力应用在其他方面（比如在客户现场咨询，或者参加售前等）。引导是如此的常见，以至于我们对其视而不见。比如在interview完成之后，所有面试官和HR一起做的well/less well的列举；各种社区活动（Open Party，CDConf等）之后的回顾；每个项目在一个迭代结束后的Retro；对于某个问题的头脑风暴等等。 项目回顾会议 在开始前，引导师需要保证团队： 每个人都有开发的态度 整个过程需要在一个足够安全的环境中进行（Safe Check） 有时候，有Team Lead在场，新人可能不愿意对某事（比如最近加班有点过分）发表自己的看法等。这时候需要有Safe Check，比如分为1到5档，大家用不记名投票的方式来表述自己是否觉得安全。如果投票结果显示大部分人都觉得不安全，则需要与会的人中，职位最高的那个人离开会议，然后再做一次Safe Check，直到大家都觉得足够安全。不过，对于已经进行过多轮回顾的团队，我们往往会忽略掉这一步。 Retro过程是，团队坐在一起，回顾上一个迭代（通常是两个星期）做过的事情，有哪些做的比较好，哪些有待改进，有哪些疑惑等等。Retro可以有很多的形式，比如简单的Well/Less Well/Questions，更聚焦在产生Action的海星式等等。 通常的顺序是： 引导者请大家用纸笔将想法写在便签（stick）上 Time box这个过程（通常是5分钟） 大家将这些stick贴在墙上 引导者和团队一起过一遍所有的stick 归类相似的stick 引导者促进团队交流，讨论stick上的问题，并形成一些改进点（Action） Action一定要足够具体，并且需要一个所有者，所有者负责确保该Action一定会发生。比如团队发现上一个迭代中Code review做的不够好，一个Action就是每天下午5点有人来提醒大家来进行Code review。 如果这时候发现有太多的问题，团队可以用投票的方式选出本次Retro要讨论的数个stick。 引导会议 在日常工作中，我们几乎每天都有会议，而且越来越多的团队已经意识到冗长，无聊的会议有多大的杀伤力了。在很多会议上，与会者要么在刷新朋友圈，要么在对着笔记本电脑写代码或者读新闻，即使强制要求不许带电脑和手机的情况下，也无法限制参加者神游太虚。 根据《引导的秘诀》这本书里的定义，引导会议是 引导会议是一个高度结构化的会议，会议中的领导者（引导者）引导参会人通过预先设定好的步骤达成所有参会人产生，理解并接受的结果。 引导会议需要充分调用参与者的积极性，每个人都需要足够聚焦，这要求引导者可以有能力使得团队振奋（比如幽默的风格，或者具有挑战性的问题等）。另外，每个人的idea都需要被充分重视（一个细节就是不要随意篡改你听到的内容，这是没有经验的引导者常犯的错误之一）。一旦所有参与者都积极起来，引导者就可以稍微退后一些，将舞台交给团队。 而有时候，情景则相反，大家都不发言，也没有看到明显的发言的趋势，这时候需要一些方法来激励。如果是团队都比较茫然，引导者需要列出一些简单而容易理解的步骤，帮助团队按照预设的节奏来逐步前进。比如，在一开始的时候就将agenda板书在墙上，并通过头脑风暴的方式，鼓励参与者来将自己的idea可视化出来。 一个典型的误区是，引导会议的最后结论是本来就存在与引导者脑海中的想法。如果仅从结果来看，这种情况可能发生，但是只能说是碰巧而已。一个好的引导者需要帮助与会者自己产生，并得出一个可行的，被广泛认可的方案，而不是强加一个自己的给团队。 我们最为专业的引导活动是UX团队在客户现场的inception，inception由一系列相互关联，环环相扣的工作坊组成，这些工作坊基本上都需要采用很多引导的技巧，帮助客户团队将自己的问题描述清楚，并形成一个所有参与者都达成一直的可行方案。 如果你不知道如何开始一个引导会议，一个简单而通用的模式是： 我们的现状是 我们的目标是 我们如何到达目标 在行进中，如何度量 《引导的秘诀》里还提到了一种5P模式：目的(Purpose)，产出(Product)，与会人(Participant)，可能的问题(Probable issues)以及流程(Process)。 5P提示你在准备会议之前，需要尝试回答这几个问题 为什么要开这次会议？主要目的是什么？ 会议后的产出是什么？ 谁需要参与会议？ 在会议中，我们可能遇到什么问题？ 遇到这些问题是，我们如何解决？ 引导中的常用技巧 在引导活动中，有一些基本的规则，可以保证引导会议的顺畅性，比如...