书名：技术团队管理者的第一堂管理课
ISBN：978-7-115-55196-2
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 王海东
责任编辑 杨海玲
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书主要从技术团队管理者如何带人、做事、建体系3个维度出发，系统地对团队建设、人才管理、文化塑造、项目管理、效率管理、绩效管理、流程建设、规范管理这8个模块进行了介绍，这8个模块的内容相互独立，读者可按照章节的顺序阅读，也可随机选择感兴趣的内容阅读。
本书适合计划转型做技术团队管理的技术人员或刚转型不久的技术团队管理者阅读。本书没有晦涩难懂的理论体系，也没有复杂深奥的抽象概念，而是从技术团队管理者的实际工作场景入手，帮助技术人顺利地过渡成管理者。技术团队管理者可以直接将书中介绍的方法应用到团队管理中，解决技术团队管理过程中遇到的问题。
程序员似乎是吃青春饭的，其黄金时期是20岁到35岁。到了35岁左右就会倍感压力：首先要面对软件行业的飞速发展，许多以前学的东西可能升级甚至淘汰；其次，随着年轻程序员的涌入，自己所处的地位岌岌可危，很可能“长江后浪推前浪，前浪被拍死在沙滩上”；更重要的是，“上有老下有小，还要背负房贷、车贷的压力”—— 这就是“程序员的35岁职业魔咒”！
35岁是一道坎，而海东本人也正值这个年龄，他撰写这本书貌似就是为了打破魔咒，标志着他成功转为技术团队管理者。不过，以我对他的了解，这并不完全是他的初衷。海东首先是一名优秀的程序员，这些年他一直在带团队，做技术团队管理，开发了许多互联网项目。溯本求源，这本书应是从中获得的实战经验的总结，是水到渠成的成果，而这些恰巧成了破除魔咒的示范。
我也是程序员出身，做过Java、.NET项目开发，同时翻译过《Java经典实例》《.NET本质论 第1卷：公共语言运行库》等书。在继续“走技术线还是技术团队管理线”的问题上，我选择了技术团队管理。差不多在我35岁时，我翻译了《敏捷迭代开发：管理者指南》，书中列举了统一过程、极限编程、水晶、Scrum、动态软件开发方法（Dynamic Software Development Method，DSDM）、特征驱动开发（Feature Driven Development，FDD）、自适应软件开发（Adaptive Software Development，ASD）以及精益开发等开发方法，这些方法让当时做技术管理的我眼前一亮。软件开发复杂而多变，尤其是客户的需求难以把握，开发管理变得作茧自缚，“剪不断，理还乱”。而敏捷开发则以用户的需求变化为核心，采用迭代、循序渐进的方法进行软件开发，大大提升了开发效率以及客户满意度。我就是敏捷开发的受益者，也顺理成章地成为其布道者。
这次，本书再次让我眼前一亮。因为软件开发不是靠独行侠、个人英雄主义就可以完成的，需要工程化，需要团队协同作战。事实上，人才是软件开发的核心。《人月神话》就提出：人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间可以互相替换。只有精良高效的技术团队，才是完成项目的根本保障。
如何打造高效的技术团队？一般意义的团队管理，包括目标设定、流程打造、绩效考核、激励措施等。技术团队管理有一定的特殊性：技术团队更像一支足球队，需要训练与磨合，不断成长；技术团队管理者要立足于技术常识，要有创新管理、知识管理和不确定性与风险管理；技术团队管理者要有一定的专业基础和技术敏感度，这依赖于其作为程序员在其“黄金期”打下的坚实技术基础；当然，要从程序员转型为技术团队管理者，本身就是一个跨越式的跃迁，取决于管理者自身的修炼与外界的机遇。海东酷爱阅读，还热衷于组织读书会，具有很强的沟通能力。正如乔布斯的经典名言“好学若饥，谦卑若愚”（Stay hungry，Stay foolish），只有好学才不会给自己的人生设限。转型首先是认知与思维的转变，然后是实践、复盘、再实践。如果想快捷转型为技术团队管理者，本书算得上是“武林秘籍”了。
我其实不喜欢“码农”这个词，程序员的境界比这要高许多。只要想起自己曾经满怀惊奇、兴奋与真诚敲下的那个程序——“Hello，World！”，我们就会充满了渴望和力量，因为程序员最初的梦想就是改变世界。程序员不能只局限于编码（事实上，编码只占软件开发的一部分），也就是说，不能让现实的苟且剥夺了诗和远方。
比尔·盖茨和史蒂夫·乔布斯都是技术人员出身，他们创造了一个新的世界。事实上，程序员有一个天然的优势，就是其不停修炼的编程思维。编程思维是一种创新思维，它包含了逻辑、框架和拆解等思维模式。我也注意到，海东的技术团队管理策略自觉或不自觉地受到了编程思维的影响。本书就好比定义了一个技术团队管理框架，其中团队建设、人才管理、文化塑造、项目管理、效率管理、绩效管理、流程建设和规范管理等相当于管理模式，而输出则是精良的技术团队。
最后，我想说“程序员的35岁职业魔咒”是程序员人生第二成长曲线的破局点。海东的这本书提供的思维框架和实践方法，或许能帮你跨越鸿沟，重启提升引擎！我特别建议程序员聆听音乐，欣赏名画，多一些艺术修养。我觉得程序员出身的管理者，更应该像一个乐队的指挥，开发出的不仅是软件，还是艺术品！
北京魔笛创新科技发展有限公司董事总经理
中国科技咨询协会创业导师
我猜每个技术人员转做管理时都会有下面的疑惑，我也经常被别人咨询这些问题：做了很多年的技术到底要不要转管理，转做管理有前途吗？转做管理后到底怎么带团队？
其实，从技术人到管理者是一个很自然的转变，我们要顺势而为，不要刻意逃避转型管理，否则可能付出很多却发展平平。只要找到管理的工具和方法，管理技术团队并没有想象的那么难。
提到技术团队管理，我们首先想到的就是管人，但我想说的是，比起管人，更重要的是带人，带出一支理念相同、目标一致、有凝聚力的团队。
那如何才能带出这样的团队呢？很多人觉得可能需要极强的领导力，要会讲故事，还得能激励人，更要高瞻远瞩吧？
或许这些并不重要！
其实技术团队管理者不必会演讲，从技术人转型的管理者，大多做的比说的多；也不必懂得激励人，程序员大多自我驱动，团队伙伴之间朝夕相处，也都清楚彼此的习惯和秉性；更不用有管理相关的专业背景，大多数技术团队管理者是计算机相关专业科班出身，且技术团队的管理对技术有强依赖；甚至不需要高情商，技术人员通常直来直去，毫无掩饰，不用和他们兜圈子。
能带好团队的管理者其实靠的都是系统的管理方法——能清晰规划团队的目标，有效地管理团队的每一个执行环节。有了系统的管理方法，一个刚转岗的技术人员就能赶走带队恐惧，顺利从技术人员过渡到管理者，打造出一支高效的团队。
长期以来，我试图寻找一套现有的、适合大多数技术团队管理者快速落地实操的团队管理方法，但始终未能如愿。带队这些年，我将自己亲身实践的经验和方法归纳总结，并查询了大量资料，总算总结出这套一学就会的技术团队管理方法，提炼成本书带人、做事、建体系的3大维度的内容。
技术团队管理者的核心工作是带人、做事、建体系。人带不好，事就做不成，而带人高效地做事，终极解决方案则是建立规范化的流程体系。本书按照从带人到做事，再到建体系的顺序进行介绍，将技术团队管理者的核心工作从这3个维度拆解成8个模块。图1是这3个维度和8个模块的框架图。第一个维度是带人，分别用团队建设、人才管理和文化塑造这3章进行描述，揭示技术团队管理者带好人必须要有度量，能成就他人；第二个维度是做事，分别用项目管理和效率管理这2章进行描述，展示做事的核心要讲求方法，注重效率；第三个维度是建体系，分别用绩效管理、流程建设和规范管理这3章进行描述，它的核心是控制和公开透明。这3个维度可以有效地帮助技术团队管理者从0到1打造出一支强大的团队。本书每章都有相应的工具或方法，技术团队管理者遇到管理问题时，试着对号入座，就能找到对应的解决方法。有了这些方法，转型中的技术团队管理者将告别迷茫与烦恼。
图1 技术团队管理框架
我们来看一下这8个模块的主要内容。
现在就让我陪你一起，从“技术人”的角色出发，放下恐惧和包袱，踏实坚定地成为技术团队的“管理者”。
王海东
2020年12月
2019年5月的一个下午，我发现自己在一线带团队已有十个年头，突然冒出一个想写一本关于自己这些年带队实践的图书的想法。这个之前从未有过的想法，一瞬间让我如同被电击一般。从有想法到成书，中间有太多的艰难，在这里我要感谢我的朋友和家人，在我写书的过程中他们给了我太多的帮助。
首先感谢张晓坤老师，他曾经是中央民族大学计算机系的教师，微软认证讲师（MCT），翻译过10多本IT图书（如《敏捷迭代开发》《Java经典实例》等），后在儿童教育项目上创业，也非常成功。是他不断鼓励我出版本书，并帮我联系出版社，让我更加坚定写完本书的信念。
感谢本书的责任编辑杨海玲，非常高兴能和这么优秀的人合作，是她不断指导我完善和打磨书中的不足之处，本书才能这么快问世。这本书耗费了她很多的精力，她让我感叹编辑的责任与专业。
感谢我的好兄弟胡晨宇，他是做内容和营销的牛人，最擅长提炼爆款文章公式，做过很多优秀的案例，在他身上我学到了很多写作的方法，帮助我不断优化本书内容。
感谢技术团队的伙伴们，这本书中的很多方法都是与团队伙伴们一同实践和总结的。感谢团队伙伴们一路对我的信任和支持，让我的工作充满动力。
感谢我的妻子和可爱的儿子。写书很不容易，在写这本书的整整10个月时间里，周末我从没休息过，晚上也会写到很晚。儿子5岁，正是需要陪伴的时候，我却很少陪伴他。感谢他们在我最忙碌的日子里的鼓励和付出，愿家人永远快乐健康。
感谢每一位读者，是你们让我在写作的路上更有动力。欢迎加我好友，分享你的读书收获和带队经验，让我们共同学习成长。
本书由异步社区（https://www.epubit.com/）出品，社区为您提供相关资源和后续服务。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入勘误信息，单击“提交”按钮即可。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线投稿（直接访问www. epubit.com/selfpublish/submission即可）。
如果您来自学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接通过邮件发送给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT图书和相关学习产品，为作译者提供优质的出版服务。异步社区创办于2015年8月，提供大量精品IT图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近40年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
新上任的技术团队管理者往往有“三把火”，但结果多数是“惹火上身”。新官上任如何才能在短期内获得优秀的业绩，站稳脚跟，务实地做到统领全局，整体规划，分步实施呢？
技术人员能搞定很难的技术，但并不一定能搞定管理，职位的变化意味着工作内容的彻底转变，这种转变需要快速了解清楚工作职责，那么技术团队管理者的职责具体有哪些呢？
一般而言，技术人员往往是一群性格高傲、不善交流沟通、遇到问题爱独立思考、有死磕精神且热爱钻研技术的人，带领这样一群人，怎样才能摆脱一管就死、一放就乱的局面呢？
我在互联网行业工作了10年，创过业、做过架构、当过高管。这些年我做过的事情中最喜欢的一件还是以创业者心态带着技术团队做点儿有挑战的事情。因为带团队的能力是技术团队管理者应具备的基本能力，所以技术团队管理者只有不断地在实践中训练和强化它，未来才能带领更多的人做事。
然而，带好团队确实不容易，尤其是对于刚刚转型不久的技术团队管理者。我自己也是一样，从程序员到技术团队管理者，一路跌跌撞撞、踉踉跄跄地踩过很多坑，也学到了很多宝贵的知识，下面我带着你启程避开这些坑。
坦白讲，大多数技术团队管理者都是被迫从技术岗位转型的，所以新官上任会面临一系列尴尬的问题，例如，如何能让那些技术强、资历老、年龄大的技术人员配合工作，如何带领团队做出业绩，如何明确团队责任、规划技术路线等。在很多情况下，领导在“关键时刻”任命新的技术团队管理者，可能是因为项目任务重、压力大而临危受命，可能是因为公司内部“政治”环境复杂，需要一个新的技术团队管理者来平衡内部“权力”，也有可能是前任技术团队管理者因不堪重负愤然提出离职，而这一切都逼着新上任的技术团队管理者在短期内实现从“管代码”到“管人”的转变。
但众所周知，新上任的技术团队管理者由于身份和职责的快速变化，往往会水土不服，很难适应新岗位，其原因归结起来有以下3种。
（1）思维难变：从技术岗位突然到管理岗位，缺少培训和指导，更没有过渡期，一直用技术人员思维带队做事，每天为各种事情焦头烂额。
（2）排挤他人：有些新上任的技术团队管理者为稳定地位，排挤资历老、不服管的员工，而任用自己信任和听话的员工。
（3）自吹自擂：新上任时信心满满、自吹自擂，干活时能力有限、水土不服，最终以项目失败而告终。
那么作为一个新上任的技术团队管理者，如何才能取得团队和领导的信任，务实地统领全局，整体规划，分步实施，短期内做出业绩呢？具体做法如图1-1所示。
图1-1 新官上任的做法
新上任的技术团队管理者需要格外谨慎，因为新官上任时内部可能有很多人羡慕嫉妒恨，新官上任的一举一动会被格外关注，大家生怕接下来会有什么大举动。
自古新官上任三把火，很多技术团队管理者上任后带着“不点火怎么能立威”的想法，常常会做出几件大刀阔斧的事，以表现自己与众不同的才能，好让众将“俯首称臣”。其实这并不是明智的做法，新上任的技术团队管理者第一时间要做的事情应该是熟悉业务和流程，快速凝聚团队，让团队成员有安全感，并思考怎么在和领导的蜜月期内做出业绩等。
刚上任的技术团队管理者，岗位刚刚变化，还需要时间适应，而各项工作又千头万绪，每一项工作的开展都有很多阻碍，需要熟悉和解决。因为缺乏经验，很难面面俱到，这时往往需要团队核心人员的支持与配合，所以和团队核心人员建立信任就显得格外重要，如果新上任的技术团队管理者为了立威，排挤他们，虽然能逞一时之勇，但将会对团队的稳定和项目的推进产生很大的阻碍作用，同时也会让别人觉得没有度量。最重要的是，没有团队核心人员的信任和支持，能在短期内产生业绩的概率也非常小。
那么如何才能取得团队信任呢？答案是从解决团队中出现的问题开始。
要解决团队实际问题，首先需要发现问题，再深挖问题的根源，并从根本上解决问题。其实，技术团队成员出现的很大一部分问题都是低级错误导致的。对于低级错误，完全可以用规范制度约束行为来解决，例如，当技术人员没有规范的编码习惯和上线巡检流程，就会经常被各种混乱的代码和奇怪的问题所困扰，最终导致线上系统故障频出，工作效率极低，这时需要深入分析问题，并找到问题的关键之处，制度管人、规范管事，建立一套标准的工作规范制度就非常有必要。
同时，技术团队代码是核心，代码质量是产品质量的保证，而技术团队成员的技术能力又参差不齐，如果没有严格的代码规范标准和代码评审制度，项目中的整体代码就很难都达到高质量的标准，质量不高的代码对技术团队来讲几乎就是灾难，后期开发和优化都需要花费大量的时间，质量不高的代码上线后甚至会造成严重的事故。
除此之外，技术部门常被业务部门催促赶工，在工期短压力大的情况下，很多开发中的流程常常被略过，如技术方案评审、正式测试前的提测环节，更别说上线前性能相关压测和参数调优了，上线后各种问题和bug频繁出现，导致业务部门对技术部门的信任度急剧下降。
分析了团队可能存在的问题，接下来新上任的技术团队管理者就可以提供有针对性的解决方法。
首先，新上任的技术团队管理者需要和团队核心人员友好相处，即使团队核心人员怀有敌意，新上任的技术团队管理者也要释怀，第一时间团结团队成员，消除危机感，这样新上任的技术团队管理者才能够腾出很多精力来思考业务突破口和流程上的优化点，避免陷入信任危机，疲于奔命协调各种关系。
其次，新上任的技术团队管理者要制定相对合理的规范制度，这些规范制度在得到团队内部认可后，要求团队严格按照制定的标准执行，这样既规范了工作秩序，又提高了工作效率，而且为团队协作提供了依据和准则，风险职责也更加明确和清晰。
再次，在代码质量方面，新上任的技术团队管理者要加强技术方案评审、代码质量评审、自动化质量平台检测等环节，来保障项目上线质量。同时，整理代码规范文档，作为规范参考标准。另外，还要建立代码质量监督机制，让团队养成重视代码质量的习惯。
最后，对内的问题处理好后，就需要花时间稳定和其他部门的关系。很多互联网公司的业务部门和技术部门之间相处并不“融洽”，这是由于两个部门的职责不同导致的，技术部门作为支撑部门，需要依附于业务部门才能创造价值，而业务部门经常“病急乱投医”，不按流程跨部门合作，让技术人员长期处于一种疲于奔命的状态。部门协作方面，新上任的技术团队管理者要制定一套标准的需求提案流程，需求提出后严格要求签字确认，对于确认后的需求，要进行严格的技术评审和排期。
当团队的人、事、规范和制度落实后，团队会有明显的改变，这些明显的变化会让新上任的技术团队管理者得到认可。
其实，新上任的技术团队管理者对外要和各个业务部门建立有效的协作机制，推进部门间的高效合作，并不断地优化和改进这些合作流程和机制，经过2 ~ 3个项目的打磨，部门之间就会形成稳定的协作流程和规范，这时团队对新上任的技术团队管理者也会更加信任。
总体来说，新上任的技术团队管理者需要先着眼于技术和业务，与团队内外建立良好的关系，提升团队凝聚力，这样才能打赢一切硬仗，实现团队的共同目标。
刚刚上任的技术团队管理者，在大刀阔斧地改革的同时一定要考虑短期如何获得业绩的事情，因为刚上任其实是站在聚光灯下，公司上下期望值非常高，希望他们接手团队后，团队和业务能产生立竿见影的效果。如果只做长期规划而不做短期见效的事情，时间久了，团队和公司都会对他们的工作能力产生怀疑。
对于新上任的技术团队管理者如何开展工作，并没有标准答案，不过我觉得一份靠谱的业务规划一定包括短期、中期和长期3个部分，短期内如果做出业绩，就会坚定团队的信心，更会得到团队和公司的认可。
那么，要想短期内做出业绩可以从哪些方面入手呢？其实技术部门作为支撑部门，技术团队管理者的很大一部分工作是对内的，只要提升了技术团队的效能，基本就做出了业绩。要想短期内提升技术团队效能，第一步就是要找到技术团队在项目开发中花费时间占比较长的事项，根据我以往的经验来看，技术团队开发中低效的事项往往与技术人员的能力相关性不大，通常是技术团队低效协作导致的。优化好协作流程就能提高开发效率。毕竟技术团队最核心的工作还是完成研发任务，如果要做出更多的业绩，就需要多和业务部门的领导沟通，了解业务需求，把技术深度融合到业务中，用技术对业务进行分析与透视，解决业务痛点和难点，帮助业务部门提升业绩。
完全熟悉公司业务需要较长的时间，短期内可以先熟悉公司核心业务部门的业务，解决业务部门的一些实际的问题。举例来说，很多企业因为没有信息化，客户都是由销售人员单独进行管理的，销售人员的客户信息也不会进行共享，销售人员一旦离职，客户的线索往往就会中断。由于没有信息化，销售人员也不会对客户的线索进行深入的跟踪和挖掘，更做不了根据竞品数据挖掘客户的潜在需求，从而找到行业的市场机会。这时新上任的技术团队管理者可以帮助业务部门把数据上系统（但这些业务系统并不建议自己开发，采购第三方成形的系统会是不错的选择，第三方专业的系统既稳定，又能立刻用上），以此帮助业务部门分析客户和行业数据，用数据指导业务的方向。
业务短期有突破后，新上任的技术团队管理者对公司的业务会更加了解，这时候做中期和长期的规划才会靠谱些，中长期的规划要在结合公司整体目标的基础上考虑部门目标、市场机会、投入资源、关键节点和技术难点等。中长期的规划需要考虑很多综合因素，而且随着公司的发展和业务变化，原有的规划也会不断做出调整，变化较大，所以不建议新上任的技术团队管理者在未站稳脚跟之前，做那些短期内无法显现成果的事情。
技术团队管理者相对于业务出身的管理者，表达能力往往偏弱一些。业务部门主管的基本工作就是沟通，有的主管从业务员做到部门负责人可能已经磨炼了十几年。而技术团队管理者很多都是从程序员转岗的，平时锻炼的基本是写代码能力，而非沟通能力。但是对于新上任的技术团队管理者，与领导保持良好的沟通可以说是非常重要的事情。及时向领导汇报工作，包括工作计划与进展、项目执行的障碍、技术对业务的决策与支持等，这些都有利于获取领导的支持和理解。
但值得注意的是，和领导高效地沟通是建立在信任的基础上，新官上任，领导基本上都会格外关注，并给予很大的信任和支持，新上任的技术团队管理者只有务实做事，才能留住这份信任，在与领导的沟通中不必做出过多的承诺和保证。领导对提升的人的能力是有了解的，因此与领导沟通要坦诚，切不可大话连篇和隐瞒欺骗，因为说过的话是要兑现的，如果领导是一个言行一致、眼睛里容不得半点沙子，还特别较真的人，那么说过的话无法兑现最终很难得到满意的结果。
新上任的技术团队管理者想要赢得领导的信任和支持，还是要在短期踏实地做事，找到技术推动业务的突破口，业绩不是喊出来的，是实打实干出来的。做事稳重有序，不夸夸其谈，等做出了业绩自然会得到他人的认可。
所以，新上任的技术团队管理者首先要稳定团队，梳理好做事的流程；然后在短期内做出业绩，得到领导和团队的认可；再后要与领导进行有效的沟通，逐步建立互信的关系；最后脚踏实地地做事，去赢得更多人的尊重。
技术人员升职为技术团队管理者后，其实工作内容的前后变化还是很大的，在时间、目标、职责、精力和关注点等方面都会截然不同。而这些不同点对新上任的技术团队管理者来说或多或少是有些模糊的，下面我们一起来看看这些不同点。
（1）职责不同：技术团队管理者更要对整个团队负责，而不像技术人员一样只负责代码开发，不考虑其他团队成员的代码质量和效率。
（2）时间不同：技术人员有整段时间可以做事，只要按计划执行，就可以完成任务，而技术团队管理者更多的是在碎片化的时间里带团队做事，计划往往赶不上变化。
（3）问题不同：技术人员在工作中只需要解决自己的技术问题，就可以确保工作成果，而技术团队管理者每天要花费大量时间处理下属的问题，才能扫清项目执行中的障碍。
（4）沟通不同：技术人员遇到问题只需向上沟通，而技术团队管理者不仅要向上沟通，还要向下沟通和平级沟通。
（5）质量不同：技术人员只对自己的代码质量负责，而技术团队管理者要考虑项目整体质量，才能确保结果有较高的质量。
（6）思考不同：技术人员只需思考如何提升自己的技术能力，而技术团队管理者要考虑项目的进度、质量、成本等诸多因素。
（7）关注不同：技术人员平时关注技术的时间较多，而技术团队管理者为了提升团队整体的效率，平时关注人和事的时间较多。
（8）目标不同：技术人员的目标一般是事情怎么做，重点是过程，而技术团队管理者的目标是找谁做，重点是结果。
升职前后的变化很大，上面的8个不同点，每一点都需要新上任的技术团队管理者学会“管人”，职位的变化导致工作内容完全转变，这些新的内容需要技术团队管理者去适应，并清楚具体的工作职责。
下面我们来看看研发部门中3种角色的管理岗位的具体工作职责，这些工作职责并不是相对孤立的，在很多中小型互联网公司中这些管理岗位的职责都会有重叠。
（1）团队管理者：任务分派、人才管理、横向协作、向上汇报、绩效考核、文化塑造、流程建设、规范建设。
（2）高级工程师：设计规划、代码评审、需求分析、技术分享、技术革新。
（3）项目负责人：制订计划、进度控制、质量控制。
下面我们一起来看看这些管理角色是如何落实团队工作的。
团队管理者是一个团队的核心，需要搭班子、定目标、带队伍，建立完善的协作流程体系，塑造开放透明的团队文化，这个过程需要团队管理者懂得借力，有更多人跟随和支持，才有可能成功。具体的工作职责包括任务分派、人才管理、横向协作、向上汇报、绩效考核、文化塑造、流程建设和规范建设，如图1-2所示。
图1-2 团队管理者的工作职责
团队管理者为团队成员分派任务时，要有明确、具体的要求，分派任务前要明确要求和目标，执行中遇到问题要给予引导，任务的阶段性成果要及时反馈，对做得较好的地方要给予肯定和正面的评价，条件允许的情况下，可给予一定的物质激励。
任务分派前，要充分考虑目标实现的可行性以及目标实现的动力，包括投入的资源、对能力的要求、目标难易程度等，让下属在任务完成中有一定挑战但也不至于丧失信心和动力，这样任务完成后才会有成就感，同时也能学到很多东西，做事的动力才会更大。为了避免下属对任务目标的理解出现偏差，可以在任务分派后让下属重复一遍任务的具体内容以及要达成的目标，这个方法可以确保执行结果不会出现大的偏差。
同时，还要帮助团队提前发现任务执行中可能遇到的问题，让团队提前做好预案，降低任务执行中的出错风险，增加任务完成概率，任务分派时团队管理者可以询问下属：“任务执行过程中可能遇到哪些问题？”“如果遇到这样的问题，应该怎么处理？”“如果任务执行失败，你觉得可能是哪些原因？”这样可以锻炼下属对任务的整体把控力和独立思考力。
另外，分派的任务如果执行周期较长，要设立里程碑节点，每个里程碑节点需要确定具体时间，因为分派没有截止时间的任务根本谈不上有效的管理。应及时审查阶段性成果，关注执行过程中遇到的问题，对于常出现的问题，要深入思考、追溯源头，从根本上解决问题。
解决问题的能力是每个团队管理者的硬技能。作为团队管理者，除了要及时帮助团队解决问题，还需要提升团队解决问题的能力。下属在任务执行中遇到问题，思考很久但仍没有找到解决方法而寻求帮助时，该如何帮他解决问题，并提升他解决问题的能力呢？
对于下面的一些思考路径，包括清晰描述问题、类比问题、大胆假设和小心求证，团队管理者在帮助下属解决问题时可以试试看。
（1）清晰描述问题。吉德林法则说：把难题清清楚楚地写出来，便已经解决了一半。这句话告诉我们清晰地描述问题是解决问题的前提条件。对于了解问题全貌，清晰的阐述问题，可以采用5W2H模型对问题信息进行收集和观察，5W2H模型分别是：Who（谁）、Where（什么地方）、When（什么时间）、What（发生了什么）、Why（为什么）、How（如何）、How Many（多少）。模型应用格式是：谁在什么时间什么地方发生了什么，这个问题是如何发生的，为什么会发生，有多少因素会受影响？
（2）类比问题。拿当前出现的问题和之前出现的问题对比，找出相同点和不同点，相同的地方应用之前的解决方案，对于不同和特别之处要避免生搬硬套。其实每一个团队的日常工作中重复出现的问题并不少，如果能找到一套有效的方法提升雷同问题的解决效率，下属任务执行效率就能提高不少。
（3）大胆假设。当遇到有挑战性的难题，尤其是没有任何思路的时候，对问题可以进行大胆假设，多一些假设，就会多一些解题思路，也会多一些选择。不过，基于一定的技术能力和经验的假设才更接近真相。毕竟，假设也是基于专业知识为前提的。
（4）小心求证。对问题假设后，要对假设的可能进行分类，排除掉那些明显不靠谱的假设，对于剩下的假设条件要小心求证，不要放过任何细节，慢慢推理和论证，并寻求更专业人员的帮助，直到得出合理的结论。
要解决问题，除了清晰地描述问题、类比问题、大胆假设、小心求证，解决问题的决心也很关键，对资历浅的技术人员来说，他们遇到问题时往往很害怕，在心态上就已经输了，所以团队管理者还要帮助下属树立解决问题的信心，有了必须解决问题的决心和适合的方法，问题迟早都会被攻破。
任务完成后，团队管理者对最终的工作成果考核时，要做到客观中立，不带有个人主观色彩地进行评价，同时对于考核结果不理想的下属，团队管理者要让他们知道问题所在，并帮助下属找到适合的方法来改善和提升不足之处。对于考核结果优秀的下属，要及时给予肯定和奖励，找出下属执行中的亮点，让团队中更多成员来学习。
总体来讲，对于任务分派，需要注意以下5点。
（1）所有分派的任务一定要有目标和截止时间。
（2）对任务阶段性成果要及时审查，并帮助团队成员解决执行中遇到的问题。
（3）不要做“老好人”，而要及时指正下属的问题，打造一支能打硬仗的团队。
（4）教会下属分析、解决问题的方法，避免他们陷入问题陷阱。
（5）对优秀的下属要及时给予肯定，激励他们做出更好的成绩。
人才是企业的核心竞争力，团队管理者要建立完善的人才梯队，对于人才梯队的建设可以从招聘、解雇和培养3个方面入手。
（1）招聘。团队管理者要深度思考公司的业务规划与发展，根据公司战略方向设立团队的目标，再根据团队目标做招聘计划，明确团队需要搭建的人才梯队模型，以及在不同的发展时期需要招聘的人才。对于人才的招聘，可以优先从团队内部选拔，这样可以大大减少人才的招聘时间并降低成本。
同时，为了提高招聘效率，让招聘工作责任到人，还需要建立一套标准化的招聘流程，包括招聘规划、简历筛选比对、远程初试、信息登记、技术面试、素质面试。
对于面试环节的技术面试是考核的重点，分值占比较大，技术面试要重点考察专业技能、应用架构和项目经验。技术之外的素质面试要考察工作中需要的软性能力。
（2）解雇。要对试用期的员工进行严格考核，避免转正后发现其能力不能胜任。对于试用期完全无法胜任本职工作，进步又缓慢的员工，以及不认同公司或团队理念而出现严重违纪或重大事故的员工，团队管理者要果断将其解雇，千万不能犹豫心软，碍于情面将就录用，因为这样会给团队造成很不好的影响，不合适的人坚决不能将就。
当然，解雇员工前要提前和对方沟通，给对方留有思考的时间，以便有一定的缓冲空间使对方接受。解雇时要说出具体原因，尤其是触犯公司价值观和底线的员工，更要表明立场，同时也要肯定对方给公司和团队做出的贡献，和平解约，好聚好散。对于离职的员工要做好交接，收回所有权限和账号，以确保信息不外传。
（3）培养。团队管理者懂得培养下属非常重要，如果不懂得培养下属，就没有下属完成团队中有难度的工作，最终团队管理者只能事无巨细地参与到每一件事情中，陷入越忙越乱、越乱越忙的怪圈中。同时如果团队管理者不懂得培养下属，那么其自身也很难得到提拔，因为其一旦升职，没人能顶替其现在的位置。
更多关于人才管理的内容，我们会在第2章中详细讲解。
良好的跨部门横向协作是提升跨部门合作效率的关键，互联网公司中技术部门和业务部门的关系往往并不融洽，归结其原因主要还是各自的目标和利益不同，但技术部门和业务部门又是需要高度配合的部门，所以跨部门横向协作非常重要，处理好跨部门横向协作可以极大地提升工作效率。平时工作中要让业务部门及时了解技术部门的工作，这样有利于过滤掉业务部门不合理的产品需求，获取业务部门资源上的帮助，还可以帮助技术部门减少会议和其他琐事的纠缠，把精力专注地投入到产品的开发上。
在跨部门的横向协作机制上，双方需要制定合理的协作规范、制度和流程，定好做事的“规矩”，坚决杜绝口头传递需求，中途随意更改需求。通过“规矩”约定双方基本底线，避免不切实际的事项给技术团队造成的不必要干扰。
更多关于横向协作的内容，我们会在第5章详细讲解。
在实际的工作中团队管理者往往不太愿意主动向上汇报。其实，向上沟通非常重要，能高效地和自己的领导沟通，让领导及时知道团队情况和工作进展。当领导觉得团队管理者办事靠谱，团队管理者自然能获得更多的工作支持，工作开展起来也会更加顺利。
对于向上沟通，首先，需要明确目标和沟通的重点事项，认真理解领导提出的问题以及背后真正的意图；其次，为了让汇报能有重点，节省双方沟通时间，需要对信息进行整理和汇总；最后，沟通时要用“结论+问题+建议”的形式汇报。
更多关于向上汇报的内容，我们会在第5章详细讲解。
绩效考核操作起来非常不容易，也非常考验团队管理者的能力，技术团队管理者很可能“一听就会，一做就废”，结果甚至事与愿违，越考核越起反作用。其实，常规的绩效考核很难适应灵活多变的组织形式和业务形态，快速发展的组织必须要构建敏捷的绩效考核系统。
构建敏捷的绩效考核系统，首先，能够帮助员工成长，不以利益诱导完成工作，工作内容注重提升员工能力，帮助员工解决问题，制订成长计划，采取有效行动，不断得到提升。其次，通过目标驱动完成工作，制定目标不仅是为了衡量绩效结果，更多要关注个体目标和整体目标的关联，聚焦在更有价值的事情上。再次，考核过程能够持续反馈，传统的绩效考核周期太长，要在短周期内持续反馈，让技术人员在反馈中进行诊断和自检，进而更好地完成任务，获得收获和成长。最后，考核团队整体产出，整体大于部分之和，以组织整体产出作为评估标准更有价值，也能帮助组织整体与目标对齐。
构建敏捷的绩效考核系统可以让团队建立自驱的内核文化，增进部门合作仪式感，以关键技术驱动业务增长，从而打造出高绩效的敏捷团队。
更多关于绩效考核的内容，会在第6章详细讲解。
技术人员和机器打交道的时间太多，有的技术人员生活在编码的世界里，一天说不了几句话，团队氛围大多数都是沉闷的，团队管理者需要加强团队文化建设，让团队氛围从沉闷变成活跃，再到乐于奉献，因为优秀的团队文化可以有效地统一团队意识，管理团队情绪，约束团队行为，提高团队效率，塑造优秀人才。这是团队长期持久健康发展的根基。
再优秀的文化，也是团队一步步脚踏实地践行出来的，对于技术团队的文化构建可以重点从“坦诚”“学习”“复盘”“接受失败”“帮助成长”这些关键词入手。通过工作中的规范、工具和要求一步步地执行，形成团队的习惯和做事风格。
更多关于文化塑造的内容，会在第3章详细讲解。
完善的流程可以帮助技术团队管理者简化工作，避免陷入日常协调性的事务中而让自己整天处于疲于奔命的状态。同时完善流程还可以有效地帮助团队赋能，控制执行风险和结果，让团队去中心化并塑造良性的团队文化。
研发部门工作中一些核心流程的建设，包括产品开发流程、产品测试流程、用例评审流程和运维巡检流程。通过这些流程可以有效地提高团队工作效率。规范的作业流程可以减少因混乱造成的损失，同时也让团队职责清晰，做事有据可依，避免推诿扯皮的情况出现。
更多关于流程建设的内容，会在第7章详细讲解。
让团队依靠自律完成工作就像让胖子按照既定的减肥计划减肥一样，很难确保最终结果会令人满意，另外，团队成员很容易对每天按部就班的工作形成路径依赖，即使工作方式有问题也可能察觉不到，技术团队管理者要让团队摆脱路径依赖，重新审视团队的工作，快速熟悉和开展工作。
有经验的技术团队管理者会从规范制度入手，打造出符合团队发展的规范制度，通过规范制度中标准的输入动作，优化团队行为，影响团队的执行结果，形成更优秀的工作方式，让团队从中收获到成功的动力，由这种及时反馈的动力来推动团队前行，才能最终固化成团队的执行习惯。
更多关于规范建设的内容，会在第8章详细讲解。
互联网公司的高级工程师既需要把控公司的技术方向，又需要解决具体的技术难点，还需要针对产品需求进行需求分析和架构设计，他们是技术领导型人物，需要参与技术体系的搭建和技术氛围的营造，包括设计规划、代码评审、需求分析、技术分享、技术革新，是连接业务和技术的关键角色，如图1-3所示。
图1-3 高级工程师的工作职责
高级工程师对代码进行架构的时候，要清楚地知道业务发展规划和目标，要让架构适应业务，确保架构的高可用，减少架构的复杂性。不能盲目地追求前沿技术，适合公司当前业务发展的才是最好的。对于系统架构设计缺陷导致的问题，要合理评估风险及后续的影响点，尽量避免只对眼前故障的修复，对于影响较大的风险点要尽早重新设计架构，从根本上解决问题。
同时，还需要搭建持续集成（CI）平台，通过持续集成平台减少技术人员的重复工作。自动化的流程能够提高开发效率、减少重复工作并降低出错风险。每次通过自动化的构建来验证程序问题，能更快和更准确地发现问题所在。
技术人员在能力不足或项目工期紧的情况下，往往会写出一堆糟糕的代码，导致系统上线后各种小问题不断，高级工程师要经常进行代码评审，及时清理这些小问题，否则日积月累可能会引起线上发生重大的事故。
高级工程师在每次项目上线前，都要及时组织代码评审，提升技术人员的代码质量意识，形成质量规范，从而避免一些小问题的累积而造成线上事故的发生。同时每次代码评审都是技术人员学习和交流的机会，能促进团队不断思考和进步，代码评审这种协作方式很像结对编程，也是一种敏捷开发。对于代码评审要注意以下几点。
（1）检查编程规范。代码评审时严格按照规范检查，代码规范包括命名规范、代码规范、注释规范、日志规范、异常处理、多线程处理等。
（2）每次检查少量代码。每次评审的代码量不宜过多，评审的代码量过大会造成注意力很难高度集中，所以平时要增加评审的频次。
（3）代码审查清单。高级工程师要列一个代码审查清单，有一份代码审查清单可以避免检查项的遗漏。
（4）不以个人喜好评判别人。代码评审中不能以自身的喜好对别人的代码进行随意评价，更多的要从代码审查清单和功能实用性出发，同时评审中要就代码说事，不能对他人进行批评打击。
高级工程师要参与到初期的业务需求分析中，分析需求实现的可行性、风险点、开发成本等，只有对业务有清晰的了解，才能架构出满足业务需求的代码。
获取需求后，需要对需求进行详细的分析后才能设计出技术方案，技术方案的内容包括架构图、用例图、流程图、实现逻辑、库表设计、引用框架。好的方案是设计出来的，高级工程师对需求分析和设计要格外重视，确保需求实现的可靠性。
技术方案要整理成文档，文档的内容要清晰明确，以作为后续功能设计和测试用例编写的依据。在需求评审时，要认真比对产品需求，验证设计文档的完整性和正确性。
对于技术分享这件事情，很少有技术人员觉得是一种享受，其中一个原因可能是对分享后的结果预期并不看好，另一个重要的原因就是团队里没有人做表率。这时需要高级工程师做好表率，带动团队定期分享，通过分享构建一种学习文化，它是营造技术氛围的重要部分。对于分享内容可以不做限制，围绕工作和生活都可以，如总结成长心得、提升认知、提升解决问题的能力、提升沟通协调能力、好书分享等。
对于高级工程师，分享应该是其工作的一部分，其他人可以轮流或者自愿报名参与分享，分享的频次可以结合团队的实际情况，可以设定为每月2～6次。
高级工程师需要能够识别业务发展中的潜在业务需求，搭建好研发基础架构，构建高效的技术体系，打造一个指数型技术组织，推动技术和业务的高度融合，把技术转变为生产力，利用技术创新和技术提效工具推动业务高速增长。
除了关心技术能力和技术创新，高级工程师在技术变革中还要不断寻求合作和支持，包括向外寻求技术专家的合作，获取更前沿的技术；向上寻求领导的支持，获得更多的资源支持；向下寻求团队的认同，达成更高效的协作。将自己的想法不断推演，让更多的人可以参与进来，包括产品团队和业务团队，只有这样才能实现技术变革，才能通过技术创造更大的价值。
现在互联网公司项目经理的职位少了很多，一般由团队管理者、技术骨干或产品人员来担任管理项目的任务，但管理的内容却没有变化。项目负责人对项目的把控主要有制订计划、进度控制和质量控制这3个部分。
（1）制订计划。项目立项后，需要制订项目计划，制订项目计划包括确定目标、需求管理、需求分解、任务排序和工时估算。
（2）进度控制。项目实施时需要对项目进行进度把控，项目进度控制方法包括制订进度计划、每日站立会、进度看板和高效沟通等。
（3）质量控制。项目质量管理可以从代码质量分析平台和质量体系搭建入手，其中质量体系的搭建包括预防准备、过程管控和集成质量平台。
更多关于项目管理的内容，会在第4章详细讲解。
刚上任不久的技术团队管理者，还是会把很多精力投入到技术开发和难点攻克上，每次项目上线，总会忙得焦头烂额。团队规模扩大后，渐渐发现团队每天都有解决不完的问题，自己是团队里最忙、最累的那个，即使不眠不休也解决不了团队的所有难题，而这样疲于奔命的工作换来的团队的整体收益却并不一定高。
同时，技术人员又是一群脑力劳动者，敏感性较强，富有创造性，且工作内容变动性较大，因此带领这样的一群人，不能用传统的方式进行管理，而需要懂得授权和激励。
总体来说，带领这样一群人要遵循“抓大事，容小错”“放小事，担大责”“看细节，零容忍”的原则，如图1-4所示。
图1-4 带队原则
技术团队管理者首先要学会的就是放权，团队被充分的授权才有可能成长，但对于放权，有些技术团队管理者并不太愿意，觉得下属技术能力有限，代码实现的效果没有自己亲自开发的好，编码又不同于别的工作，一次小小的失败就可能会引发大的线上事故，评估风险和开发效率后，觉得只有自己亲自上阵才会放心。
技术团队管理者同时也怕放权后不能把控项目和技术细节，并且失去了权力，担心万一下属做得比自己好，也会对自己的职位构成威胁。这是典型的官僚主义，权力欲望过强，对控制欲望强的技术团队管理者而言，放权的确有很大的挑战。
其实放权并不是一味放手不管，聪明的技术团队管理者对下属放权应该抓大事，容小错，放手而不放任。如图1-5所示。
图1-5 放手和放任的基准
在授予下属权力的同时，要有监督机制。这样既能让下属放开手干，又能避免发生严重事故。对于交代的大事，其关键点要严格检查，这些关键点决定着事情的成败，控制好这些关键点，风险就能降低很多。在放权给下属的过程中难免会犯一些小的错误，技术团队管理者对此要有包容的心态，及时对下属进行指导和帮助，并通过流程和制度规范有效控制和避免错误的出现。
举例来说，项目开发中每天完成什么工作，需要和谁沟通等，这些下属都可以自己决定，按正常流程执行就行，无须实时把控。但项目的质量、工期、成本这些都是项目关键点，需要实时了解情况，有问题需要下属立刻汇报。对于开发中的一些细节，如代码规范、评审制定、交付要求等，这些都可以通过部门的制度规范进行要求。
技术团队管理者放权给下属做一些重要事情的时候，对细节和结果会非常关注，但放权给下属做一些小事时，技术团队管理者往往会忽略具体细节和过程，其实小事更能看出下属的责任心，小事做好了才能放心让他做更重要的事情。
现实中很多技术团队管理者把工作中的小事交给下属处理，经常不去过问，甚至在交代下属事情的时候，还会嘱咐下属“这件事情交给你了，你看着办就行，不用来问我”，实际上这并不是对下属的放权，而是对管理的弃权。
能力越强，责任越大，技术团队管理者要让下属明白，授权意味着信任，同时也意味着责任，能担多大责任，才能拥有多大权力。要想让员工敢于承担责任，还需要技术团队管理者塑造良好的职责文化，加强责任意识的培训，并改变员工对错误的认识。
授权后，下属可能会有很多问题解决不了，技术团队管理者可以试着引导下属寻找解决问题的答案或是和下属一起讨论解决方案。但不要直接告诉下属，即使技术团队管理者知道问题的答案，如果直接告诉对方，技术团队管理者也缺少了和下属互动的机会，同时也不利于下属摆脱向上依赖从而养成主动思考的习惯。
当下属负责的一些事情出现失误时，应要求下属及时记录具体的执行细节和具体问题，这些细节和问题都是日后复盘的重要信息，通过这些细节和问题可以帮助下属不断反思，快速纠正执行过程中的一些不当之处，避免重蹈覆辙。
正常情况下，团队都有一套标准的流程、制度、规范，做到把控关键点和授权常规事务并不算难事，只要跨过自身“权力”这道坎就可以。但抓核心细节，对于技术团队管理者的要求要高很多，要求技术团队管理者要有清晰的判断力和敏锐的思考力。
我们来看一个最能体现技术团队管理者抓核心细节的场景——技术方案评审。技术团队管理者需要细致地把控每一个技术点，不放过每一个技术细节。对于设计不足的方案，坚决不能通过技术评审环节，强调技术方案的重要性，细节决定成败。
对于细节管理，并不是要求技术团队管理者对团队所有的工作事无巨细和面面俱到，而是要求技术团队管理者在关键事项和关键结果上把控和监督执行细节。
技术人员有想法，不喜欢被限制，技术团队管理者可以先通过合理的流程制度，把技术体系搭建起来，有了完善的监督体系后再进行授权，充分调动各自的自主性和创造性。
