在最高层面上，整个团队必须目标一致，在报告进度上遵守最佳实践。 ### 任务宗旨——不，我是认真的 每当听到“任务宗旨”这个词，很多人的第一反应都是大公司颠来倒去说的那些空洞无物、营销意味浓重的公司宗旨之类的东西。下面这个例子就是一段某家不具名的大型电信公司的公司宗旨。 我们立志成为全球最受尊敬、最有价值的公司。我们的目标是通过令市场瞩目的优质服务来丰富客户的个人生活，帮助企业获得成功，同时为股东创造价值。 说来奇怪，我不觉得有任何人尊敬这家公司！这里是另一家大型企业的公司宗旨： **提供实时的解决方案以满足客户需求。** 这句话到底是什么意思？它可以代表任何事情——如果我们在这家公司工作的话，我们根本就不知道到底是编写软件更重要，还是修漏水管或者送披萨更重要。正是这种含糊不清的东西让公司宗旨在世人眼里显得那么空洞。 对工程团队来讲，撰写任务宗旨就是要准确地定义产品的方向和范围。好的任务宗旨不是轻易写成的，但是它或许能为你节省数年的时间来澄清哪些是团队应该做的，哪些是不应该做的 ¹。 几年前，当Google决定要把Google Web Toolkit（GWT）开源的时候，我们曾经担任过团队的指导。我们检视了开源和闭源开发之间很多不同的地方，特别注意了在一个谁都可以来发表意见、贡献补丁、对产品最微小的某个方面提出批评的环境里，设计、讨论和编写软件所要面对的困难 ² 。在解释了这些困难之后，我们告诉团队，他们需要写一份任务宗旨，向公众描述哪些是产品的目标（还有哪些不是）。 出于上述各种原因，有些工程师对此颇为犹豫，但是也有一些人表示有兴趣，团队负责人似乎也觉得这是个不错的主意。但是等到真正坐下来开始写的时候，大家对于这份宗旨的内容、基本要素和风格又产生了巨大的争论。在一系列讨论（和会议）之后，团队不但交出一份漂亮精练的任务宗旨，甚至还准备了一整篇“让GWT更出色”的文档 ³ 来逐条解释它。他们还专门开辟一节来解释哪些不是项目的目标。下面就是这份任务宗旨。 GWT的任务是要通过让程序员利用现有的Java工具，为任何现代浏览器构建全功能的AJAX，从而彻底改善用户的网络体验。 这句话包含了很多基本要素，我们认为它是任务宗旨的绝佳范例：它不但包含了方向（通过让程序员……改善网络体验），同时还限制了范围（Java 工具）。几年后有一次我们和那位团队负责人吃饭的时候，傅攀勃告诉他说我们非常感谢他当年坚定地支持我们让团队撰写任务宗旨。他回答说，其实当初我们提出的时候他觉得这完全是浪费时间，但是当他开始和团队争论怎么写的时候，他居然发现了一些之前都不知道的事情：他的首席工程师居然不同意产品的方向！ 撰写任务宗旨强迫他们在产品的走向上求同存异，否则到时候一定会拖缓（甚至停滞）开发进度。在网上公开任务宗旨后，不但整个团队自己可以完全专注在那些必须完成的事情上面，而且也不需要再浪费口舌去和潜在的贡献者争论产品方向——他们只需要让新人去读一读“让GWT更出色”这篇文章就可以了，很多问题都能迎刃而解。  任务宗旨可以帮助团队求同存异 任务宗旨可以保证项目不会随着进展而偏离目标。但它也不是一成不变的。如若所处大环境或是商业计划发生巨变（对创业公司来说很常见），团队成员绝不能顽固不化，他们应该重新评估原来的任务宗旨是否还有价值。像宪法一样，这种改变肯定是异常困难的，因为它原本就不应该是可以随意更改的东西。但是当这个时刻来临之际，至少它是可以改变的，人们也应该予以认真考虑。任务宗旨应该与时俱进，及时反映公司或者产品的变化。 ### 开会要有效率 绝大多数工程师都把会议归类为必不可少的恶魔。如果利用得当，开会是很有用的，但是人们经常会滥开会，组织不当，而且几乎一定会把会议拉得很长。我们期望的会议应该像污水处理厂一样：数量要少，位置要远，还要在下风口。所以这一节也非常精练，只讨论小组会议。 首先是所有会议中最可怕的：常务会议。这种会议一般一周开一次，应该只能用于发布简单的通告或者介绍——要求所有与会人员一个一个报告进展情况（不管他们是不是真的有什么重要的事情要宣布）完全是浪费时间，只会让人觉得不耐烦，恨不得立刻打晕自己好不用再受折磨。任何值得深入讨论的内容都应该在会议结束后进行，而且应该只涉及相关人员。这种会议应该允许人们在重要议程结束时离开，而且要是没什么大事，或者可以通过 E-mail 来宣布消息的话，完全可以取消会议。我们曾经见过一些把能够参加会议和身份地位等同起来的公司文化，结果没人愿意被落下。说得直白一点，这种做法实在是太愚蠢了。 有些工程师非常推崇像敏捷这样的开发方法所倡导的每日站会，如果能保持短小精悍，这种形式是可以接受的。这种会议一开始的时候都很短（15分钟左右），大家真的是围站在一起，轮流报告自己正在做什么，但是如果不保持警惕，很快这些会议就会被拉长到 30 分钟，人们会坐下来东拉西扯，好像是参加集体治疗课程一样。所以，如果你的团队打算开每日站会的话，一定要事先委任会议主持人，而且他要看着时间，防止会议变得太长。 如果你正打算做一些新的设计，那么尽量把会议人数控制在五个人以下——除非只有一个人可以拍板，否则在超过五个人的会议室里是做不出任何新设计或者决策的。如果你不信，可以去找五个朋友一起跑到市中心，然后试试看你们六个人能不能设定一条覆盖六个旅游景点的观光路线。我打赌除非你们让其中一个担任领头羊，然后他怎么走你们就怎么走，否则你们会站在路口争论一整天。  没用的会议和折磨没什么两样 会议对所谓的“工作时间”⁴ 来说通常是一种干扰，这个词的灵感来自保罗·格雷厄姆的一篇文章“工匠和老板的时间安排”⁵ 。如果工程师总是要中断手头的工作去开会的话，他们是很难完全进入工作状态的。你应该在日程表上留出三到四个小时的大段时间，把它们标记为“忙碌”或者“工作时间”，然后把事情做完。如果一定要开会，那么尽量把会议安排在休息时间，比如午饭时间，或是下班之前。Google一直都有（可惜也经常被无视）“周四不开会”⁶ 的传统，就是为了让大家有时间把工作做完。好的开始就是成功的一半，以后甚至可以空出20～30个小时的大段时间来专注工作。 有关开会的五条小贴士： 1．只邀请一定要参加的人； 2．开会前要决定好议程，而且要事先通知所有人； 3．达成目的后应提早散会； 4．注意别跑题； 5．尽量把会议安排在休息时间前后（比如午饭时间，下班前等）。 开会前一定要事先准备好会议议程并且至少提前一天通知所有与会人员，让大家知道要开的是什么会。把会议人数降到最低（别忘了同步交流的成本）。我们认识很多人会无视没有议程的会议邀请，包括工程师、工程经理，甚至主管和副总裁。 为了能达成会议的目的，只邀请那些真的需要与会的人。有些人在发现与会者实际上是在看 E-mail 而没有认真开会的时候，会规定不准带笔记本电脑去开会。可惜这只是治标不治本——人们在开会的时候看 E-mail 很有可能是因为他们一开始就不需要参加这个会议。 主持会议的人应该拿出权威来毫不犹豫地（有礼貌地）打断那些跑题乃至妄图独揽话语权的人。要做到这一点并不容易，但却是值得的。最后，也是最重要的一点就是，如果时间尚早而议程上的议题已经讨论完毕，千万别犹豫，立刻散会吧。 ### 地理上分散的团队 如果你隶属一个分布各地的团队，或者工作的地方离同事们很远，那么不但需要在沟通渠道另寻出路，更要在沟通上面多下功夫。如果团队里有异地的同事，那么决策的记录和分享往往都是书面的形式，比如E-mail。在线聊天、即时通信、走廊上的随性交谈都可以是沟通讨论的地点，但是我们还是需要把这些讨论的相关内容广播给所有人知道，保证大家的信息对等性以及参与度（另外一个好处是，存档后的邮件列表就是文档）。当需要快速建立对话的时候，视频对话也是非常有用的工具，而且现在为整个团队配备摄像头的成本也是相当低廉的。 我们在做Subversion项目的时候有一句座右铭：“邮件列表上查不到的讨论等于没发生过。”在聊天室里说话可以百无禁忌，什么想法都可以提出来，但是到了真正确定方案的时候，我们千万不能忘了那些没参与讨论的人。即便团队分散各地，只要将这些谈话内容重新发表到邮件列表上，每个人就都有机会看到决策是如何形成的（如果觉得有必要，他们还可以发表意见）。如果你想要培养基于共识决策的团队文化，那么这一点是至关重要的。 和一个远在异地的同事交谈应该和直接去他的办公桌交谈一样做到无摩擦。如果你在异地工作，那你应该利用所有的媒介（比如在线聊天、即时通信、E-mail、视频对话、打电话等）和团队沟通，保证大家不但知道你的存在，也清楚你在干什么。最重要的是，千万不要低估了面对面交流的力量。无论你发了多少E-mail，在网上聊了多久，打了多少个电话，还是要大胆地经常跳上飞机去见见同事们。这也适用于海外的雇员、团队和分部雇员——安排好时间去总部和同事们见个面吧。 ### 设计文档 开发新项目的时候，往往很难抑制住那种想要立刻开始写代码的冲动，但是这么做的结果往往是很糟糕的（除非你只是打算很快地做一个粗糙的原型出来）。同样，很多工程师都不做设计就直接开始编码，后果往往是惨不忍睹的。 设计文档一般由一个人负责，两到三个人撰写，审核的人数则更多一些。它不但勾勒出整个项目的前景，也直白地告诉整个团队你想做什么以及打算怎么做。而且这时你还没有花费几周（甚至数月）编写代码，比较容易接受意见和建议，帮助你改进产品和优化实现。另外，当设计文档定型之后，它能帮助你安排划分项目的工作量。而且，当编码工作开始以后，设计文档绝不是一成不变的：随着项目的进展而发生的变化应当及时反映在设计文档里，而不是等到了产品要发布的时候才去更新，不过这一点是说起来容易做起来难。大多数团队根本没有文档，而有些团队只在很短的一段时间里有很漂亮的文档，剩下的很长时间里只有过期的文档。 说到这里，你也不要走到另一个极端“唯设计文档论”里去。我们曾经遇到过为了一百行的小程序写了整整四页设计论文的控制狂。如果写一份设计文档的时间足够把整个项目推翻重写好几遍的话，那就不要浪费时间写设计文档了。用经验和判断来作出适当的权衡吧。 * * * * * > ¹ 这一点我们要一再强调——保持专注的方法就是要拒绝各种诱惑。 > ² 我们经常把编写开源软件比喻成在弹跳床上用扑克牌搭建房屋。这需要稳健的双手、大量的耐心，还有能大声制止那些看也不看就想往下跳的人的决心。 > ³“让GWT更出色”可以在这里找到，http://code.google.com/webtoolkit/making-gwtbetter.html。它绝对是任务宗旨的写作典范。 > ⁴ 译注：原文是“make time”，即工匠（maker）专注工作的时间。这里的工匠一词泛指那些从事创造性活动的人，比如程序员、作家等。 > ⁵ http://www.paulgraham.com/makersschedule.html > ⁶ 这个传统是Google工程部的副总裁韦恩·罗辛在2001年建立的，旨在改善工程师的生活品质。傅攀勃多年来一直都坚持不在周四开会，效果相当不错，但是这需要非常严格的执行力，如果有人不识相的话，有时候还可以写E-mail去大骂一通。