《如何成为一名研发主管--关于个人、过程、工具和团队之一》中对研发主管的”个人和过程“两方面进行了阐述，本文对剩余的”工具和团队“两个方面进行进一步说明。

三. 工具

为什么工具对于研发主管而言很重要？因为针对重复性或耗时过长的工作，我们可以利用工具来改善过程；针对自身能力或工作上存在的弱点我们也可以利用工具弥补。尤其对于研发过程而言，团队工具的使用一致性和有效性对团队工作效率有直接关系，同一个工具不同人采用不同的使用方式导致系统集成、功能测试等出现问题的现象也是屡见不鲜。研发主管作为一个Mentor，需要对整个团队的工具本身及其使用模式进行把控和协调，确保团队所有人认识一致。

关于工具有一条定律：没有最好的工具，只有最适合自己的工具；工具只有培养使用习惯后，才称之为工具。个人很喜欢，也觉得研发主管需要梳理团队中的工作流程，根据流程确定最适合自身团队的工具和使用模式。

说起工具，我们要提一个感念叫“ALM”（即Application Lifecycle Management，应用生命周期管理），后续讲的各种工具也是围绕着ALM这个主题进行展开，而不是简单的独立介绍某个工具而已。结合“AgileALM: Lightweight tools and Agile strategies”这本书中提到的概念，作为研发主管眼中的ALM包含的内容可能是长成这样：

上图中的各项中的制品（如代码、需求、文档、交付物等）一定程度上都需要通过工具进行有效管理和维护以确保信息的流转和跟踪，下图就是这一思路在具体工具上的一种表现形式：

对研发线而言，通过需求分析把项目/产品的范围分解成一个个带有Ticket的任务，该Ticket作为研发工作开展的基础。从上图中我们可以看到这个Ticket贯穿了整个ALM，而ALM中的每一步都有某一个工具管理着该Ticket。如：

• Redmine：项目、研发、缺陷管理的统一平台，作为基本的Ticket系统对项目/产品范围和时间进行管理。为问题跟踪、进度控制和团队协作提供平台和视图
• Eclipse：主流开发工具，同时又是强大的集成平台，可通过Redmine Mylyn Connector集成Redmine；通过Subclipse集成SVN；通过Jenkins Mylyn Connector集成Jenkins；也可进行Maven、Tomcat等工具的整合
• SVN：配置管理工具，系统代码、文档和资源存档的工作平台
• Jenkins：主流持续集成平台，自动化构建、服务发布、代码审查工具

另外作为研发主管，对团队进行知识管理和沟通管理也是日常工作中的一部分，涉及到：

• OneNote：Office自带的知识管理平台，可建立企业内部服务完成团队内各个成员知识以及组织级别基本信息的共享
• Email：沟通和协作的基本媒介，明确细节、追踪状态、安排事情以及进行历史记录备份

以上工具市面上类似的很多，也都大同小异，可做类比。后续会有专题对工具进行详细介绍，熟练掌握这些工具将成为研发主管手中强大的武器。

四. 团队

通常一个产品线研发团队的主要角色以及数据流如下，PO（产品经理）作为产品线的核心角色与各方都需要进行交互和协作；PM（项目经理）根据项目输入将产品线功能转化为项目范围，并对时间和成本进行监控；DEV（研发人员）负责系统设计和功能实现；而QA（质量保证人员）根据需求对DEV的制品进行验证和确认，并保证流程的正确性。

根据上图结合组织发展的需要，从团队角度出发研发主管充当三个主要接口：

• 团队外部接口：DEV主要和PO和QA之间有直接的交互和协作（与PM相对较少），这个交互和协作的接口通常就是研发主管，这是对外的接口
• 团队内部接口：研发主管作为DEV的Leader，对内部开发人员而言也有一层对内的接口
• 组织级别接口：研发主管是组织技术管理方面的中坚力量，对组织过程改进也会贡献自身的力量

团队对外接口工作一方面在于通过Ticket系统与PO在范围管理、时间管理和内部沟通模式上达成一致；另一方面与也应该通过Ticket系统与QA进行Bug管理、问题跟踪，并协助QA进行最终服务的发布。

团队内部接口是研发主管团队管理的重点，个人觉得有代表性的工作包括：

• 开发模式的选择和执行：主流的开发模式大体分成瀑布和敏捷两大阵营，我们这里不探讨两大类模式的优劣，但根据项目周期和特点作出合适的选择是研发主管需要考虑的。如果选择类如瀑布的阶段性模型，则把握各个Stage-Gate变成工作流程的重点；如果选择敏捷，则推行诸如Stand-up Meeting等各项敏捷实践是研发主管的日常工作。
• 团队代码质量的保证：代码的同级评审时保证代码质量的有效手段，具体展开的方式有很多种，但大致都会按照如下的流程进行。研发主管主导代码的同级评审过程，采用代码走查、审查、集体Review等一种或多种形式，并推广代码重构的方法论和实践方法。

• 系统设计会议的组织：产品/项目开发一种比较合理的模式是产品/项目确定范围，开发人员确定开发的时间和阶段。作为对外接口工作的一部分，研发主管需要在团队内部组织系统设计会议以指定初步的开发计划。通常涉及根据需求讨论和设计功能实现方案；拆分功能点为任务、指派人员并录入到Ticket系统上；根据Ticket系统上任务确定开发顺序和进度计划等步骤。
• 团队工作过程的改进：管理的本质是持续不断的改进。过程改进通常遵循质量管理大师戴明提出的PDCA环，在工作开展中，个人认为定期组织研发回顾会议是团队工作改进最有效的方式。回顾的一般流程、工具和活动可参考：

研发主管组织级别接口在部门、公司级别的结构化决策中提供过程资产的定义、研发团队管理经验、流程的改进意见等确保产品/项目全生命周期的完善以及组织过程资产的建设。各个组织可能会有不同的方式和流程，这里不展开。

讲完”个人、过程、工具和团队“四个方面之后，我们来看一下任何一件事情的两个方面：重要性和紧急性。根据四象限分析法，做重要但不紧急的事情是团队良性循环的基础。但现实中我们往往在做即重要又紧急的事情，进度管理也往往不是研发人员能够单方面决定。既要保证内部团队的高效运作，又要满足对外项目经理、产品经理的各种要求，研发主管需要培养对外、对内两个层面都能追求一种平衡的觉悟和思路。

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