IT研发团队管理容易忽视的那些事

背景介绍

       面对VUCA环境，很多公司都急切期望用更少的成本来达成或超越业务目标，当前市面上已经涌现出很多的方法，如敏捷方法、精益思想、DevOps、持续交付、等。不可否认这些方法取得很多不错的成效，这里就不做太多的陈述了。面对复杂的业务领域，作为技术体系该怎么样的应对这样的环境挑战呢？建议技术体系在如下方面发力：

• 团队管理方面
• 技术管理方面
• 持续改进

Part-1：团队管理方面

       在软件交付流中人是很重要的，而软件实现团队更是注重之重，那么团队能力、协作方式、等方面是技术 Leader是需要重点关注的。

团队能力提升

       业务领域学习：在面向强业务领域，作为软件实现团队在具备软件实现的基本功，还得利用业余时间学习相关的业务知识，这样团队在和业务领域专家沟通就可以很好的与业务专家在同一个上下文进行交流，如：团队需要做一个财务相关的系统，团队对财务知识一窍不通，沟通成本就会很高，并且分析、设计、开发、测试、运营的过程中可能都不清楚自己所在的位置，作为专业人员可能会出现如何才能更好的服务业务目标的疑问。

       开发能力提升：在开发过程中基本遵循“开发-调试-修复”的闭环操作，基本不考虑优雅性，模块摆放位置是否合理，借助熊老师的话就是依靠本能做事。为了防止代码烂到根，团地会制定代码规范，如：变量命名遵守驼峰命名等。往往这类情况需要先在系统设计上下苦工，同时面对团队输出需要加大评审力度，重点关注：复杂性、特殊情况处理、与设计方案匹配度、等。同时，需要加强团队需求理解、需求拆分、系统设计、代码实现等能力提升。

团队拆分方面

       面临大团队管理一般是分而治之，将团队拆分协同工作，一般团队拆分有几种方式：

• 根据成员职能能力拆分，如：需求、研发、测试、运维等，在研发方面可以再次细分Web开发、APP开发、后端开发、架构。根据这类拆分往往每个团队都需要有个人来担任相关领导；
• 根据团队支持特性拆分，如：财务、OA、培训、具体业务、基础服务。

       在团队协作方面可根据自己的业务与团队特性进行拆分，往往需要遵守拆分后的跨团队协作线路不要太多，实现一个非常小业务目标交付都得拉上很多团队才能实现。还得注意团队是否可以闭环跟踪、持续发展。

团队协作方面

       复杂项目必然会牵扯不同业务域、技术体系进行团队协作才能实现项目最初的目标。在价值端到端交付流程设计中需要建立相关的流程标准，把握好每个环节的准入、准出、内部工作方式，流程节点把控原则就是“输入的是垃圾，输出往往也是垃圾”，在节点内部的工作方式往往需要负责节点的同事清楚内部的细则并清楚本节点的关键步骤。

       有些时候会出现信息不完全就需要实现的场景，这个时候可以启动一个针刺进行最小成本判断可行性。这样不至于在团队协作中后期才发现不可行，这样的沉没成本往往很高。

Part-2：技术管理方面

       在大团队背景下，很多时候大家关注的是人怎么办，往往会容易忽视技术体系，市场上很多企业由于技术体系混乱导致公司发展受限于技术体系，技术管理没有一套好的管理思路，给企业势必造成不良影响。做好技术管理有几块需要下大力气。

技术栈管理

       在项目中很多时候会出现功能大致相同的平台，使用的是完全不同的技术栈，这类情况给公司平台运营造成比较高的平台运营成本。对于在技术能力不断更新的年代不更新可能无法达到资本、业务发展的需求。如以前咱们都是单体应用即可满足业务发展，后来演变成SOA，再到现在微服务、容器化、服务网格。在这样的环境平稳的给平台换引擎。

• 技术栈引入管理：在很多公司引入新的技术没有限制可以让开发团队的成员随便在核心平台引入，比较容易造成新技术没有达到预期目标的失败风险。尤其在项目底层框架上引入新技术栈，如：替换数据库连接组件、程序部署方式变更、等；这个需要进行技术栈识别，现有平台缺失的技术能力、升级现有平台技术能力，不同场景处理方式是不同的。
• 技术栈落地管理：在技术栈确定需要引入后，对正在运行的平台进行引擎更换、添加能力来说，往往不可能立马就更新，需要进行过实验、验证。可以再二类平台进行初略验证后再大面积铺开。更新操作基本可以单独迭代版本或在业务迭代版本中挪用时间进行。在新增技术能力这个就比较简单可以先用个业务需求、内部需求进行验证，再大面积引入。

       面对稳定的平台或构建流程进行技术能力更新做到多评估、多实验、多总结，相信团队专业人员做好跟踪失败概率会低很多。

设计方面

       设计方面是一门艺术，很多团队在做系统设计过程中都是以实现业务目标为基础，但是仅仅实现业务环节打通是不够的，这里不讲领域驱动设计、面向对象分析与设计、数据库设计，仅在团队设计中容易忽视的地方进行阐述：

• 平台运营能力：项目在需求环节缺失细分场景分析、端到端交付过程中有出现特殊情况未处理，很容易引发生产平台与预期效果不一致，这个时候往往需要平台运营进行介入，如果系统设计环节不考虑这部分内容，那么平台大规模推广将会引发灾难性结果。在运营方面一般需要遵守发现问题、报障、分析、调整、发布等操作，对于一个平台客户发现问题可能是直接流失。在平台运营能力方面做到用户尚未发现问题就已经解决这才是运营的目标。
• 平台响应业务调整能力：日常项目中很少有人会明确规划平台的可调整能力，这个时候在设计环节需要做好哪些东西需要开发相关系统能力来匹配。比如需求中有一些规则、阈值，这个时候系统设计、程序设计人员就需要考虑了，这些不能应编码了，需要进行配置开关及阈值调整，同时可以的话将这些内容丰富成功能让业务上进行后台操作，从而解决业务的问题。
• 平台部署、扩容能力：这个考量点主要存在公司项目频繁更新、集群级别部署，还有缓存机制、数据处理机制、负载均衡机制等、异地灾备，等。这是需要在设计环节就考虑的，在互联网时代水都不想经常看到服务器怎么内存、IO爆了，停服更新，这是对公司的一个品牌影响，同时是对技术体系的一个考验。
• 设计落地与传递：对于设计传递来说的话有文档、会议等方式进行，还是建议设计能文档化，同时UML图形要多些，现在团队偏好能看图绝对不看文字。设计要求可以根据公司及团队情况定义要求，一般数据存储、接口、交互图是必须的，在核心模块方面到算法、类图、对象交互图也不为过。前期比后期的调整成本会低一些。
• 团队情况：在设计的过程中很多时候是有限制条件的比如当前平台拥有的技术能力、团队归属领域、团队能力情况、团队人力情况，这些都是设计环节需要考虑的，其中团队归属领域是需要时刻注意的，如果都是相关文件服务，由于负责文件服务的团队没法提供某些特定接口就直接开天劈地的设计了另外一套文件存储规则，那么后期数据传递、平台能力发散等问题就等着头疼了。

       总之，平台设计的好与坏是需要一定时间证明的，前期必要的基础建设是很重要的，不然在项目上马后再补，成本会进一步增加。

环境管理

       在业务价值端到端价值交付大部分需要流通开发环境、测试环境、验收环境、性能测试环境、生产环境最终才交互客户/用户使用。而在大项目中往往会因为环境问题导致超过迭代周期。为了防止这类场景发生就需要制定相关环境的管理规范。

• 环境相似度：往往面对不同的环境职责也不一样，但是在团队工作中经常会出现为什么开发环境可以，测试环境跑不起来的问题，一般会有数据不一致、环境版本不一致等情况，为了减轻这类问题需要将各环境网络情况、负载情况、系统版本及相关软件版本号统一以下，从而减少环境问题引起的不一致问题。
• 流通规则设定：牵扯流通大部分都是把握好准入、准出，在上游质量没有把控好，导致返工，浪费了下游经历这导致成本上升，尤其是设计及开发环节需要把握好相关的质量，这里大家可以考虑下验收测试，以终为始，在当前环节验证符合要求后再向下游流通。
• 环境职责：在环境管理方面，哪个环境该承担哪些职责还是需要在团队中声明的，同时在使用其他环境需要获得相关环境的团队同意再使用，最好是用完恢复在使用前的效果。很多公司开发同事很多时候哪个环境对开发工作量最小都会使用那个环境，这样会浪费整体价值交付的时间。
• 环境事物优先级：很多公司是开发要负责新特性开发、bug解决、生产问题解决，在复杂的环境中可以定好各个环境的问题处理顺序，这里业内大部分是以生产用户/客户的问题优先，其次是验收环境，遵守顺序就是越接近客户优先级越高。

       为防止团队在价值交付的过程中不被经常打断，作为技术人员在日常工作中需要守护各类环境。

自动化体系建设

       自动化发展就是将重复的工作进行自动化，释放重复工作产生的成本，释放的资源可以做更有意义的事情。而在软件工程中有很多环节是比较低技术含量的。如：代码的静态扫描、简单的测试、打包、环境部署、生产情况监控等。

• CI/CD流程自动化：功能开发后程序员往代码服务器进行代码推送，后台立马对增量代码进行静态扫描，跑单测，通过后部署到测试，执行自动化测试脚本，没问题继续往下流转，直至项目发布到生产环境。这里需要很多的工具引入，同时自动化测试是一个比较大的工作量，如果没法做全流程可以挑一些内容自动化，这样可以减少一部分重复的工作。
• 生产监控自动化：生产监控方面需要做好环境健康监控，应用健康情况监控，自动收集数据进行分析并报障或处理。
• 测试自动化：测试自动化从项目长期收益来说是值得推崇的，项目前期或试错阶段可以不自动化，但是如果项目已经在生产稳定运行，自动化将可以成为质量保障很好的一环。当平台已经变的很复杂了，如果研发进行技术底层更新，这个时候需要测试进行权量覆盖的测试，要么资源无法匹配，要么就是限制平台的发布，这往往不是老板或领导期望看到的结果。在测试自动化过程中，需要选好试点项目、技术框架、让自动化脚本成为资产，而不是附属工作。

       在自动化的道路上需要团队持续积累与学习，自动化可以缩减很多人力资源，小公司缩减的资源并不明显。

Part-3：持续改进

       团队已经开始正常交付了，那么如何持续高效的交付高质量的业务价值将是大家需要坐下来探讨的问题了，通过以下几点来讨论这个主题：

• 指标收集：在设计工作流程的时候往往需要考虑如何收集数据，为后期决策提供支持，可以用固定单元（时间、工作量）进行统计代码质量、bug数量、bug解决速率、生产问题数、生产问题解决速率、发版频次、需求交付时间等。
• 周期性回顾：往往需要团队来思考，在近期的表现，需要考虑技术的发展，团队的方向，团队所负责的平台接下来怎么才能更好的服务业务或其他团队？还有什么可以提升质量、降低成本

       善于总结并不断改进的团队战斗力不会太弱，这是一个有思想的团队。

Part-4：结尾

       这算是第一篇对外抛出的文章，如果文章中有不对或不足的地方，还望各位同仁多多指导。再此祝福每一个从业人士顺心如意，技术人员碰到的问题不再是魔咒！大家可以关注个人的公众号：IT_Road_Ray（IT路）