核心观点
这份研报探讨了数据驱动工程领导力如何通过识别和解决工程团队中的工作模式问题，从而提升组织效率。报告分析了20种典型的工程团队工作模式，并将其分为个体层面和团队层面两种类型。
个体层面工作模式
- 领域冠军：精通特定领域的工程师，其贡献高效但可能导致停滞和人员流失。
- 囤积代码：工程师倾向于私下完成工作后才提交，导致协作减少和代码质量下降。
- 异常高的客户流失率：可能由完美主义、外部利益相关方问题或任务难度导致。
- Bullseye Commits：工程师理解问题并分解任务，提交小而高质量的代码。
- 英雄主义：工程师在最后一刻修复他人工作，破坏反馈回路和团队协作。
- Over Helping：工程师过度帮助同事，影响自身工作效率和同事独立能力。
- 一尘不染：工程师在开发新代码的同时修复现有代码，减少技术债务。
- 在区域内：工程师高效稳定地交付高质量成果，保持可持续的节奏。
- 位操作：工程师长期专注于代码库的某个特定领域，进行微小的改动。
- 忙碌的身体：工程师活跃度高，但缺乏对代码库的整体拥有感。
团队层面工作模式
- 范围蔓延：项目范围在实施后逐渐扩大，导致额外工作量和效率下降。
- 不可靠的产品所有权：产品负责人频繁变更需求，导致工程师工作量波动和沟通问题。
- 扩展重构：计划改进或修订代码的努力引发范围急剧扩大。
- just one more thing：团队在冲刺接近尾声时提交大量拉取请求，表明工作流程问题。
- 压铸橡胶：工程师批准同事的代码而缺乏实质性评论，导致代码质量下降。
- 知识壁垒：工程师群体只相互审查彼此的工作，形成信息孤岛。
- 自我合并的pull requests：工程师未经审查就合并自己的代码，绕过代码审查流程。
- 长期存在的PRs：长期悬置的拉取请求表明团队内部存在分歧或问题。
- 高总线系数：团队中知识分布不均，依赖少数工程师，存在风险。
- Sprint 回顾：利用数据进行反思和改进，关注工作模式和团队进展。
关键数据和研究结论
- 代码损耗水平通常在13-30%之间，异常高的流失率可能是团队或个人遇到困难的信号。
- Bullseye Commits通常规模小、影响中等，并接受彻底的评审。
- 英雄主义行为可能导致不健康的团队动态和懒惰的文化。
- Over Helping会占用工程师自身时间，并损害同事独立能力。
- “一尘不染”模式有助于减少技术债务，值得鼓励和推广。
- “在区域内”模式表明工程师高效稳定，值得借鉴。
- 位操作模式可能导致停滞，需要引导工程师接触新领域。
- 范围蔓延通常由设计阶段规划不善和关注不足引起。
- 不可靠的产品所有权可能导致范围蔓延和工作量波动。
- 扩展重构很少由产品团队驱动，需要团队讨论和决策。
- “再来一件事”模式表明工作流程存在问题，需要识别和解决瓶颈。
- 压铸橡胶模式牺牲了代码审查的益处，需要重视代码审查流程。
- 知识壁垒会导致审查不够充分，需要引入外部人员或交叉培训。
- 自我合并的拉取请求绕过了代码审查，需要强制审查或配置构建系统阻止。
- 长期悬置的拉取请求表明团队内部存在分歧或问题，需要推动对话向前发展。
- 高总线系数意味着团队中知识分布不均，存在风险，需要促进知识共享。
- Sprint 回顾是持续改进的便捷方式，需要利用数据进行反思和改进。
数据驱动工程领导力
数据驱动工程领导力通过识别和解决工程团队中的工作模式问题，提升组织效率。通过使用Pluralsight Flow等工具，管理者可以获得对开发流程的可见性，识别瓶颈，并采取措施进行改进。最终结果是提升了质量，增加了编码时间，更健康的知识分配，以及更快的上市时间。
