背景
相比三年前，自己这次通过主动跳槽找到一份能充分发挥自己管理权限和管理能力的岗位，通过近4个月的努力和尝试，对自己的工作成果做一个基本的小结。
在这段时间内，我从以下几个痛点依次去解决的，并且达到了较好的效果。
文档缺失
| 现象 | 1 核心业务缺失访问文档，领域文档，不方便理解 2 旧业务维护和迭代成本高 3 成员协作时大量的时间放在了讲解上 |
|---|---|
| 本质 | 1 懒，大部分人不愿意写 2 意识，大部分人没有意识到该写哪些文档，也不知道怎么写 |
| 措施 | 1 痛点宣讲，描述出具体的文档缺失时会导致的效率问题，理解问题 2 针对明显的核心业务访问问题提供模板，并定期要求指定业务线的人输出文档 |
| 效果 | 1 大部分业务线都补充了基本的项目信息，访问说明，用户说明 2 其他各种类型的文档也在积极的补充进来，形成了事事有文档，有留档 |
业务线混乱
| 现象 | 1 同一个业务可能不同人都经手过 2 新项目和需求按照谁空谁来做 |
|---|---|
| 本质 | 1 没有意识到专人专职的重要性 2 没有严谨的项目排期，没有考虑到交接成本 |
| 措施 | 1 专人专职，减少变动 2 ab角 |
| 效果 | 1 大部分业务线都固定在对应的owner，业务稳定性和交付效率得到了提升 2 每个业务都有备份和可调用缓冲资源 |
错误不好追溯
| 现象 | 1 代码经过压缩，看不到具体问题 2 大部分经过运营反馈上来 |
|---|---|
| 本质 | 1 没有良好的错误监控体系 2 没有访问上下文分析 |
| 措施 | 1 推进错误监控的里程碑计划 2 增加自定义级别的错误和捕获 3 增加阿里云日志的排查思路 |
| 效果 | 1 核心的3-4个业务接入错误监控，可每天看到具体的错误 2 根据错误做分类分析，不再依赖于运营提供信息 3 人均掌握了如何查日志解决问题 |
用户行为追踪
| 现象 | 1 用户行为没有记录 2 特定主动埋点没有方案 3 业务研发和运营没有方向 |
|---|---|
| 本质 | 1 缺少错误监控的采集方案 2 缺少数据展示的平台 |
| 措施 | 1 自研埋点sdk 2 基于阿里云日志消费提供数据投递 3 数据大屏选用datav |
| 效果 | 1 核心业务利用sdk实现了规整的埋点 2 数据大屏作为成熟的解决方案后续也自研了多个插件，不但展示了现有数据还作为研发和运营的长期指导方向 |
技术储备几乎为空
| 现象 | 成员都是业务研发，不思考技术精进和技术问题的专题讨论 |
|---|---|
| 本质 | 1 氛围不够 2 个人主动意识不够 |
| 措施 | 1 技术虚线，定技术任务 2 定季度指标 3 定专题负责人 |
| 效果 | 1 完善的各个技术细分体系 2 每个分支季度都有目标和结果产出 3 每个人根据自己感兴趣的方向进行投入并产出，获得了大的成长，也为团队积累了经验 |
临时需求固定的扛在一个人身上
| 现象 | 来了紧急需求和线上故障都是原来的固定高p解决 |
|---|---|
| 本质 | 1 没有好的任务分发机制 2 其他人的快速理解能力缺失 |
| 措施 | 1 建立任务需求池，tl负责初步评审，平分配给合适的人 2 团队内维护每个人擅长接，适合接的需求类型 3 针对特定类型需求，提供其技术方案，标准工时 |
| 效果 | 1 非常规需求按照一定比率流转到了各个业务前端 2 需求的解决效率高了，从一个人承担到整个团队承担 3 特定方案的整理让更多团队成员具有更多能力 |
更多
你还有更多的案例或者需求想和我分享么？欢迎关注我的语雀：链接