技术团队效能
1.技术管理者的思考起点
1.1.如何避免自己成为整个团队的瓶颈？
- 需要个体保持独立人格：分享想法、承担责任
- 斌能个体的手法：透明、开放、有序、批评、肯定
- 管理原则：告诉团队什么是鼓励的，方向在哪儿
1.2.如何让集体成为真正的团队？
- 让个体发挥特长、完善不足
- 形成集体约束力
- 如何量化考核技术人的KPI？
- 业务贡献
- 技术贡献
- 设计重构
- 我在客户通项目中，对CRM销售域进行了领域建模和设计，并且抽象合理。
- 我发现Infrastructure中package分类不合理，进行了重新设计并重构完成。
- 我发现现在系统中错误码比较混乱，我梳理制定了新的错误码规范，并完成了代码重构。
- 技术影响力
- 在团队内分享10篇干货，点赞数1000。
- 团队分享策略模式，得到同学好评 。
- 我接受邀请，在行业会议上分享了SOFA架构。
- Code Review
- 我在review某某代码的时候发现，可能存在线程不安全的隐患。
- 我在review某某代码的时候发现，存在设计不合理的现象，此处使用责任链可以很优雅的解决问题，并具备一定的扩展性。
- 创新提效
- 我发现本地测试启动PandoraBoot比较浪费时间，所以写了一个TestContainer大大提升了自测效率。
- 我发现有一些boilerplate代码不需要写，所以对乐观锁、分页进行了annotation支持，简化了代码。
- 在某个项目或者技术点上面，我产出了一篇专利：基于领域模型的业务配置化。
- 代码质量
- 提测后的Bug数，线上故障数（系统可以提取，不用自己填写）
- 我完善了某某模块的单元测试，并多次在自动化回归中发现问题。
- 应用质量
- 团队贡献
- 总结
- 作为技术团队，我们就应该在User Story之外，加上我们的Technical Story，把完成业务需求和系统重构都当成我们的核心任务。
- KPI vs OKR
- OKR 全称是 Objectives and Key Results，而 KPI 的全称是 Key Performance Indicators
- OKR 和 KPI 具体的差别表现在：OKR 的关键词是 Objectives，KPI 的关键词是 Indicators！
- OKR 关注的是目标，KPI 关注的是指标。当我们关注“目标”的时候，我们会思考接下来我要做的事情是什么；而我们关注“指标”的时候，我们会思考自己的工作如何评价。
- 以程序员为例，如果我们关注目标，我们会想接下来我应该做什么事情，是要解决产品的卡顿问题，还是可以引入大数据来做精准推荐；而如果关注指标，因为我们的工作是编程，那我们就会想哪些指标可以衡量编程工作呢？我们想到的是代码行数、bug 数、单元测试覆盖率这些；
- 以足球运动员为例，如果关注目标，我们会想到夺冠、四强、保级；如果关注指标，那我们就会想到进球数、助攻数、跑动距离、比赛场次等；
- 以滴滴和快的为例，如果关注目标，快的的目标应该是超越滴滴；如果关注指标，快的的指标应该是司机数量、订单数、乘客数等；
- 为何这两种思考方式差异非常大呢？有一句名言形象的说明了这点：如果方向对了，就不怕路途遥远！而如果方向不对，指标再漂亮都没有意义，甚至指标越漂亮就错的越大。目标就是我们的方向，指标就是评价我们做的事情的质量。使用 OKR 的时候，我们的思维第一反应是“我们的目标是什么”；而使用 KPI 的时候，我们的思维第一反应是“我们的职责是什么”，如果我们将思维固化在当前的职责，那就不会去审视整个环境当前的状态以及后续可能的变化，也就不会及时的根据实际情况进行调整。
1.3.我们需要什么样的工程师？
2.模型
2.1.技术团队效能动力模型
2.1.1.集体环境效能
- 工具
- 管理支撑
- 工程方法
- 概要设计
- 单元测试
- 编码规范
- 代码审查
- 数据驱动
- 平台化
- 工具化
- 自动化
- 项目管理
2.1.2.个体职业素养
- 自我管理
- 习惯培养
- 工作日报
- 制度遵守
- 信守承诺
- 律他
- 轮岗
- 知识管理
- 专业素养
- 业务素养
3.心得
- 好团队是培养出来的，而非招聘而来的
- 技术管理者的信念是重中之重
- 团队效能问题比技术问题更难解决
- 个体的可塑性比已有经验与能力都重要
- 人性可以理解但无法驾驭
4.未来