| 当一个研发或产品线团队人员数量达到几十人规模时，点对点的平面式沟通管理模式势必成为产品研发和团队发展的瓶颈，这时候就需要从人员组织架构上做出调整，即从点对点的平面式管理转换为金字塔型的梯队式管理。作为一个研发团队，技术研发主管（本文指的是带领一个小团队进行研发和管理工作，团队规模通常在3~7人之间）作为梯队式管理中的基层主管在技术人员管理以及产品开发过程把握上发挥其核心作用。本文从团队管理角度出发，从技术研发主管的定位开始展开，对如何培养和建设技术主管队伍从以下几个方面进行阐述：
1.个人
2.过程
3.工具
4.团队
我举一张龙舟图对研发主管的定位进行描述，见下图。图中除了坐在船体里划桨的队员之外，最重要的莫过于站在船头的擂鼓手和站在船尾的舵手。个人认为舵手就像团队中的产品经理为团队把握前进的方向，而擂鼓手则是我们的研发主管为技术团队加油助威、保持冲劲和斗志。
对上述定位进行细化，研发主管充当了三方面主要的角色：
1.Facilitator：作为技术团队和外部团队（如产品团队、项目团队、运营团队等）的协调人，对整个产品开发过程的统一高效起到协作和润滑作用。
2.Problem Solver：作为团队中技术方面的权威，通常需要主导解决开发过程中的疑难问题。
3.Teacher：作为管理人员，负责对新人的培训和指导，确保研发团队认知水平和工作模式达到一致。
针对以上三种角色，研发主管在研发资源的有效运用、Know-How的传承、研发流程的推动、工程师的人才培育以及技术问题的解决上将需要起到其关键作用。正如“Conway‘s
Law”中所描述的那样：一个软件设计和开发的结果，很大程度上反应了团队的组织与沟通架构，而研发主管作为组织与沟通架构中的重要一环其重要性是显而易见的。
然而在肯定研发主管作用的同时，也不得不承认其面临的挑战。传统行业的主管的核心任务是整合，即要求团队成员步调一致，大家站在一起稳步朝前走；而互联网行业中的研发工程师们确有其独特的创造性，很多时候有其自身的想法和判断，这就要求研发主管既要对团队进行整合又要发挥团队成员的差异性，如同项目管理我们需要追求一种平衡一样，研发主管也面临着同样的难题。
解决上述难题的方法我认为有两个方面：一方面从组织级别需要为研发主管们提供一个Platform，包括相对完备的基础设施（如研发管理的工具、人员管理的规章制度等）、工作流程（如内部标准测试流程）等；另一方面也需要研发主管自身确立一套Mindset，包括工作的思路和方法论、主观意愿等。下面我们就先从“个人”角度出发谈谈研发主管所应该具有的综合能力和面临的转变。
一. 个人
下面这张表格是普通研发工程师和研发主管之间的对比，从表格中我们不难看出研发主管需要从以往的执着、专注、本位、创意转变到全面思维、计划管理、引导培育和沟通协调，即工作的范围和内容将从“I”字形转变到“T”字形：
从价值观而言，很多来自敏捷领域的思维模式都是需要被提倡的，如沟通、简单、反馈、勇气、公开和承诺。这里不再展开，可参考XP和Scrum相关书籍。
要想成为一名成功的研发主管，国外学者梳理了“4个P”作为对其工作思想的指导，即：
1.Pencil&Paper（将过程付诸记录）
2.Plan（计划引导成功的方向）
3.Passion（热诚驱动一切）
4.Perform（个人及行动的组合）
个人觉得这个“4个P”对其他领域的管理也是通用的。研发人员从创意中不断获取技术所带来的成就感，对研发主管而言，当管理本身也变成一种创意时，所面对的可能就是一个充满战斗力和激情的研发团队。
二. 过程
从类如CMMI、IPD这样的过程模型所倡导的理论思想而言，一件事情想要做成功，“如何正确的做事情”这一理念是被高度倡导的。那我们如何正确的做事情呢？这就需要进行过程管理和过程改进。狭义技术层面的过程管理可能没有像产品、项目或者组织级别所定义和关注的那么全面和重要（个人觉得多数情况下没必要和不可行，这同样也是一种平衡），但常识性的、业界普遍认为能提高产品开发和交付能力的过程实践也是研发主管做必须了解和掌握的。类似过程可能有很多，我在这里仅列举自身周围特定环境下比较有针对性的几点：
1. 版本控制
版本控制对技术人员而言不是一个新词，但在技术管理各个方面都不完善的环境下，版本控制也就需要作为一个核心过程进行统一管理和把控，我通过问答式进行简要说明。
1.版本控制的思路和目标？开发部署分离、版本可见和版本一致这三点是版本控制的基本思想，目标是在研发过程中形成一致的认识。
2.版本在哪里控制？版本控制的思想无处不在，内部测试和服务发布是其中最需要在全体成员之间形成统一规范的两个方面。内部测试中的版本控制用于与QA等部门之间的交互和协作；服务发布则作为正式的服务交付进行控制。
3.版本控制的范围？对一般系统而言，表现端、服务器端、数据库是需要明确进行版本控制的范围。尤其对数据库版本的控制是在团队协作、特别是分布式团队协作环境下的一大难点。
4.版本控制的重要性？从团队协作的角度看，合理的版本控制会促进信息透明跟踪和尽早发现问题；从服务提供者的角度看，版本控制对减小出错概率和维护成本而言也能提高用户满意度、降低实施和运营成本。
2. 配置管理
配置管理（CM）同样不是新词，在类如过程改进模型CMMI或产品研发体系IPD中都有明确的说明和指导，但对技术人员而言普遍没有形成统一的认识和实践模式。配置管理中主要包含基线（Baseline）、配置项（CI）和变更控制（Change
Control）等重要概念，虽然配置管理更多应该属于是项目管理上的范畴，但在研发主管的Mindset中，如何管理系统的配置项、维护代码基线的稳定性也是日常研发管理中的一项重要任务。
3. 持续集成
持续集成是敏捷领域的一项核心实践，在《持续集成：软件质量改进和风险降低之道》这本书中，作者把持续集成抽象成如下的效果图：
从图中可以看到，完整的理想模式下的持续集成需要从代码编译、数据库集成、测试和审查以及服务部署各个方面进行集成和反馈，从而达到提升质量和降低风险的目标。实际环境下根据产品开发的场景，研发主管应对集成的程度、方式和频率进行把控，做到集成的成本和效果之间达到平衡，毕竟类似数据库集成等领域无论在理论和实践上都需要较高的要求，但持续集成的确为信息的反馈和透明提供了有效的手段和模式。
4. 过程自动化
从过程改进角度而言，过程的自动化是一个可以持续进行尝试和探讨的入手点，对提高开发效率、降低由人为因素所引起的错误起到促进作用。日常工作中，过程自动化在潜移默化中影响着研发团队内部以及跨团队协作流程，研发主管工作相关的自动化过程通常包括如下领域，我们通过Ant、Python等脚本或Jenkins等工具平台进行过程自动化建设。
1.程序开发，例如使用Ant脚本在代码编译过程中引用多方资源并形成统一服务
2.功能测试，例如使用Jenkins在构建过程中执行JUnit单元测试
3.系统部署，例如使用tomcat maven插件进行war包在tomcat容器中的自动化部署
4.服务发布，例如使用Python脚本生成面向各种Android市场的apk发布包
5. 部署流水线
代码开发和维护工作自然重要，但对研发主管而言，项目/产品的生命周期以及围绕该生命周期展开的各项流程环节更是需要花时间和精力进行设计和监控以确保整个过程的正确性。下面是一般系统开发所具有的部署流水线，该部署流水线整合了多个过程中的要素并形成了面向开发、测试和运维团队的统一工作流。
通常测试人员和运维人员技术水平相对较弱，碰到技术问题往往找研发人员进行解决，所以研发主管在部署流水线中需要起到主导作用，通过合理运行自动化工具、配置管理策略参与建立内部测试和发布流程，为外围团队（项目管理、实施运维等）提供高效易操作的技术接口，从而提高服务发布和运行的客户满意度。
三. 工具
为什么工具对于研发主管而言很重要？因为针对重复性或耗时过长的工作，我们可以利用工具来改善过程；针对自身能力或工作上存在的弱点我们也可以利用工具弥补。尤其对于研发过程而言，团队工具的使用一致性和有效性对团队工作效率有直接关系，同一个工具不同人采用不同的使用方式导致系统集成、功能测试等出现问题的现象也是屡见不鲜。研发主管作为一个Mentor，需要对整个团队的工具本身及其使用模式进行把控和协调，确保团队所有人认识一致。
关于工具有一条定律：没有最好的工具，只有最适合自己的工具；工具只有培养使用习惯后，才称之为工具。个人很喜欢，也觉得研发主管需要梳理团队中的工作流程，根据流程确定最适合自身团队的工具和使用模式。
说起工具，我们要提一个感念叫“ALM”（即Application Lifecycle
Management，应用生命周期管理），后续讲的各种工具也是围绕着ALM这个主题进行展开，而不是简单的独立介绍某个工具而已。结合“AgileALM:
Lightweight tools and Agile strategies”这本书中提到的概念，作为研发主管眼中的ALM包含的内容可能是长成这样：
上图中的各项中的制品（如代码、需求、文档、交付物等）一定程度上都需要通过工具进行有效管理和维护以确保信息的流转和跟踪，下图就是这一思路在具体工具上的一种表现形式：
对研发线而言，通过需求分析把项目/产品的范围分解成一个个带有Ticket的任务，该Ticket作为研发工作开展的基础。从上图中我们可以看到这个Ticket贯穿了整个ALM，而ALM中的每一步都有某一个工具管理着该Ticket。如：
1.Redmine：项目、研发、缺陷管理的统一平台，作为基本的Ticket系统对项目/产品范围和时间进行管理。为问题跟踪、进度控制和团队协作提供平台和视图
2.Eclipse：主流开发工具，同时又是强大的集成平台，可通过Redmine
Mylyn Connector集成Redmine；通过Subclipse集成SVN；通过Jenkins
Mylyn Connector集成Jenkins；也可进行Maven、Tomcat等工具的整合
3.SVN：配置管理工具，系统代码、文档和资源存档的工作平台
4.Jenkins：主流持续集成平台，自动化构建、服务发布、代码审查工具
另外作为研发主管，对团队进行知识管理和沟通管理也是日常工作中的一部分，涉及到：
1.OneNote：Office自带的知识管理平台，可建立企业内部服务完成团队内各个成员知识以及组织级别基本信息的共享
2.Email：沟通和协作的基本媒介，明确细节、追踪状态、安排事情以及进行历史记录备份
以上工具市面上类似的很多，也都大同小异，可做类比。后续会有专题对工具进行详细介绍，熟练掌握这些工具将成为研发主管手中强大的武器。
四. 团队
通常一个产品线研发团队的主要角色以及数据流如下，PO（产品经理）作为产品线的核心角色与各方都需要进行交互和协作；PM（项目经理）根据项目输入将产品线功能转化为项目范围，并对时间和成本进行监控；DEV（研发人员）负责系统设计和功能实现；而QA（质量保证人员）根据需求对DEV的制品进行验证和确认，并保证流程的正确性。
根据上图结合组织发展的需要，从团队角度出发研发主管充当三个主要接口：
1.团队外部接口：DEV主要和PO和QA之间有直接的交互和协作（与PM相对较少），这个交互和协作的接口通常就是研发主管，这是对外的接口
2.团队内部接口：研发主管作为DEV的Leader，对内部开发人员而言也有一层对内的接口
3.组织级别接口：研发主管是组织技术管理方面的中坚力量，对组织过程改进也会贡献自身的力量
团队对外接口工作一方面在于通过Ticket系统与PO在范围管理、时间管理和内部沟通模式上达成一致；另一方面与也应该通过Ticket系统与QA进行Bug管理、问题跟踪，并协助QA进行最终服务的发布。
团队内部接口是研发主管团队管理的重点，个人觉得有代表性的工作包括：
1.开发模式的选择和执行：主流的开发模式大体分成瀑布和敏捷两大阵营，我们这里不探讨两大类模式的优劣，但根据项目周期和特点作出合适的选择是研发主管需要考虑的。如果选择类如瀑布的阶段性模型，则把握各个Stage-Gate变成工作流程的重点；如果选择敏捷，则推行诸如Stand-up
Meeting等各项敏捷实践是研发主管的日常工作。
2.团队代码质量的保证：代码的同级评审时保证代码质量的有效手段，具体展开的方式有很多种，但大致都会按照如下的流程进行。研发主管主导代码的同级评审过程，采用代码走查、审查、集体Review等一种或多种形式，并推广代码重构的方法论和实践方法。
系统设计会议的组织：产品/项目开发一种比较合理的模式是产品/项目确定范围，开发人员确定开发的时间和阶段。作为对外接口工作的一部分，研发主管需要在团队内部组织系统设计会议以指定初步的开发计划。通常涉及根据需求讨论和设计功能实现方案；拆分功能点为任务、指派人员并录入到Ticket系统上；根据Ticket系统上任务确定开发顺序和进度计划等步骤。
团队工作过程的改进：管理的本质是持续不断的改进。过程改进通常遵循质量管理大师戴明提出的PDCA环，在工作开展中，个人认为定期组织研发回顾会议是团队工作改进最有效的方式。回顾的一般流程、工具和活动可参考：
研发主管组织级别接口在部门、公司级别的结构化决策中提供过程资产的定义、研发团队管理经验、流程的改进意见等确保产品/项目全生命周期的完善以及组织过程资产的建设。各个组织可能会有不同的方式和流程，这里不展开。
讲完”个人、过程、工具和团队“四个方面之后，我们来看一下任何一件事情的两个方面：重要性和紧急性。根据四象限分析法，做重要但不紧急的事情是团队良性循环的基础。但现实中我们往往在做即重要又紧急的事情，进度管理也往往不是研发人员能够单方面决定。既要保证内部团队的高效运作，又要满足对外项目经理、产品经理的各种要求，研发主管需要培养对外、对内两个层面都能追求一种平衡的思路和技巧。
| 
