《管理不易管理之人》作者问答_技术管理_Shane Hastie

Linux 之父出席、干货分享、圆桌讨论，精彩尽在 OpenCloudOS 社区开放日，报名戳了解详情 



 写点什么

Mickey Mantle 和 Ron Lichty 写了一本关于程序员管理和使用的书：“管理不易管理之人：管理软件人才和团队的法则、工具和领悟”。在此书中，作者根据他们自己的经验加上对程序员、团队主管、经理、总监和CTOs 的访谈和对话，勾勒出一幅程序员及程序员团队的特征图，并提供了历经多年收集总结的大量工具和经验法则。最近他们接受了 InfoQ的访问。

InfoQ：先来讲一下写作背景吧——你们为什么要写这本书呢？

作为软件从业者，我们一直在观察软件产业的演变。数十年以来，人们一直在追求更快的硬件，新的、更好的计算机语言、开发框架、过程改进和认证（例如 ISO 9000），不断改善的项目管理方法——所有这些都极大地促进了软件产业的发展。但是，在对软件产业的灵魂——创造出伟大的软件产品的众多程序员，以及如何有效地管理这些程序员——的关注之上反而非常不足。

我们身为程序员的经历，加上数十年管理程序员的经历，使我们获得了许多有益的知识：我们程序员是怎样的一群人，我们愿意为何而奋斗，以及如何高效的管理我们这样一个群体。

我们发现，有关管理程序员和程序员团队之困难的书非常地少，或者还不够好。这促使我们下决心去写一本新书，从非常个人经验的视角，分享许多奇闻轶事、经验和工具，这些是我们经年累月获得或者自己实现、并经过实践验证的。

InfoQ：在这个话题上你有哪些背景呢——为什么大家要听你的？

我们不是学院派；我们曾经写代码并管理团队，交付有着大量用户的软件产品。曾几何时，Ron 在 Berkeley Systems 领导屏保和游戏软件的开发，而 Mickey 在 Broderbund Software 领导其著名的儿童和娱乐产品的开发，那个时候如果写这本书的话，我们受到的关注应该会超过当时世界上几乎任何两个开发经理。我们会讲述创造这些产品以及管理这些团队的故事，并分享历经辛苦获得的领悟，希望使其他经理的工作变得更轻松一些。

然而，本书并不限于我们自己的经验。“奶油中心部分”是一个读者对本书中间的 80 页的称呼，给出了 300 条经验法则和至理名言，来自于全世界的程序员经理，包括很多名家。这是我们在几十年间亲身听到、读到和用到的智慧精髓，希望它们能像帮助我们一样帮助到其他的人。

InfoQ：本书的目标读者群是？

一线的程序员经理是本书的首要目标读者，无论是新晋经理还是资深经理都适合。本书提供的很多实用的建议以及工具，将有助于他们成为更加成功的程序员和程序员团队的经理。

其次，本书的目标读者还包括开发部门的经理，其主要职责是指导由程序员经理组成、或包括程序员经理的团队。我们希望，通过这本书，他们能够通过借助与我们的合作来提升他们的程序员经理并管理好自己的部门。

第三个读者群体是 C 级别的管理层，他们通过软件（以及制作软件的程序员）支撑着公司的成功运转，他们希望获得洞察力，来理解如何管理看上去难以管理的程序员群体。这是很多合作伙伴的 CEO、COO 和 CIO 告诉我们的。

最后，读者不断地告诉我们，这本书对想成为更好的带人的经理的任何人都有着莫大的帮助。本书所介绍的洞察力和工具，对所有想成为成功经理的人都是适用的。

InfoQ：管理程序员和管理知识经济领域中的其他角色有什么不同吗？程序员的独特之处在哪里？

除了程序员，任何有其它领域管理经验的人——包括其它工程领域——都会同意管理程序员是一件既特别又困难的事情。一部分原因是因为与其它领域——如硬件设计或者机械工程相比，软件开发的结果更加的不可感知、难以度量进展。其次是因为虽然编程的某些因素被称为“工程”，但同样存在一些因素实际上更类似“工艺”、“艺术”或者“交易”。工程应该是可预测的、可重复的，但是编程却并非如此。你什么时候听说过一座高楼或者一条高速或者一个净化工厂被迫中途放弃，仅仅是因为建设者无法预测完成之日？虽然所有知识工人都有他们自己的挑战，我们感觉还是程序员的挑战最大。

InfoQ：对一个想管理程序员团队的人来说，最大的挑战是什么？

许多新晋程序员经理比他们所带的同事入职时间早不了多少，从个人贡献者到经理的转换本身就是一个挑战，尤其是在一个你曾经是其中一员的团队。更为糟糕的是，绝大多数新经理在被晋升到这个角色之前，没有任何正式的培训或者指导。对很多人来说，这是最有挑战性的一面。

第二个挑战是知道该做什么：什么事情是重要的，什么是不重要的。本书将列出我们认为对一个新经理来说，哪些是最重要的事情，哪些不太重要。

第三个挑战是行为上的巨大变化。一个伟大的程序员（正像我们之中的多数在成为经理之前那样）擅长于将世界关在门外，进入私密寂静之域——作为一个程序员你与处理器独处，你编写代码完成所愿。与此相反，一个成功的经理必须要做的，不仅是在门口放一个欢迎的红地毯，而且要真心实意地邀请大家有任何事都可以随时来访。你的工作不再是个人成就，而是驱动和支持程序员去完成任务了。

InfoQ：在书中，你通过各种各样的“透镜”来观察程序员——在观察程序员的时候有哪些角度呢，为什么要从这些角度来看？

我们的“透镜”包括程序员类型（例如，系统程序员、数据库开发者，等等），不同的个性（例如，喜欢白天工作的、夜猫子，等等），不同的年龄段（例如，婴儿潮的、千禧一代，等等），以及其它。重点是，要想有效的管理一个程序员，你得细致入微的理解他们，适当的时候使用一些工具。这样才能因人而异的使用不同的激励方式。我们甚至提供了一个公式来帮助你计算某个程序员最关心的东西。

InfoQ：本书承载了各种各样的的信息——一些章节看上去是附有模板、指南和检查表的“如何做”，而另外一些关注软性因素，例如文化、激励和关系。如何平衡？哪些领域是最重要的？

不同的信息可以分类为法则、工具和领悟，就像书名副标题所书。这本书的目标就是要提供者三样基本的信息——法则、工具、领悟——我们希望在我们成为经理之处就拥有所有这三样东西。哪个更重要取决于个别的读者，由他们来决定。我们认为这些都非常重要。

InfoQ：在有关管理的一部分，你提供了一整章来讨论“向上管理”——这当然是每个经理都必须具备的技能，和工作领域无关，对程序员经理而言有什么特别的呢？

你是对的，向上管理是每个成功的经理为了最大化其职业成功而必须掌握的技巧。在这么多年的“管理老板”之后，我们也非常理解它的重要性。然而，我们很少在管理课程中听到。

虽然向上管理是普遍的，我们为程序员经理加了一些特别成分。虽然程序员的经理通常是程序员出身，但是迟早我们会发现要管理那些不理解（或者不想理解）程序员文化或者技术的老板。

InfoQ：你们在公司文化和建立一种“开发亚文化”上花了一个章节——如何才能建立这样一种成功的亚文化呢？

这是很重要的一个章节，因为它讲述了如何利用公司文化的正面力量，同时屏蔽公司文化的负面力量，代之以你管理的团队希望拥抱的价值。

InfoQ：关于“经验法则和至理名言”有整整一个部分，这些都是你们长期积累并证明了价值的。读者该如何善加利用呢？

我们认为，这些经验法则和至理名言代表了本书的一部分精髓。单单是读一遍就会增加一个经理的信心，使他确信自己正在做正确的事情来开发软件，毕竟这些话是无数前辈的沥血之作。我们亲自使用这些话来消除纷争、确立原则，使得开发朝着正确的方向前进。例如，当看到一个简单问题的复杂解决方案时——经常是在被贪婪的业务伙伴们包围的时候（他们往往不理解一下子开发出所有功能的难度）——谁能忽视“不要煮沸整个大海”（don’t boil the ocean）这句话呢？

我们两个人共同收集的一句话是 Brooks 定律：“向一个已经延期的软件项目加人只会使它更延期”，出自 Fred Brooks 的软件项目管理的经典之作《人月神话》，出版已经 40 多年了，我们还是经常遇见没有听说过这句话的管理层。把类似这样的话放进一本口袋书太有意义了。

InfoQ：在本书的网站上，你提供了一个工具列表——读者在此网站上能访问到哪些信息呢？

在网站上，我们给出了多年收集或实现的工具，包括职位描述示例，程序员新手的入门检查表，帮助管理项目的项目工作手册示例，季度目标模板，以及很多其它有用的工具。好的经理会希望去定制这些工具，但作为起点还是会节省大量的时间。我们认为单是这些工具本身的价值就已经超过了书的定价。

InfoQ：你还有什么话要对读者说吗？

我们最主要的目的是完成一本我们希望在一开始管理其他程序员时就能拥有的书。我们两个在被提升为经理之前都是程序员——与其他大多数人一样，没有培训、指导、反馈。我们都在错误中前行，慢慢变成了好经理、甚至是伟大的经理（来自下属的反馈）。我们希望，这本书使得从同事到经理的转变更容易一些，希望它成为那些无法找到一个好导师的程序员经理的一个导师。我们心里揣着这个希望来写就了这本书。

样章参见第8 章。

关于作者

Ron Lichty有着 30 年的软件行业从业经验，绝大部分时间是作为程序员经理、开发总监、产品和工程副总裁度过的，曾经服务过的公司包括 Apple、Fujitsu、Razorfish 和 Schwab。他有 4 本著作，发表了数百篇文章。他的咨询客户包括创业型公司以及其它大大小小的公司，他帮助这些公司解决了软件研发中的各种困境。