当一个研发或产品线团队人员数量达到几十人规模时，点对点的平面式沟通管理模式势必成为产品研发和团队发展的瓶颈，这时候就需要从人员组织架构上做出调整，即从点对点的平面式管理转换为金字塔型的梯队式管理。作为一个研发团队，技术研发主管作为梯队式管理中的基层主管在技术人员管理以及产品开发过程把握上发挥其核心作用。本文从团队管理角度出发，从技术研发主管的定位开始展开，对如何培养和建设技术主管队伍从以下几个方面进行阐述：

• 个人
• 过程
• 工具
• 团队

我举一张龙舟图对研发主管的定位进行描述，见下图。图中除了坐在船体里划桨的队员之外，最重要的莫过于站在船头的擂鼓手和站在船尾的舵手。个人认为舵手就像团队中的产品经理为团队把握前进的方向，而擂鼓手则是我们的研发主管为技术团队加油助威、保持冲劲和斗志。

对上述定位进行细化，研发主管充当了三方面主要的角色：

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

针对以上三种角色，研发主管在研发资源的有效运用、Know-How的传承、研发流程的推动、工程师的人才培育以及技术问题的解决上将需要起到其关键作用。正如“Conway‘s Law”中所描述的那样：一个软件设计和开发的结果，很大程度上反应了团队的组织与沟通架构，而研发主管作为组织与沟通架构中的重要一环其重要性是显而易见的。

然而在肯定研发主管作用的同时，也不得不承认其面临的挑战。传统行业的主管的核心任务是整合，即要求团队成员步调一致，大家站在一起稳步朝前走；而互联网行业中的研发工程师们确有其独特的创造性，很多时候有其自身的想法和判断，这就要求研发主管既要对团队进行整合又要发挥团队成员的差异性，如同项目管理我们需要追求一种平衡一样，研发主管也面临着同样的难题。

解决上述难题的方法我认为有两个方面：一方面从组织级别需要为研发主管们提供一个Platform，包括相对完备的基础设施（如研发管理的工具、人员管理的规章制度等）、工作流程（如内部标准测试流程）等；另一方面也需要研发主管自身确立一套Mindset，包括工作的思路和方法论、主观意愿等。下面我们就先从“个人”角度出发谈谈研发主管所应该具有的综合能力和面临的转变。

一. 个人

下面这张表格是普通研发工程师和研发主管之间的对比，从表格中我们不难看出研发主管需要从以往的执着、专注、本位、创意转变到全面思维、计划管理、引导培育和沟通协调，即工作的范围和内容将从“I”字形转变到“T”字形：

从价值观而言，很多来自敏捷领域的思维模式都是需要被提倡的，如沟通、简单、反馈、勇气、公开和承诺。这里不再展开，可参考XP和Scrum相关书籍。

要想成为一名成功的研发主管，国外学者梳理了“4个P”作为对其工作思想的指导，即：

• Pencil&Paper（将过程付诸记录）
• Plan（计划引导成功的方向）
• Passion（热诚驱动一切）
• Perform（个人及行动的组合）

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

二. 过程

从类如CMMI、IPD这样的过程模型所倡导的理论思想而言，一件事情想要做成功，“如何正确的做事情”这一理念是被高度倡导的。那我们如何正确的做事情呢？这就需要进行过程管理和过程改进。狭义技术层面的过程管理可能没有像产品、项目或者组织级别所定义和关注的那么全面和重要（个人觉得多数情况下没必要和不可行，这同样也是一种平衡），但常识性的、业界普遍认为能提高产品开发和交付能力的过程实践也是研发主管做必须了解和掌握的。类似过程可能有很多，我在这里仅列举自身周围特定环境下比较有针对性的几点：

1.  版本控制

版本控制对技术人员而言不是一个新词，但在技术管理各个方面都不完善的环境下，版本控制也就需要作为一个核心过程进行统一管理和把控，我通过问答式进行简要说明。

• 版本控制的思路和目标？开发部署分离、版本可见和版本一致这三点是版本控制的基本思想，目标是在研发过程中形成一致的认识。
• 版本在哪里控制？版本控制的思想无处不在，内部测试和服务发布是其中最需要在全体成员之间形成统一规范的两个方面。内部测试中的版本控制用于与QA等部门之间的交互和协作；服务发布则作为正式的服务交付进行控制。
• 版本控制的范围？对一般系统而言，表现端、服务器端、数据库是需要明确进行版本控制的范围。尤其对数据库版本的控制是在团队协作、特别是分布式团队协作环境下的一大难点。
• 版本控制的重要性？从团队协作的角度看，合理的版本控制会促进信息透明跟踪和尽早发现问题；从服务提供者的角度看，版本控制对减小出错概率和维护成本而言也能提高用户满意度、降低实施和运营成本。

2.  配置管理

配置管理（CM）同样不是新词，在类如过程改进模型CMMI或产品研发体系IPD中都有明确的说明和指导，但对技术人员而言普遍没有形成统一的认识和实践模式。配置管理中主要包含基线（Baseline）、配置项（CI）和变更控制（Change Control）等重要概念，虽然配置管理更多应该属于是项目管理上的范畴，但在研发主管的Mindset中，如何管理系统的配置项、维护代码基线的稳定性也是日常研发管理中的一项重要任务。

3.  持续集成

持续集成是敏捷领域的一项核心实践，在《持续集成：软件质量改进和风险降低之道》这本书中，作者把持续集成抽象成如下的效果图：

从图中可以看到，完整的理想模式下的持续集成需要从代码编译、数据库集成、测试和审查以及服务部署各个方面进行集成和反馈，从而达到提升质量和降低风险的目标。实际环境下根据产品开发的场景，研发主管应对集成的程度、方式和频率进行把控，做到集成的成本和效果之间达到平衡，毕竟类似数据库集成等领域无论在理论和实践上都需要较高的要求，但持续集成的确为信息的反馈和透明提供了有效的手段和模式。

4.  过程自动化

从过程改进角度而言，过程的自动化是一个可以持续进行尝试和探讨的入手点，对提高开发效率、降低由人为因素所引起的错误起到促进作用。日常工作中，过程自动化在潜移默化中影响着研发团队内部以及跨团队协作流程，研发主管工作相关的自动化过程通常包括如下领域，我们通过Ant、Python等脚本或Jenkins等工具平台进行过程自动化建设。

• 程序开发，例如使用Ant脚本在代码编译过程中引用多方资源并形成统一服务
• 功能测试，例如使用Jenkins在构建过程中执行JUnit单元测试
• 系统部署，例如使用tomcat maven插件进行war包在tomcat容器中的自动化部署
• 服务发布，例如使用Python脚本生成面向各种Android市场的apk发布包

5.  部署流水线

代码开发和维护工作自然重要，但对研发主管而言，项目/产品的生命周期以及围绕该生命周期展开的各项流程环节更是需要花时间和精力进行设计和监控以确保整个过程的正确性。下面是一般系统开发所具有的部署流水线，该部署流水线整合了多个过程中的要素并形成了面向开发、测试和运维团队的统一工作流。

通常测试人员和运维人员技术水平相对较弱，碰到技术问题往往找研发人员进行解决，所以研发主管在部署流水线中需要起到主导作用，通过合理运行自动化工具、配置管理策略参与建立内部测试和发布流程，为外围团队（项目管理、实施运维等）提供高效易操作的技术接口，从而提高服务发布和运行的客户满意度。

本文主要就从“个人和过程"角度对如何成为研发主管进行阐述，关于"工具和团队"请参阅《如何成为一名研发主管--关于个人、过程、工具和团队之二》。

如何成为一名研发主管--关于个人、过程、工具和团队之一