按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
，并且像狗一样追着自己的尾巴，结果自然是一无所获。我不知道——也许你应该预先发一个议程，或者一些我们将要讨论的文档？拜托你做点什么！
如果你把会议的主旨作了通告，我可能还会提醒你，一定要坚持这个主旨！我不关心是否还有另外50个会议，去做另外的50个决定、讨论另外的50个话题或者更多的信息共享。我现在参加这个会议，我就只想专注于这个会议。如果有人想要谈论其他的什么事情，让他在我们结束之后再上演他自己的秀吧！
作者注：如果有人试图转移话题，你该如何不失礼貌地打断他呢？我喜欢的方法是，对他说：“让我们先把这个话题讨论完，然后再谈你的话题。”通常情况下，当你结束了第一个话题之后，所有人都想离开了。那个会议干扰者将不得不另外安排一个会议，并且邀请合适的人参加（这样要好得多）。如果那个干扰者坚持认为应该先讨论他的话题，那么首先讨论他要这么做的理由（这时候会议实际上仍然聚焦在原先的话题上）。如果理由很充分，那么是你的会议时机还不成熟，因而是你的会议需要另行安排。在这种情况下，没人会介意离开当前的这个会议。
我们正在试图做什么？
接下去，我的问题是，“我们正在试图做什么？”
？ 我们是在试图做出一个决定吗？很好，就让我们做个决定，其他的像头脑风暴、状态检查、流言澄清等统统跳过。
？ 我们是在试图共享信息吗（比如一个状态汇报会议）？很好，把信息列表上的内容过一遍，但不要试图去做什么决定或者解决什么问题。
？ 我们是在试图收集想法吗？很好，捕捉每个人的想法，无论它们有多荒诞都不要作出批评或论断。最后，挑出其中最好的一个即可作为会议的成果了。
这里的要点是，混合会议是低效的，常常会徒劳无功。大家都知道了为什么会聚到一起来，也知道了会议正在试图达成什么目标。如果你必须中途改变这些前提，那你要深思熟虑之后，让每个人都意识到，现在规则已经变了。否则，你会浪费所有与会者的时间，永无止境地纠缠不清，最后还不得不重新召开会议。如果你要这么做，麻烦你不要邀请我。我不会参加的！
作者注：有个典型案例，就是在Scrum会议上提出设计问题来讨论。Scrum会议是用于共享信息的，不是用于收集想法或做决定的。没什么像设计讨论一样，不经意间就能让Scrum会议脱离轨道。然而，因为设计讨论是很值得做的，我们在Scrum会议上会把讨论的话题在白板上列出一个清单。等Scrum会议结束之后，那些想讨论这些话题的人可以留下来，参与接下去的设计会议。
为什么他们会在这里？
很好，我们已经知道了开会的理由，也知道了我们正在做什么。现在的问题是，为什么他们会在这里？我指那些不该在这里的人。这些人在问一些多余的问题，他们只是在重复别人的观点，他们只需在必要的时候表示一下同意。那么，为什么这些人会在这里呢？
会议的持续时间跟参加会议的人数是直接成比例的，说不定它们的关系还是线性的。你应该只邀请那些必须出现在会议上的人。
？ 试图做一个决定？邀请可以做决定的人。其他所有人都可以在会议之后、通过e…mail了解到会议的情况。不是所有必要的、需要做决定的人都能参加吗？那就取消会议。立即取消！否则，你将不得不在所有人都能参加的时候重新召###议。
？ 状态汇报会议？邀请那些将要汇报状态的人。其他所有人都可以在会议之后、通过e…mail了解到会议的情况。有一些需要汇报状态的人不能参加吗？我猜他们肯定是懒鬼。
？ 头脑风暴会议？邀请一些有创意的、思想开明的人，他们是会议成功的关键。其他所有人都可以在会议之后、通过e…mail了解到会议的情况。
有时候，你必须邀请一些其他人来参加会议，他们对会议是否成功起着至关重要的作用，比如主持人、协调员、啦啦队队长等。但也就这些人了。如果太多其他人登记要参加会议的话，你最好取消会议。（你可以预先判断出将有多少人参加会议，因为当有人接受一个转发的会议邀请时，你会收到一个确认信息。）
尽量预定一个小型会议室，这样可以把一些不速之客排除在外。尽量把会议安排在30分钟内结束，这样可以让大家准时出席并且保持会议过程的高效进行。你可以声称这是一个“工作会议”，必要的时候甚至可以使用“信息权管理”（IRM，Information Rights Management），以阻止会议邀请信被转发。
为什么我现在才听到这个？
对于一些重要的主题，你不想让关键的相关人员吃惊。没人喜欢匆匆忙忙地被拉去做至关重要的决定，也没人希望对关键领域发生的事情丝毫不知。如果你想要会议开起来比较顺畅，那么预先跟关键人员做个沟通。你们可以发现问题，协商折衷方案，预先让所有人都取得一定的共识。接下去，会议更多地只是一个形式了。对于要做决定的会议来说，这是个好方法，只是它比较费时。但对于一些至关重要的决定，这也是至关重要的一步。
书包 网 。 想看书来
接下去要做什么？
现在会议开完了，结束了，一切都过去了，对吗？错了！会议像好莱坞恐怖电影中的鬼怪蛇神一样，它们会重新获得生命，然后吃掉剩下的那些人。决定接下去要做什么，把它们写到e…mail中去。这样才能使已经结束的会议不会死灰复燃。
写e…mail的时候，把所有与会者的名字放在地址栏中，并且抄送所有受会议结果影响的人。务必要包含一个对会议所做的决定、共享的信息或者收集到的想法的简短总结。然后列出接下去的安排，指明谁在什么时候做什么事情。此刻，你终于可以放心地继续前进了。
看到了吧，尊重别人的时间并没有那么难！会议在很多方面是昂贵的。当然，会议对于加强组织的沟通也是必要的。但如果你要开会，那就把会开好。所有人都会赏识它，你也能完成更多的事情。
书包 网 。 想看书来
你失去理智了吗？
2006年7月1日：“停止写规范书，跟功能小组呆在一起”
我不是项目经理（PM，Program Manager）。我也从来没有担任过项目经理。我将来也不可能成为一名项目经理。这并不是我个人对项目经理的抵触。因为我的朋友之中不乏有出色的项目经理。很显然，我没有权利去教导项目经理怎么去做他们的工作。
尽管如此，项目经理应该停止写规范书。就这么简单！他们在浪费我的时间，浪费组织的时间，浪费整个公司的时间。你几乎可以听到残留着的、细微的、嘎扎嘎扎的声音，因为规范书像白蚁一样在一口一口咬掉公司和客户的价值。我对此深恶痛绝！
其实不仅仅是项目经理。开发者也必须停止写开发规范书。测试者则必须停止写测试规范书。疯狂必须停止！浪费必须停止！我们必须重新找到我们的感觉，找回我们的生产力，还有我们的智慧。
作者注：如果用回应数来考量，本栏目肯定是我发表过的最有争议的栏目之一。你也可以从接下去的那段文字看出，我当初就猜到了这一点。关于我的观点，大家最大的误解是在“正式文档”和“非正式文档”的区别上面。我认为，多工种呆在一起工作的团队只需要非正式的文档，比如把白板上的内容拍了照片放到维基网站上，并加上少许的注释。而被距离隔开或按照工种划开的团队则需要正式的文档，比如具体的规范书。
“你肯定不是认真的？”我听到忠实的读者这么说，“你多年来一直鼓吹质量（参见第5章的“牛肉在哪里”栏目）和设计（参见第6章的“通过设计解决”栏目）。你告诫开发人员在他们拿到规范书之前不要采取行动，在没有彻底理解设计之前不要开始编码。莫非现在你承认以前是被误导了，或者甚至可能你本身的认识就是错误的？”不，当然不是。
功能团队在开发用户体验之前必须首先理解它，开发人员在实现一个内部设计之前也必须首先充分理解它，这样才能面对面地解释给同伴听。但是，这些步骤中没有哪个需要正式书写的文档。
为什么我们需要正式书写的规范书呢？客户不需要它们。市场和产品规划部门也不需�