访谈：当开发者成为技术主管 如何领导团队

当开发者成为技术主管之后，他们就必须在领导团队与继续进行技术工作之间找到某种平衡。

在 Patrick Kua 的著作《与技术主管对话——从新手到专家》（Talking with Tech Leads- From Novices to Practitioners）中，作者为我们分享了多位技术主管的故事，包括他们所面对的情形、挑战和领导团队的方式。

本书探索了技术主管的角色和日常活动，并为如何处理技术领导方面的职责提供了实用的建议。

InfoQ 有幸与 Kua 进行了一次访谈，谈论了技术管理这一角色，以及他如何在团队中开展工作、处理人际关系问题的实践、成为技术主管的优点与弊端，以及如何成为一名技术主管的建议。

InfoQ：是什么促使你编著了一本有关于技术主管方面的书籍？

Kua：世面上已经有无数的书籍教读者如何编写“优秀的”代码，至于介绍软件方法论，例如极限编程、Scrum、看板和精益等方面的书籍就更多了。此外也有许多关于领导和管理方面的书籍，但几乎一本是关于“仍然在写代码的领导”方面的书籍。我看到开发者刚刚成为技术主管这一角色时所面对的困难，而且他们总是为相同的挑战所困。在本书中，我希望能够将记录下这些故事、他们所学到的东西，以及他们所面临的困境，以此来帮助其他技术主管认识到他们的处境并非独一无二的，并且告诉他们已经有许多人克服了这些挑战。

InfoQ：本书对多位技术主管进行了采访，他们都分享了各自的经验。你为什么选择以这种形式来编写本书？

Kua：虽然我在如何成为一个优秀的技术主管方面已经有所心得，但我也想了解其他人是如何扮演这一角色的。使用采访这种方式是让观点尽量保持客观的一种自然的选择。在本书的第一批反馈中，我很惊讶地发现人们对于这些故事的共鸣是如此的强烈。我也知道故事的力量是非常强大的，我觉得这些故事能使其他技术主管从中受益，因为这一角色也许是非常孤独的。在采访全部结束之后，我将它们按照场景进行排列，有组织地按照我所采访过的多位技术主管的顺序出现。这种形式并不是打算告诉读者某种“唯一的正确方式”（因为并不存在这种方式），而是扮演技术主管这一角色的不同方式。我同时感觉到，这种形式很容易让读者随手打开本书翻阅几页，并随时离开它，这对于那些没有多少时间的读者来说更容易接受。

InfoQ：技术主管是一种怎样的角色？他与架构师、团队主管，或是 Scrum Master有怎样的不同？

Kua：技术主管的角色通常是指某位开发者需要对创建系统的整个开发团队负责时，所扮演的角色。技术主管这一角色与其他角色会产生一些职责上的重叠，例如架构师、团队主管或 Scrum Master，但这一角色的独特之处在于，他结合了领导与技术两个方面的内容。一个优秀的架构师看上去与技术主管很相似。但就我所知，许多公司都很纠结于如何定义架构师的角色，以及架构师所做的工作。他们的职称包括企业架构师、数据架构师、业务架构师，通常这些职位存在的原因在于他们的视角更加宽广，但这些角色通常来说不会参与每日的具体工作。在我看来，技术主管的不同之处在于，他们一方面要对交付软件系统负责（就像一位架构师那样），而另一方面他们还需要参与每日的系统实现工作。简而言之，他们就是那些要参与编码工具的架构师。团队主管通常要对团队成员的感受负责，而优秀的技术主管同样会承担这一职责。另一方面，团队主管并不一定都有技术能力，这使得团队主管很难参与技术讨论、掌握团队的技术方向以及决策，有时甚至是不可能的。而 Scrum Master 这一角色是在 Scrum 敏捷方法中定义的，并且只存在于那些使用 Scrum 的环境中。反之，任何规模的开发团队往往都存在一位技术主管的角色，他对团队的技术方面负责。技术主管有时也会担任 Scrum Master 的角色，但就像团队主管一样，并不是所有 Scrum Master 都具有领导开发团队和团队的技术走向的能力，因此就不能够同时扮演技术主管这一角色。

InfoQ：你能为我们分享一些优秀的实践，描述一下技术主管应该怎样在团队中开展工作吗？

Kua：当然了。虽然我在书中写到了技术主管是如何对开发团队的技术方向负有直接责任或间接责任的，但其实有许多种方式可以让技术主管实现这一目标。某些技术主管在如何实现团队愿景方面显得更有指挥性，这种情况对于缺乏经验的团队来说或许更加有效。这种技术主管不仅会规划团队的愿景，并且对于如何实现该愿景方面会提供十分具体的细节（使用具体的工作、库或框架以实现目标）。对于更有经验的团队来说，技术主管可以依赖团队成员的经验和知识以处理问题，意味着只有在团队成员无法作出决定时，技术主管才会参与处理问题的流程，并推动团队工作的开展。虽然我并不是重量级的 RUP（Rational 统一过程）工具的粉丝，但我十分支持使用不同的图形工具帮助开发团队对于他们所创建的产品形成一个通用的认识。绘制图形和讲故事对于技术主管来说是有些大材小用了，但它们对于帮助团队理解技术愿景方面的贡献是无价的。要想做好这一点，一种良好的方式是将整个团队带到一块白板前，并尝试对团队正在创建的系统的架构进行建模。

InfoQ：你对于技术主管所必须处理的人际关系方面的问题有没有什么示例？他们是如何进行处理的呢？

Kua：我在团队中经常看到两种非常明显的人际关系问题。第一点是处理开发者之间的不同意见。从理想的角度来看，一个独立自主的团队应该能够找到办法以处理内部的冲突。但在实际中，这一点往往不如人们所希望的做得那么好。技术主管必须经常性地缓解团队中的两种不同意见所造成的冲突。包括将问题明晰化、探索各种替代解决方案（而不仅仅是两种提议方案），或者甚至要对各种方案进行尝试，以验证这些方案的优势和缺陷。极限编程实践中的探针实验（Spike）经常被用于评估两种不同的途径，并且对某个原型进行验证，比起无休止的争论也要有效得多。第二种人际关系问题是处理团队的水平与实际要求的水平之间的差距的问题。技术和工具每时每刻都在变化，而软件系统又是如此复杂，要使团队随时掌握每一种技能几乎是不可能的。一个高效的技术主管能够找到让团队在学习的同时交付软件的平衡，他们也持续地想方设法将知识和技能分享给其他团队成员，以防止知识壁垒的出现，并且让每个任务都能有超过一个以上的团队成员参与实现。专注于某个技术主题的技术演讲，或者是一次团队代码审核都是技术主管实现这一点的优秀示例。

InfoQ：在本书中你提到了技术主管午餐。你能解释一下这是什么意思，以及它所带来的好处有哪些吗？

Kua：转变为领导者角色时所面临的最大挑战之一，就是你会很容易发现自己的角色是多么的独立无助。我们开展技术主管午餐的目的，是作为一种让来自于不同团队的技术主管之间建立起一种支持网络的方式。

我们的技术主管午餐是在一次聚餐中让 4 到 6 六技术主管共同出席，让他们谈论一下各自所遇到的问题。我们邀请每个参与者表述一种他们所面临的挑战的场景，并让其他技术主管分享他们对这个问题的处理方式。在很多方面，我们的技术主管午餐都像是一种对具有相似职务的人进行非正式教导的循环。我们发现，这种方式能够非常有效地在彼此之间分享心得与体会，例如时间管理、如何在继续编写代码和履行其它职责之间保持平衡，以及如何应对一些专惹麻烦的人。

InfoQ：你能描述一下成为一位技术主管的好处与坏处吗？

Kua：技术主管会发现他们对于软件系统和开发团队的技术方向同时具有间接责任和直接责任。这一角色的一个优点在于，与作为开发者相比，它会使你对整个系统的观点更开阔，以更有策略和更长远的方式来考虑问题。技术主管在应对业务人员方面往往需要花费更多时间，这将在两方面给予业务人员更大的影响力：一是基于技术能力所产生的产品方向，二是对于长期交付的产品的计划活动的影响。另一方面，技术主管的责任更多，因此能够参与编码的时间就大大减少了，这一点也是开发者转变为这一角色时所遇到的最大的挑战之一。业务的需求会要求技术主管对系统承担间接责任，但技术管理对于细节的掌控就减少了，也这需要团队成员之间更强的信任。

InfoQ：成为技术主管并且做好这一角色是非常具有挑战性的，正如我们在你的书中所读到的那样。如果技术主管需要支持，他们应该到哪里去寻求呢？

Kua：虽然一个团队通常只有一位技术主管，但在大多数组织中，整个组织的技术主管不只一位。找到一位可以依赖的同伴对于技术主管来说通常是一个良好的开始。我还会建议让技术主管找到某种形式的教练或是指导员，以帮助他们澄清所观察到的事物，并评估他们对某些没有清晰答案的问题的看法。如果某个技术主管和某位项目经理的关系良好，那么该项目经理可以成为一个良好的非正式教练。我还想提醒技术主管一点，他们的整个团队就是某种形式的支持，并且团队成员在某些类型的问题上往往能够想出更加出色的解决方案，这也是一个良好的信号。

InfoQ：技术主管的新手和专家之间的主要区别体现在哪里？

Kua：我认为技术主管的新手和专家之间的最大区别在于，他们对于从“实现”转变为“使之实现”的能力和自信。新上任的技术主管会尝试控制设计和代码实现，因为这是他们作为开发者时最习惯的工作。到了某一阶段，他们会意识到这种方式无法持久，同时也夺走了其他开发者的创新能力和解决问题的乐趣。随着新手的经验的积累，他们对于代码没有按照他们所希望的方式编写，但整体的解决方案还是按照计划进行的现状感到逐渐认可了。一个有经验的技术领导能够更好地表达某些指导原则，并且了解什么时候该插手，什么时候该放手。

InfoQ：团队该怎样学习业务人员的需求呢？

Kua：在这里我要引用精益社区中的思想，鼓励开发者去“现场”，或是说是工作产生的地点进行考察。我认为，如果开发者们能够更多地理解业务上的问题和终端用户的问题，他们就能够编写更好的解决方案。当然，这取决于你所编写的软件的类型，但我绝对建议开发者们去看看他们的软件是如何运行的，并尝试与使用者产生共鸣。另一种能够帮助团队学习这些需求的方式是，让业务目标和衡量指标对开发团队变得可见，以此提醒团队他们的系统的实际作用。这些示例包括：改善的转化率（例如：实际购买了某产品的用户与浏览过该产品的用户之间的百分比），回头客或支付订阅用户数量的提升。

InfoQ：对于希望成为技术主管的开发者，你能够提供一些参考资源吗？

Kua：我推荐以下一些书籍：

• 由 Gerry Weinberg 编著的《成为一名技术领导》（Becoming a Technical Leader），这本书出色地概括了成为一名领导者意味着什么，通用的问题处理技巧，以及怎样理解如何驾驭一个组织。
• 由 Kerry Pattern 等人编著的《关键对立》（Crucial Confrontations），这是一本优秀的书籍，它描述了一种如何在不改变信息量的前提下进行交流的特别方式。
• 由 Roger Fisher 和 Willam Ury 所编著的《谈判力》（Getting to Yes）是一本非常简短的书籍，它介绍了如何处理谈判中的情况，这对于试图解决团队中有关技术解决方案的冲突的技术主管来说是非常重要的。
• 由 Simon Brown 编著的《开发者的软件架构参考》（Software Architecture for Developers）是一本可以随时阅读的书籍，它对于如何针对架构进行有效的交流提供了良好的指导。
• 当然还有由 Patrick Kua 我本人编著的《与技术主管对话》一书，其中分享了超过 35 位技术主管面临的场景、挑战以及各自的应对方式。

关于本书作者

Patrick Kua是《回顾指南：敏捷团队的指导手册》（ The Retrospective Handbook: A guide for agile teams ）以及《与技术主管对话：从新手到专家》两本书籍的作者。Patrick 出色地处理了技术与非技术领域之间的协调，并且负责领导团队编写基于.Net、Java 和Ruby 等技术的生产环境中的软件系统。Patrick 对于与团队进行密切的工作具有很高的热情，并且热心地帮助他们成长，并且学习进行可持续的、长期的改变，有时也会帮助他们克服逆境。Patrick 将回顾看作一种改善团队的基础手段，也热心地帮助团队从回顾实践中获取最大的价值。你可以订阅他的博客，或是他的Twitter 帐号 @patkua 。

查看英文原文： Q&A with Patrick Kua About Talking with Tech Leads