厌倦了频繁往复地用Email发送或更新会议议程？何不把它更新在一个Wiki页面上而把链接共享给你的团队？Wiki相对于E-mail的其中一个重要优势就在于它将众人的目光凝聚“拉(pull)”到一处，而从本质上改变信息更新和共享的方式和效率。在每次更新过内容之后，你只需再次把链接通过Email发送出去（更方便的是一些企业Wiki已经具有自动邮件通知的功能），把人们的注意力“拉(pull)”到你的更新上来。这样带来的好处是：

• 在会议开始前同事即可充分了解会议内容
• 在会议结束后方便跟踪任务状态
• 自动归档历史会议记录，方便日后查询或引用

企业内部沟通方式从“push”方式（如Email等）向“pull”方式（如企业Wiki等）的适当倾斜，可以使得你的项目管理或者会议管理更加高效、方便而且透明。

Wiki vs Email

企业Wiki和Email之间最大的区别是他们的工作机制：Email用来“Push”信息，而Wiki却恰恰相反，它通过“Pull”信息而实现自我进化。

我们已经习惯于通过Email把信息发送给地址簿里的任何一个人，而且这样似乎看起来非常简单有效，然而事实上，每个新邮件的到来从某种意义上来说对收信人都是一种“干扰”，而且因为每个收信人都收到了一个copy，他们实际上都被孤立了，因为他们不知道别人在收到邮件后的反应——如果邮件的初衷是为了讨论某个问题，这种形式的效率将非常低下。

Wiki的出现，将众人的目光拉拢到同一个可更新、讨论的页面上，因为每个人都可以阅读、评论和更新，这就意味着每个人都可以在第一时间内与别人交流意见，从而逐渐在同事中营造出一个活跃而且内容丰富的互动社区。

换句话说，Email更适合用来通知，而Wiki则更适合用来讨论。我们需要做的则是让他们物尽其用，既通过Wiki：

1. 讨论问题；（越是旷日持久，越能见到Wiki带来的不同）
2. 更新文档；（越是层次丰富、参与者众的文档，越是需要企业Wiki的协作优势和版本控制）
3. 保存不时之需；（不积跬步，无以至千里）

而通过Email仅仅是通知重要信息。

通过结合Email使用Wiki，我们可以尽量减少“无用”邮件对人们日常工作的干扰，同时又可以在企业内部“培育”出一个集中、高效且灵活的信息共享和发布平台。何乐而不为之

高效会议

如何举行高效的会议已经是老生常谈，你可以参考一下唐骏的如何组织高效会议，其实根本没有什么大不了的，也完全没必要拘泥于某种所谓“高效会议”的形式，如果说有，那就在开会前问问自己，这个会要解决什么问题？如果没有问题需要解决，大家现在和将来都会安居乐业，又为什么要开会浪费时间呢？除非只是想交流一下同事感情，活跃一下项目气氛？

好了，言归正传。使用Wiki能使你的团队的会议更短更有效率。为什么?

1. 会议议程。借助Wiki的在线更新功能你可以事先把会议议程共享给同事，从而使得任何与会同事都可以在会议开始之前就得以了解会议议程并做相应准备（报告抑或问题等，当然也包括打瞌睡），因此在会议中，问题的提出会更有针对性；
2. 与会同事甚至可以在会议开始前就在Wiki上提出自己的问题和意见，作为会议的主持人你可以更容易地把握会议节奏（什么问题需要详细讨论，什么问题可以暂时靠边站）。你的会议因而更加高效；
3. 会议备忘录。会议结束后最重要的是会议备忘录——我们把它更新在Wiki上，并保持跟踪每一项任务直至任务结束。这样，你便可以非常轻松、高效地开好任何一次会议。

你觉得怎么样？

Wiki不是银弹，它并不万能。试图用企业Wiki迅速替换掉现有的Office工具并不现实，更切实可行的做法是，Wiki应被用作提高项目运行效率的润滑油——它共存于我们日常应用的各种工具之间（如Microsoft Office等办公软件， Outlook等邮件系统），通过取长补短，我们的团队可以基于Wiki平台共享项目知识、工作实践甚至开展计划、跟踪任务（可以参考用JIRA, CVS, XPlanner, 和Wiki来进行项目管理），从而逐渐使得项目团队这台发动机的各个主、配件之间相互配合得更为流畅，在最大程度上发挥系统性能和团队生产力。

在知识管理中，一个成功的Wiki平台就是项目团队中一块吸引知识碎片的磁铁，它的磁场就是团队协作，项目或者部门的维基教练或者知识经理（Knowledge Manager）则是保证这个磁场历久不衰的关键。

Wiki不是银弹，它只是一种高效工作的手段。

行动前的头脑风暴！

在开始实施企业Wiki之前，包括在试点Wiki之前，大家需要聚在一起头脑风暴：Why and How? 也就是为什么以及如何建立Wiki。

在解决“为什么”的问题时，首当其冲的就是分析、研究当前团队或者项目的Pain Points，然后维基教练需要从一一列出的pain points中出发去寻找是否有基于Wiki的解决方案，比如：

• 团队需要把小而零碎的知识收集到一个集中的地方以方便大家查询；
• 项目经理需要为新加入的员工创建项目的beginners’ guide, 以使得他们尽快上手工作；
• 维护或者支持性的项目亟需一个强大的知识库以提高团队响应时间和工作效率；

如果大家最后没有找到Pain Points，就最好不要强求——既然团队工作已经很有效率和默契，为何还要画蛇添足呢？ 只有当新的工具真正为团队带来实惠，才能谈的上真正的成功，才算“有意义”。