希拉里竞选团队CTO：如何让工程师团队的沟通更高效

大数据文摘作品，转载要求见文末

编译 | 大力、张家豪，ether、

田奥leo、宁云州

初创公司工程师团队的工作往往是从人数上开始出岔子的。

希拉里·克林顿总统竞选团队中的前任副CTO（首席技术官）Derek Parham如此描述工程师团队的合作问题。因为不了解团队之前的情况，新入职的工程师很可能会改写代码并搞砸一些工作。

工程师们的工作会有重合的地方，他们会在毫无意识的情况下处理相似的问题，因此宝贵的时间（尤其是对那些处理混乱情况的高级工程师而言）都被浪费了。

“随着工程师团队人数的增加和产品数量的增长，团队会陷入不健康的工作模式中，” Parham说道：“就好像一个小孩的衣服，随着她长大，渐渐穿不下了。而且她不可能某天醒来突然发现鞋子小得穿不下了。对于工程师团队来说，在意识到问题存在之前，这一直是一个缓慢而微小的阵痛， ‘因此必须得作出改变。’”。

Parham对组织管理大型的工程技术团队这种具有挑战性工作非常熟悉。希拉里的竞选团队快速招聘了80个人的技术团队，并由Parham负责招聘、数据基础架构、移动端、运营和安保部门——这是建立在一个由500多名技术型志愿者组成的叫做Devprogress的团队。在那之前，他帮助开发了谷歌公司的智能办公套件G Suite，并担任技术总监。G Suite旨在为所有公司、学校和组织带来高效的办公应用。现在，Parham是很多处于快速增长期企业的顾问。

专注于工程架构、团队成长和产品开发的工作让Parham不断见到相同的问题在团队中一次又一次的出现。在这篇采访里面，他与我们分享了技术设计评审系统（包括他亲自测评的部分）。它最成功的地方在于能使工程技术团队健康运转、沟通明晰并卓有成效，即使团队成员不断壮大、团队所需工作的项目不断增多，也能保持这个系统有效运转。

做一个工程项目是探寻一片荒野

大部分工程师团队依赖于设计文档来描述、审查和支持项目或部件。这些都不是新的话题了（这些只是我们等会儿会谈论到的基础）。缺少设计文档就开始做一个项目，就好像一个背包客没有地图便贸然闯入一片森林。工程师团队没有那么多探索的时间。对于还不太清楚这些概念的读者，下面这个例子能很好的说明。

有许多理由可以说明设计文档是多么有帮助：

• （理由一）校准：当一个团队人数增加并且开始涉及产品各种方面工作的时候，一部分人就会开始不知道另外一部分人在干什么。如果成员们不完全知道事情的走向，代码和系统就可能出现冲突。设计文档为整个团队提供了一个讨论、咨询和互相理解的平台。
• （理由二）了解背景：如果设计文档将之前的工作都分类好，新来的工程师就能迅速的融入到工作中，了解到产品和功能是如何创建的，了解到具体的操作和过去进行了哪些实验以及过去的决策是如何进行的。设计文档可以记录下已经离职的工程师过去的工作和决策。
• （理由三）制定判断标准：“任何将系统最优化以形成新的功能的工作都需要判断标准”，Parham说道。“也许你需要节省时间、人力，或提前确定产品发布的时间，并且你为了完成工作不得不接受技术债务。”如果你记录下你的判断标准，你就能让团队的工作主次分明。如果情况有变，你也可以很方便地查阅是否需要重新进行相同的判断。

简单来说，设计文档可以在荒野中为你开辟道路，给你设置沿途的路标，因此你可以清楚地知道哪里有弯路和路障以及它们是怎么产生的。“如果你的工程师团队还没有设计文档和检查程序的话，你可以着手这个工作了，”Parham建议到。但是基础的设计文档不足以应付混乱的工作。实际上，如果设计文档没有被妥善处理，它们还会引起其他的麻烦。

设计有效的文档

实际上，如何创建这些文档可能会变成一个烫手的山芋——通常没有人主动想揽这个活。这个工作又累、时间又紧、还会分散其他编程工作中的精力。在许多公司内，设计文档的工作完成后通常没有什么人响应。

Parham说：“人们会将设计文档用email发送出来并且询问其他人的反馈意见，然后你就会发现这个问题，也就是每个人都认为其他人会去读设计文档并给出反馈，然而事实上并没人去做。工程师们会把这种沉默当成默认或者无所谓的情况，然后建立出没有任何反馈的功能或系统。这样的系统往往几个月后就会出岔子，如果人们当初真的读过或者谈论过设计文档，问题也就不会发生了。所以很重要的一点是确保你有一套体系，能够保证员工去读设计文档。”

正因为这种恶性循环，许多工程师团队认为设计文档的工作并没有价值。这种想法通常会变成一种自我实现的预言，然后整个团队的沟通就崩溃了。这也是为什么仅仅做好设计文档是不够的，你还需要有一套完全执行设计检查的流程。Parham在长期的工作中发现：工程师们只有在知道自己的工作会受到全团队合理检查的时候才会真正投入地工作。

要开始这项新的流程，Parham建议你将获得反馈的渠道扩大到对你所做的工作感兴趣或者能够接触到你的工作的其他团队上去——安保、运营、前端、后端或者产品（团队），而不仅仅是工程师团队——这样，越来越多的人会被激励并在适当的时候提供反馈。你可以从告知他们开始，不久之后他们就会开始给你提供建议了。

“让你的初级工程师编写原始的设计文档，然后高级工程师来编辑”他说：“将工作分给更多的工程师会帮助你保持团队的活跃性，同时也能使你的高级工程师有更多其他的工作时间。”

在谷歌，Parham建立了一套详细的设计文档的模板帮助你的团队工作。无论如何，你的文档不应该只是简单的点子合集，实际上应该将不同部分清楚的区分开（并把这些列为一个清单），包括：

• 背景：你所要解决问题的背景。为什么需要解决？它有什么其他相关系统、功能或产品？谁主要来负责这个问题？
• 设计目标：项目的必要条件和目标。也应该包括流量推断、用法、所需正常运行时间等数据。
• 系统图表：所有这个设计相关的二进制数、数据库和第三方服务的图表。将数据可视化极大地帮助人们对项目有一个高层的认识，并且更容易全面地理解受影响的事物。
• 设计总结：用一两段话做解决问题的总结。这个总结不应该太长；旨在帮助人们快速简便地认识正在构建的东西。
• 设计细节：设计的细节特征需要在这里列出。这可以包括许多详细的子部件、代码位置、测试策略、国际化、扩展策略等等。
• 制定判断标准：这里可以完美地进行免责声明，说明特定的决策是如何形成的，负面的影响是如何显现的，需要考虑的缺陷，工作进程中会有的技术债务和未来可能需要改变的结果。

这个模式会强力地迫使一个工程师和团队的其他相关成员开始沟通。他们必然会开始仔细地收集信息并将项目落到实处，而不是凭空草草地写下什么。此外，这个流程还会使沟通更加顺畅，糟糕的点子将更快的被淘汰，任何负面的问题都会在摇篮里被掐灭。

“设计文档其实是很多单向对话和判断标准的一种资料编制。”Parham说。“文档实际上不应该对团队展现出很多新的议题而是主要表现那些已经达成共识的部分。”

初版的设计文档理论上应该被所有关键成员（也就是文档信息的提供者和负责项目的高级工程师）认可，然后你才能将其发送给其他团体。

然后，创建一个空白的谷歌文档让每个人都可以列出自己关于这个设计文档的意见并附上自己的名字，而不是允许所有人都直接在文档上面评论。这将作为即将举行的设计评审的议程。对于感兴趣的人来说，这就是在人们反馈后、和设计检查前的设计文档的样子。

“等到你发送这个设计文档的时候，几乎所有未知的东西都应该在文档写作的过程中被发现，“Parham说。“这种每个人亲身参与的设计评审过程本身并不意味着做出决策。它是为了创造一个更好的团队文化,让每个人都了解文档中的内容，作为一种安全防范机制来捕捉任何隐藏着的或紧急关头的问题。”

建立基本规则

一旦你有了一个扎实的设计文档，接下来就是准备评审本身了。但是如何有效地进行这么多人的审查呢？Parham给出了很具体的建议。

首先，为你这次会话选择一个主持人和会议记录员。他们应该是中立党派，和你在参与的事务没有任何情感的关联(但需要有高于平均水平的指导和对话能力)。然后，在现场审核之前，提前48小时向你想得到反馈的对象发送邮件——发送设计文档以及空白的Google doc以获取问题和评论。在这个电子邮件中为会议设定基本规则和期望。Parham建议把这个列表中的指导发送给你的团队以确保会议是富有成效的:

• 每个人都应该在会议之前向问题文档添加问题。这份文件将成为审查的议程，并让我们能够直接面对问题，节省大家的时间。添加时，请在问题旁添加你的姓名。
• 每个人都可以坐下来听，但除非阅读了设计文档，否则会议人员不能在会议中发言。如果答案在文档中，那么主持人会跳过并打断问题，这样做是为了不浪费大家的时间。我们在房间里有很多人，所以让我们充分利用它。“ （作为这个规则的结果，你会看到许多人在会议之前匆匆略读文档，比以前不读要好得多）。
• 不能发电子邮件，不能打字除非是在记录笔记。可以随意打开笔记本电脑，但只能阅读设计文档。我们在这里是为了把接下来的45分钟全身心地投入给给这个产品或是功能。当你将来提交设计文档时，你也会感激别人同样为了你这样做。
• 主持人会持续将内容推进并且可能会要求特定的讨论在线下进行。这同样是为了节省大部分工作组的时间。

保留非特定专题的问题直到最后，但随时可以跳到与当前相关的任何问题。 记笔记的人应该尽可能记下所有的东西。Parham说：“90％的团队最初可能会忽略这封电子邮件，因为他们正忙于其他工作。 但是，如果他们有机会阅读文档，他们肯定会有问题要添加（因为没有设计文档是完美的）。观察是谁添加问题是跟踪团队参与的一个好方法，同时这也产生了大量的责任与义务。 你甚至可以使用这个过程，看看谁有潜力从初级工程师转移到高级工程师以及他们的见解和问题能够在多大程度上帮助其他团队。”

“我的策略是在接下来的48小时内观察问题文档，并确保它开始被填充，”他说：“你通常会看到一种模式——一两个工程师问了绝大多数问题。这没有关系，因为他们可能会问其他人有的常见问题。但是，你希望拥有多样化的群体提出问题——团队的多样性意味着经验的多样性。

了解你的审查会话中的消息。一个确保没有人兴奋地参加审查的办法是使它看起来像一个正式的演讲，而不是一个讨论。

Parham说：“人们对设计评审的一种模式是用幻灯片把它变成一个编写好的演讲。但是这并不可行。你想提出一个设计评审的目的就是你正在寻找有关该提案的反馈。 如果人们认为你已经做出了不可改变的决定，那么他们就不会在反馈中坦白。

选择主持人是让整个团队的不同成员参与此过程的绝佳机会。你一定想要一个非常擅长沟通的人很好地控制一个房间，了解技术细节，并且不会让谈话变得充满争论或者是话题快速的来回往复。这就是为什么你想要从一个客观的派别中挑选这个角色。当与一份工作的距离很近时，人们很难保持情感的冷静与理性。如果你过分地捍卫你的工作，而不是协作，那么你只会想要从这种客观的工作中脱离出来。 相对而言，来自工程团队其他部门的主管工程师就非常适合主持人的角色。

Parham指出，如果前端团队正在提出一个与几个系统集成的新功能，请让后端负责人或运营负责人担任主持人。你可以用这种方法培养你的高级工程师承担更多责任。你不想让CTO一直在操办这些事情。实际上，你更多地希望CTO成为参与者，而不是主持人或演讲者。

在会议开始之前，为了无需任何谈话就能解决简单的问题，最好在问题文档中提前回答。例如，关于没有详细说明的发布日期或客户端需求的问题，也许一个图表或链接就可以是回答查询的最有效方法，在这种情况下，在线回复是有意义的。但是，作者还是应该准备好跟踪每一个问题。

保持专注

在审查的那一天，保持一种良好的组织性是必要的，你需要让每个人都在45分钟的时间内保持专注，这时候唯一的办法就是创建议程并坚持下去。以下是Parham建议你做的步骤来确保可以成功完成一个亲自参与的设计审查：

1.发送提醒

在审查开始前几个小时，发送一封电子邮件来提醒小组将他们的问题添加到指定的文档。通常情况下，这是大多数人实际阅读并做出贡献的时候。然后，在审查开始前约30分钟，主持人应根据情况对问题进行处理，并进行分批归类。

• 你的所有运营相关的问题是什么？
• 你的所有安全问题是什么？
• 你的用户体验问题是什么？

这可能需要一个很好的逻辑分组，因为在审查过程中，你需要同时讨论类似的事情，以使得对话的内容建立在类似的事情之间或者同时回答相关的问题，“Parham说。

为了确保合适的人员参加并实际来到会议，你可能需要有一点创意。每个人都有自己的方法，但它们的共同点必须是活力。你应该抽出一个场合，来阐述这对你和你的团队来说很重要；你很高兴能获得反馈，因为这样才有可能构建最好的东西。你应该使用你所拥有的任何工具来传递这种兴奋的感觉。

Parham说：“在谷歌，我会使用Nerf武器（一种玩具枪）让每个人参加设计评审。”“我们将对他们开火直到他们起身并过去。 我会在整个走廊上跑动，说：‘设计评审时间！ 设计评审时间！’“你可以使用食物，关闭他们的电子邮件帐户等各种方法，只要你能让人们出现在设计评审的现场就行。

2.回顾规则

刚开始时，主持人应该提醒记笔记的人员在审查过程中跟踪关键的观点和见解。 当每个人都在房间里后，他们应该简单地过一遍规则来再次强调它们需要被实施。

Parham说：“你需要强调大家不要说话，除非他们读过设计文件。这是关键，因为在许多设计评论中没有阅读文档的人将会开始提问已经存在和已经得到回答的问题，而浪费大家的时间。一个房间里可能有20个人，你需要十分高效。当他们的时间收到尊重后，工程师会非常感激。”

阅读规则后，一堆人会打开笔记本电脑，打开设计文档并开始阅读。人们通常会去会议并仅仅是去听，但是如果你告诉他们在阅读之前他们实际上并不能提出有价值的意见，他们会去阅读它。

3.让每个人大声阅读自己的问题

在设计评审过程中，主持人不该作为问题的提出者，而是应当把机会给大家，让提问者自己说出自己的问题。

“让每个人在团队中发声，可以获得更有效、更实在的回答和反馈”，Parham认为：“这样的交流讨论是更为自然和真诚。如果让主持人照本宣科般的念一题答一题，大家很难专注和投入其中，不够了解提出的问题，也不能给出很好的回答。”

如果某个问题占用时间过多，或某个回答太冗长，主持人可以打断他们。会议记录员负责记下每个达成的共识和决定，而且最好尽可能详细地记录下所有内容，在Google Doc的问题列表中就可以查看哪些问题是有回应的和回应的具体信息。这样能帮助大家回顾会议内容，特别是对于没参加会议但是感兴趣的人，会便利许多。

“如果你的设计文档做得还不错，不大会有很多宽泛的提问发生。” Parham 说：“大家提的问题会是比较明确的，答案也都是直截了当的，像是‘我们没有这样做，因为做了个权衡取舍，主要考虑的因素是xxx’’或是‘我们会把这个加入进去’这样的。”

4.开放讨论

当Google Doc里写下的所有问题都提问完毕，如果还有时间的话，主持人应当留给大家开放讨论，提出其他的具体问题，或者提供建议和反馈等。比较好的情况是，有一些新的内容或修正在开放讨论中提出，但不会太多。偶尔也可能会有很多。

“在Google，如果某个设计文档中存在一些明显的争议或问题，我们会在更新改进文档后，再进行一次讨论，” Parham说：“对于大的项目和团队来说就更是这样，比如人数在100人以上，必须确保每个人都对细节了解得很清楚才行。因为你要做的是可能要用数年的系统，花几周时间把它理清楚，是应该的。”

比如像几年前Marketplace这个app的设计过程就是如此。

“我记得设计文档修改过很多次，因为Marketplace是个很大的项目。它是我们远程合作完成的，也是比较早期的项目，那时有不少沟通方面的问题产生。设计评审流程可以在这个时候发挥作用，因为我们只需用几周时间去反复调整和改进，这样比耗费半年时间把项目做完了却发现更大的问题来得好，比如产品没法用，或者和其他产品或功能有冲突，或者满足不了人们的需求。”

Parham认为，这样的设计评审流程，对于大的团队或是有许多远程合作的团队来说，是非常有帮助的。那些在外地的团队成员，常常会觉得自己被遗忘或被排除在讨论之外，这个流程可以让他们了解大部队的进度，并参与到讨论中来。

“在一开始的时候，多花点时间写设计文档和做评审，是值得的。这样能保证每个人都知道要做什么，明白有哪些利弊上的权衡和取舍原因。要确保沟通是足够充分的，特别是要听取关键岗位的工程师的看法，这样能避免将来产生问题和麻烦。”

处理反对意见和异议

设计评审过程中，有时会产生积极的甚至是激烈的争论，这是很自然的，却是很不利的。如果争论持续时间过长，耽误了其他问题讨论，主持人应该介入和喊停。如果争论还在继续，应该由资深的工程师出来维持讨论秩序。

“如果评审过程中产生了激烈的争论，主持人应该控制好场面，让争论方意识到我们该转移到更核心问题的讨论上，把公开争论改为私下讨论。”

一般来说，如果有较大的争论产生，是因为没有和与之相关的人员充分沟通。你可能得和他们一一交流，把这部分设计文档重新写一遍。请告诉争论方，你会和他们进一步沟通，讨论各方观点的优劣，把他们的意见考虑进去。

“如果设计文档很完美，那么评审过程中不会有问题产生，大家会说这个已经是最优的了，” Parham说：“但我们总有局限和不足，一蹴而就的情况是很难发生的，总是会需要不断地检查和改进。这个不断改进的过程中，可能大家提供的意见是先后不同的，好的建议也许会来得稍晚一些，不要觉得步伐被打乱了，这也是计划推进的一部分。”

如果你是第一次做设计评审，有争论产生是不可避免的。当你做得越来越熟练，争论也会减少。

Parham认为“争论也是好事情，它们的作用是很神奇的。你会发现，哇，这个漏洞我们现在就发现了，不是三个月后才来挽救。还没开始码代码，只是一块做设计评审，就能做到这点。”

最严苛的批评造就最好的问题预防体系

严苛的批评反对，对于团队成员也是好的学习机会，包括资历稍浅的工程师和非工程师们，都能详细了解到技术方案和利弊权衡取舍的决策过程。

对团队的益处

Parham 说：“想想看，有多少公司在项目实施后才征集大家意见和建议，而在此之前忽略了某些重要问题，很多代码和时间精力都浪费了，以至于不得不从头来过。这对初创公司是极大的耗损，必须牢记。”

设计评审过程，从一开始的文档编写，到后面的公开或私下的交流讨论，对团队有许多益处：

• 促进整个公司内的交流沟通
• 提高对技术基础架构的理解，特别是对非工程师而言
• 对过去完成的和现进行的项目有更好的了解
• 设计出更好的功能和产品
• 节省时间精力，特别是对更高级岗位的人员而言

按照设计评审的这些步骤，能让每位工程师都说出自己的想法，而非仅是那些最常发言或最强势的。

“技术负责人都明白，你的团队中会有经常发表意见的成员，也会有很少发表意见的成员，” Parham认为“很多时候，他们其实有很深入的思考，只是没有表达出来。比如大家在进行无明确目的或主题的讨论时，或者在邮件里争论某个问题时，这些安静的工程师们并不会加入其中。而设计评审流程，可以让他们也很自然地参与进来。”

设计文档的编写和评审流程，能避免不必要的时间精力浪费，也能有效地促进公司内各个职能部门间的沟通。

“大多数工程师只是希望自己的意见被听到，即使在过去的项目中，他们的意见没有被采纳，他们仍是希望参与的，” Parham说“虽然更高级的职位才是做最终决策的人，但培养每个人都能在决策流程中有所贡献，而不是被告知或接受指令要做什么的氛围也是设计评审流程意义所在。”

除了技术部门，对其他职能部门，比如市场，销售，设计等也是有帮助的，让他们的成员参与进来，实现跨部门的信息开放和沟通，受益面将是很广的。

“任何人都可以参与到设计评审中来，” Parham说“好的想法可能产生于任何一个地方。我喜欢让设计和产品团队都参与进来，他们能更好地从公司层面来思考，并懂得怎样把自己的工作做得更好。”

原文链接：http://firstround.com/review/making-engineering-team-communication-clearer-faster-better/

2017年7月《顶级数据团队建设全景报告》下载

关于转载如需转载，请在开篇显著位置注明作者和出处（转自：大数据文摘 | bigdatadigest），并在文章结尾放置大数据文摘醒目二维码。无原创标识文章请按照转载要求编辑，可直接转载，转载后请将转载链接发送给我们；有原创标识文章，请发送【文章名称-待授权公众号名称及ID】给我们申请白名单授权。未经许可的转载以及改编者，我们将依法追究其法律责任。联系邮箱：zz@bigdatadigest.cn。