转眼工作十年了，从20年10月开始，断断续续做了近三年的小团队管理，这里作简要总结一下。
所谓小团队管理，其实就是现在说的虚线组长，需要写代码、给团队提供指导等，但是由于不是高级别大领导，不需要应付很多烦人的破事。从这层来看，挺适合我这种性格的人。
以下是以小团队为背景来总结的，格局显得较小；当然每个人的观点不一样，不一定是正确的理解。
核心要点（对自己）
- 情商、基于别人的角度思考
- 个人习惯采取对内温和对外强硬的方式；当然结合自身情况和环境具体选择；这个方法可以让你更好的理解人和事情；我不认为所谓的“情商高”就是“老好人”。
- 以身作则
- 以自己为榜样，让团队其他成员看到正确的做事方式等；包括技术方案、沟通方式等，当然包括一些无法避免的脏活累活等；用高效和人性化等方式应对 。
- 令人信服的技术功底
- 小团队管理的特点，就是领头的人也是需要写代码和干实事，而且跟团队成员的距离是最近的；需要保持自己良好的技术功底，才能更好的给团队提供有效的建议；另外作为有追求的技术人，谁都想跟着比自己优秀的人一起共事。
- 保证成员尽量免干扰、休息时间如无必要不打扰
- 这一点是我基于人性化的角度考虑的，有些人可能会觉得不重要。给团队提供深度工作的环境，才能提升效率；在一些不紧急的事情少，要做到不随意打扰，减少团队的负面情绪。对应上面第一条，将心比心，每个人都想要良好的工作体验。
- 真诚、谦虚、透明
- 尽量保持团队一定的透明度，减少不必要的暗箱操作。大部分情况下不需要开会，只需要一篇简明扼要的文档，即可让团队快速了解事情的内容。团队成员也在发展，要清楚有一天他们的能力会超过你。而我一直坚持的做法是，业务上坚持写文档，尽量减少业务壁垒（也是为自己放假偷懒准备），技术上提供合理的建议，不遗余力的提高自己的“可替代性”。
- 认清自己。领导需要团队的力量才能发挥作用。不要错把平台的能力当作自己的能力。把公司的给予当作自己的给予。
- 人性化管理
- 现在很多公司都追求狼性文化，说着各种假话哄下属为自己加班干活
- 个人管理经验理念是，先做人再做领导
- 如非必要。不严厉。许多人还没到那个层级就采取低端没人情味的管理方式。要和同事成为朋友，营造友好的工作环境，而不是一味向上管理。
- 尽量保持技术更新升级
- 在确保充分测试，稳定灰度的同时，适量的升级有利于系统的稳定，增加维护人员的积极性。这种东西无法直接给出具体收益，但应该长远考虑，一味的保守只会让技术越来越落后
核心要点（对团队）
- 聪明、叙述简明扼要、能抓重点
- 乐于分享、采用高效的分享手段（文章即可）、实事求是
- 有团队主人翁意识，主动了解业务
- 对技术原理好奇并积极探索
- 尊重别人的时间
- 跟进事情有反馈和结论
- 在正确的事情面前，敢于说不
- 重视自己的“可替代性”、免于个人单点、提升团队容错性
小团队技术管理者的事项列表
- 业务侧
- 快速满足需求
- 通用业务组件抽象
- 旧业务熟悉
- 定期删除无用代码，增加代码可维护性
- 遗留需求记录和跟进
- 业务知识文档化，方便查阅和备忘
- 需求上线时间定时跟进（你就是项目经理）
- 技术侧
- 旧业务梳理和重构
- 架构灾备和优化、资源隔离等
- 通用工具类封装
- 管理后台搭建 （解放技术）
- 服务异常监控（后端接口，前端APM等各个维度）
- 技术组件升级，提升团队技术广度
- 废弃业务下线，回收资源
- 业务技术调研，团队具备快速满足产品新需求的能力
- 分享，相互学习，个人认为文档就行了，会议实际上挺形式和浪费大家的时间
- 帮助review方案和代码
- 技术债务登记和逐步处理（分优先级[每个季度一定要完成一定比例的低优先级任务]，保持代码洁癖，不给后来人挖坑）
- 开发规范制定（避免后续维护混乱，也方便大家日常开发查阅）
- 开发阶段和上线阶段checklist，避免犯重复的错误，避免上线遗漏导致项目延期
- 技术面试
- 应急处理、日常维护等文档化（公开、透明、高效）
- 团队文档整理规划
- 新人指引
- 业务模块（服务模块、业务知识整理、业务交接记录、业务安全风险点）
- 工作规划（需求列表、技术规划、技术债务）
- 开发规范（项目上线流程、公共库说明、开发协议、服务架构图、业务逻辑开发套路等）
- 工作文档（应急、日常维护等）
- 常见问题处理导航
- 技术文档（技术型、分享类）
- 技术方案（日常需求上线方案归档）
- 复盘、故障报告
- 业务调研
- 其他备份