本文发表于《程序员》杂志2014年12期。
当一个研发团队人员数量达到一定规模时，点对点的平面式沟通模式势必成为团队发展的瓶颈，这时候管理岗位应运而生，一些技术人员也在“技而优则仕”的理念下走上了管理岗位。所谓管理，管的是人，理的是事情，无论哪个方面对技术出身刚踏入管理岗位的人而言都不是易事：有些人在做管理的事情，但思维还停留在技术上；有些人虽然思维已经在管理上，但苦于没有找到管理的模式和套路。是质变还是量变？本文基于团队管理角度，从管理人员的定位展开，阐述如何从技术走向管理。
管理人员是三方面角色的混合体：
解决技术转向管理所面临的难题，确保转变过程是质变而非量变的第一个要素就是确立正确的Mindset。下面这张表格是普通研发工程师和管理人员在Mindset上的对比，从表格中我们不难看出管理人员需要从以往的执着、专注、本位、创意转变到全面思维、计划管理、引导培育和沟通协调，即工作的范围和内容将从“I”字形转变到“T”字形。
从价值观而言，很多来自敏捷领域的思维模式都是需要被提倡的，如沟通、简单、反馈、勇气、公开和承诺。管理人员不仅仅是这些价值观的实践者，更应该是其倡导者。要想成为一名成功的管理人员，个人梳理了“2P3R”原则作为对其工作思想的指导，即：
如同CMMI、IPD等研发管理和过程模型所倡导一样，一件事情想要做成功，“如何正确的做事情”这一理念是被高度倡导的。那我们如何正确的做事情呢？这就需要进行过程管理和过程改进。过程涉及研发的各个方面，管理人员眼中的过程通常包括项目管理过程、产品管理过程、技术管理过程以及团队管理过程。过程是管理人员手中的武器，技术人员可能转向上述一个或多个方面的管理岗位，但业界普遍认为能提高产品开发和交付能力的过程实践以及相关工具也是在角色转变中所必须了解和掌握的。
技术转向管理首先需要关注研发模型。研发模型包含PACE、IPD、CMMI、SCRUM、XP、LEAN以及PMBOK中的内容，这些理念和模型都有其独到之处，但也各有其局限性。技术人员关注的更多的是技术本身，而管理人员需要根据团队现状和研发特点选择合适的研发管理和过程改进模型以提高团队服务交付能力。
应用生命周期和发布流水线是管理人员需要关注的另一方面。代码开发和维护工作自然重要，但对管理人员而言，项目/产品的生命周期以及围绕该生命周期展开的各项流程环节更是需要花时间和精力进行设计和监控以确保整个过程的正确性，常见的配置管理、版本控制、持续集成等都属于这一范畴。
围绕应用生命周期的各项制品（如代码、需求、文档、交付物等）一定程度上都需要通过工具进行有效管理和维护以确保信息的流转和跟踪。技术人员关注代码写的好，管理人员的视角在于信息透明性。我们通过需求分析把项目/产品的范围分解成一个个带有Ticket的任务，这些Ticket作为研发工作开展的基础，管理人员需要熟练掌握项目管理系统、版本控制系统、自动构建系统等工具从而通过这些Ticket进行范围和时间的把控。同时，对于管理人员而言，建设团队知识管理平台、规范邮件等基础工具的使用等都是日常工作中的一部分。
技术人员在团队中通常只需维系一种接口关系，即开发者接口，但对管理人员而言，在团队管理中通常需要充当三个主要接口，分别是团队外部接口、团队内部接口和组织级别接口。技术人员转向管理初期往往会因为对多接口的不适应而影响具体工作的开展。
团队外部接口一方面在于与外部团队在范围管理、时间管理和内部沟通模式上达成一致，另一方面与也应该协助质量保证团队确保最终服务的发布。
团队内部接口涉及团队各个方面，团队工作模式的选择和执行、工程实践的推广、团队代码质量的保证、团队会议的组织、团队工作过程的改进等都是内部接口的关注点。团队成员通常对内部接口有一定认识，但想要站在管理岗位上灵活推动和把控，需要技术人员从参与者到主导者的转变。
组织级别接口在部门、公司级别的结构化决策中提供过程资产的定义、研发团队管理经验、流程的改进意见等确保产品/项目全生命周期的完善以及组织过程资产的建设。
任何事情都包含重要性和紧急性这两个方面，根据四象限分析法，做重要但不紧急的事情是团队良性循环的基础。既要保证内部团队的高效运作，又要满足对外的各种要求，刚踏上管理岗位的技术人员需要培养对内、对外两个层面都能追求平衡的思路和技巧，这也是从技术走向管理中从量变到质变的过程。
技术走向管理，质变还是量变？--刊于《程序员》2014年12期
原文地址：http://blog.csdn.net/lantian08251/article/details/41980551
