作者：[美]Louis Testa 著
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
管好团队做对事——软件企业成长手册试读：
前言
在许多成长中的小型公司中，项目经理们在执行CEO战略意图的同时，往往还得处在不得不与技术团队和其他高级经理打交道的位置。通常情况下，即使当工作的非技术因素已经最大程度地影响公司的成败时，开发经理们依旧仅仅关注于技术。伴随着公司的成长，曾经看上去很小的问题也在不断扩散，最终引发成为主要灾难。我写本书的目的，就是为那些新上任的开发经理们提供建议，告诉他们如何成功地应对这些挑战。
小公司中的开发经理在很多方面都不同于在一个稳定的大公司中的同等角色。例如，小公司的开发经理通常不仅要和开发人员一起支撑亟待成熟的产品，还必须与被公司成长过程中面临的挑战所吸引的技术大牛共事。但最重要的是，小公司的开发经理必须对员工、产品、过程、规划、技术以及客户等诸多因素给予广泛的关注。
相对而言，大公司通常支持多种现有产品，他们的过程定义通常比较清楚而且相对稳定。大公司的政策通常限制了开发经理所用的工具、技术及实现方式。相对于小公司的同等角色，大公司的开发经理工作范围更明确而狭窄。
本书作为一本实践指南，为那些经历过初始生存阶段且正在试图进一步发展壮大的小公司中的开发经理们提供了实用的指导原则。其目的是帮助管理者预见问题并在其变得棘手前及时进行处理。这里描述的技能主要适用于销售产品级软件或提供软件服务的小公司，并不针对软件咨询业务。本书不仅提供了总体建议，也提供了具体解决方法以及详细的模板和电子表格，这些内容都非常有助于开发经理们将基本概念应用于具体实践。
由于涉及范围较广，本书的书写方式采用了指令式的风格（prescriptive style）而不是议论型argumentative风格——也就是说，不建议采用广泛的论据来说明这些良好的工作技能如何到位。这方面的资料将大大扩大本书的范围，但同时也会降低它的可读性。
为方便起见，笔者使用“开发经理”和“开发管理人员”贯穿全书，这些术语用于指代高层软件/工程管理人员——不论是首席技术官（CTO）、工程副总裁、工程总监，还是高级工程经理这样特定的工作职位。这个人既要从事软件工程师的管理，还要担负质量保证、文档说明以及项目管理等团队的管理。虽然本书的目标读者是开发总监，不过非技术类管理人员也同样会受益于本书所描述的问题和解决方案。本书的章节结构及相关说明
为便于参考，本书分为如下主要部分。● 开发团队。● 产品和技术。● 工程之外。● 为项目、过程及质量管理制订工作流程。● 规划未来。
虽然本书是按顺序逐个主题逐层深入的，但读者还是可以跳过一些章节直奔感兴趣的主题。公司发展阶段
公司从启动到发展成熟是分阶段成长的。本书将涉及其中的一个或多个阶段。表1是根据公司的规模和产品的成熟度对发展阶段所做的定义。表1 公司启动发展的阶段阶段公司规模（员工数量）客户启动少于120～2个，没有主要客户立足12～403～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致谢
正是因为付出了大量的心血，才使得我的第一本书如此有趣。然而，无论我个人付出多大的努力，如果没有包括家人和朋友在内的众人给予的帮助与建议，本书将不值一读。
没有我妻子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-1中以调侃的口吻比对了面试说词与现实之间的差异。表1-1 面试与现实的对比面 试 说 词现 实 情 况我们有一些很小的该产品是一场灾难。只要你上了贼船，就会为所有的错误承质量问题担一切指责我们需要提升我们没有产品可以如期交付，由于市场及其他高层不能下最后的的交付承诺决心，公司在整个开发过程中需要不断修改新产品功能。即使这样，所有的人都希望按期交付我们有一支伟大的团队成员正在大厅里尖叫着讨论，至少有一位工程师由于不工程师团队，只是够格要被开掉需要一些指导我们是一个有紧迫你那个“懒惰的”的开发团队正期待着混过工作午餐、每一感的公司，有干劲个夜晚以及大多数周末——除非你干掉他们十足的员工
在你加入公司走上令人生畏之路时，你需要充分利用现状。1.1.1 立即着手处理
在你任开发经理的一开始的日子里，急迫的问题需要立即引起你的注意。一些问题自从上任经理离职之日就开始堆积在那了，在你桌上堆放着延期数月的决策方案。在沼泽中跋涉是对处理这些积压工作最形象的比喻。
在专注于这些问题时，你可能会感受到压力，这会危及你长期的成功。只关注急迫的问题，会让你失去从公司、产品、同事以及你的团队中学习成长的机会，所以要做一次深呼吸看一看更广阔的天地。
如果在解决悬而未决的问题与处理日常危机之间分割你的时间，你会最终减少一些重复出现的问题，这样会提升团队的效率。每天花一部分时间从公司获得一些情况要比全力以赴处理积压问题更有效率。此外，你最好去了解一下团队所面对的重大问题，这将会促使你较早找寻出解决之道。许多问题还会在日常工作中冒出来并迫使你持续转移注意力。可以通过建立一个根据自身时间来处理多方面要求的体系来避免这个混乱的过程。1．维护一个问题和处理成果的列表
从一开始养成细致的任务管理和记录保存好习惯将会对工作非常有帮助。维护一份清单，清单中要包含有关你的决策、处理过程以及一些重大问题，特别是那些对你较为迫切的问题。根据问题解决完成时间排出列表的优先级。管理好这份列表不仅有助于你减缓由于遗漏问题而引起的焦虑，将列表组合还可以让你和老板一起对你所排的优先级和问题处理进展进行评审。
逐日审核你的任务列表锁定优先问题。对于大的任务，则要锁定那些短时间内能够完成的子任务。每周要把重点放在高优先级的大任务上，否则，短期紧迫的要求依旧会导致进一步的延期。如果你日常处理这些问题的时间有限，则要避免时间透支并妨碍你的工作进展。
当你完成了一个解决问题的任务的时候，记得标记上日期并将任务存档。这个档案文件将在日后你被问起如何处理这些问题细节时有所帮助。验收成果同样有助于提高自身工作的积极性。2．尽可能去授权
在适当的时候，对一些紧迫的问题进行职责分配，不要试图亲力亲为地解决所有问题。适当的任务分配可以使你和你的团队更富有成效，并且通过处理新任务也可以提升整个团队成员的士气。任务分配时，要确认受托者清楚了任务的内容、与其他相关工作的优先次序以及进展状态检查的时间点和完成日期。同样也要确认项目成员知道可以从你这里得到更多的信息。
如果不适合将整个任务分配出去，你可以将一部分任务分配给团队成员。例如，你可以把信息收集分给其他人而把审核留给自己。或者你也可以让一个团队成员提供一个问题的背景分析并指导他去分析数据。如果你能赋予团队成员承担部分重要工作的机会，你们都会受益。
当处理完棘手问题时，记得向老板通报你的进展。这有助于预防对你工作上的误解。1.1.2 经历初始培训
初始培训阶段的成功需要集中付出努力与时间。每天要留有稳定的时间用于熟悉公司的员工，学习公司的技术，了解公司的产品、市场以及运作流程。找出你最机敏且能集中精力的1～2个小时。每天提前上班，并把每天最初的时间用在培训上，然后在以后将这段时间用于处理疑难问题。
作为新任的开发经理，在你的老板给你一些灵活度来熟悉工作和企业文化时，你会拥有3～6周的“蜜月期”体验。这一时期你可能会期望加班，用这些额外的时间来熟悉工作并处理重要的问题。如果老板认识到了你额外的付出，他会为最初雇用你的决定感到满意。在你展示了自己的能力后，就可以将工作时间适当减少到适度合理的水平。
要知道你是否被特别雇用，被期待成为变革代理人或期待给一个高效的部门带来增量变化。这些期待将决定你如何把结果展示给你的团队和老板。例如，如果你认定的重大问题而公众却期望维持原状的话，你就要耗费大量的时间和精力去说服老板和团队去认识一些问题的重要性。
你解决长期问题的时间也很关键。例如，如果你等到6个月以上再讨论宏观问题，你将面临比较巨大的挑战。你可能失去了展示创新理念甚至确定问题之所在的机会，一旦你沉浸于细节，就很难认识到系统中的瑕疵。当人们更愿意从新经理那里倾听新颖的观点时，你会发现开发团队更加抗拒变革。
如果你提议实施重大变革，要向公司如实陈述其利益和成本。“兜售”你的变革可以帮助你避免树敌或面对其他人抗拒变革的行为。1.1.3 收集信息
收集公司产品、人员以及过程方面的信息有助于你制定头3～6个月的工作策略。通过与老板交流以及花时间与你的直属下级、同僚们沟通，以获取公司更广阔的前景。你的目标是了解公司的成就与全局性问题，并学会如何发展才能最好地为公司服务。从询问如下开放式问题开始，找到并分辨出问题的主要切入点。● 运作良好的业务是什么？● 你看到的主要问题是什么？● 你建议的解决方案是什么？
然后将学习成果融入到工作总结中，并寻找一个解决模式。1．创建讨论总结
当你与同事、经理以及其他员工商讨问题时要做笔记；然后把你的点评融入到带有强调符号的陈述之中，以确保思路清晰而富有条理。释义转述和总结性注释会使你的陈述短小精悍。
之后，分门别类整理总结文件。每一类都可以包含问题以及成就两个方面。在每一个问题方面之后，罗列出一个你们交流讨论的相关解决方案。这里有一个用于收集信息的推荐分类列表（当然，你的列表也可以用不同的展示方式）。
技术 质量问题
人员 内部文档
组织架构 风险
清晰的目标 客户服务
方针 市场和销售
过程 财务问题
计划 其他
问题和解决方案可以分为三类：你和你的团队可以直接解决的问题；需要通过与其他部门或其他组织中的人员合作解决的问题；你只能施加影响而不能直接解决的问题。根据你的摘要标示出每一个问题。
一个最终文件的摘录可以做成这样。
4．技术● 有利因素：我们的技术比竞争对手更快更可靠。● 有利因素：编程语言和函数库都是最新的。● 问题：系统在A-15子系统中没有冗余性，将导致“核心崩
溃”。这需要与运营部门协作。● 问题：API几乎没有错误校验。两个缺陷数据请求就可以导
致系统擦除数据库。
解决方案：我可以通过与开发人员讨论直接解决。2．把你的总结应用于工作之中
之后，为发现的问题和取得的成果设置优先级。将成功的做法与问题进行排名可以让你考虑如何保持有利因素的优势。一个简单的A、B、C优先级对最初的排序就很好，并且可以在每一级别都遵循这一体系。将老板的指示级别提高，但也不要低估其他人的反馈。最终，你必须决定解决哪些方面的问题并且如何解决它们。从最高级别的问题中制定一个行动计划。例如，估算未来3～6个月你能完成多少。一个切实可行的计划会帮助你避免一次跟踪过多的任务以至于能完成的工作越来越少。
制定计划前要确认相对于改善型工作你完全了解自己能承担的混合型项目工作。对于一个小公司，至少要花费自己10%～20%的时间和团队5%～10%的时间来解决和当前项目没有直接关系的问题。这类与项目无关的问题包括提高生产率、指导培训讨论、推进技术、规划未来、改善工作关系，以及解决人的问题。
行动计划的失败通常是由于缺少公司的支持，所以要确信在你不断的努力下能从老板那里争取到支持。你需要你的老板极力支持——至少是认可——如果你希望成功。如果你的老板否决了你的建议，你需要理解他的忧虑——或者，你依旧相信你的建议，去做更多的研究然后兜售。在你的方法获得成功以前，你的老板需要知道你在用一种合理的方式来解决企业中存在的问题。
你也应该与其他部门经理特别是市场和销售经理们沟通。他们需要理解实现他们所谓的短期目标为何要花费如此多的时间和资源。要说明你的变革能给公司带来的长期利益。由于你确定的问题并不仅仅与你的部门相关，与其他人讨论和反馈意见将增进你对问题范围的了解以及帮助你找到最好的解决方案。
将每一件费神的事情当做一个带有时间表和资源的项目。要持续促进项目改进，否则他们就会失去动力；不能提升领导力就会导致随着公司的发展壮大，生产力却更为低下。得到公司的总体概况当我加入目前公司的时候，我花时间与不同部门的十几个人去交流。我把所听到的信息整合入一个只有几页纸的总结性文档中。这个过程让我洞察到了即将发生的一切。与每个人交流是一项启发性活动，它指引我直奔最先需要解决的首要问题。—— 新任经理1.2 了解人
了解你的同事将使你的工作更富有成效并且更加有趣。相反，不去熟悉他们会导致看法片面也容易产生摩擦。幸运的是，你可以通过与人特别是你团队中的开发人员交流来增进相互了解。
询问如下问题。● 你喜欢做什么？● 你不喜欢分给你什么工作？● 你最擅长做什么？● 你需要什么帮助？● 你在哪工作过？● 你为何加盟这个公司？● 你会想怎样改变？
对这些问题的回答将会提供如何与他人共事的线索。掌握开发人员如何完成工作以及与其他人相互合作有助于进行表现评价。阅读团队过去的绩效评审可以提供一些见解，前提是前任经理写下了有用的评审意见。如果前任经理没有写下意见，你也可以得知在到任之前这个团队是如何管理的。
也要和团队之外的员工交流。与全公司的人员进行沟通不仅可以体验到企业文化还可以清楚什么方式可行以及什么方式不可行。与公司其他人建立关系所带来的好处是难以想象的——另外，了解人也可以使自己身心愉快。
第2章和第3章就如何与你的团队工作进行了详细讨论。第9章和第10章就如何与整个公司的其他人一起工作提供了建议。1.3 不愿透露信息
你可能会遇到不愿透露信息的工程师或其他人。他们通过如下方式表露出抵触情绪。● 声称太忙以至于不能回答你的问题。● 避重就轻地提供一小部分信息。● 即使你相信他们清楚的时候，依旧声称无可奉告。● 提供了大量没有上下文的低级细节信息。● 故意遗漏技术细节。
这些答复似乎关上了你要获取所需资料的大门。要克服这一点，就需要理解它们背后的真正原因。这里是一些人们不愿提供信息的常见原因。● 从利己角度出发，他不愿意别人知道的比他多。● 出于对职业安全的考虑，想把持住关键信息。● 由于缺乏了解而尴尬。● 工作很忙，看不到你的培养价值。● 总的来说不喜欢或不信任管理人员。
有礼貌地坚持请求所需要的信息往往很奏效。在任何情况下，通过解释你所感兴趣的信息来建立信任感，但要坚持让工程师及时地提供资料，要做到如下几点。● 为了有效地与工程师以及他人协同工作，你需要了解技术，知道
该用哪种技术。● 你需要在某些方面有完整的资料，而不是粗略的概况。如果工程
师以缺少时间为借口，可以与他商量承诺的时间。你也可以要求
他加班。● 如果工程师的答复不全面或未成型，请工程师就课题继续深入研
究并报告给你。这显示出你对这个人的信心以及你所要求的重要
性。● 如果这个人确实不知道答案，要她非常直接明确地告诉你。并询
问谁有可能知道答案。如果你无法从这个人这里得到资料，安排
另一个工程师帮你整理。● 告诉工程师你将做出影响他工作的一些决定，而且工程师应该知
道这些决定。
怀有敌对情绪的工程师们需要争取过来——或者，最坏的情况，把他们清除出去。行动前花时间去了解这个人以及他/她的动机。第2章和第3章将进一步阐述管理开发团队的细节。1.4 认同企业文化
企业文化涉及员工间相互配合的方式以及管理回报的表现形式。为了认同企业文化，要把经理们说的话与做的事进行观察对比。阅读公司价值观与使命感也同样有所帮助。你可以通过与同僚们讨论来确定是怎样的使命感和价值观影响着公司的发展方向；你应该明白如何利用这些资源对员工实施有效的管理以及做出正确的工作决策。建议如果你的老板在最初的工作会谈时没有讨论公司价值观的话，价值观很可能就是企业的基本信条。
小型和成长型公司需要仔细全面考虑之后再推出他们的价值观和宗旨。这些宗旨是构建企业文化的基石。管理人员必须培养员工接纳这种价值观与使命感，管理人员也应该审核那些与这些宗旨不一致的主要决策。由于小公司和成长中的公司变化较快，相对于大型和稳定的企业，价值观和使命宗旨就显得尤为重要。
在一个运作良好的公司，价值观和使命宗旨就是这个企业的定义。人们基于明确的价值观做出公司发展方向及机构职能等方面的决策。例如，对质量的关键作用认同将会导致CEO将质量管理团队在组织架构中置于突出位置并且加强质量培训。作为开发经理，要尊重公司的使命感与价值观并尽力将之融入到自己的管理风格之中。
第9章包含了企业文化的细节内容。1.5 学习技术、过程和产品
在最初工作的两个月里，要获得公司技术、过程以及产品的全貌。要掌握技术是如何利用的，产品是如何工作的，开发过程是如何运转的，以及开发团队成员是如何配合工作的。评价你所了解的内容并确定你还没有完全掌握的方面。然后通过系统地收集相关信息填补相应的空白。
要完全了解产品。除了数据流，至少还要审核用于展示主要模块的高层架构。团队中的开发人员应该可以描述这些原理并可以提供现成的总体文档。告诫在许多小公司，概述和过程文档往往是过期的或者缺乏细节性的描述。
将掌握的信息写成文档和画成图表有助于你吸收信息（像Microsoft Visio就是非常有用的画图工具）。你画的图表将融入公司的知识产权。用这种方式充实公司的知识产权会产生多方面效应：新员工将拥有一本培训手册，其他小组以及公司潜在的合作伙伴将拥有参考资料，并且，如果公司出售，知识产权将增加它的价值。
要考虑把你的图表送给开发团队获取反馈。他们可以点出问题并提供改善建议。更正和提炼过程图表通常需要几个回合。在这一过程中，团队会针对产品和实际工作过程的细节形成一致看法。此外，这种努力将会改进现有的流程。
系统性思考掌握的内容有助于避免你在培训过程中以及日后管理能力上出现的盲点。图1-1说明了用于审核的技术主题样例清单。图1-1 技术审核列表
要对公司产品形成正确的认识，就要从很多方面来收集资料。请销售或市场经理对你进行产品使用培训以使你掌握他们是如何将产品展示给客户的。
独自做产品实验促使培训细节更易于记忆。用真实的假定数据做实验——而不要使用客户或产品数据。使用安全的数据使你在实验中不必为损坏和暴露数据而担心。尝试每一个功能、每一个按钮以及每一个数据录入模块——并试图中断它们。你需要很好地了解产品以及它的局限性。
你可以在第5章和第6章发现更多的产品资料。第7章和第8章包含技术和工具，第15章包含过程方面更多的细节。1.6 了解客户
熟悉公司的客户也是最初评估的一部分。与销售和市场团队交谈来了解公司的老客户。也可以与销售人员一起确定拜访客户，并留意收听销售电话，这些方式都有助于你来认识了解你的客户。
与销售和市场团队讨论如下问题。● 客户满意度。● 客户对产品质量和功能的看法。● 客户采购关注点及价值取向。
花一些时间与关键客户一起了解他们如何使用产品。这种交流将使你洞察到客户是如何看待你的产品的。要了解产品所服务的行业。从销售和市场团队得到的信息将非常有帮助。
第12章包含了了解客户方面更多的细节内容。1.7 了解公司的业务流程
要掌握公司的业务流程，了解不同团队是如何通过一起工作来提供产品，实施技术支持，以及提供客户服务。许多公司都有对你来说非常重要而独特的总体流程去了解。把你收集到的资料画成流程图不仅可以澄清业务流程还可以创建一个方便其他人使用的参考手册。
创建一个企业总体流程将会澄清哪些团队负责软件产品或服务的哪一部分。记得要包含客户与公司之间相互配合的部分。
一个企业工作流程图也可以让一个新公司受惠：它帮助执行团队发现问题并且领会如何更好地提供新的服务和产品。工作流程图也可用做新员工的培训资料，帮助他们理解如何通过自身的努力来支撑公司的发展。团队成员将通过了解他们的工作对全局发展的贡献感受到前进的动力。
虽然工作流软件和复杂的图表方法对于捕获企业的工作流非常有用，但对小公司来说简单的图表就足够用了。附录C说明了画示意图的直接方法，包括基本例子。即使你已进入公司一段时间，你也可以发现通过勾画流程图对洞察公司如何运作以及发现有待改善提高的领域非常有价值。得到公司的总体概况我以前的公司大概提供12种不同的产品，每一种都需要不同类型的报价。我写下了全部的企业流程并详细描述了每一种产品耗费的工程成本。详细报价并决定如何对产品报价是一件大好的事情，允许我们提供更快和更精确的报价。一个图形化的企业工作流可以让经理们更易于发现流程的改善方法。我们同样也将这些材料作为新员工培训教材的一部分。——高级经理1.8 回归重点
本章为你提供了大量需要考虑的内容。这是围绕那些需要全面解决的问题进行的宏观性总结——帮你找到走出丛林的方向性清单。● 结识人 了解你公司的人，特别是其他经理、老板以及你的团队。● 处理问题 处理紧急问题，但要尽可能去分派任务。不要让紧急
的要求耽误你的学习。● 跟踪问题 保留一份问题优先级列表。并将问题按急迫型和长远
型进行分类。● 收集信息并进行总结 与至少十几个同仁进行交流，了解他们所
做的工作，运作良好的是什么，以及问题在哪。通过这些讨论做
一个总结。选取其中的一些内容加到你的长期问题列表中。● 学习 花大量的时间掌握公司的产品、客户、文化、行业、技术
以及组织架构。● 评估工作流程 画出重要的企业流程并找出改善它们的机会。
在最初工作的几个月中每周至少要回顾一次这个列表。如果你漏掉了关键领域的信息，就要考虑进行调整把重点放在这些方面。在最初的几个月里，没有最佳的单一方法或现成公式来统筹你的时间，但如果你持续在高压模式下处理一个又一个危机，找一个不被打扰的安静空间来筹划一个重点放在关键领域的计划。如果你不积极地去努力筹划，你将会继续面对这种恶劣的情形——但当你确立了方向并为之而努力的时候，工作就会变得非常有趣。第2章 管理开发团队
在一个小公司做开发经理，你会拥有在大多数大公司找不到的独特角色。无论你的职位是首席技术官、工程副总裁还是总监，你都必须成为CEO及执行团队成员与你的开发团队间联系的纽带。在一个小公司，你必须能以不同于那些大公司开发经理的方式去全力以赴。2.1 理解你的核心价值
在投身于管理一个团队之前，让我们先审视一下如何才能成为有效的管理者。问一下自己如何与你的开发团队一起工作以及如何用你的核心价值观去带动大家。你对他人的尊重，你的道德准则，你自身带队和倾听的能力，提供反馈的能力以及关注其他人的成功等因素都会影响你如何做出决策。
作为一个经理，在与你的团队一起工作时，你需要一个可随时存取工作法宝的“工具箱”。你的工具箱里应包含用于激励人员、供自己查阅和选择团队的工具，还应该有组织团队、设置工作空间、管理项目、解决冲突以及与团队沟通的方法。多种工具与方法在手，你才可以为工作选择出最好的方案。
相比之下，一个死板的经理可能只有一种工具——在上一家公司的上一份工作中所用的那一套工具。不过，俗话说的好，如果你只有一把锯，那么所有的问题都只能用锯子来锯。
下面的部分涵盖了关键的工具以及核心价值观的组成部分：信任、灵活性、诚挚、机密性、尊重以及授权。2.1.1 信任
一个充满信任的公司最具有生产力，因为员工们不会在权术斗争、指责他人缺点或守住自身位置等方面耗费精力。这些公司鼓励直接沟通——员工们通过正确的信息及他们的工作支持取得管理人员及相互间的信任。这促进了员工高昂的斗志，因为员工们把精力放在了生产而不再是小心谨慎。
鉴于在小公司工作要比在大公司工作风险大，小公司的员工必须能够相信来自高级管理人员的信息。由于小公司和成长中的公司常常缺乏可观的资源，高度信任的环境提升了成功所需的效率。
在低信任度文化公司工作的员工就会把精力浪费在查找其他人的缺点和保住自身的位置方面。员工们认为他们需要仔细核实管理层所做评价的真实性。在这样的公司，管理人员通过回报低信任的行为延续了低信任度的文化，例如政治动机、对其他人的公开口头抱怨、谣言、逼迫其他团队决策的政治攻势以及恶意中伤。低信任度文化趋向于在那些人人自危的公司中繁殖。管理往往是权威和政治。高级经理们把精力放在如何踩着别人上去。当高层管理人员缺乏针对性的积极努力时，那些通过表现低信任的行为来晋升的人则存在有短期利益。
为什么没有更多的企业建立起高度信任的环境？建立信任需要管理人员通过讨论公司价值观与核心理念来付出每一天的努力，而不仅仅是做一个年度回顾。高度信任的文化需要经理们雇用合适的人才，在公司文化中指导他们，规范他们所期待的行为。最后一个摆设我们的QA团队由6位工程师组成，我们都擅长于自己的工作。当我们的QA经理离职另谋高就的时候，副总裁指定了一个既没有QA经验也没有管理经验的经理。我们团队愿意给他一次机会。然而，过了4个月，他不仅对质量管理没有任何兴趣反而还挑拨我们的关系。最终，团队其他成员找到了其他工作而经理并没有安排人员来接替他们。我是公司雇用的最后一位QA工程师。我给经理写了一封电子邮件，要求他把精力放到QA上来。我对团队其他人员离职而没有安排人员接替深表关注。他把我开掉了，并由于我的反抗而在那一天强行把我送出大楼。即使私下交流，我都不应该信任他的公平性。我发现在我到另外一家公司做管理工作两周后这位经理也退出了。他毁了QA团队并最终离开了公司。——QA工程师
作为经理，你可以通过显示高标准的公平性、机密性、尊重、诚挚以及冲突解决方法来建立信任感。你要有效处理那些让你失去信任的团队成员。例如，如果一个团队成员向你汇报她已经完成了任务，你期待着任务圆满地完成了。如果你事后发现她没有完成任务，你就不再信任她。此人将成为你的拖累，因为你必须仔细检查她的工作以确认圆满完成。
在高度信任的环境中，一个开发经理在注视她的团队。她既不把团队看做完成工作的机器；也不将她的角色看做是将上层管理人员提出的要求与问题传递到团队的导管。实际上，她很好地照顾了团队与公司的双方利益。
信任似乎是一个抽象概念。下面的例子有助于说明高度信任与低信任度针对不同情形的表现。● 你正在参加一个行政会议，一个与会经理提到你的一个高级开发
人员未能及时交付项目。这是由于市场部在最后一分钟改变了要
求，你和开发人员随之做了一些修改。● 低度信任表现：直接在会上指出这是市场经理多次修改定义的后果，并且在未征得你准许的前提下，提升了费用。● 高度信任表现：表明你同意其结果是不可接受的。你计划审核改善未来业绩目标的项目。你邀请了市场部经理参与讨论。● 一个开发人员告诉你他的兴趣在于想拿一个硕士学位。你清楚如
果这一点兑现的话，就需要再找另外一个人加入到团队。● 低信任度表现：找一个借口开掉这个工程师，因为你知道他随时都有可能走人。● 高度信任表现：确认这个工程师是否可以在工作的同时上课学习。如果想离开公司继续接受教育，要他尽可能考虑清楚利弊。● 在业务高峰时段你的服务器却停了4分钟。你最初的分析认为可
能是问题出在运营团队，一个软件的复合缺陷阻止了系统正常的
自动恢复。你不负责管理运营团队。● 低信任度表现：立即告诉CEO有关运营团队的失误，并指出运营总监需要加强对员工的培训。● 高度信任表现：花一些时间和运营总监一起调查问题。然后，你们一起向CEO详细汇报事件经过以及避免此类事件再度发生的下一步工作计划步骤。2.1.2 灵活性
相信自己是被信任的团队员工就会以值得信赖的方式行动；在你如何对待你的团队这个问题上比较灵活的话将有助于营造高信任度环境。用你期望的老板对待你的方式来对待你的团队。如同关注团队成功一样去关注个体的成功。开发人员不仅仅是雇用的员工，工作之外还有事业与生活。如果你用你公平正直的方式和他们相处，通常他们也会反过来以公正的方式对待你。
当团队成员遇到问题或陷入生活困境之中，且这些问题导致她难以用正常的方式来工作时，你就可以展示灵活性的一面。这种状况的灵活度意味着允许她在家工作一段时间或允许她休假。灵活性也可以意味着短期内调整一个人的工作时间或将工作日调整到周末。
你也可以在工作分配方面，根据某人的要求做相应调整而向其倾斜来显示你的灵活性。每个开发人员都会专注于自己感兴趣的特定任务，这不仅可提升团队成员的工作积极性，而且提供了宝贵的交叉培训，这一交叉培训在个人重复性地专注于同一领域时是不可能发生的。
灵活性并不意味着对所有团队成员无论其是否有问题都提供相同的解决方案。例如，一个员工由于家庭问题需要在家工作一周，其他成员就不能也在家工作。当一个员工远程工作或工作时间不同于团队其他人，就要把原委告诉你的团队，帮助他们理解你的决定。当然，在某些情况下，你也应当允许被照顾的员工留有一些含糊细节，因为把个人隐私告诉其他人是不合适的。
一个经理的灵活性影响着其他核心管理领域。当员工经历难于正常完成工作的情形时，他更信任做事有灵活性的经理。
一些员工可能会利用你处事灵活的特点，但偶尔被员工利用总要比事事僵化要好很多。尽管少数个别人谎称了他们的处境，但大多数人还是诚实的。2.1.3 诚挚
你的团队成员将感谢你为他们的成功而付出的诚挚关怀。你可以用言语和行动来体现你的关心，但最终要体现在行动上。如果你的员工相信你是真诚的和可信赖的，他们将更愿意根据你的指示用新的方法来解决问题而不是处处抵制。诚挚不是管理时尚我的经理公开表示我们目前所作的工作并不一定是我们兴趣所在。她鼓励人们去发现自己的兴趣即使这可能导致他们最终离开团队。即使公司不再填补空缺时她也还在坚持。她坚持不懈地把我们个人兴趣放在第一位而且全心全意地帮助员工解决所有问题。我们始终愿意跟她一起干。——高级技术作家为什么无人可信管理团队举行会议宣布裁员和削减预算。CEO指出在营业额回升以前我们要被迫冻结招聘以及在花费上要精打细算。一周之后，所有的经理通过公司收到了奔驰租赁服务。在下一次会议问及此事时，CEO解释说由于高层执行团队先前拥有“车辆补贴”，经财务人员确认这项支出不能免税。所以管理人员用租车代替，而这正好发生在削减预算之后。当问及为何没有砍掉这笔费用时，他的答复是这是激励政策的需要，以用于留住高层管理天才。——硬件经理
如果你的行为表明你缺乏诚意，那么无论你用多么认真的口吻去跟人们谈话，你都不会被信任，而且作为经理不仅你的指令会缺乏效力，还可能导致团队成员对你的伤害。你的团队不再会为公司而尽全力。例如，考虑一个削减预算而无盈利公司的例子。在经理要求他的团队精打细算节省成本之后，他在自己的办公桌上配置了一台新计算机，尽管他目前的计算机还很新，这个经理将失去员工的尊重并毁了自己的信誉。2.1.4 机密性
信赖的同时也就建立了信任。如果一个员工信赖一位经理，她期望那些信息不要被其他人分享或被不恰当地利用。除非一个信赖的员工严重违反了道德规范、触犯了法律或使公司陷入困境，你就不能分享这些信息或利用它背叛这个人。通过鼓励人们信赖你的环境，将有助于解决问题而不是放任自流。
例如，一个员工告诉你她想调换到一个不同类型的项目里去。她谈到了其他公司的潜在就业机会。听到这个消息，一些经理可能会立即开掉这个员工或安排她做一些不重要的任务——因为她随时都可能走人。无论如何，由于这个员工已自愿透露了这个消息，这显示出她很信任你，并且，实际上她并非真的想走——她可能只是想给你一个调配工作的机会。如果她决定离开公司，出于对你的信任和尊重，她会给你一些时间做交接。2.1.5 尊重
团队中的每个人必须受到你、其他开发人员和同事的尊重。缺乏尊重可能会公开化的方式展现出来。例如，会有人当着他人的面或在他人背后诋毁另外一个人。缺乏尊重也可能以阴险的方式体现，像某人通过贬低其他人的资历、技能或其他能力来达到诋毁他人的目的。
如果你团队中的一个成员诋毁了另外一个人，把诽谤的人拉到一边跟他谈话。不要等待状况“自我愈合”。根据问题的程度，你可以让人力资源管理人员参与进来。
通过让团队专注于解决问题而不是指责别人的问题来构建相互尊重的氛围。鼓励员工独立解决问题，并只有在他们自己不情愿做或不能做到时提供帮助。2.1.6 授权
成功的开发人员总是喜欢他们的工作并期盼下一次挑战。如果你已经定义了明确的目标，就要后退几步，来让他们成功，他们将会自我导向并自我激励。被赋予权利的员工将取得成功。
相比之下，感觉到每一步都在细节管理中的员工，就会把工作看做换取报酬的合理任务。他们知道那些管理人员所要求的任务有时是无效的或无用的，但他们相信他们无力改变现状。管理人员把他们看做清理完管道就回家的管道工。
给你的团队成员授权时，要确认他们理解了开发目标以及任务边界。边界要确定到合理的限度，但不是神圣得如印度圣牛般不能讨论与改变。在赋予清晰的边界和适度的灵活性前提下选择一个解决方案可以保证员工们不会感觉被管得过死。
下面就是一些边界类型的例子。
项目约束 时间表、功能、预算以及资源。
公司政策 需要管理人员批准拨一些专款。
技术边界 解决方案中合作伙伴将处理特殊的技术问题。
业务边界 为减少不断扩大的运营成本，需要采购一些软件组件，并对这些组件进行选型。
确定了清晰的边界后，让团队成员们选择他们如何一起工作并找出解决方案。把团队管得松散一些，监控进展，指导他们不断地取得成功。2.2 与你的团队沟通
成功的沟通需要你考虑讨论内容以及在开始谈话以前怎样去说。你所做的沟通应该针对每一种情形做相应调整：要知道在一个环境中奏效的事情未必能在另外一种情形中起作用。
与你的团队沟通时，要计划涵盖项目工作与人员方面的话题。项目工作要包括增加收入、降低项目风险、提升生产率的策略等开发涉及的方面。人员方面的话题应包括指导、培训、矫正错误、答复问题、化解忧虑、讨论长期问题和新观念、工作上所需的帮助以及职业规划帮助等。
通常，管理人员只侧重项目工作，针对当前那些推动公司短期成功的实际问题。然而，沟通时不能不涉及其他可能会导致降低生产效率、增加人员流动、质量问题、失去机会以及降低积极性等问题。至少要花1/5以上的沟通时间跳出当前项目来谈问题。要考虑到项目相关问题与员工个人相关问题间沟通方法的不同；每一种沟通方式都需要相对应的场合以确保沟通能正确解决相关问题。下面的章节讨论了与你的团队沟通的方法，包括一对一、项目沟通、团队会议以及非正式谈话。2.2.1 一对一
一周一次与个别开发人员举行一对一例会给经理们提供了最好的机会来讨论大部分人员问题。（相对而言，团队建设则需要通过团队会议来发展员工间友好关系并增强相互配合。）如果你的团队多于6人，鉴于时间关系，你可以隔周搞一次一对一例会。
一对一例会提供了建立信任感及倾听个人观点的机会。让员工来引导最初的讨论。交谈初始避免讨论当前任务及所面对的问题。有时，开发人员并不知道如何开头，你可以通过询问如下问题作为开始。● 你对你的工作有何忧虑？● 近来遇到问题了么？● 你有改进想法么？● 你需要增加设备和软件么？● 你的长期职业规划是什么？● 你有可分享的想法么？
一对一的会议非常适合讨论问题、提供建议、商定问题的解决方案以及分配任务或要求针对某一问题提供解决方案。任务分工要明确，但是要避免对解决方案阐述得过于详细。相反，应该像这样成功地达成一致意见：给员工解决问题的授权，并提供建议。总的来说，不要立即将解决问题的任务分给提出问题的人。如果你习惯这样做，你的员工将不会再提问题来引起你的注意。不去倾听在我职业生涯的早期，我的老板是一个不愿意倾听的人。当我带着问题找他想知道下一步如何处理时，他会打断讨论并开始给我下指示。他总是在我说清楚我能解决的问题之前发布命令。我后来就不再跟他讨论问题了。——软件经理
如果你想利用一对一会议推进项目进程，就要等到把别的话题讨论完再进行项目状态讨论。如果你开始讨论项目情况，将会耗费你全部的会议时间而其他问题不再会引起你的注意。2.2.2 项目沟通
你如何举办项目沟通取决于项目规模以及发布周期。项目发布周期较短时，每日站立例会——所有参会者站着开15～20分钟会议——可能比较合适。经理每天同一时间安排会议，要求参会者就前一天的进展、今天的计划以及需要的紧急求助做简短陈述。站着开会不是为了解决问题或讨论话题。相反，任何发现的问题可以落实到具体人员去解决跟踪。
对于发布周期较长的项目，每周一次的项目状态例会，同时结合走到同事的办公桌前与他们交流讨论的方式，可能比较有用。这个周例会通常30分钟～1小时。项目状态以及日程安排会议通常要包含一些细节讨论，除此之外还应包括下几周的计划。也应包括团队发现的一些风险以及项目经理指派一些人共同来应对并减缓那些风险。
你也可以凭借企业内网/维基（intranet/wiki）发布通告、电子邮件、白板通知或正式评审会等方式与你的团队进行项目沟通。一些项目成员不是总会知道整体项目状态或最近的项目或时间表变化。不与团队沟通整体状态可能导致混乱，而清楚地传达这一信息不仅可提升工作积极性还可以提高项目成功的可能性。如果你为你的团队提供正式的项目进展信息，他们会更愿意在早期指出问题和差异，而且他们也愿意把他们的进展状态报告给你。
与团队进行进展状态沟通时，要根据工作量的大小规范报告的内容和频率。项目进展状态描述应该包括近期已完成的工作、下一阶段要解决的问题、产品已修改的功能、截止到今天的完成状态、遇到的问题以及当前存在的风险。
按时完成项目依赖于准确的进展状态信息，这些状态信息中应包括为项目中途更正留有的时间。2.2.3 团队会议
定期安排项目会议将增强团队凝聚力并提升团队业绩。团队会议可根据团队的大小每周或每两周举行一次。会议可办成论坛形式用以讨论总体问题或为新流程和政策提供培训机会。团队会议也可以允许团队成员们讨论相关内容或提出问题。
会议不应该是即兴活动，不管怎样，你应该事先准备一个议事日程或主题列表。在你桌面上打开一个文件并保持打开状态，根据大家提到的内容随时增加信息要点条目；这个文件将是下一次会议议事日程的基础。一个确定的议事日程将有助于会议短小并且避免漫无边际的讨论。事先分发议事日程将使会议更有效率。
过长的会议会消耗精力并影响你们的成本底线，所以要尽可能把会议开得短小。长时间的会议也是代价高昂的——如一个12个人的团队耗时2小时的会议等同于3个工程人日（24小时）。
要允许工程师们说出对诸如政策以及高层管理人员决策等问题的忧虑。跟踪这些问题并且每周和团队一起对它们进行评审，即使你们还没有答案。要确认提供了相关问题的进展状态并进行相应的补充，这些问题中既包括先前会议提出的那些公开议题，也要包含正致力于关闭的问题。
有时候，一个有不满情绪的工程师也可能利用团队会议去抱怨诉苦。如果这个工程师跨越了从建设性建议到破坏性抱怨的底线，那么就简短地打断谈话并让他单独和你会面一起讨论他的困惑。
规范的开发小组会议不适合进行细节技术讨论。建立单独的技术会议机制，这样可以把重点放在特定的话题，并使得大多数会议开得比较随意，以便人们不需要都出席并随时可以退出。否则，那些与特定技术主题不相关的工程师们就要花费时间自始至终地来听取对他们没有意义的讨论。2.3 解决冲突
在某些时候，团队成员间会产生分歧。作为他们的经理，你应该鼓励他们直接化解分歧，而不是让分歧妨碍合作。典型的分歧通常包括：技术选型、公共资源利用或者不顾全他人的行为。通过直接或折中讨论的方式团队成员通常可以解决技术和资源的分歧，但是不顾全他人的行为需要采取不同的方法。
同事间的问题一旦形成就无法继续共事。如果一个人在生另外一个人的气，劝住受害的一方同时要求另外的人到会议室讨论问题以便于找到解决办法。如果他们不能化解分歧，你可以安排一个相关人员共同参加的会谈来讨论问题。无论怎样，如果冲突中涉及了不道德的行为，第一时间介入最有助于工作：把个别人拉到一边并且以解决问题为目标开始讨论详细情况。
有时候，是你团队的成员与其他团体的人发生冲突。这些冲突常常涉及未及时交付，但核心问题通常是欠缺沟通。要鼓励每个人把问题先谈出来。如果他们不能解决问题或过于乐观就要提供适当的帮助和指导。
协助处理复杂的冲突时，首先要与冲突涉及的每个人谈话以了解问题双方的看法。在有限的时间内改变局势。适当召集一个由当事人和他们经理参加的检讨会。不带主观臆断地分析导致发生冲突的真正原因。要求各方考虑下一次类似事件发生时他们可以用怎样不同的方式来改善局面。如果需要，加上你的建议。行动起来化解冲突一个项目经理和她的老板告诉我他们和我的一个工程师有些不愉快。这个项目由于要进行午夜网上直播，需要在下午5点以后上班。经理告诉我那位工程师应该在工作结束后电话通知。那位工程师并没有打电话，所
试读结束[说明：试读内容隐藏了图片]