《与编码人员一起工作》作者访谈

本文要点

• 软件开发不像其他业务过程，不能采取相同的管理方式

• 与编码人员一起工作就必须要了解软件开发的特质

• 敏捷开发是个强大的体系，必须小心应用才会有更好的效果。

• 管理技术债即早期投入较少的时间以节省后期大量的时间

• 理解软件开发人员的观点和优先级是打造高效工作关系的关键

这本《与编码人员一起工作》是一本指导非技术型读者管理软件开发团队的实用手册。在这本书中，Patrick Gleeson 解释了软件开发过程是如何运转的，管理者做些什么能使其更为高效，以及做什么能与编码人员建立起稳固的工作关系。

你可以下载本书的第二章样本进行预览：为什么写软件和盖房子一点都不一样。

InfoQ 采访了 Gleeson，请他谈了谈管理软件开发的主要挑战以及如何应对它们，管理者做什么可以预防或减少技术债，管理者应意识到程序员的偏见，以及管理者做些什么能与编码人员建立起稳固的工作关系。

InfoQ：是什么让你下决心写这本《与编码人员一起工作》？

Patrick Gleeson：前些年有段时间，我发现我一直在重复讲某些话。通常，与我交流的不是编码人员，要么就是企业家，要么就是同事在找我寻求建议，我们探讨如何参与到编码人员团队构建软件的工作中，以及问题出现的各种方式。在指导期间我发现，有些东西对于没在编写软件上投入过时间的人来讲一点儿都意识不到。但同时若要清楚你是否能够与编写软件的人共事，这些事又是至关重要的。我想，如果我能够把这些事记述下来，就能帮一些人预防这些错误了，这些可都是我在第一线总结的“血的”教训。

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

Gleeson：有些人不亲自写编码，而他们的事业成就又取决于编码人员为他们所写的软件，这本书的主要受众就是他们了。具体来说，主要就是 IT 项目经理、就职于创业公司的人、业务分析师、中小企业 CEO，以及任何自己寻找各类软件开发代理委托人的人。但同时它也是以软件开发人员为出发点而写的，特别为那些管理其他编码人员以及投入大量时间与非技术型同事交互的团队领导。

InfoQ：通过阅读这本书，能让领导者得到些什么？

Gleeson：我想主要谈两点。第一点是这本书的目标，即成为管理软件开发团队的实用指南。我花了很多时间思考激励编码人员的独特因素，围绕应得到鼓励的工作和无适当保障措施的不利影响出现的趋势。还有几章讲了如何招聘开发人员，如何使他们保持愉快的心情。

第二点，这本书是关于技术与非技术之间沟通的书。它所讲的是如何让不清楚编码的人更好地理解软件开发过程，不论是想办法解释像技术债之类的概念，还是劝说关键利益干系人特定工作方式即使在外人看来违背直觉，但会让他们得到所需的结果。

InfoQ：软件开发管理的主要挑战是什么？

Gleeson：最大挑战在于软件开发不像其他业务流程或其他工程规范那样运转，有着微妙而实际又很重大的差异。这意味着如果你管理项目时借鉴其他过程和规范，差不多总会失败。特别是，编写软件时想要精确定义需求是非常难的，为一个指定特性预测完成它所需的工作量更是难上加难。这两点就意味着从其他规范中借鉴项目计划和管理的做法基本上没什么价值。

InfoQ：从敏捷角度出发，你建议如何应对这些挑战？

Gleeson：基本上，像 Scrum、极限编程等等各种敏捷规范都已经承认，这种软件开发所必然面对的困难是由需求规格和评估中的未知情况造成的。避免把眼光放得太远，专注于收集数据并从中总结分析，能尽早暴露制定错误决策的风险。也许颇有争议，但我认为这种敏捷方法论所提倡的迭代、增量的开发从本质上有些效率低下，它带来大量的会议、重复编写大量相同的代码等等。但如果接受这些低效，我们可以显著降低软件项目的风险，在很多时候这就是个明智的选择：低效的成功总好过鲁莽的失败。

InfoQ：你建议在什么时候别用敏捷？

Gleeson：当你们不能全情投入时，不仅指软件团队还包括其他利益干系人。大家经常忘记敏捷是一个需要涉及到的每个人都积极参与的过程，而不仅限于开发人员。比如说 Scrum，如果你有一群致力于此的编码人员，但负责该项目的高管却不想参加每两周一次的迭代回顾，那么就可能招致失败。同样的，如果软件只是大型跨职能项目的一部分，敏捷可能也不合适于你：它最适合于解决软件项目管理的问题，当应用于比如硬件原型设计时则未必有效，因为原型的逐次迭代要花费几个月的时间。

InfoQ：管理者做什么可以预防或降低技术债？

Gleeson：时间就是金钱，它随着技术债的积累而增加，其实这个财务隐喻非常好，因为你会在技术债上支付利息：你拖得越久，陷得就越深。所以管理者最主要的就是让开发人员有足够的时间去完成他们的工作，不至于一开始就陷入技术债。为适应变化，会进行需求变更和临时调整代码，这时就会经常出现技术债了。企图让软件需求不发生变更是毫无意义的：这也正是为什么需要敏捷，所以要管理预期以确保可以彻底响应变化，花些时间“重构”软件，而不是为了应急积累技术债，这是管理者能做的最有帮助的事了。

InfoQ：管理者应意识到哪些程序员偏见？

Gleeson：我认为其中最突出的是对新生事物的偏爱。软件开发关乎的就是要持续关注新生事物，因为重复的东西总会被自动化，所以大家会仅仅因为新鲜而爱上一个工具、一门技术或一种技巧。这会带来偏见，偶尔会完全迷失，导致开发人员主张错误的决策。管理者应该留心观察，看看对新生事物的偏爱是否正在扭曲开发人员的判断。

害处差不多大的是厌恶。出于不同的原因（经常是做事无把握），开发人员可以发现他们自己实际上投入于不喜欢的特定语言或工具上，有时这很不合理，偶尔会完全影响生产力。在最糟糕的情况下，它会营造有害的环境，其他开发人员仅仅因为使用过去的技术而被轻视，使团队形成紧张的气氛。如果一名开发人员陷入总被他们责骂特定技术的境地，管理者就该高度重视起来，阻止事态的发展，因为它没有工作效率且很不健康。

InfoQ：对于想要与编码人员建立稳定工作关系的管理者，你有什么建议吗？

Gleeson：记住编码人员也是人。通过最近 40 年或更长的时间，大家已经对软件开发人员形成了刻板印象，而且通常是负面的看法，把编码人员塑造成了异类。尽管实际上编码已经成为越来越主流的职业，从事这一行的来自于各种不同的背景。所以带着对编码人员的刻板印象与之协作非常有害。这就是说，如果你花时间写写代码，就会改变对许多事的看法，而对于管理者来说，了解不同的观点又是极为重要的。例如，构建用户界面时，编码人员会花更多的时间在界面相关的源码上，而不是界面本身，所以让他们记住它将如何呈现给用户不是件容易的事。讨论界面时，编码人员脑中所想与平面设计师所想会迥然不同。好的管理者会预料和调解这些观点差异，利用这些差异而不是让它们产生冲突。

关于本书作者

Patrick Gleeson 从事编码和编码人员的管理已经有 10 几个年头了。他曾于各种组织任职，从定制软件的咨询到跨国公司，再到小型初创企业，现在他是 Think Smart 的技术总监，这家公司为年轻人提供工具，让他们可以做出更好的职业规划。他还为电影和剧院兼职担任过制作人，有一次，他花了一年时间制作电子动物木偶参与了机器人马戏团，其中有一只演奏木琴的机械章鱼。

查看英文原文： Q&A on the Book Working with Coders