团队管理之道——Michael Collins访谈录

团队管理之道

Michael Collins访谈录

【Michael
Collins
】是RedJack有限公司的首席科学家，该公司为马里兰地区提供网络安全方面的咨询。在这个职位上，他开发了可供超大型网络使用的流量监控系统和分析技术。在到RedJack公司工作之前，Collins博士在卡耐基·梅隆大学的CERT网络情景侦测（Network
Situational Awareness）团队中工作，那时他所开发的工具和技术供美国国防部CENTAUR项目和美国国土安全部的EINSTEIN项目使用。
【Andrew Stellman & Jennifer Greene】资深软件工程师、项目经理。他们从2005年开始为O'Reilly出版社编写过几本畅销书，包括《Applied Software Project Management》、《Head First PMP》、《Head First C#》。


我们对
Michael
Collins
的工作领域产生兴趣是因为两个原因。第一个原因，
Michael
职业生涯的很大一部分时间都在与具有学术背景的团队一起从事研究工作。而第二个原因，那些研究工作的目的是为政府内外部的重要客户解决具体、实际的安全方面的问题，他的工作横跨了学术和商业两个领域。我们想听听他是怎么看待团队管理

这个问题的。

Andrew
：听说你曾参加过一个检测网络入侵的研究项目。



Michael
：我们大多数时候想要实现的是模型常态。而我所做的大部分工作属于异常检测的领域，异常检测又属于入侵检测领域的一部分。大多数异常检测都是尝试构建一个正常行为的模型，这样如果你突然发现自己落到了正常行为区域之外，就会感到好奇，想知道为什么会发生这种情况。

举个信用卡的例子，你有自己正常的消费习惯。但是如果突然间你跑到加德满都去消费了，信用卡公司就会打电话问你：“你现在在加德满都吗？”这就是异常检测，是信用卡的异常检测。在网络流量上做的也是同样的事情。



Andrew
：这么说，你们的目标是查看路由器数据，通过查看路由器日志中的海量数据，可以检测出那些成功或不成功的入侵？



Michael
：这是我们一直追求但又很难实现的目标。但是首选方法为正在进行的事情建模。但在建模的时候，对于要处理的问题又不是很清楚。这是研究工作中最重要的一个特征：你不是很清楚自己需要做些什么。常常地，在整个过程中需要不断地构建和重新构建工具。比如说客户现在每隔大约
5
个小时可以执行一次查询。他们每天执行查询的方式就是这样的。他们会发布图形，说“今天发现的就是这些”。我们在一台双处理器的奔腾机上（
2001
年）把查询时间从五六个小时缩短为大约
10
分钟。我们把初始报告拿给他们，客户不禁问到：“你们是怎么做到那么多次查询呢？”我们解释了如何收缩数据并将查询过程规范化。客户的回答是：“我们需要这套东西。”



Andrew
：突然间你就得到一个软件项目。


Michael
：是的。



Andrew
：你需要一个团队来构建这个软件。


Michael
：是的。我们小组最初是
4
个人。其中两个人做编码，但这两个人都不会被认为是“程序员”。特别是，有一次我说自己是程序员，我的老板
Suresh
冲着我大声叫嚷了
5
分钟：“你可以干木工的活，但你不是木匠。你是一名研究人员。你写代码是为了回答问题，你不是开发人员。”

让我在这里表明几个看法。我们实际上已经准备好对付艰苦的工作环境了，我之所以说是“艰苦”，是因为我想不到有什么更好的表达方式。比如说我们的文件类型头文件，已经有一个内置的版本系统了。我们一直在准备着向前和向后的兼容。

我们在工程环境方面已经有了足够的经验，知道在原型和产品之间的差别有时候就是简单地更改一下上面的标签，因此知道构建原型是一种奢侈的东西。所以，我们没有想到会得到那样的反应，但是我们从一开始就将系统开发看做是一个严肃的问题。



Andrew
：在做研究项目并与做研究项目的人交谈时，我看到的一件事情和你的老板
Suresh
说的一样，研究人员不是程序员。对于某个开始做博士研究或在大学环境中开始做研究项目的人，他们应当如何把你获得的经验用到他们自己的项目中？你做的那些工作和幼稚的研究团队所做的有什么不一样的地方？



Michael
：很重要的一件事情（同时也是一件真实存在的情况，特别是对研究生而言）是他们有一种倾向，事先不做必要的思考就匆匆忙忙随意地弄出很多东西来。

我们所做的一件重要的事情是将工作分解为一些具体的、小的、定义清晰的“小项目”。这样做的一个主要原因是确保小项目中的代码健壮。如果看一下
SiLK
的架构
（
SiLK
是我们构
建的一个系统的名称），会发现有一个有点类似核心库的东西，管理着文件读取、
I/O
及很多类似的东西。到目前为止我们一共写了大约
40
个应用程序。

研究项目的失败率很高。所以，理想的情况是尽可能在这些小项目上的开发上多投入一些时间，然后可以测试一下，看看它们是否有用，看看它们是否解决了问题，如果不能解决，就抛弃掉。我们知道需要花费时间，但是通过这种方式，我们至少不会花费大量时间。真正有用的东西会添加到核心
SiLK
库中。最关键的一点是，因为我们花了很多时间来考虑版本控制并确保核心库是健壮的，所以我认为我们避免了很多在研发项目中常见的让人头疼的事

，在那些项目中，最后得到的是一个不断膨胀的软件。因为在做研究的时候，你会随意添加大量的东西。你产生一个想法后就会试试那个想法，希望那个想法有用。实际上，我们会毫不留情地砍掉无法使用的东西并承认自己的失败。我们也花了很多时间重新构建，保持核心系统小巧、健壮。



Andrew
：听起来像是站在架构的角度来看待问题的，基本上是让它不要超出范围，承认有些东西是无法使用的。然后在无法使用的时候把它扔掉，把它从解决方案中去掉，这样，你就不会得到很多越来越难维护的低劣代码了。


Michael
：是的。研究与功能蔓延的差别真是非常非常细微。

随着时间的推移，我们还要做的一件事情是：比如说工具
X
做的是某件事，但是后来工具
Y
做了
X
做的事情，而且做得更好。那我们就试图要取代并废弃工具
X
。但是发现系统还在使用中，客户那里的一些人还要继续使用工具
X
。但是对我们来说，这不再是高优先级的开发任务了。因为人们仍旧在使用那个系统，这种情况附带的一些重要的东西是，有很多与之相关的文档：有培训、手册、会议。而且他们在某种程度上会变成培训课程、培训手册，定义了如何使用系统。当我们取代那个工具后，我们会把它从培训的主要部分中移除掉，放到后备部分中。



Andrew
：这么说，有工具、架构，还有一个你们在构建软件时试图优化的领域。你们改变了工作方式，为的是让软件有更好的可维护性。你们一起工作的方式是什么？我指的是人员方面。你觉得你们一定要做一些和很多研究项目不同的事情吗？这是你们常常考虑的问题吗？一个随着时间的推移而演进的环境？



Michael
：嗯，这是一个有趣的问题，因为我们遇到一些有趣的、技能有隔阂的问题。我们有几个做研究的人，主要是统计学或高级软件工程背景，对编码一无所知。后来我们又招聘了一些主要是担任程序员的人。但是理想的是找一些处于二者之间的人：如果你既能做统计分析，又能编写
C
代码来做数值分析，那就是我们要找的人了。部分原因在我们的工作中，研究人员比编码人员更容易得到证明。所以，我们最终的目标是让每个人都成为一种半自治的编码人员
/
研究人员，还有几个人基本上承担架构的守卫责任。长期来看这种做法是不可行的。我想时间长了就不可避免会产生技能上的隔阂，因为人们的特长、兴趣和技能是不一样的。

我们遇到的一个问题是，有一位高级研究员，很明显就不是程序员。所以，在遇到问题而周围又没有人为他写代码的时候，他就只能坐在那里玩弄手指了，这个长期存在的问题是我们必须解决的。最后，我们找到了一位应用开发人员，他愿意和那样的人一起工作，向他们提供他们所需要的代码。



Andrew
：这样你就需要解决一个问题：团队中的部分成员是纯粹的研究人员、科学家、数学家、统计分析学家，他们不是编程人员。在软件公司，常常可以看到的情况是有一个团队与业务客户合作。但是在这种情况中，那些非编程人员是团队中不可或缺的部分。



Michael
：是的。在提取需求时我们遇到不同的问题。研究人员充当了发现新想法的引擎。这也是我们为什么要找一些既能做研究、又能做开发的人的原因。他们是提出问题的人，他们会构建工具来解决问题，在多个场合中，工具都要求是可以使用的。然后我们会找几个人试着分析一下如何利用已经开发好的东西并放到整个系统中。这样，你得到那些能做研究、又做开发的人构建的原型，有几个人事后思考如何把原型放到架构中。一个人会考虑如何把东西放到库中，而我会考虑总体方向：这里是我们目前所做出的东西的差距，那里也许是我们可以弥补差距的地方。我们已经有些这些工具，如果把这些工具的功能扩展到一下，做这些额外的工作怎么样，现在我们对问题有了明确的观点。

这样做的好处是，随着我们做的事情越来越多，那些纯研究人员虽然不会写
C
程序，但是他们可以写一些脚本或类似的东西，把工具绑在一起。接着我们得到一个解决方案—一个很慢的解决方案—我们可以用些比现在好的东西。这样，我们就可以把一些开发精力用到开发工具的优化版本上。



Andrew
：也就是说这种方法的核心是，既是一个构建软件的项目，又是一个研究项目，一些本来不是编码人员的团队成员也可以采取某种方式对代码作出贡献，这种贡献有可能把各个点连起来，帮助项目进行到下一个有趣的研究问题上。


Michael
：是的。我们的想法是达到一个中间地带。首先，你永远也不要指望着一个纯研究人员对代码库作出贡献。但是如果我们有一些工具，研究人员就可以写一个
shell
脚本来使用这些工具，这对于他来说没有负担，对我们来说不会造成破坏。是一些类似于这样的东西，他可以做他的工作，对问题提出一个初始的解答，我们可以使用那个信息，说：“现在可以构建
X
系统了。”

再次说明一下，我们在采取这个想法时，我们并不知道我们这样做是否有价值。



Andrew
：你有多少次发现自己走到了错误的道路上，需要从软件中删除代码？因为在删减功能特性或改变代码时，常常会在解决问题的时候引入同样多的新问题。


Michael
：
SiLK
有两层，因此可以避免那种情况。有一个架构—文件系统、文件存储和类似的东西，然后就是围绕着这些东西的工具。从
SiLK
的角度来看，研究有两个方面，包括了实现，或是将一组工具融合在一起来解决问题。有一个规则是，研究要围绕着工具展开。如果我们提出了新的想法，我们就把它做成了一个工具，对于中央架构没有损害，也没有影响。



Andrew
：从架构的角度看，是高度模块化的，你可以用
shell
脚本把不同的程序结合在一起，这部分要尽可能模块化。而从团队的角度看，你总是要努力确保人们在技术上尽可能灵活。


Michael
：是的。也就是说，我们最后有人变成了架构的守护者，那是个技术工作。



Andrew
：你是否遇到过团队成员之间发生冲突的时候？


Michael
：研究小组中是由固执己见、高度自治的人组成的，依靠的是他们自己的基金。争论已经成为常态

。

争论基本上有两类。第一类是研究上的争论：我应当试试这个想法，我应当试试那个想法，还有一个想法我也得试试。作为一个经验法则，你要试试这个想法，如果证明是可行的，你就接着做下去。如果不可行，就不要做下去。但是，我们也会生产交付给客户的东西。我们用工具做出所有的原型，如果工具证明是有用的，我们就***一个模块和一个培训课程，然后教给人们如何使用工具。我要做的一件事情是从使用工具的人那里获取需求，因为他们的想法一般会比我们的想法好。我们使用工具做研究，他们利用工具来找人！

那是我们的一种争执。还有一种争执是关于代码基完整性及类似的东西。我和
Suresh
之间有过一次场面壮观、尽人皆知的争执，这场争执对他来说更像是一件小事。他刚参加了两个星期的陪审团，刚刚履行完他的职责，然后就让我们交付一些软件了，太糟糕了。如果不把软件测试好，我是不会交付软件的。发生这件事情的原因是因为在那时，我们还没有达成共识，找一个人来做代码基础库的守卫者。我特别提倡的一件事情是做系统可靠性的权威。我弄过一份所有失效情况的错误树，为系统管理员写了一份文档，描述当系统有某种方式失败时，应当如何利用这份文档，如何恢复。这样，我就不会让任何东西漏过去了。那场争论持续了
4
个小时，我一直坚持自己的立场。这对我来说是件大事，因为在此之前我一直都是
Suresh
的下属。在这次争论后中我取得项目足够的控制权，我不能让自己的名声受损，因为坦率地说，他刚才参加了陪审团，做事情感觉有点敌对。

实际上，关键是，你是搞学术的，声誉对你来说非常重要。在写论文的时候，名字要写在论文上。那时关键之一：当我们做出什么东西的时候，我们有一种文化，就是一般都要全力以赴地投入到这个想法上，那是我们的名声所在。组内的每个人接受的都是这种观念。你代表的是我们，你的工作代表的是我们，如果出了什么错误，你必须处理它，修正它，在发布的时候要小心。


最终我们到了这样一种情况，为了让发布更加顺利，我们建立了陪审团体系。我们有一些把事情弄糟的人，我在内部采取的办法是利用人的自尊。有一次系统中出了一点小故障，导致两个字段的位置颠倒了，最后我私下里找到开发人员说：“看看，你让我在客户面前像个傻瓜一样。我承担了责任，但是以后不要再做这种事情了。”此后，他表现得极为认真、勤勉，确保类似的事情不再发生。

我的背景是理论方面的，受到工程设计很多想法的影响。我们都接受了一种思想的训练，认为真理不应当是独占的。所以，我们期望着发生争论。我们在文化上也强调，争论不是针对个人的。我认为最卓有成效的环境是，人们都相互尊重、但是对人又不偏不倚，我这么说是因为这样他们才会提出毫无偏见的观点，不会把别人当成傻瓜。他们不会总想着如何才能不伤害你的感情，也不会想着怎么样去伤害你的感情。作为一个小组，必须鼓励相互之间的争执，到了最后能够客观地达成一致意见。


关于争论，我们的原则之一是到了最后必须达成某种一致意见。这样我们可以全力地相互争论。大多数时候我们的争论在本质上是技术、实验或类似的东西，所以到了最后必须试验一下，看看谁是对的。和我们打交道的大多数人都有博士学位。我们这个过程的要点就是：如果不知道一件事情对不对，就必须通过试验来验证。



本文
节选自《团队之美》

一个优秀的软件开发团队面临一个棘手的问题，在这样的团队中工作是一种什么情形呢？如何才能打造一个富有战斗力的团队？一组不能融洽相处的人也能够开发出好的软件吗？当项目关系重大、进度又很紧张的时候，团队领导如何让每个人都能符合既定的要求和日程安排？
本书带你到幕后看一看软件工程历史上最引人关注的团队。通过最杰出的程序员、架构师、项目经理和思想领袖的一系列引人入胜的故事和访谈，你将从资深团队领导的成功与失败中学到经验。