如何做好技术团队的管理（个人经验）

人员管理

• 人员组成
  • 产品
    • 必备，人数看团队数量
  • 测试
    • 必备，人数看团队数量
  • 开发
    • 前端
      • 必备，人数看团队数量
    • 后端
      • 必备，人数看团队数量
    • 移动端
      • 看业务
    • 运维
      • 看人员质量和基础组件
    • dba
      • 看人员质量
• 人员招聘
  • 面试
    • 基础扎实
    • 经验丰富
    • 性格靠谱
    • 大公司背景
    • 意识强
• 新人培训
  • 导师制
  • 规范文档沉淀
• 人员成长
  • 技术成长靠个人
  • 管理上的成长靠组织
• 绩效考核/激励
  • 创造价值
  • 开发需求记录在案
  • 数据说明一切
• 团队氛围
  • 一个月团建一次
  • 多分享
• 公平公正公开
  • 任务需求和开发要有记录
  • 数据说明一切
• 特殊处理
  • 不遵守规矩，造成事故，记录给大家分享，事不过三

研发流程

• 需求预审
  技术负责人和产品评审，拒绝不合理的需求
• 需求评审
  技术和产品评审，讨论合理方案
• 分配任务
  技术负责人分配
• 技术方案
  开发多写技术方案，有记录
• 技术方案评审
  开发评审技术方案，有助于大家互相学习提升，保证项目质量
• 开发排期
  开发自己安排工作
• 开发
  开发写代码
• 自测、联调
  开发自测，减少测试工作量，保证代码质量
• code review
  必须执行，保证代码质量，互相学习成长
• 体验
  产品发现问题
• 测试
  性能测试和功能测试
• 发布
  最好自动化一点
• bug修复
  线上bug记录，修复，目的是为了减少bug

代码质量

指标：

• 安全
  root权限收回，服务器，数据库
  机器内网集群，反向代理访问，需要端口才开，机器之前需要授权才能开端口
  https
  参数强校验
  使用登录服务，不要自己写登录逻辑
  使用框架的sql预处理
  注意越权访问的校验
  中间件校验sig
  session过期时间
  注意字符串转义
  乐观锁，悲观锁
• 健壮
  参数校验
  异常处理机制
  内存占用过大
  常驻进程连接超时
  重试机制
  日志
  告警
• 整洁
  代码分层，封装
  命名
  不要写一大坨
• 性能
  循环查库？
  不必要的查库
  过多复杂的运算
• 易于维护
  多写注释
  注意命名
  不要写一大坨
  要优雅，也不要过度封装
  直观易理解
• 拓展
  不要写死
  多配置
  封装
• 解耦，便于迁移
  指定数字或者字符，请用常量
  依赖的服务收拢，统一配置，不要写死
  多配置
• 封装而不过度封装
  代码直观易于理解
  封装注意可读性
  多写doc语法
• 少挖坑
  少挖坑

开发效率

• 开发工具
• 通用组件封装
• 通用技术类型抽象
• 多分享

技术规范

• 代码规范
• 数据库设计规范
• 其他命名规范

版本发布

• 发布频率
• 自动化发布工具，walle，jekins，git ci/cd
• crontab自动替换
• 队列自动更新
• 数据库自动执行
• 平滑重启服务
• 回滚机制
• 风险意识

事故处理

• 预防：
  风险意识
  经常提醒
  定期总结
• 处理：
  事故记录
  事故人总结
  改进措施

基础组件

• 日志
  性能要高，对业务影响小
  业务区分
  告警等级
  关键字查询
  关键id索引
• 告警
  异常的情况有地方看
• 监控
  代码埋点上报
  性能要高，对业务影响小
• rpc服务
  高性能远程调用框架
  服务注册和授权
• 统一数据库
• 快速部署环境
• 基础服务监控组件（数据库，服务器等）

文档沉淀

不管什么乱七八糟的东西，多写就对了

工作汇报

• 需求流程管理工具
  必备，一年下来谁干了什么一目了然
• 周会工作对齐
  必备，工作进度把控
• 季度总结

技术氛围

不要影响开发进度

• 技术调研
• 技术分享
• 鼓励分享
• 兴趣小组

绩效考核

• 目标
• 达成
• 对比
• 成长