我与团队共成长

在四年多软件测试生涯后，承蒙领导器重，我成为了官方认命的开发团队组长了。这个时间点其实不算特别早，很多过来人在工作两三年都做到了这个位置，但因为公司最近几年都没有怎么招人，而老员工基本都留下来了，所以空位并不多。这次空缺刚好是其中一个组长离职后，老板看重的一个技术同学对组长不感兴趣，老板挑中了我，毕竟半个老员工，加上平时的大局观，老板还是挺欣赏我的；两三个月后，另一个组的组长将调去别的组做项目经理，我也一起带那个组，感觉压力山大；同时，该领域有个外包小组，协同我们一起开发这个领域，自然也落入我的怀抱中。这里稍微提一下，外企的项目经理和架构师多是内部升职上去的，空降比较少，这和别的企业可能不太一样。

带团队，肯定得有自己的想法和做法，何况站在很多厉害的小组长之上。因为我对业务比较熟悉，对公司流程也比较熟悉，对同事也比较熟悉，到了这个职位，自然期望能够把自己的经验带给团队，也期望展示自己的实力，当然最重要的是一起成长。那我主要做了哪些事情呢？

1. 团队目标确认，打造一支业务精干随时迎接挑战的团队是我们的目标，化繁为简是我们的使命，从页面设计、导航跳转、优雅代码等角度说明怎么做到化繁为简。每个迭代我都会找出最好的例子，哪里体现出来我们的团队Slogan，工作中也不缺少美，缺少的是我们的发现。为此，我会关注团队实现饿每个需求，关注流程优化，关注代码评审和重构，从日常工作中得到体现我们团队使命的、蕴藏在工作中的点点滴滴。

2. 团队能力矩阵，就是本领域涉及的模块、本领域用到的工具语言、产品的整体认识和业务知识、通用技能进行评估，评估等级会有四种：了解、基本、资深、专家，每个等级都会有一定要求，这个标准会提前沟通。每个组员先进行自我评价，我安排短会逐个Review，形成团队个人能力矩阵表。当然我们不是期望每个条目都有专家，比如GIT使用，一般开发了解即可，配置管理员需要时专家。通过这个表格，可以发现团队的长处和薄弱点，比如有些重要领域没有backup；有些领域很重要但没有专家，需要培养；有些即将开始的项目需要的技能不在，需要给资深的同事或者有类似经验的同事提前准备开搞等。团队的整体能力矩阵其实也出来了，可以找出哪些是我们的优势，哪些是我们的劣势，结合公司战略，哪些是用需要重点关注的，一目了然。

3. 团队需求池定期与产品沟通，确认接下来几个月要做的事情，重点关注下一两个迭代要做的事情。需求通常包括业务需求和技术需求等，在满足业务需求的同事，技术也需要演进，比如组件升级、重构、新技术研究、创新点子实施、提前准备接下来开发需求的能力等。保证业务，同时技术有所积累，团队的同学有所成长，这才是最重要的。

4. 继续Scrum，但各个环节有章可循，并有所创新。具体指什么呢？从计划会议、站会、回顾会、演示会等多角度说明输入输出，说明一些最佳实践以及小小Tips，并在以身作则基础上，每个同学Rotate做Scrum Master，我全力协助。这样人人都熟悉流程，也就理解到做Scrum Master的不容易。当然，还得有微创新，回顾老三样：好的、值得改进的、改进措施，可以增加一词回顾环节，增加分享环节，即兴与有备错开等。比如即时贴分颜色，日常任务列表化（开发包括哪些任务，测试包含哪些任务等）。

5. 打造分享文化，每个迭代至少一次分享，鼓励大家进入公司级别或更高级别的分享。分享内容可以是新技术、新工具、踩过的坑、软件开发方法、产品介绍、培训心得、缺陷分析、持续集成策略、代码评审等最佳实践分享，这些内容来自团队内部或团队外部，不管再忙，我也尽量做到保持这个习惯，除非整个大项目团队已经有分享了。三个团队一起搞分享，这氛围就更浓了。

6. 激励团队，这真的是一门学问，需要继续探索。我的做法之一是把整个团队的事情分成几个大块，然后识别出最需要提升或者保持的领域，每个领域都有一个Prime。比如单元测试、TDD、重构、自动化测试、测试设计、文档、安全、创新、分享等大主题下都有一个Owner来驱动，当然我会列出一些需要做的事情，这些大家都可以行动起来，在自己的领域有专攻，在一段时间也可以做轮换。系统中的组件，也分别有Owner，以及对应的一个同事backup，目标是每个组件都有强人，遇到线上问题可以支持，开发设计也可以支持，内外部分享也可以支持，这个还是非常不错的。

作为团队小组长，除了在日常工作中与团队同甘共苦外，制定计划，进度跟进，准备数据和各种汇报，以及在公司战略指导下促进团队进步，同事考虑团队下一步的工作和成长。路漫漫其修远兮，吾将继续上下求索……