【推荐】高效软件开发团队管理

米奇 W蒙托罗恩《告别失控：软件开发团队管理必读》是一本非常有参考意义的团队管理书籍，其中很多观念与经验非常值得学习。

本书站在技术经理的角度，从多个方面讲解如何理解软件工程与程序员，如何管理好上司、下属团队以及如何激励团队，如何形成良好的团队文化，如何管理成功的软件交付等一系列经验和方法。同时，书中还谈到了招聘、选择技术人员的重要性与方法。

为何程序员难管

第一部分，描述了软件开发工作的特性，以及程序员这种工作的特殊性，为何程序员难以管理。

对于程序员而言，程序员的工作很有趣，程序是纯粹的创造愉悦，做出对其他人有用的东西而带来快乐，体会持续学习的乐趣，任务的无重复性；工作的对象是可以自由驾驭的代码，令人开心。程序员像诗人一样，操作的是与纯粹思维事务只差一点点的代码。

正因为多数程序员都很享受工作，你可以理解为什么难以管理他们。如果有人付钱让你开心地玩，你还会愿意受制于人吗。程序员可以分为两类，一类“左脑型”，原本可以成为工程师、会计师或教育工作者，另一部分可能成为艺术家、音乐家、作家等，他们本质上更加自由奔放，这类人群中产生的天才程序员更多。因为，程序员的创造性的工作性质，以及程序员自身对自由追求的特性， 使得管理程序员比较困难。

"管理程序员更像是放牧一群猫"这句话揭示了高效、成功的程序设计经理难当的本质原因。猫的自由主义、个人主义色彩浓厚，而且狡猾、贪玩、好奇、独立。程序员也一样。因为程序员都是些无拘无束的人，常见的激励方法往往不能奏效。除了进行必要的技术监督并把开发实践和过程落实到位之外，善于利用程序员的自我意识和改变世界的欲望也很关键。程序员的动力源泉不仅仅是报酬，更多的是工作本身和工作环境的高要求。程序设计是一个创新的过程，需要有效地处理特殊情况。

程序员类型

第二部分，程序员之间的差异非常大，本章描述程序员之间的差异，对程序员进行分类。程序员的差异主要来自个人内在因素，而不是外在的属性。理解程序员的方法有很多多种，我们从以下几个不同的角度来考虑：程序设计工种；程序员的类型；领域知识；程序员的工作要求与能力；工作地点与关系；代系特点；个人特点。

程序员设计工作通常分为4中类型：客户端程序员、服务器端程序员、数据库程序员、Web开发人员以及其他脚本编写者。可能许多特殊的程序设计工作难以确切地归结为上述类型，但总的来说，这4种类型可以覆盖世界上绝大多数程序员，其中每一种程序员擅长的风问题解决方法、使用的工具以及侧重的产品方向都各不相同。

关于程序员类型，实际上从技术知识、实践经验和程序员的专长角度去考虑，可以把程序员分为：

1. 系统工程师/架构师
2. 系统程序员
3. 应用程序员
4. 非真正意义上的程序员

系统工程师/架构师是最有技术和经验的，要想理解所有相关的系统组件（操作系统、通信系统、数据库、在线/离线访问、安全性、硬件等）之间复杂关系，需要对所有这些技术和系统都有丰富的专业知识和经验。通常，在一个规模合理的团队中，只会有一两个“真正的”架构师。

大部分架构师从系统程序员做起，能理解系统中所有组件的工作原理，包括客户端、服务器的操作系统和通信系统。系统程序员负责编写与硬件交互的设备驱动程序，创建能够为设备驱动和应用程序执行提供运行时环境的操作系统，为其他程序员提供工具和服务于交付程序。很多中间件团队的工作也可以归结为这类工程师的职责。

大部分程序员属于应用程序员，他们开发的程序或结果通常给终端客户直接使用。一些应用程序员能够跳出代码本身的束缚，与应用程序的用户产生同感，真正从用户的角度看问题，从而很好地把握各种可视化、交互式的设计之间的细微差别。这样的应用程序很适合从事用户界面（UI）开发。

非真正意义上的程序员，他们当中有些人使用图形用户接口（GUI）指定程序逻辑或商业逻辑，然后生成用户可访问的应用程序。

招聘优秀的程序员

第三部，谈到如何招聘优秀的雇员。 一流的成员招聘一流的雇员。招聘时要提前明确需要招聘什么类型的雇员，负责哪方面的事情，全职还是合同工。

高效的管理

第四部，要成为高效的程序设计经理，需进行四个部分的工作：

1. 向下管理
2. 向上管理，对领导
3. 对外管理
4. 自我管理

向下管理

向下管理最重要，作为一线的程序员设计经理，大部分时间都要花费在向下管理上，包括管理你的直接下属、间接下属，并提高管理效率所需做的事情。

作为技术管理者，需要赢得下属对你的技术尊重，获取高级别的职称，在技术趋势和前沿上保持或者领先与你的下属和同事，细节可能不那么清楚。广泛掌握技术趋势和技术大局，对于其中看来很有应用价值或者特别有趣的部分进行深入钻研，并通过电子邮件向直属员工分享其中的精华，或在公司级别的定期会议中进行分享，向更大的圈子分享。参与一些协会或组织，了解趋势和信息。获得团队的尊重，还有很多微妙的方面，包括展现出诚信、公正、信任、支持、鼓励以及宠爱与“严厉的爱”的平衡。

团队管理方面，要努力招聘优秀的程序员，扩充团队人力资源力量，在无法扩充人力的情况下，要仔细思考现有团队如何持续推动团队进步，如何强化团队。对于不同类型的程序员采用不同的管理措施，对于杰出的架构师，他们是团队中最大的野猫，需求给予充分的信任，相信他们很做出更好的产品。一般而言应用程序员往往比系统程序员更容易管理。他们往往都比系统程序员更容易相处，而且他们的开发进度也往往容易看到。这是因为大部分应用程序都有某种形式的界面（UI或对外借款），而优秀的经理可以通过界面进行准确的进度评估。数据库和操作系统的程序需要对引导他们进行更多的优化，更多关注程序的运行环境，钻研更深。对于UI和Web开发员，他们使用高阶语言和工具进行开发，这使得他们不那么技术化，更依赖于他们所使用的工具的性能。他们需要面对需求的不断修改，需要培养他们快速响应迭代的能力。

技术经理工作中的一个重要部分是引导事情走向正确的方向。这意味着确保团队成员之间以及团队之间有正确的沟通。也意味着发现前进路上的阻碍并找到移除它的办法：通常是让一个程序员来开始或者结束一个任务。引导的目的是为了让事情完成，而不在于如何完成。经理独断专行偶尔可以，但对于一个经理来说，要想最大化地利用自己的时间和技能，就要引导程序员自己做出正确的决定，而不应该自己就把决定做了。这样可以帮助下属员工培养进，积累经验、建立自信，还能获得哪些具体执行决定的员工的认同。作为经理，你必须指出大方向，然后做好充分的检查，以确保员工做出正确的决定和实现。及早检查下属员工做出的重要决定，否则当你想插手介入并中途修正时，员工可能已经做了很多无用的工作。

其中程序设计经理必须学会的最重要的一课，是要保护他的团队成员，免受组织中每日泛滥不觉得各种问题、争议和“机会”的干扰。

作为经理最重要的职责之一，是评判员工的工作绩效，并持续改进他们的绩效。每日反馈、季度/年度绩效审查，以及每月或者每季度目标等都是很好的工具。可以帮助你完成绩效的评估和改进工作。为了改善每个人的绩效，最简单的办法，与他达成共识，设定一系列必须达成的目标或必须完成的任务，并指定完成的时间。接着定期审查这些目标的进度。

目标可以设立得比较通泛（如“提高编码技巧”）。面对复杂任务的挑战的我们，动力其实是自制力、专业精通、目标感、紧迫感、表扬赞赏、成就感，以及（对于做出的努力和采用的策略而不是对于结果的）正面的反馈。

对于团队中绩效太差或者对组织表现出破坏性影响的人，你应当解雇他们。同时，要学会如何激励团队成员，根据马斯洛需求层次理论，在低层次需求未被满足的情况下，更高层次的激励没有多少用武之地。适用于程序员的激励因素，最重要的是：改变世间；学习与成长；工具和技术；认可与称赞；有趣；利益。

关于团队的组织结构方面，技术经理应该思考各种你可能用来组织你的员工的方式，以及它们的优缺点，这是很有用的。关于人员配置，如果存在全职雇员和合同工，办公地点集中的方式可能更高效，便于沟通。

敏捷开发推崇“结对编程“，一般小团队比大团队效率更高。很多程序设计项目的规模都太大了，以至于小团队无法完成，我们都曾管理过需要几十甚至大批程序员一起工作的项目，他们没办法在同一个办公室工作，办公距离甚至超出了走了可以到达的距离。如此规模的项目需要更严格的项目计划、更正式的沟通方式、更详尽的文档，以及集成程度更高的系统测试。

当管理稍大的组织是，你需要提升一名你的下属员工来帮助你管理团队，或者从外部聘用外部经理。

团队文化建设方面，除非运气好能直接继承到成功的程序设计文化，否则你需要自己去建立它。为了维持这种文化，你还需要好好培养建立它。一个良好的工作环境，有利于开发高质量软件，重视按时构建和交付符合目标、客户导向的软件；充满尊重和公平的氛围，让员工保持高效率；容易培养并促进承诺和激励的环境；关于产品、项目和可交付物的度量标准，用以衡量团队的努力程度，并改进成果。

向上管理

向上管理指如何有效地管理你的老板以及他要汇报的那些人。另外你还要弄清楚如何汇报、如何沟通，以及要采取什么样的其他行动，才能上你的老板认为你是一个高效而成功的程序设计经理。管理你的老板初看起来似乎是一件比较奇怪的事情，但实际上成功地管理好你的老板可能比管理好你的团队还要重要，至少对你个人而言是这样。这个背后的原因在于，成功并不只在于你做了什么，更需要考虑别人如何看待你所做的成果：现实中外在认知往往比实际行动更重要。

向上管理始于了解你的老板，知道他们是什么类型的人：他们是技术型的，销售和市场型，财务型的，还是其他类型？是大局型还是细节型的？他们关注的敏感问题是什么？

让你的团队成员知道，你为了减少对他们工作的干扰，在幕后做了很多工作，这一点非常重要。同样，你也需要让你的领导知道，你为他分担了很多工作。这意味着，他需要知道的是，在没有他的指导与参与下，你通常能处理好哪些类型的事情，而不是那些事情的细节。你需要了解老板是如何评判他的，什么事情能够让他获得成功？你可以做什么事情帮助他？通常这些问题本质都更偏向长期战略，而不是短期战术。所以，请你弄清你的经理的工作目标是否包含以下几点：提高质量；按时交付；创新；其他关于产品的目标；问题汇报；合作与伙伴关系；收入、支出。找出对他而言非常重要的那些事情之后，你可以主动尝试对其中一件或多件做出贡献。

向外管理

向外管理，是指如何有效地管理你们部门之外的同级经理和其他同事。向外管理还涉及对组织外部的关系的管理，比如技术供应商、供应商、合作伙伴、竞争对手，以及行业中有影响力的人。与你部门内部的人好好合作才能更好与组织内其他人成功合作。你需要仔细研究公司组织结构图，找到各个职能部门的主管，想办法让自己逐渐了解他们，或是各部门中与你同级的经理，请他们吃饭，或者偶尔停下来跟他们聊聊天，提前建立彼此之间的跨部门纽带关系是很有必要的。以后，你真需要向他们发出请求或寻求帮助的时候，会更加容易。跨部门的纽带关系不仅能帮助你自己，也是促进不同部门团队之间双向协作的重要途径。在大多数组织中，了解下面列出的这些部门的主管，或者至少了解其中与你对应的经理，会非常有用。例如:

1. 财务（发票、付款、工资）
2. 采购（采购请求、供应商资质、加速购买）
3. 人力资源（雇佣、解雇、绩效审查、内部和外部薪酬公平、实习、招聘员工与合同工）
4. 营销（市场研究、展会、公司通信、新闻发布、营销担保、销售提成）
5. 销售（客户反馈、客户问题、客户联络、客户渠道）
6. 技术支持（关键客户问题、客户反馈、趋势、悬而未决的问题）

找办法建立好部门间的关系，除了直接约见他们之外，还可以尝试通过下面这些非正式的参与性活动结识他们：跨职能培训（一起培训可以形成强大的情感纽带）；组织内的社交活动，非正式午餐。

大多数程序设计经理的工作重点是管理他们下属的一个或多个程序设计团队，但还有可能需要管理外部技术人员，以及其他公司之外的关系，包括：客户；技术提供商；技术创新和工作方式颠覆这；工具供应商和提供商政府、贸易和国际标准组织；行业协会；专业组织；大学教育工作者；本地关系。

自我管理

最难管理的人总是自己，我们每个人都善于否认——我们会忽视坏习惯、差劲的实践，以及对其他人无法容忍的问题行为。要有效地管理自己，首先需要实事求是地评估自己的习惯、实践和行为；然后找出那些你想要改变的；最后履行你的改善计划。需要评估以下几个方面：
个人风格；时间和优先级管理；沟通管理；管理实践；跟踪管理；寻找导师

个人风格方面，即你的行为举止，是一个需要仔细考虑的重要事情，风格由很多因素决定的，其中包括：你的外表和衣着、你工作有多努力、你是否守时、你行为表现（个人行为和专业行为）、你是否把员工作为人而不仅仅是程序员来考虑，以及其他因素。我们觉得重要的是，选择自己的本色风格，然后如果有必要，再做一些细微的改变，来改善这一风格。

在时间和优先级管理方面，你最重要的资产就是时间，对时间要吝啬，但同时对那些真正需要它的人要慷慨给予。找到方法来管理好时间，你的生活将会过得更好。

技术的进步创造了很多沟通途径，远远超过了我们的处理能力。要想成为一个有效的经理，你必须建立机制来控制和管理洪水般的信息。不能让它控制你。

为了进行高效的管理，你必须建立一种对你和员工都行之有效的，可以让工作更成功的管理实践。在我们的经验中，这主要是指在一对一的关系或团队环境中，进行有效的沟通。要成为一个高效的经理，必须首先成为一个高效的沟通者，最高效的沟通者往往都是优秀的倾听者。人们一般都是想要被倾听，你的员工也是如此。用心关注与你沟通的人，在听完对方所说的内容之后，重述你听到的内容，以确定你的理解正确。这个办法通常需要先找到对方叙述独白过程中的休息点，再说类似于“那么我说一下我的理解；你说的是不是…”。在沟通的过程中，不要隔着办公桌，这样很让人很不愉快。许多人认为管理是自上而下的，具有权威性的地位，也就是说，处在金字塔的顶端——山之王。与此相反，我们建立你把自己看成处于金字塔的底部，而你的员工在顶端。他们和他们的工作才是真正重要的。每天制定一个任务清单，尽可能完成更多的任务，感受你完成每一项任务的成就感。

跟踪管理通常是一个经理的大部分工作，需要询问自己“这个任务完成了吗，如果没有，为什么没有，它什么时候能完成？”，跟踪自己的工作进度。

作为持续学习如何当经理的一部分，可以寻找一位或多位导师，如果你对那些非常成功的人进行合理的样本调查，很可能会发现，他们中的许多人都会指出一个或多个导师，他们的生活过程中起到了很大的帮助，使得他们成为成功人士。

项目交付

项目开始于愿景，但必须通过需求、假设、预期、风险、里程碑和最终交付的流程，才能成果交付。

虽然敏捷开发建议开发与需要人员一起，有问题随时询问需求人员进行解答，当你需要自己制造需求的时候，很难做出满足客户需求的产品，猜测从来不是获知需求构建什么产品的好基础。多项研究表明，依照模糊的需求进行开发构建，是软件开发中代价最大的错误，并且是项目失败的主要原因之一。因此，在项目一开始，你最主要的任务是，确保与商务团队就需求、假设、预期、风险、里程碑和交付物进行清晰、干脆的沟通。你并不需要亲自进行所有沟通，但是需要确保有人来做好这些沟通。

在所有和产品相关的人中，程序设计经理最有可能成为那个规划工作的人，包括组织功能点，识别需要完成的任务，并弄清楚每项任务需要做哪些事情，定下每一件任务需要在什么时候完成多少。方法如下：

1. 将项目拆分为功能点，并按优先级排序，根据两个原则进行优先级排序：客户价值、风险
2. 将功能点拆分为任务和子任务，每个任务最少需要2天的工时，不超过一周的开发时间
3. 将任务估计集成为项目估计，一个比较常见的问题，估计5天的任务，需要5天的时间来开发，而实际上很少有组织中的程序员在5个日历中能拥有完整的5天开发时间，通常会被叫去开会、团队会议、设计会议、QA会议、Bug会议等，关于之前版本或产品的维护的会议。一条非常保守的业界经验法则是：程序员用于编码的时间一般不会超过55%，或者更高一些60%，这意味着一个11天的任务需要20个日历日才能完成。

风险高向工作优先进行，合理评估工作中的风险点。

定义“完成”应当由商务、开发、项目管理、 QA以及其他团队共同协作，以确定每项功能在什么情况下可以宣布完成。
除了写好代码，还需要完成：

设计复审；
同级复审（或者结对编程）；
代码复审；
单元测试；
代码提交；
源码控制注释；
性能测试；
重构；
与构建负责人沟通好需要做的改动；
写好在线帮助，并集成；
从源码库构建一个完整版本；
源码库构建版本通过单元测试；
新的源码库构建版本通过自动化集成回归测试；
修复 bug；
写好安装脚本；
进行跨平台、跨浏览器、多配置下的测试；
更新项目故事或用例测试计划；
写好相关文档；
产品经理、产品所有人以及/或者客户验收通过；
记录任务时间；
关闭任务。

整个团队对“完成”的要素达成共识并同意交付这些要素非常重要。不同的团队认同相同的“完成”定义的情况并不常见。甚至在达成了共识的同一个团队中，这些定义都可能因为迭代、任务或冲刺阶段的变化而改变。

参考工具：http://managingtheunmanageable.net/tools.html