配图
「时光不负，创作不停，本文正在参加2022年中总结征文大赛」
背景
我是一个超级喜欢读书的人，也是一个喜欢分享的人，在2015年开始按照番茄工作法复盘每日的工作后，慢慢的发展自己有一些知识点，会忘记，会忘是人所难免的事情。于是我找到了我的第一款工具软件，印象笔记。
当我找不到好的方案时，我就会读书，读博客，看是否能联系到这些作者给我一些思路甚至讨论一些问题，特此感谢那些能够和我讨论问题的嘉宾，作者，技术大佬。
在印象笔记里，我记录了第一份实习工作里所必须要记录的那些知识：下面这些知识对一个前端来说都是必要的，但不难的
svn的操作知识，java项目的环境搭建，后端如何生成一个验证码图片，利用emmet快速生成样式代码，移动端百分比流式布局的技巧，各种图片格式的差别等等。
转眼间来到2021年，我的专业生涯本身来到了瓶颈，作为tl的发展也遇到了部分瓶颈。2022年上半年是自己逐渐摆脱这个瓶颈，渐入佳境的半年。
- 其中专业的瓶颈，如何解决支撑业务之后的宽度和广度的问题；
- 其中tl的瓶颈，如何在业务包工头之外，让团队有更大的发展，对业务有更大的价值。
团队需要你么
如果团队不需要你，其实你的职业发展并不会有什么发光点。你在团队里可能是包工头，可能是比大家经验多一些给些建议，可能是代表大家参加一些会议，可能是就你待的久你来，可能是你比较愿意接手管理的事情。但这些琐事你做下去，都不会有定性和定量的结果，我们要有一个结果，定性的，定量的都必须有，来让团队觉得需要你，你很重要。
刚好我去的这个团队，是需要或者说至少公司是期望管理者做些什么的，只是怎么做，他们也不知道。因为就落地来说，支撑业务还是第一步的。
上半年里，我重点思考了几件事，有些是去年下半年也在做的，并取得一定成功的。
1 团队里需要形成什么样的氛围，团队里的谁是已经具备的，这样的氛围能解决什么问题
2 业务里目前需要什么样的人，我们的团队符合么，还差什么，什么可以做的更好
3 领域知识里，我们哪些有了，还差什么，怎么共建
4 让团队里核心的人，在某个或者某些角度都有明显的成长
团队里形成什么样的氛围 -- 驱动人
责任意识
原来，我们很多历史业务，不是我们写的，我们不熟悉的，我们不擅长的，就下意识的会推诿，因为即使支撑了也没有什么好处。以个人为维度以具体的事情为维度。
现在，我们按照业务线划分， 把所有业务线的事情否分配了责任人，只要这个业务线相关的任何事情，都和你有关，你是第一责任人，把业务范围和人绑定。然后，我们约定了一些不错可培养的业务线负责人，让他们在承担这样的责任时，有更大的成长，做一些指导。这里包括了业务文档输出，业务内代码的熟悉，业务内团队的带教，管理团队内成员的进度和阻塞问题。
如果原来是被分配的，现在我的同学可以主动的承担起这些事情。
当然我们还不止这些，这些是纯业务上的需要，技术上的事情我们也做了责任约定。这个没有额外奖励，只是单纯的业务需要，团队需要，你有意愿承担并愿意长期承担，其相关的一切事情。
这里我们把微前端底座调研，前端旧项目迁移，钉钉适配，错误监控，可视化组件封装，代码cr，开发环境搭建，小程序体系搭建，校园号菜单里程碑计划，组件教程，等都给到了对这个主题有兴趣的同学。这些都有具体的落地和长期支撑。
同时，对技术团队来说，最重要的莫过于线上问题的反馈和解决，我们强调并执行了这样的响应，线上故障大于迭代大于技改，对于线上的故障，只要在职状态，保证当天查看初步定位，严重的当天修复，不严重的必须给出具体的方案在下个发布周期发布上线。严重的问题，组织复盘会议，扩大会议，给出严谨的报告以及如何更全面的避免类似问题。
喜欢当前的工作，做就做好
你的具体某个时间的工作状态，我不关心，我关注的是你是否喜欢现在的工作，以及在积极的调节。
如果喜欢他，那么就说下自己做了哪些努力，没有结果也可以，至少有那么一些变化，至少是心情愉快的。
如果不喜欢他，你做了什么计划整改，知道它的原因是什么么？这件事因为你变的更糟了还是更好了。
在周报里，在日常沟通里，强调这样一点基本的原则。
同事也是你的朋友
以前，我们之间除了真的需要和对方沟通，其他时候沟通很少，
从周会增加了5分钟的轮流的闪电分享之后，团队的氛围更加融洽，我们更加知道每个人的状态，目标，对什么感兴趣。
除了这个，还有公开的裸心会。只有把自己的想法真实暴露出来，这个团队才知道你是不是适合，你的成员是不是适合这里。没有谁，愿意真的把自己当螺丝钉运转。
以结果为导向，输出为导向
鼓励并支持哪些拿出结果的人，包括不限于：
1 支撑多倍的业务压力的
2 拿出技术成果，解决实际业务问题的
3 愿意花时间和精力增强团队能力的人
4 能为团队的技术架构做思考，做方案的人
5 团队内积极承担更多事情，更多责任的人
6 成长巨大的人
业务里需要怎样的人，怎么正向反馈，向上推动 -- 驱动业务
跟进技术细分，技术评审
初步制定细分和估时模板之外，在核心业务线参考和讨论真实需求的估时，为什么这样，你我的差别，盲区是公共的还是你个人的。
这个过程中产出了：
- 更加细化的细分模板，可以帮助我们分析到这次迭代的工作量 -- 我们下一步的计划是产出标准的用户故事，流程图，伪代码
- 让部分同学开始关注页面之外的业务逻辑，后端是如何设计的，如何影响后端的设计，如何了解产品的需求是否合理，目前做到了向前0.5步
- 某些常见的需求是有技术方案的，并不是都需要自己从0到1产出。比如我们遇到了智能硬件的项目搭建，不知道的同学觉得要半天，其实目前和移动端方案一致，2h即可；比如返回多次的交互问题，已经有成熟方案的情况下，直接复用；比如对接小程序唤起，方案成熟下，1一天即可，直接为相关的项目减少了3-4人天。-- 你不是一个人做需求，也不是外包做项目，你是在团队的技术体系下做项目，如果你这次迭代也产出了新的方案，也应该同步给大家，让这件事的人效*N。
业务复盘，只有不断具有复盘意识的人才能把业务越做越好
复盘出的问题：
- 项目管理的常见问题，边界处理 -- 写到技术方案中
- 人员协作不透明 -- 对自己的言行负责
- 技术方案不严谨 -- 给到更多人审核，核心成员备份
- 过于乐观估时 -- buffer估时，充分考虑，让技术方案的评审颗粒度和严谨程度提升一个台阶
- 方案沉淀 -- 解决过的问题就是我们应该有方案的，有定论的
- 基本技能不会 -- 协调沟通方案，沟通需求的能力，给大家多做示范，项目管理中如何解决某些常见问题
领域知识
作为一个确实的从切图仔年代走过来的前端，其实前端的话语权，能做的事情已经明显的变多了。以下的你肯定了解过甚至做了好几年了，但是永远不知道这件事最好是做到什么样子。
几个大方向的变化
1 混合开发，比如app混合开发，智能硬件内的，钉钉微应用，打到一些流量入口比如浙里办
2 纯web开发，可以在企微，微信内多端并行
3 单纯的前端友好形态，小程序（包括不局限于微信小程序，头条小程序，qq小程序），app（rn,flutter）
方向很多，但只是代表需求可能会很多，不像之前那么受限。
几个深度的变化
- 组件化，工具化，可以把你觉得可以抽象复用的逻辑以不同的形式复用并提升人效
- 工程化，解决复杂或者具有难度的事情，比如最常见的脚手架，物料库，持续集成
- 领域专题，前端性能监控，错误用户，业务埋点
我们团队内在q1+2的输出沉淀：
1 小程序的从0到1
2 datav组件从0到1，多人掌握并备份
3 echarts组件的生态搭建
4 业务埋点：4.1 pc端埋点的数据方案 4.2 统计时长方案
5 微前端读作非阻塞任务的基本设计，自定义生命周期设计
6 关于行政区地图数据存储，版本管理，跨团队约定
7 校园号自定义菜单的里程碑设计以及推进
8 编辑器的引入以及常见问题的解决
9 前端安全问题系列方案
10 组件标准使用文档的初步整理以及上线
11 针对企微和微信场景的能力增强
12 代码共享，在线组件的开发以及迭代方式
13 ，，，
团队核心成员的成长
技术专题分享
包括seo分享，前端性能监控，sso单点登录，hook分享，多级下钻等
任务攻坚
灰度发布，钉钉适配，魔方对接，班牌性能优化，鉴权优化，开发环境搭建，部署迁移，直播对接，乐享通用方案等
团队内技术文档（包括部分业务文档）
30万字，500+
说了这么多，我的成长在哪里？？？
回到最开始我讲的背景，在我的管理风格测评里我是I型，也就是影响型。在这一年里，体现最明显的就是给大家做榜样，沉淀可贵的技术资源，业务资源，为前端团队对外打造好的专业的口碑。先支撑好，做好自己，再看能否贡献好的业绩指标。
所以我这半年的成长主要体现在：
- 对技术上更加专注，当一个方案成为临时方案时，我要吧它变成稳定的，可中长期使用的方案，也就是一个技术专家和架构师要做的事情。比如业务埋点这件事，我在内部共沉淀30+以上的方案细节，并科普最少3次，目前团队内80%的人可以理解这个方案，并能在业务中接入，设计出适合业务的数据格式，并能和我参与讨论下步的埋点技术方案可能思路，比如补偿发送，链路分析。
- 在项目管理基本认知和实践上，更加纯熟，任何项目管理上的问题都可以给到组内以及组外的同学正确的认知和处理办法，并落地，如果不能落地，让大家都接受这已经是目前的最好结果
- 对业务更加敏感，会分析我们的业务为什么行或者不行，向上到各部门总监级别拿到更准确的信息
- 跨部门的协作，我也向前一步，推动更大局，更重要的事情
- 赋能我的成员，把我的认知，能力切实的示范，并交给他们，相信他们能做好，慢一点也没有关系
最后，想说
你看到之后，也许觉得什么也没收获，因为你可能想得到一篇特别实用的技术文档，或者技术选型的结论，想拿来主义。
但结合我多年的经验，特别好用的技术一定是一篇文章讲不完的，特别好用的技术也一定是有使用背景的，当我们遇到对应的问题，去分析他的背景，整理可用的资料，一遍遍分析哪个好，哪个不好，一次次妥协之后，那个方案才是真的属于自己的方案。最有竞争力的简历，项目经历。
目前大部分成体系的技术文档已经转到语雀，有兴趣大家可以关注下我，目前沉淀300万字，并成为语雀2021年度的语雀天使，少数的几个坚持日更的博主，www.yuque.com/robinson
我的更新频率：
有兴趣的同学欢迎关注我，也关注我最近一篇更新的文章，关于自定义菜单的思考。这个是真实业务场景问题，并且目前尚无看到好的方案。