技术走向管理，质变还是量变？--刊于《程序员》2014年12期

本文发表于《程序员》杂志2014年12期。

当一个研发团队人员数量达到一定规模时，点对点的平面式沟通模式势必成为团队发展的瓶颈，这时候管理岗位应运而生，一些技术人员也在“技而优则仕”的理念下走上了管理岗位。所谓管理，管的是人，理的是事情，无论哪个方面对技术出身刚踏入管理岗位的人而言都不是易事：有些人在做管理的事情，但思维还停留在技术上；有些人虽然思维已经在管理上，但苦于没有找到管理的模式和套路。是质变还是量变？本文基于团队管理角度，从管理人员的定位展开，阐述如何从技术走向管理。

1. 何为管理人员？

管理人员是三方面角色的混合体：

• Facilitator：作为研发团队和外部团队（如产品团队、项目团队、运营团队等）的协调人，对整个产品开发过程的统一高效起到协作和润滑作用。
• Problem Solver：作为团队中某一方面的权威，通常需要主导解决研发过程中的疑难问题。
• Teacher：作为管理人员，负责对团队成员的培训和指导，确保研发团队认知水平和工作模式达到一致。

针对以上三种角色，管理人员在研发资源的有效运用、Know-How的传承、研发流程的推动、技术人员的人才培育以及问题的解决上将需要起到关键作用。正如“Conway‘s Law”中所描述的那样：一个软件设计和开发的结果，很大程度上反应了团队的组织与沟通架构，而管理人员作为组织与沟通架构中的重要一环其重要性是显而易见的。然而在肯定管理人员作用的同时，也不得不承认其面临的挑战。传统行业管理的核心任务是整合，即要求团队成员步调一致，大家站在一起稳步朝前走；而软件行业中的研发工程师们却有其独特的创造性，很多时候有其自身的想法和判断，这就要求管理人员既要对团队进行整合又要发挥团队成员的差异性，如同项目管理我们需要追求一种平衡一样，管理人员也面临着同样的难题。

2. 关于Mindset

解决技术转向管理所面临的难题，确保转变过程是质变而非量变的第一个要素就是确立正确的Mindset。下面这张表格是普通研发工程师和管理人员在Mindset上的对比，从表格中我们不难看出管理人员需要从以往的执着、专注、本位、创意转变到全面思维、计划管理、引导培育和沟通协调，即工作的范围和内容将从“I”字形转变到“T”字形。

从价值观而言，很多来自敏捷领域的思维模式都是需要被提倡的，如沟通、简单、反馈、勇气、公开和承诺。管理人员不仅仅是这些价值观的实践者，更应该是其倡导者。要想成为一名成功的管理人员，个人梳理了“2P3R”原则作为对其工作思想的指导，即：

• Plan：计划引导成功的方向
• Perform：个人及行动的组合，执行力
• Record：将过程与结果付诸记录
• Responsibility：责任确保对团队的把握
• Rule：规则为工作展开奠定基础

以上这“2P3R”原则对其他领域的管理也是通用的。技术人员从创意中不断获取技术所带来的成就感，而对技术出身的管理人员而言，当管理本身也变成一种创意时，所带领的可能就是一个充满战斗力和激情的研发团队。

3. 过程与工具

如同CMMI、IPD等研发管理和过程模型所倡导一样，一件事情想要做成功，“如何正确的做事情”这一理念是被高度倡导的。那我们如何正确的做事情呢？这就需要进行过程管理和过程改进。过程涉及研发的各个方面，管理人员眼中的过程通常包括项目管理过程、产品管理过程、技术管理过程以及团队管理过程。过程是管理人员手中的武器，技术人员可能转向上述一个或多个方面的管理岗位，但业界普遍认为能提高产品开发和交付能力的过程实践以及相关工具也是在角色转变中所必须了解和掌握的。

技术转向管理首先需要关注研发模型。研发模型包含PACE、IPD、CMMI、SCRUM、XP、LEAN以及PMBOK中的内容，这些理念和模型都有其独到之处，但也各有其局限性。技术人员关注的更多的是技术本身，而管理人员需要根据团队现状和研发特点选择合适的研发管理和过程改进模型以提高团队服务交付能力。

应用生命周期和发布流水线是管理人员需要关注的另一方面。代码开发和维护工作自然重要，但对管理人员而言，项目/产品的生命周期以及围绕该生命周期展开的各项流程环节更是需要花时间和精力进行设计和监控以确保整个过程的正确性，常见的配置管理、版本控制、持续集成等都属于这一范畴。

围绕应用生命周期的各项制品（如代码、需求、文档、交付物等）一定程度上都需要通过工具进行有效管理和维护以确保信息的流转和跟踪。技术人员关注代码写的好，管理人员的视角在于信息透明性。我们通过需求分析把项目/产品的范围分解成一个个带有Ticket的任务，这些Ticket作为研发工作开展的基础，管理人员需要熟练掌握项目管理系统、版本控制系统、自动构建系统等工具从而通过这些Ticket进行范围和时间的把控。同时，对于管理人员而言，建设团队知识管理平台、规范邮件等基础工具的使用等都是日常工作中的一部分。

4. 再论团队

技术人员在团队中通常只需维系一种接口关系，即开发者接口，但对管理人员而言，在团队管理中通常需要充当三个主要接口，分别是团队外部接口、团队内部接口和组织级别接口。技术人员转向管理初期往往会因为对多接口的不适应而影响具体工作的开展。

团队外部接口一方面在于与外部团队在范围管理、时间管理和内部沟通模式上达成一致，另一方面与也应该协助质量保证团队确保最终服务的发布。

团队内部接口涉及团队各个方面，团队工作模式的选择和执行、工程实践的推广、团队代码质量的保证、团队会议的组织、团队工作过程的改进等都是内部接口的关注点。团队成员通常对内部接口有一定认识，但想要站在管理岗位上灵活推动和把控，需要技术人员从参与者到主导者的转变。

组织级别接口在部门、公司级别的结构化决策中提供过程资产的定义、研发团队管理经验、流程的改进意见等确保产品/项目全生命周期的完善以及组织过程资产的建设。

5. 小结

任何事情都包含重要性和紧急性这两个方面，根据四象限分析法，做重要但不紧急的事情是团队良性循环的基础。既要保证内部团队的高效运作，又要满足对外的各种要求，刚踏上管理岗位的技术人员需要培养对内、对外两个层面都能追求平衡的思路和技巧，这也是从技术走向管理中从量变到质变的过程。