详情
本书是为软件开发人员、软件项目经理，以及打算成为软件项目经理的软件开发人员准备的，对软件项目管理中涉及到的问题从技术层面以及管理层面进行了讲解。通过本书，读者可以学习到如何计划、安排软件的开发进程，如何更为有效地管理项目团队的成员等知识。
书名：管好团队做对事——软件企业成长手册
ISBN：978-7-115-23127-7
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 [美] Louis Testa
译 郭稚晖
责任编辑 傅道坤
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
Copyright © 2009 by Louis Testa. Title of English-language original: Growing Software, ISBN 978-1-59237-183-1, published by No Starch Press. Simplified Chinese-language edition copyright © 2010 by Posts and Telecom Press. All rights reserved.
本书中文简体字版由美国No Starch Press授权人民邮电出版社出版。未经出版者书面许可，对本书任何部分不得以任何方式复制或抄袭。
版权所有，翻印必究。
软件行业中最为经典的语录就是“唯一不变的就是变化本身”。作为中小型软件公司的技术领导，在迅速应对行业、市场以及公司内部调整变化时，在做好队伍建设，产品定义，工程实施的同时，既要贯彻高层主管们所制定的战略指导方针，也要处理好各级部门与同事的关系。这些技能与素养的培养对于那些刚刚从工程师队伍成长起来的技术经理们来说是一个很大的挑战。
而本书就是站在这样一个特定的角度，教您如何培养这些技能与素质，以帮助您解决软件公司运营过程中出现的日常危机，并指导您如何打造并领导一个高效的团队，如何定义你们的产品，如何实现从客户到CEO之间各类人员的精诚合作，从而确保完成高质量的交付产品。本书包含了以下内容：与你的CEO和执行团队一起有效工作；提升开发团队效率并激发他们的工作热情；评估你们的软件方法用以提升开发效率并防止失误；利用产品原型来弥补市场与工程直接的空隙；排除技术定时炸弹的隐患等。
作为有着20余年项目管理经验的高级技术经理，Louis Testa先生在本书中融入了大量的实际案例和指导意见，使得软件管理行业的新人可以在字里行间体会他的谆谆教诲，找到前行的路标。而具有一定管理经验的项目经理通过阅读此书，也可以更新其陈旧的管理经验，打破其原有的陈规旧俗，从而对软件项目管理的认识达到一个全新的高度。
在许多成长中的小型公司中，项目经理们在执行CEO战略意图的同时，往往还得处在不得不与技术团队和其他高级经理打交道的位置。通常情况下，即使当工作的非技术因素已经最大程度地影响公司的成败时，开发经理们依旧仅仅关注于技术。伴随着公司的成长，曾经看上去很小的问题也在不断扩散，最终引发成为主要灾难。我写本书的目的，就是为那些新上任的开发经理们提供建议，告诉他们如何成功地应对这些挑战。
小公司中的开发经理在很多方面都不同于在一个稳定的大公司中的同等角色。例如，小公司的开发经理通常不仅要和开发人员一起支撑亟待成熟的产品，还必须与被公司成长过程中面临的挑战所吸引的技术大牛共事。但最重要的是，小公司的开发经理必须对员工、产品、过程、规划、技术以及客户等诸多因素给予广泛的关注。
相对而言，大公司通常支持多种现有产品，他们的过程定义通常比较清楚而且相对稳定。大公司的政策通常限制了开发经理所用的工具、技术及实现方式。相对于小公司的同等角色，大公司的开发经理工作范围更明确而狭窄。
本书作为一本实践指南，为那些经历过初始生存阶段且正在试图进一步发展壮大的小公司中的开发经理们提供了实用的指导原则。其目的是帮助管理者预见问题并在其变得棘手前及时进行处理。这里描述的技能主要适用于销售产品级软件或提供软件服务的小公司，并不针对软件咨询业务。本书不仅提供了总体建议，也提供了具体解决方法以及详细的模板和电子表格，这些内容都非常有助于开发经理们将基本概念应用于具体实践。
由于涉及范围较广，本书的书写方式采用了指令式的风格（prescriptive style）而不是议论型argumentative风格——也就是说，不建议采用广泛的论据来说明这些良好的工作技能如何到位。这方面的资料将大大扩大本书的范围，但同时也会降低它的可读性。
为方便起见，笔者使用“开发经理”和“开发管理人员”贯穿全书，这些术语用于指代高层软件/工程管理人员——不论是首席技术官（CTO）、工程副总裁、工程总监，还是高级工程经理这样特定的工作职位。这个人既要从事软件工程师的管理，还要担负质量保证、文档说明以及项目管理等团队的管理。虽然本书的目标读者是开发总监，不过非技术类管理人员也同样会受益于本书所描述的问题和解决方案。
为便于参考，本书分为如下主要部分。
虽然本书是按顺序逐个主题逐层深入的，但读者还是可以跳过一些章节直奔感兴趣的主题。
公司从启动到发展成熟是分阶段成长的。本书将涉及其中的一个或多个阶段。表1是根据公司的规模和产品的成熟度对发展阶段所做的定义。
表1 公司启动发展的阶段
| 阶段 |
公司规模（员工数量） |
客户 |
|---|---|---|
| 启动 |
少于12 |
0～2个，没有主要客户 |
| 立足 |
12～40 |
3～5个，1个主要客户 |
| 发展 |
40以上 |
6个以上客户，2个主要客户 |
本书提供了用于解释关键点的现实情况的叙述短文，这些短文散布在全书各处。虽然出于一致性的考虑，这些故事是以第一人称来写的，但它们是我个人及其他人的经验汇总。正文中隐去了公司和个人的名字。
电子表格示例用来说明解决特定类型问题所需的信息汇总、分析及展示技术。每一个电子表格都在正文中予以说明和描述，它们可以从http://www.nostarch.com/growingsoftware.htm下载，并用在Microsoft Excel或OpenOffice.org Calc中。这些示例的主要目的是让读者利用简单的电子表格去分析和解决潜在的问题。
虽然这些电子表格可以用正常的方式使用，许多情况下还是需要你自定义电子表格的样式布局。你自己也可以通过输入所有的字段来重建电子表格。箭头所指单元格中可以输入计算公式，并可以在示例的右边或下边给予说明。在适当情况下，可以按照电子表格中所附注释的描述来复制整行或整列公式。图1中给出了示例和说明。
输入公式时，在将公式从一个单元格复制到另外一个单元格时，要注意美元符号（$）会对公式读取数据的方式产生影响。这些影响不包括公式被复制后，美元符号导致的计算错误。
图1 本示例列举了单元格的操作说明
对于电子表格示例来说，正确的格式同样很重要。默认的输入格式是“常规”格式，这种格式并不会以最适当的方式显示所有数值。上例中隐含了一些格式：日期应该采用日期格式；货币应采用小数点位置带零的货币格式；数字应采用的格式是根据所需要的小数位数进行四舍五入。
Excel与OpenOffice.org Calc的显著差异
- OpenOffice.org Calc使用分号（;）分隔公式中的字段，微软Excel使用逗号（,）分隔。本书在所有的公式中采用逗号分隔所有的字段。如果使用Calc，要使用分号进行替代。例如，Excel公式 = WORKDAY(B3, C3)在Calc中则为=WORKDAY(B3; C3)。
- 第二个显著差异是使用表间引用来引用其他工作表的单元格。在Excel中使用感叹号（！）实现表间引用，而在Calc中使用的是句点。例如，在Excel中引入Eng表格的公式是=Eng!H3，而在Calc中则是=Eng.H3。
本书也提供了由虚线框围着的示例模板，以便于读者复制用做初始模板。读者在填充模板时，可随时将模板的说明予以删除。
正是因为付出了大量的心血，才使得我的第一本书如此有趣。然而，无论我个人付出多大的努力，如果没有包括家人和朋友在内的众人给予的帮助与建议，本书将不值一读。
没有我妻子Edie以及4个孩子Logan、Kevin、Kerry和Brady的鼓励，我不可能写完本书。Edie的忠告和建议促使我重写了许多章节并填补了其中的空白。
在此，要特别感谢Clayton Greer，他对本书进行了细致的技术审核并提供了大量有价值的建议；感谢Anita Maria Gutierrez对本书全稿广泛而全面的审核，以及从编辑角度所提供的见解和改进建议；感谢Jef Bell对本书全面而透彻的审核与积极建议，并提供了让本书更有说服力的创意；感谢Mike Portwood对本书主题富有见解的建议以及为审核本书花费了大量时间。
此外，对Bob Tidwell、Curt Frye、Paul Irvine、Gordon Huntsman、Miki Tokola、Rick Sanstrom和Dylan McNamee提供的宝贵建议与信息致以诚挚的谢意。
最后要特别说明的是，与No Starch Press的团队人员一起工作的感觉很美妙。他们是Megan Dunchark、Tyler Ortman、Lisa Theobald和Adam Wright。任何有志于图书出版的技术作家，都可以联系他们。我向你们隆重推荐（我想我做到了）。
IT技术团队经常由一群个性执着甚至倔强、较真、直爽还有些乖张的技术狂人组成，管理这样一群特殊的人，不能“硬来”，而是要使用“巧劲儿”。我本人从事了十多年的技术团队管理工作，记得在最初成为团队管理者时，对一些相关领域的知识接触较少，也不可避免地走了一些弯路。很高兴能看到这样一本书面世，为初为技术团队管理者的读者提供了一个全面的升级读物，为大家打开了一扇快速了解IT团队建设和管理知识的大门。
——东软网络安全营销中心总经理、中国计算机学会YOCSEF大连分论坛AC委员、大连海事大学客座教授、LMI（美国领导力中心）领导力教练 赵鑫龙
任何伟大的公司都是从小企业走过来的，当你有幸在这样的团队中担任技术管理工作的时候，你不仅要是一把锋利的匕首，更要是一把万能的瑞士军刀。你不仅是技术经理、架构师、质量经理，还需要是运营经理、产品经理、流程经理，其实你已经必须时刻站在CTO的角度来思考问题了。对于任何管理类岗位，真正决定个人成功与否的因素都是技术技能之外的东西，比如性格、团队融入、思考问题的方法论等。以科学的态度做技术，以市场的视野做产品，以营销的心态做管理，本书虽不是十全大补，但作为够份量的实用指南，足矣！
——凡客诚品架构总监 栾义来
本书提供了大量的实际案例和指导意见，能够帮助软件公司在团队管理以及在产品定义、质量控制方面获益。本书通过大量的实例讲解，告诉管理者如何建立、扩充、管理你的团队，如何提升开发团队的效率并激发他们的工作热情，如何合理利用资源与制定流程规范来解决与执行团队的合作冲突、项目过程质量控制等问题。对于互联网公司来说，本书具备丰富的内容与指导意见，是伴随技术经理成长的一本好书，推荐给大家。
——新浪博客技术经理 张华东
开发经理们往往只关注公司的技术。虽然技术非常有趣，但优秀的经理人必须首先了解和他一起工作的同事。只着眼于技术而忽略人的作用，就如同在训练一个棒球队时将所有的时间花费在测试最新、最大的球上一样。
本部分包含了启动新的工作，和开发组织一起工作，以及成功扩展你的团队。不要担心，我们也会谈论技术，后面会讲到的。
想象一下你沿着一些新的路径在树林中远足旅行。天气很好，你也很放松。随着不断前行，你发现景色开始变化，你进入了未经开发、崎岖不平的荒野。最终，你停下来坐在一块大石头上并吃了点零食。
当你在吃的时候，你意识到你不知道自己身处何处。你忘了带一张地图，也忘了规划路线和做上路标。现在你突然感到了紧张和恐惧。你迷失了方向。你想走得更快些——无论是按既定方向前行还是转身回去。但你知道，迷失在树林中的时候，惊慌且任意方向上奔跑只能犯更大的错误。
你记得一些荒野求生的建议：当你迷失的时候，先停下来评估方位，然后行动。你已经停止了前行。你要评估自己的处境并问自己几个问题：我怎么知道我在哪里？我的背包中是否带有工具、地图或其他有用的装备？从出发到现在已过了多长时间？预计多长时间能平安返回？下一步，你制订一个计划——然后采取行动。
现在，换一个场景：你在一个在新兴领域迅速成长的小公司中担任工程副总裁。虽然你从公司创建伊始就伴随其成长，但它已不再处于你所熟知的起步阶段了。你感觉像没带地图迷失在树林里。就像徒步旅行者，任何迅速而匆忙的行动都将使你的处境更糟，所以不要恐慌，先停下来，评估局势，尽可能汇总信息，制订策略，然后行动。
另一方面，如果你在一个成长中的公司开始一份新工作，你也许感到你陷入了树林之中——失去了最初跋涉的欢乐。同样的方法适用于这种处境，不管怎样，在你采取下一步行动前先停下来纵览全局并收集你能掌握的信息。不论你是第一次迷失还是再次迷失，采取如下步骤，你就可以找到出路。
伴随着技术型公司增长的波动性，忠于公司的高级职员会逐步减少。当一个公司业务重点发生转折或改变的时候，开发经理们通常开始找寻新的工作。当然，获得新工作的第一步，始于面试。
面试中，面试官将尽力描绘他们公司的美景，如同薄雾笼罩的莫奈名画。而一旦你开始工作，则图画开始扭曲，甚至有些像毕加索的作品。面试中所描述的微妙的小问题变成了你亟待解决的巨大危机。表1-1中以调侃的口吻比对了面试说词与现实之间的差异。
表1-1 面试与现实的对比
| 面 试 说 词 |
现 实 情 况 |
|---|---|
| 我们有一些很小的质量问题 |
该产品是一场灾难。只要你上了贼船，就会为所有的错误承担一切指责 |
| 我们需要提升我们的交付承诺 |
没有产品可以如期交付，由于市场及其他高层不能下最后的决心，公司在整个开发过程中需要不断修改新产品功能。即使这样，所有的人都希望按期交付 |
| 我们有一支伟大的工程师团队，只是需要一些指导 |
团队成员正在大厅里尖叫着讨论，至少有一位工程师由于不够格要被开掉 |
| 我们是一个有紧迫感的公司，有干劲十足的员工 |
你那个“懒惰的”的开发团队正期待着混过工作午餐、每一个夜晚以及大多数周末——除非你干掉他们 |
在你加入公司走上令人生畏之路时，你需要充分利用现状。
在你任开发经理的一开始的日子里，急迫的问题需要立即引起你的注意。一些问题自从上任经理离职之日就开始堆积在那了，在你桌上堆放着延期数月的决策方案。在沼泽中跋涉是对处理这些积压工作最形象的比喻。
在专注于这些问题时，你可能会感受到压力，这会危及你长期的成功。只关注急迫的问题，会让你失去从公司、产品、同事以及你的团队中学习成长的机会，所以要做一次深呼吸看一看更广阔的天地。
如果在解决悬而未决的问题与处理日常危机之间分割你的时间，你会最终减少一些重复出现的问题，这样会提升团队的效率。每天花一部分时间从公司获得一些情况要比全力以赴处理积压问题更有效率。此外，你最好去了解一下团队所面对的重大问题，这将会促使你较早找寻出解决之道。许多问题还会在日常工作中冒出来并迫使你持续转移注意力。可以通过建立一个根据自身时间来处理多方面要求的体系来避免这个混乱的过程。
从一开始养成细致的任务管理和记录保存好习惯将会对工作非常有帮助。维护一份清单，清单中要包含有关你的决策、处理过程以及一些重大问题，特别是那些对你较为迫切的问题。根据问题解决完成时间排出列表的优先级。管理好这份列表不仅有助于你减缓由于遗漏问题而引起的焦虑，将列表组合还可以让你和老板一起对你所排的优先级和问题处理进展进行评审。
逐日审核你的任务列表锁定优先问题。对于大的任务，则要锁定那些短时间内能够完成的子任务。每周要把重点放在高优先级的大任务上，否则，短期紧迫的要求依旧会导致进一步的延期。如果你日常处理这些问题的时间有限，则要避免时间透支并妨碍你的工作进展。
当你完成了一个解决问题的任务的时候，记得标记上日期并将任务存档。这个档案文件将在日后你被问起如何处理这些问题细节时有所帮助。验收成果同样有助于提高自身工作的积极性。
在适当的时候，对一些紧迫的问题进行职责分配，不要试图亲力亲为地解决所有问题。适当的任务分配可以使你和你的团队更富有成效，并且通过处理新任务也可以提升整个团队成员的士气。任务分配时，要确认受托者清楚了任务的内容、与其他相关工作的优先次序以及进展状态检查的时间点和完成日期。同样也要确认项目成员知道可以从你这里得到更多的信息。
如果不适合将整个任务分配出去，你可以将一部分任务分配给团队成员。例如，你可以把信息收集分给其他人而把审核留给自己。或者你也可以让一个团队成员提供一个问题的背景分析并指导他去分析数据。如果你能赋予团队成员承担部分重要工作的机会，你们都会受益。
当处理完棘手问题时，记得向老板通报你的进展。这有助于预防对你工作上的误解。
初始培训阶段的成功需要集中付出努力与时间。每天要留有稳定的时间用于熟悉公司的员工，学习公司的技术，了解公司的产品、市场以及运作流程。找出你最机敏且能集中精力的1～2个小时。每天提前上班，并把每天最初的时间用在培训上，然后在以后将这段时间用于处理疑难问题。
作为新任的开发经理，在你的老板给你一些灵活度来熟悉工作和企业文化时，你会拥有3～6周的“蜜月期”体验。这一时期你可能会期望加班，用这些额外的时间来熟悉工作并处理重要的问题。如果老板认识到了你额外的付出，他会为最初雇用你的决定感到满意。在你展示了自己的能力后，就可以将工作时间适当减少到适度合理的水平。
要知道你是否被特别雇用，被期待成为变革代理人或期待给一个高效的部门带来增量变化。这些期待将决定你如何把结果展示给你的团队和老板。例如，如果你认定的重大问题而公众却期望维持原状的话，你就要耗费大量的时间和精力去说服老板和团队去认识一些问题的重要性。
你解决长期问题的时间也很关键。例如，如果你等到6个月以上再讨论宏观问题，你将面临比较巨大的挑战。你可能失去了展示创新理念甚至确定问题之所在的机会，一旦你沉浸于细节，就很难认识到系统中的瑕疵。当人们更愿意从新经理那里倾听新颖的观点时，你会发现开发团队更加抗拒变革。
如果你提议实施重大变革，要向公司如实陈述其利益和成本。“兜售”你的变革可以帮助你避免树敌或面对其他人抗拒变革的行为。
收集公司产品、人员以及过程方面的信息有助于你制定头3～6个月的工作策略。通过与老板交流以及花时间与你的直属下级、同僚们沟通，以获取公司更广阔的前景。你的目标是了解公司的成就与全局性问题，并学会如何发展才能最好地为公司服务。从询问如下开放式问题开始，找到并分辨出问题的主要切入点。
然后将学习成果融入到工作总结中，并寻找一个解决模式。
当你与同事、经理以及其他员工商讨问题时要做笔记；然后把你的点评融入到带有强调符号的陈述之中，以确保思路清晰而富有条理。释义转述和总结性注释会使你的陈述短小精悍。
之后，分门别类整理总结文件。每一类都可以包含问题以及成就两个方面。在每一个问题方面之后，罗列出一个你们交流讨论的相关解决方案。这里有一个用于收集信息的推荐分类列表（当然，你的列表也可以用不同的展示方式）。
技术 质量问题
人员 内部文档
组织架构 风险
清晰的目标 客户服务
方针 市场和销售
过程 财务问题
计划 其他
问题和解决方案可以分为三类：你和你的团队可以直接解决的问题；需要通过与其他部门或其他组织中的人员合作解决的问题；你只能施加影响而不能直接解决的问题。根据你的摘要标示出每一个问题。
一个最终文件的摘录可以做成这样。
4．技术
有利因素：我们的技术比竞争对手更快更可靠。
有利因素：编程语言和函数库都是最新的。
问题：系统在A-15子系统中没有冗余性，将导致“核心崩溃”。这需要与运营部门协作。
问题：API几乎没有错误校验。两个缺陷数据请求就可以导致系统擦除数据库。
解决方案：我可以通过与开发人员讨论直接解决。
之后，为发现的问题和取得的成果设置优先级。将成功的做法与问题进行排名可以让你考虑如何保持有利因素的优势。一个简单的A、B、C优先级对最初的排序就很好，并且可以在每一级别都遵循这一体系。将老板的指示级别提高，但也不要低估其他人的反馈。最终，你必须决定解决哪些方面的问题并且如何解决它们。从最高级别的问题中制定一个行动计划。例如，估算未来3～6个月你能完成多少。一个切实可行的计划会帮助你避免一次跟踪过多的任务以至于能完成的工作越来越少。
制定计划前要确认相对于改善型工作你完全了解自己能承担的混合型项目工作。对于一个小公司，至少要花费自己10%～20%的时间和团队5%～10%的时间来解决和当前项目没有直接关系的问题。这类与项目无关的问题包括提高生产率、指导培训讨论、推进技术、规划未来、改善工作关系，以及解决人的问题。
行动计划的失败通常是由于缺少公司的支持，所以要确信在你不断的努力下能从老板那里争取到支持。你需要你的老板极力支持——至少是认可——如果你希望成功。如果你的老板否决了你的建议，你需要理解他的忧虑——或者，你依旧相信你的建议，去做更多的研究然后兜售。在你的方法获得成功以前，你的老板需要知道你在用一种合理的方式来解决企业中存在的问题。
你也应该与其他部门经理特别是市场和销售经理们沟通。他们需要理解实现他们所谓的短期目标为何要花费如此多的时间和资源。要说明你的变革能给公司带来的长期利益。由于你确定的问题并不仅仅与你的部门相关，与其他人讨论和反馈意见将增进你对问题范围的了解以及帮助你找到最好的解决方案。
将每一件费神的事情当做一个带有时间表和资源的项目。要持续促进项目改进，否则他们就会失去动力；不能提升领导力就会导致随着公司的发展壮大，生产力却更为低下。
得到公司的总体概况
当我加入目前公司的时候，我花时间与不同部门的十几个人去交流。我把所听到的信息整合入一个只有几页纸的总结性文档中。这个过程让我洞察到了即将发生的一切。与每个人交流是一项启发性活动，它指引我直奔最先需要解决的首要问题。
—— 新任经理
了解你的同事将使你的工作更富有成效并且更加有趣。相反，不去熟悉他们会导致看法片面也容易产生摩擦。幸运的是，你可以通过与人特别是你团队中的开发人员交流来增进相互了解。
询问如下问题。
对这些问题的回答将会提供如何与他人共事的线索。掌握开发人员如何完成工作以及与其他人相互合作有助于进行表现评价。阅读团队过去的绩效评审可以提供一些见解，前提是前任经理写下了有用的评审意见。如果前任经理没有写下意见，你也可以得知在到任之前这个团队是如何管理的。
也要和团队之外的员工交流。与全公司的人员进行沟通不仅可以体验到企业文化还可以清楚什么方式可行以及什么方式不可行。与公司其他人建立关系所带来的好处是难以想象的——另外，了解人也可以使自己身心愉快。
第2章和第3章就如何与你的团队工作进行了详细讨论。第9章和第10章就如何与整个公司的其他人一起工作提供了建议。
你可能会遇到不愿透露信息的工程师或其他人。他们通过如下方式表露出抵触情绪。
这些答复似乎关上了你要获取所需资料的大门。要克服这一点，就需要理解它们背后的真正原因。这里是一些人们不愿提供信息的常见原因。
有礼貌地坚持请求所需要的信息往往很奏效。在任何情况下，通过解释你所感兴趣的信息来建立信任感，但要坚持让工程师及时地提供资料，要做到如下几点。
怀有敌对情绪的工程师们需要争取过来——或者，最坏的情况，把他们清除出去。行动前花时间去了解这个人以及他/她的动机。第2章和第3章将进一步阐述管理开发团队的细节。
企业文化涉及员工间相互配合的方式以及管理回报的表现形式。为了认同企业文化，要把经理们说的话与做的事进行观察对比。阅读公司价值观与使命感也同样有所帮助。你可以通过与同僚们讨论来确定是怎样的使命感和价值观影响着公司的发展方向；你应该明白如何利用这些资源对员工实施有效的管理以及做出正确的工作决策。
建议
如果你的老板在最初的工作会谈时没有讨论公司价值观的话，价值观很可能就是企业的基本信条。
小型和成长型公司需要仔细全面考虑之后再推出他们的价值观和宗旨。这些宗旨是构建企业文化的基石。管理人员必须培养员工接纳这种价值观与使命感，管理人员也应该审核那些与这些宗旨不一致的主要决策。由于小公司和成长中的公司变化较快，相对于大型和稳定的企业，价值观和使命宗旨就显得尤为重要。
在一个运作良好的公司，价值观和使命宗旨就是这个企业的定义。人们基于明确的价值观做出公司发展方向及机构职能等方面的决策。例如，对质量的关键作用认同将会导致CEO将质量管理团队在组织架构中置于突出位置并且加强质量培训。作为开发经理，要尊重公司的使命感与价值观并尽力将之融入到自己的管理风格之中。
第9章包含了企业文化的细节内容。
在最初工作的两个月里，要获得公司技术、过程以及产品的全貌。要掌握技术是如何利用的，产品是如何工作的，开发过程是如何运转的，以及开发团队成员是如何配合工作的。评价你所了解的内容并确定你还没有完全掌握的方面。然后通过系统地收集相关信息填补相应的空白。
要完全了解产品。除了数据流，至少还要审核用于展示主要模块的高层架构。团队中的开发人员应该可以描述这些原理并可以提供现成的总体文档。
告诫
在许多小公司，概述和过程文档往往是过期的或者缺乏细节性的描述。
将掌握的信息写成文档和画成图表有助于你吸收信息（像Microsoft Visio就是非常有用的画图工具）。你画的图表将融入公司的知识产权。用这种方式充实公司的知识产权会产生多方面效应：新员工将拥有一本培训手册，其他小组以及公司潜在的合作伙伴将拥有参考资料，并且，如果公司出售，知识产权将增加它的价值。
要考虑把你的图表送给开发团队获取反馈。他们可以点出问题并提供改善建议。更正和提炼过程图表通常需要几个回合。在这一过程中，团队会针对产品和实际工作过程的细节形成一致看法。此外，这种努力将会改进现有的流程。
系统性思考掌握的内容有助于避免你在培训过程中以及日后管理能力上出现的盲点。图1-1说明了用于审核的技术主题样例清单。
图1-1 技术审核列表
要对公司产品形成正确的认识，就要从很多方面来收集资料。请销售或市场经理对你进行产品使用培训以使你掌握他们是如何将产品展示给客户的。
独自做产品实验促使培训细节更易于记忆。用真实的假定数据做实验——而不要使用客户或产品数据。使用安全的数据使你在实验中不必为损坏和暴露数据而担心。尝试每一个功能、每一个按钮以及每一个数据录入模块——并试图中断它们。你需要很好地了解产品以及它的局限性。
你可以在第5章和第6章发现更多的产品资料。第7章和第8章包含技术和工具，第15章包含过程方面更多的细节。
熟悉公司的客户也是最初评估的一部分。与销售和市场团队交谈来了解公司的老客户。也可以与销售人员一起确定拜访客户，并留意收听销售电话，这些方式都有助于你来认识了解你的客户。
与销售和市场团队讨论如下问题。
花一些时间与关键客户一起了解他们如何使用产品。这种交流将使你洞察到客户是如何看待你的产品的。要了解产品所服务的行业。从销售和市场团队得到的信息将非常有帮助。
第12章包含了了解客户方面更多的细节内容。
要掌握公司的业务流程，了解不同团队是如何通过一起工作来提供产品，实施技术支持，以及提供客户服务。许多公司都有对你来说非常重要而独特的总体流程去了解。把你收集到的资料画成流程图不仅可以澄清业务流程还可以创建一个方便其他人使用的参考手册。
创建一个企业总体流程将会澄清哪些团队负责软件产品或服务的哪一部分。记得要包含客户与公司之间相互配合的部分。
一个企业工作流程图也可以让一个新公司受惠：它帮助执行团队发现问题并且领会如何更好地提供新的服务和产品。工作流程图也可用做新员工的培训资料，帮助他们理解如何通过自身的努力来支撑公司的发展。团队成员将通过了解他们的工作对全局发展的贡献感受到前进的动力。
虽然工作流软件和复杂的图表方法对于捕获企业的工作流非常有用，但对小公司来说简单的图表就足够用了。附录C说明了画示意图的直接方法，包括基本例子。即使你已进入公司一段时间，你也可以发现通过勾画流程图对洞察公司如何运作以及发现有待改善提高的领域非常有价值。
得到公司的总体概况
我以前的公司大概提供12种不同的产品，每一种都需要不同类型的报价。我写下了全部的企业流程并详细描述了每一种产品耗费的工程成本。详细报价并决定如何对产品报价是一件大好的事情，允许我们提供更快和更精确的报价。
一个图形化的企业工作流可以让经理们更易于发现流程的改善方法。我们同样也将这些材料作为新员工培训教材的一部分。
——高级经理
本章为你提供了大量需要考虑的内容。这是围绕那些需要全面解决的问题进行的宏观性总结——帮你找到走出丛林的方向性清单。
在最初工作的几个月中每周至少要回顾一次这个列表。如果你漏掉了关键领域的信息，就要考虑进行调整把重点放在这些方面。在最初的几个月里，没有最佳的单一方法或现成公式来统筹你的时间，但如果你持续在高压模式下处理一个又一个危机，找一个不被打扰的安静空间来筹划一个重点放在关键领域的计划。如果你不积极地去努力筹划，你将会继续面对这种恶劣的情形——但当你确立了方向并为之而努力的时候，工作就会变得非常有趣。
在一个小公司做开发经理，你会拥有在大多数大公司找不到的独特角色。无论你的职位是首席技术官、工程副总裁还是总监，你都必须成为CEO及执行团队成员与你的开发团队间联系的纽带。在一个小公司，你必须能以不同于那些大公司开发经理的方式去全力以赴。
在投身于管理一个团队之前，让我们先审视一下如何才能成为有效的管理者。问一下自己如何与你的开发团队一起工作以及如何用你的核心价值观去带动大家。你对他人的尊重，你的道德准则，你自身带队和倾听的能力，提供反馈的能力以及关注其他人的成功等因素都会影响你如何做出决策。
作为一个经理，在与你的团队一起工作时，你需要一个可随时存取工作法宝的“工具箱”。你的工具箱里应包含用于激励人员、供自己查阅和选择团队的工具，还应该有组织团队、设置工作空间、管理项目、解决冲突以及与团队沟通的方法。多种工具与方法在手，你才可以为工作选择出最好的方案。
相比之下，一个死板的经理可能只有一种工具——在上一家公司的上一份工作中所用的那一套工具。不过，俗话说的好，如果你只有一把锯，那么所有的问题都只能用锯子来锯。
下面的部分涵盖了关键的工具以及核心价值观的组成部分：信任、灵活性、诚挚、机密性、尊重以及授权。
一个充满信任的公司最具有生产力，因为员工们不会在权术斗争、指责他人缺点或守住自身位置等方面耗费精力。这些公司鼓励直接沟通——员工们通过正确的信息及他们的工作支持取得管理人员及相互间的信任。这促进了员工高昂的斗志，因为员工们把精力放在了生产而不再是小心谨慎。
鉴于在小公司工作要比在大公司工作风险大，小公司的员工必须能够相信来自高级管理人员的信息。由于小公司和成长中的公司常常缺乏可观的资源，高度信任的环境提升了成功所需的效率。
在低信任度文化公司工作的员工就会把精力浪费在查找其他人的缺点和保住自身的位置方面。员工们认为他们需要仔细核实管理层所做评价的真实性。在这样的公司，管理人员通过回报低信任的行为延续了低信任度的文化，例如政治动机、对其他人的公开口头抱怨、谣言、逼迫其他团队决策的政治攻势以及恶意中伤。低信任度文化趋向于在那些人人自危的公司中繁殖。管理往往是权威和政治。高级经理们把精力放在如何踩着别人上去。当高层管理人员缺乏针对性的积极努力时，那些通过表现低信任的行为来晋升的人则存在有短期利益。
为什么没有更多的企业建立起高度信任的环境？建立信任需要管理人员通过讨论公司价值观与核心理念来付出每一天的努力，而不仅仅是做一个年度回顾。高度信任的文化需要经理们雇用合适的人才，在公司文化中指导他们，规范他们所期待的行为。
最后一个摆设
我们的QA团队由6位工程师组成，我们都擅长于自己的工作。当我们的QA经理离职另谋高就的时候，副总裁指定了一个既没有QA经验也没有管理经验的经理。我们团队愿意给他一次机会。然而，过了4个月，他不仅对质量管理没有任何兴趣反而还挑拨我们的关系。最终，团队其他成员找到了其他工作而经理并没有安排人员来接替他们。
我是公司雇用的最后一位QA工程师。我给经理写了一封电子邮件，要求他把精力放到QA上来。我对团队其他人员离职而没有安排人员接替深表关注。他把我开掉了，并由于我的反抗而在那一天强行把我送出大楼。即使私下交流，我都不应该信任他的公平性。
我发现在我到另外一家公司做管理工作两周后这位经理也退出了。他毁了QA团队并最终离开了公司。
——QA工程师
作为经理，你可以通过显示高标准的公平性、机密性、尊重、诚挚以及冲突解决方法来建立信任感。你要有效处理那些让你失去信任的团队成员。例如，如果一个团队成员向你汇报她已经完成了任务，你期待着任务圆满地完成了。如果你事后发现她没有完成任务，你就不再信任她。此人将成为你的拖累，因为你必须仔细检查她的工作以确认圆满完成。
在高度信任的环境中，一个开发经理在注视她的团队。她既不把团队看做完成工作的机器；也不将她的角色看做是将上层管理人员提出的要求与问题传递到团队的导管。实际上，她很好地照顾了团队与公司的双方利益。
信任似乎是一个抽象概念。下面的例子有助于说明高度信任与低信任度针对不同情形的表现。
相信自己是被信任的团队员工就会以值得信赖的方式行动；在你如何对待你的团队这个问题上比较灵活的话将有助于营造高信任度环境。用你期望的老板对待你的方式来对待你的团队。如同关注团队成功一样去关注个体的成功。开发人员不仅仅是雇用的员工，工作之外还有事业与生活。如果你用你公平正直的方式和他们相处，通常他们也会反过来以公正的方式对待你。
当团队成员遇到问题或陷入生活困境之中，且这些问题导致她难以用正常的方式来工作时，你就可以展示灵活性的一面。这种状况的灵活度意味着允许她在家工作一段时间或允许她休假。灵活性也可以意味着短期内调整一个人的工作时间或将工作日调整到周末。
你也可以在工作分配方面，根据某人的要求做相应调整而向其倾斜来显示你的灵活性。每个开发人员都会专注于自己感兴趣的特定任务，这不仅可提升团队成员的工作积极性，而且提供了宝贵的交叉培训，这一交叉培训在个人重复性地专注于同一领域时是不可能发生的。
灵活性并不意味着对所有团队成员无论其是否有问题都提供相同的解决方案。例如，一个员工由于家庭问题需要在家工作一周，其他成员就不能也在家工作。当一个员工远程工作或工作时间不同于团队其他人，就要把原委告诉你的团队，帮助他们理解你的决定。当然，在某些情况下，你也应当允许被照顾的员工留有一些含糊细节，因为把个人隐私告诉其他人是不合适的。
一个经理的灵活性影响着其他核心管理领域。当员工经历难于正常完成工作的情形时，他更信任做事有灵活性的经理。
一些员工可能会利用你处事灵活的特点，但偶尔被员工利用总要比事事僵化要好很多。尽管少数个别人谎称了他们的处境，但大多数人还是诚实的。
你的团队成员将感谢你为他们的成功而付出的诚挚关怀。你可以用言语和行动来体现你的关心，但最终要体现在行动上。如果你的员工相信你是真诚的和可信赖的，他们将更愿意根据你的指示用新的方法来解决问题而不是处处抵制。
诚挚不是管理时尚
我的经理公开表示我们目前所作的工作并不一定是我们兴趣所在。她鼓励人们去发现自己的兴趣即使这可能导致他们最终离开团队。即使公司不再填补空缺时她也还在坚持。她坚持不懈地把我们个人兴趣放在第一位而且全心全意地帮助员工解决所有问题。我们始终愿意跟她一起干。
——高级技术作家
为什么无人可信
管理团队举行会议宣布裁员和削减预算。CEO指出在营业额回升以前我们要被迫冻结招聘以及在花费上要精打细算。一周之后，所有的经理通过公司收到了奔驰租赁服务。在下一次会议问及此事时，CEO解释说由于高层执行团队先前拥有“车辆补贴”，经财务人员确认这项支出不能免税。所以管理人员用租车代替，而这正好发生在削减预算之后。当问及为何没有砍掉这笔费用时，他的答复是这是激励政策的需要，以用于留住高层管理天才。
——硬件经理
如果你的行为表明你缺乏诚意，那么无论你用多么认真的口吻去跟人们谈话，你都不会被信任，而且作为经理不仅你的指令会缺乏效力，还可能导致团队成员对你的伤害。你的团队不再会为公司而尽全力。例如，考虑一个削减预算而无盈利公司的例子。在经理要求他的团队精打细算节省成本之后，他在自己的办公桌上配置了一台新计算机，尽管他目前的计算机还很新，这个经理将失去员工的尊重并毁了自己的信誉。
信赖的同时也就建立了信任。如果一个员工信赖一位经理，她期望那些信息不要被其他人分享或被不恰当地利用。除非一个信赖的员工严重违反了道德规范、触犯了法律或使公司陷入困境，你就不能分享这些信息或利用它背叛这个人。通过鼓励人们信赖你的环境，将有助于解决问题而不是放任自流。
例如，一个员工告诉你她想调换到一个不同类型的项目里去。她谈到了其他公司的潜在就业机会。听到这个消息，一些经理可能会立即开掉这个员工或安排她做一些不重要的任务——因为她随时都可能走人。无论如何，由于这个员工已自愿透露了这个消息，这显示出她很信任你，并且，实际上她并非真的想走——她可能只是想给你一个调配工作的机会。如果她决定离开公司，出于对你的信任和尊重，她会给你一些时间做交接。
团队中的每个人必须受到你、其他开发人员和同事的尊重。缺乏尊重可能会公开化的方式展现出来。例如，会有人当着他人的面或在他人背后诋毁另外一个人。缺乏尊重也可能以阴险的方式体现，像某人通过贬低其他人的资历、技能或其他能力来达到诋毁他人的目的。
如果你团队中的一个成员诋毁了另外一个人，把诽谤的人拉到一边跟他谈话。不要等待状况“自我愈合”。根据问题的程度，你可以让人力资源管理人员参与进来。
通过让团队专注于解决问题而不是指责别人的问题来构建相互尊重的氛围。鼓励员工独立解决问题，并只有在他们自己不情愿做或不能做到时提供帮助。
成功的开发人员总是喜欢他们的工作并期盼下一次挑战。如果你已经定义了明确的目标，就要后退几步，来让他们成功，他们将会自我导向并自我激励。被赋予权利的员工将取得成功。
相比之下，感觉到每一步都在细节管理中的员工，就会把工作看做换取报酬的合理任务。他们知道那些管理人员所要求的任务有时是无效的或无用的，但他们相信他们无力改变现状。管理人员把他们看做清理完管道就回家的管道工。
给你的团队成员授权时，要确认他们理解了开发目标以及任务边界。边界要确定到合理的限度，但不是神圣得如印度圣牛般不能讨论与改变。在赋予清晰的边界和适度的灵活性前提下选择一个解决方案可以保证员工们不会感觉被管得过死。
下面就是一些边界类型的例子。
项目约束 时间表、功能、预算以及资源。
公司政策 需要管理人员批准拨一些专款。
技术边界 解决方案中合作伙伴将处理特殊的技术问题。
业务边界 为减少不断扩大的运营成本，需要采购一些软件组件，并对这些组件进行选型。
确定了清晰的边界后，让团队成员们选择他们如何一起工作并找出解决方案。把团队管得松散一些，监控进展，指导他们不断地取得成功。
成功的沟通需要你考虑讨论内容以及在开始谈话以前怎样去说。你所做的沟通应该针对每一种情形做相应调整：要知道在一个环境中奏效的事情未必能在另外一种情形中起作用。
与你的团队沟通时，要计划涵盖项目工作与人员方面的话题。项目工作要包括增加收入、降低项目风险、提升生产率的策略等开发涉及的方面。人员方面的话题应包括指导、培训、矫正错误、答复问题、化解忧虑、讨论长期问题和新观念、工作上所需的帮助以及职业规划帮助等。
通常，管理人员只侧重项目工作，针对当前那些推动公司短期成功的实际问题。然而，沟通时不能不涉及其他可能会导致降低生产效率、增加人员流动、质量问题、失去机会以及降低积极性等问题。至少要花1/5以上的沟通时间跳出当前项目来谈问题。要考虑到项目相关问题与员工个人相关问题间沟通方法的不同；每一种沟通方式都需要相对应的场合以确保沟通能正确解决相关问题。下面的章节讨论了与你的团队沟通的方法，包括一对一、项目沟通、团队会议以及非正式谈话。
一周一次与个别开发人员举行一对一例会给经理们提供了最好的机会来讨论大部分人员问题。（相对而言，团队建设则需要通过团队会议来发展员工间友好关系并增强相互配合。）如果你的团队多于6人，鉴于时间关系，你可以隔周搞一次一对一例会。
一对一例会提供了建立信任感及倾听个人观点的机会。让员工来引导最初的讨论。交谈初始避免讨论当前任务及所面对的问题。有时，开发人员并不知道如何开头，你可以通过询问如下问题作为开始。
一对一的会议非常适合讨论问题、提供建议、商定问题的解决方案以及分配任务或要求针对某一问题提供解决方案。任务分工要明确，但是要避免对解决方案阐述得过于详细。相反，应该像这样成功地达成一致意见：给员工解决问题的授权，并提供建议。总的来说，不要立即将解决问题的任务分给提出问题的人。如果你习惯这样做，你的员工将不会再提问题来引起你的注意。
不去倾听
在我职业生涯的早期，我的老板是一个不愿意倾听的人。当我带着问题找他想知道下一步如何处理时，他会打断讨论并开始给我下指示。他总是在我说清楚我能解决的问题之前发布命令。我后来就不再跟他讨论问题了。
——软件经理
如果你想利用一对一会议推进项目进程，就要等到把别的话题讨论完再进行项目状态讨论。如果你开始讨论项目情况，将会耗费你全部的会议时间而其他问题不再会引起你的注意。
你如何举办项目沟通取决于项目规模以及发布周期。项目发布周期较短时，每日站立例会——所有参会者站着开15～20分钟会议——可能比较合适。经理每天同一时间安排会议，要求参会者就前一天的进展、今天的计划以及需要的紧急求助做简短陈述。站着开会不是为了解决问题或讨论话题。相反，任何发现的问题可以落实到具体人员去解决跟踪。
对于发布周期较长的项目，每周一次的项目状态例会，同时结合走到同事的办公桌前与他们交流讨论的方式，可能比较有用。这个周例会通常30分钟～1小时。项目状态以及日程安排会议通常要包含一些细节讨论，除此之外还应包括下几周的计划。也应包括团队发现的一些风险以及项目经理指派一些人共同来应对并减缓那些风险。
你也可以凭借企业内网/维基（intranet/wiki）发布通告、电子邮件、白板通知或正式评审会等方式与你的团队进行项目沟通。一些项目成员不是总会知道整体项目状态或最近的项目或时间表变化。不与团队沟通整体状态可能导致混乱，而清楚地传达这一信息不仅可提升工作积极性还可以提高项目成功的可能性。如果你为你的团队提供正式的项目进展信息，他们会更愿意在早期指出问题和差异，而且他们也愿意把他们的进展状态报告给你。
与团队进行进展状态沟通时，要根据工作量的大小规范报告的内容和频率。项目进展状态描述应该包括近期已完成的工作、下一阶段要解决的问题、产品已修改的功能、截止到今天的完成状态、遇到的问题以及当前存在的风险。
按时完成项目依赖于准确的进展状态信息，这些状态信息中应包括为项目中途更正留有的时间。
定期安排项目会议将增强团队凝聚力并提升团队业绩。团队会议可根据团队的大小每周或每两周举行一次。会议可办成论坛形式用以讨论总体问题或为新流程和政策提供培训机会。团队会议也可以允许团队成员们讨论相关内容或提出问题。
会议不应该是即兴活动，不管怎样，你应该事先准备一个议事日程或主题列表。在你桌面上打开一个文件并保持打开状态，根据大家提到的内容随时增加信息要点条目；这个文件将是下一次会议议事日程的基础。一个确定的议事日程将有助于会议短小并且避免漫无边际的讨论。事先分发议事日程将使会议更有效率。
过长的会议会消耗精力并影响你们的成本底线，所以要尽可能把会议开得短小。长时间的会议也是代价高昂的——如一个12个人的团队耗时2小时的会议等同于3个工程人日（24小时）。
要允许工程师们说出对诸如政策以及高层管理人员决策等问题的忧虑。跟踪这些问题并且每周和团队一起对它们进行评审，即使你们还没有答案。要确认提供了相关问题的进展状态并进行相应的补充，这些问题中既包括先前会议提出的那些公开议题，也要包含正致力于关闭的问题。
有时候，一个有不满情绪的工程师也可能利用团队会议去抱怨诉苦。如果这个工程师跨越了从建设性建议到破坏性抱怨的底线，那么就简短地打断谈话并让他单独和你会面一起讨论他的困惑。
规范的开发小组会议不适合进行细节技术讨论。建立单独的技术会议机制，这样可以把重点放在特定的话题，并使得大多数会议开得比较随意，以便人们不需要都出席并随时可以退出。否则，那些与特定技术主题不相关的工程师们就要花费时间自始至终地来听取对他们没有意义的讨论。
在某些时候，团队成员间会产生分歧。作为他们的经理，你应该鼓励他们直接化解分歧，而不是让分歧妨碍合作。典型的分歧通常包括：技术选型、公共资源利用或者不顾全他人的行为。通过直接或折中讨论的方式团队成员通常可以解决技术和资源的分歧，但是不顾全他人的行为需要采取不同的方法。
同事间的问题一旦形成就无法继续共事。如果一个人在生另外一个人的气，劝住受害的一方同时要求另外的人到会议室讨论问题以便于找到解决办法。如果他们不能化解分歧，你可以安排一个相关人员共同参加的会谈来讨论问题。无论怎样，如果冲突中涉及了不道德的行为，第一时间介入最有助于工作：把个别人拉到一边并且以解决问题为目标开始讨论详细情况。
有时候，是你团队的成员与其他团体的人发生冲突。这些冲突常常涉及未及时交付，但核心问题通常是欠缺沟通。要鼓励每个人把问题先谈出来。如果他们不能解决问题或过于乐观就要提供适当的帮助和指导。
协助处理复杂的冲突时，首先要与冲突涉及的每个人谈话以了解问题双方的看法。在有限的时间内改变局势。适当召集一个由当事人和他们经理参加的检讨会。不带主观臆断地分析导致发生冲突的真正原因。要求各方考虑下一次类似事件发生时他们可以用怎样不同的方式来改善局面。如果需要，加上你的建议。
行动起来化解冲突
一个项目经理和她的老板告诉我他们和我的一个工程师有些不愉快。这个项目由于要进行午夜网上直播，需要在下午5点以后上班。经理告诉我那位工程师应该在工作结束后电话通知。那位工程师并没有打电话，所以项目经理在午夜前与另外一个完成了工作的工程师通了电话。
实际情况是项目经理给工程师留了一个带有个人电话号码的便条，以便于工作就绪时通电话。遗憾的是，工程师把号码丢了。于是，在工作完成后发了一封邮件。项目经理并没有查看邮件并认为工程师忘了。
通过对整个事件经过细节进行了解，我安排了一个会议，邀请相关人员和经理参加。我介绍了事件经过并描述了相关失误。我们讨论了将来在团体组织中如何避免类似问题的发生：以后再有下班后的工作，项目经理要写一个单页纸的计划。计划中要列出谁做什么，完成相关步骤后如何沟通以及参与者的电话号码。如果将来再出现失误，人们同意当晚电话通知经理。
会后，参会者表示他们对结果感到满意。
——网站工程经理
不要寄希望冲突会自我消融，虽然有时会这样。相反，要留意冲突，鼓励人们直接去化解它们，必要时要直接干涉。另外，不要去教训一个愿意接受调解并受到伤害的工程师，而是要在解决冲突的过程中指导他。
企业主办培训为员工未来发展进行投资表现出了对员工的关心；大多数工程师会通过提升对公司的忠诚作为回报。通过培训，当一个工程师学会了新的科技知识、自我管理的方法以及养成好的工作习惯时，自然就提高了她的绩效水平。
总的来说，工程师们的职业生涯基于技术知识并且会积极响应技术培训。技术发展得很快，以至于许多今天在细节利用上还很生疏的新技术几年以后就会被废弃。所以，大多数工程师总是要去掌握最先进的技术知识，这就使得培训成为工作生活中一个重要方面。然而，技术培训只是让工程师们短期受益，常用的工作技能培训可以在他们的职业生涯中起到深远而积极的影响。例如，学习时间管理技能将使得一个工程师更有效率而不在于他用什么技术。大多数工程师将受益于多种类型的培训，就像如下所列。
时间管理 授权
项目管理 管理基础知识
作报告 化解冲突
会议管理 员工激励
系统分析 教练指导
谈判 面试
市场基础知识 项目预算管理
投资回报基础知识 客户沟通
流程改造 了解情商
需求定义 了解个性
质量改进
不幸的是，在小公司培训往往受限于预算约束。由于培训是用短期成本换取长期效益，当预算吃紧时培训费用就很难支出。此外，许多高级经理几乎看不到开发工程师的培训价值。这就意味着当CEO收紧钱袋时，培训预算往往第一个被砍掉。
当预算吃紧时，要扛住压力坚持培训。可以考虑如下所述的办法举办形式多样的培训。
不幸的是，管理人员常常仅考虑短期培训成本，而忽视了培训带来的长期利益。砍掉即使很少的培训对小型公司和成长型公司来说都是一个战略上的失误。培训可增强员工的稳定性，提高生产效率，而小公司是靠信赖员工和低流失率来取胜的。
持续培训的态度
在公司能争取到培训经费时，我先着重制定一个培训课程清单然后让开发团队挑出最感兴趣的课程。我请了一家普通的培训公司并且接受了很棒的有关时间管理、组织会议以及项目管理方面的培训。
接下来的一年，预算吃紧，于是执行团队销掉了培训费用。不管怎样，培训的需要并没有消失。我采购了有关培训主题的书籍给团队阅读。我再次品读了图书并制作了大纲，将话题组织到流程里。经理们读完这些书后，针对每一个话题，我举办了2小时的培训会议，包括按照我事先准备的大纲进行的一个报告以及来回的讨论。
作为经理，我发现培训使我受益匪浅。
这些课程促使我评审资料并且更新相关话题的知识。
——产品开发总监
个别指导是提升团队绩效最直接和使人满意的方法之一。指导得好可以促使人们向着自我完善的方向发展，这对企业同样有益。
成功的指导需要教练了解一个人的目标。这里有一些在指导开发团队成员时需要问及的好问题。
一些人发现他们难以表述自己的职业目标。因此，开发工程师可能通过寻找新的工作来促进职业发展而不是向当前的雇主寻求更多的机会。当一个工程师被另外一家公司聘用时，说服她留下来是很困难的。最好通过指导他们让他们身心愉快并尽可能地分配他们想做的工作。
进行对话，倾听需求
在我职业生涯的早期，一个优秀的工程师由于想在技术上有别的发展离开了我所在的公司。如果我事先知道，我会安排她做一些如她所愿具有挑战性的工作。
她做出的假设是基于她当前分配的工作是她所能得到的一切，并且即使她有不同的要求也不会有所改变。她接受了另外一家公司的聘用。虽然我告诉她我可以调换她的工作，但她不愿意食言。如果我事先能通过所有的迹象知道一些情况并调换她的工作，也许她会留下来。
——工程总监
有效的指导需要一个经理的时间与倾听能力。指导应该是每周一对一会议的重要组成部分。你可以在鼓励他们发展的同时用非强制的方法逐个指导他们提升工作能力。
指导不是简单地喊口号——而是通过一些方式来矫正他们，这些方式包括：怎样让他们最好，为那些需要提高的人提供额外的培训和实践，倾听他们的忧虑并决定如何帮助他们分忧解愁。另外，当人们用错误的方式实施任务时，指导还意味着把他们拉到一边帮他们改正过来。
开发团队的激励方法不同于其他团队——工程师们基本上对鼓舞士气的口号、情感倾诉或比赛之类的事情没有好感。每个开发工程师的激励方法都是不同的，在你问及他们的时候，他们会告诉你他们需要什么。这里有一些针对工程师们的常用激励方法。
通过变化去激励
我团队中的一个工程师由于分配的工作而不愉快。他能力有限。他喜欢争辩并常常不能按时交付工作。他要求调到其他技术部门发展。当我的老板通知我要他走人时，我尝试交给他一些比较擅长的技术工作。几个月后，他的工作质量与交付时间有了显著的提高。他对自身的能力提升以及态度转变感到非常激动。我冒险给了他一个向往的机会看来得到了回报。
——工程经理
工程师，像大多数工人一样，通常在享受他们的工作时最尽力。通过增加一些压力实现合理的目标将增强他们总体的成就。如果一个工程师参与了项目内容与交付的实施，她/他将备受鼓舞并为自己的付出而喜悦。
如果工程师们受到鼓舞并喜欢他们的工作，许多人会愿意付出额外的努力。你可以确定他们最喜欢什么工作并用切实可行的目标给他们创造分配机会来达到鼓励他们的目的。听取并记下对你的团队来说最感兴趣的事情。确保团队已经拥有合适的工具来完成工作。然后去关注他们成功。
相反，通过过度加班推动人们去完成工作将极度降低团队的积极性和士气并导致人们找寻新的工作。工程师们，像每个人一样，需要在生活与工作间保持平衡。如果你期待雇员们放弃平衡的生活，将无法构建高度信任的环境和提高员工的忠诚度。
最后，要对取得的成绩予以公开表扬。你对一个人工作的直接赞赏将增强她/他前进的动力。你可以通过直接与这个人谈话进行表扬。或者，你也可以通过个性化奖励来显示你的赏识。公司与公司之间在奖励的惯例上差别很大。如果你的公司还没有奖赏的惯例，不妨去开一个头。例如，你可以支出一笔预算为庆祝成功分发小的奖励——如：请大家按摩理疗、批准额外的休假、颁发荣誉勋章、发奖金或涨工资、发礼品卡以及咖啡卡等。
每一位经理最终都会遇到一个行为不当或难于合作的员工——一个“问题员工”。他也许是你从上任经理那里接管的这个人，也可能是部门重组过来的，也许是你录用的。即使是小公司无法承担无力承担正常工作的员工，你也应付出真诚的努力来改善员工有问题的行为。
由于有很多重要的工作要做，你也许会试图推迟处理问题员工。然而，拖延只会赋予更多的时间来让问题扩大并影响其他员工。相反，只要表现欠佳的苗头出现，你就应该处理员工的问题。
两类问题比较常见：员工能力较差，员工用他们恶劣的态度扰乱团队正常工作。能力差的员工无法按时交付工作或不能准确表达出他的工作量。一个态度恶劣的员工会比较消极或比较强硬地与其他员工配合或持续对公司进行诽谤。这个人就像酸一样，最终会腐蚀团队的凝聚力以及你管理团队的能力。
将你注意到的情况与这个员工谈话作为矫正引导的开始并试图确定问题的根源。很多因素体现在员工的行为上，包括如下几个方面：员工可能需要附加培训但不敢去申请；员工可能有短期的个人问题且需要灵活的时间来解决；员工可能需要一些如何提高工作效率的指导；或者员工可能因为他所分配的工作而不愉快。
根据问题，你可以直接给员工提供指导。无论怎样，如果员工坚持认为自己不存在问题或其行为表现出的问题也不够充分，这个员工可能不会响应你的指导。这种情况下，你就更需要迅速地制定一个正式的绩效改进计划。
指导一个员工时，要从改进他工作的具体行动上达成一致作为开始，这会提供改进的目标和推动力。要监控进展并提供定期进展报告。要保持积极的教导而不是惩罚，在员工表现好的方面予以鼓励要远胜于单单指出他的错误。如果站在你的观点来重点描述他的工作好坏对公司发展的影响，他就会更愿意把指导当做一次绝好的发展机遇。
如果员工的表现在接下来的一个月没有改善或你注意到你所付出的改进努力并没有奏效，你应当考虑诸如制定正式改进方案在内的其他措施。要根据开发团队的管理状况来选择正式改进计划的时机。给员工以“通牒”的方式来迫使他矫正自己不当的行为。虽然一些经理会在不制定改进计划的前提下直接开除该员工，但对你来说，应该给他一次公平的机会以改正其不当的行为并保障贵公司免于法律纠纷。
行动执行计划的要求是多样的。通过与贵公司人力资源机构交流以了解这方面的要求。一个执行改进计划应该针对特定的问题，阐明问题所在并指出改观后的样子，并说明失败的后果。一般而言，利用不超过60天的时间作为计划的审核周期。
不要以为行动执行计划会自动导致解雇。虽然一些员工没有改正缺陷或自己离开了公司，但还会有人付出真诚的努力去改变自己并取得成功。用期待员工成功的心态对待他们。
员工评价必须是对全年持续努力的全面总结——不要等到正式的员工考评再来体现对成绩的表彰或讨论发现的问题。实际上，一个年度考评不适宜拿具体问题说事。等到年度考评再提供员工的负面反馈是不明智的，从一个经理的角度常用的管理做法是不到万不得已，不会针对个人谈及问题；这会滋生低度信任情绪。虽然年度考评通常要直面问题，但如果在年度考评中首次听到自身问题评价会让大多数员工会感到措手不及。年度考评应该比较平和。
公司应该以多种方式进行年度考评。许多小公司要么不提供考评，要么同一时间对每一个员工进行考评，还有的公司基于入职日期进行年度考评。从公司长远来看，考评应本着公司需要出发由人力资源驱动——也许要将考评形成文件以避免潜在的法律纠纷，尤其是一个人的合同到期，或者某员工因为工作业绩良好而对其进行奖赏，以使他留下来继续效力时。
不要等到考评时间再来收集信息或给团队成员提供反馈。而应该在全年中的一个个会议中提供反馈。你应该通过随时随地将员工表现记录于一个文件中以收集全年数据，而不是到了年底再来回忆这些信息。记录在手有助于你早日完成考核并使得对员工的评价更公平公正。
一个流行的做法叫做360°考评。在这种情况下，不论人力资源还是经理收集到的考评信息都将由和员工一起工作的人员来审核。其他团队的人或同事也常常有助于洞察员工的表现。作为360°考评的一部分，你也应该要求被考核人进行自我评价。自我评价为员工提供了列出本年度成绩列表以及判定自身表现的绝好机会。那些自我评价可让你唤起员工数月来承担的任务。
考评最好的形式是形成一个准确的考核评语，因为它涵盖了绩效的多个方面。写考核评语，要从收集到的信息开始。要求员工在你们会谈之前完成并提交自我评价。如果公司要求员工做自我评价，你要首先阅读它。如果公司不做要求，你也可以要求他们做自我评价。写考核评语要包含员工所取得的成绩以及需要提高的方面。要保持语言简洁文字短小精悍。完成后，审核每一句话，确保它与你要给员工传达的主体思想相一致。
考评总体格式要包括结果、成绩、改善提高以及总结。考评的开始，详细描述工程师所承担的项目。之前积累的一年来的记录与文件将使得这个任务比较容易完成。针对每一个项目提供简短的书面讨论，并描述员工的表现和主要功绩。接下来，描述优势和劣势方面。建议可以帮助他提高绩效的技能。建议员工需要通过更多培训来受益的一些方面。你也可以建议下一年度的目标。最后，就员工总体表现写一个总结。也许要求你按标准格式来填写考评信息。无论怎样，这不妨碍你在标准格式的后面附加上你的评语。
提交考评时，讨论欲考评的每一个不同方面。避免会议一开始员工就直接写考评意见，因为他会快速通读一遍而并未理解你想表达的真正意思。因而，要阐明要点并且通过提出问题以确定员工同意或不同意你的评价。给员工一些时间鼓励他提问题。只要合理，就要促使考评会向着积极向上的方向讨论。
会议的结尾，向员工提供一份写好的考评副本。你也可以考虑考评之后第二天再安排一个会议以审核考评结论是否恰当。这会给员工一个机会来考虑考评意见并在第二天把想法表达出来。
考评对员工的职业发展与收入有着很重要的影响。按规范的时间及时提交考评是一种对员工尊重的表现。一份滞后的考评可能会使被要求等待的员工情绪低落。提供滞后的考评再加上员工的焦虑可能会让他确信自己既不重要也不受尊重。
如果考评与年薪增长挂钩，那么焦虑的程度通常会更大。一些公司还存在如果经理提交考评滞后将不予恢复涨薪的可恶惯例。在这些公司中，一个经理的延迟会导致公司失去收益，以至于考评对员工来说不再是积极的感受，而转变成为让他在公司中增长玩世不恭以及摧毁其信任感的消极感受。
延迟的考评也会引起其他问题。开发工程师们会让其他人知道他们对公司和管理人员的看法。他们可能会认为公司出于节省资金的考虑延后了考评，甚至可能会推测出公司陷入财务危机。
那经理们为何会迟交考评？对于大多数经理来说，写考评报告是一个痛苦的过程，是一项通过无限期拖延尽量回避的任务，他们在考评的过程中，写不出任何内容，也提不出任何建议。许多经理忽视了通过考评来促进员工不断进步的重要性。
写得不好的考核评语对员工也会产生消极影响。这样的考评只是在人力资源授权的几个不同类别评审框架之上仅仅列出几个要点。与写得不好的考评相比更糟的是经理根本没有写任何评价内容。如果人力资源除了一个考评会议不做其他要求，考评可能演变成一个握手式的年度考评，在这种考评中，经理除了握手和列举一些不断增长的数字就是给一些口头的评价。
握手式年度考评
在我的职业生涯中，我经历了好几次握手式年度考评。我常常发现他们由于对未来发展提不出任何指导性建议而令人失望。他们也同样暗示我的经理不可能花时间来考虑我是如何真抓实干的。评语都是很积极的，所以我也很愿意做记录。记录对我非常有用，特别是当我换了新的经理以后。
我所喜欢的考评是通过积极乐观的讨论和建议来提高我所从事的工作。
——工程师
人力资源部门可以从几个方面使得评语写得不好的经理们把事情简单化。首先，考评的表格可以利用分级复选框，以使经理可以针对每个方面直接给出分值。在一些公司，表格中数值的总和或平均值决定了员工的级别。这种做法错误地假定了所有的评估项目具有相等的价值且有利于对员工做出评价。
一些表格限制了包括员工关键功能在内的关键信息填写。当你被局限于在两行之内写出一个员工建议是非常困难的。一个合理的考评需要完整的描述。
在考评的过程中，常常丢掉的环节是最低标准的质量审核或反馈。如果一个经理仅仅是生成了带有复选框和写下“做得不错”的考评，那标准实在是太低了。一个正式的考评可以很容易生成，但它不仅仅服务于公司和个人。
考评应该是一系列持续的反馈和指导。年度考评根据为期一年的指导系统输出资料来写就比较容易。员工们耗费了生命中整整一年的时间来为公司开发软件。而在经理一方将员工的工作将浓缩在短短的“做得不错”和复选列表是：
不可接受 □可接受
因而，要利用考评来加强你全年的指导工作。
以下是一些与本章主题相关的附加读物。
1001 Ways to Reward Employees, by Bob Nelson (Workman Publishing Company, 2005)
Becoming a Coaching Leader: The Proven Strategy for Building Your Own Team of Champions, by Daniel S. Harkavy (Thomas Nelson, 2007)
Love’em or Lose’em, by Beverley Kaye and Sharon Jordan-Evans (Berrett-Koehler Publishing, 1999)
Managing Software Maniacs: Finding, Managing, and Rewarding a Winning Development Team, by Ken Whitaker (Wiley, 1994)
Managing Technical People: Innovation, Teamwork, and the Software Process, by Watts S. Humphrey (Addison-Wesley Professional, 1996)
Peopleware: Productive Projects and Teams, by Tom DeMarco and Timothy Lister (Dorsett House Publishing Company, 1999)
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, by Tom DeMarco (Broadway, 2002)
What Every Manager Should Know About Training: An Insider’s Guide to Getting Your Money’s Worth from Training, by Robert F. Mager (CEP Press, 1999)
