核心观点
这份研报探讨了数据驱动工程领导力如何通过识别和解决工程团队中的20种工作模式，帮助数百个组织提升效率和能力。报告强调了数据在理解团队工作方式、识别成就、发现瓶颈以及调试开发过程中的重要性。
关键数据和研究结论
- 代码变更水平：Pluralsight的数据科学团队发现，典型团队的代码变更水平通常在25%左右，而13%-30%之间被认为是正常的效率范围。
- 异常高的流失率：通常在冲刺或项目后端出现较高的人员流动率，可能由完美主义、外部利益相关者问题或难以应对的任务导致。
- Bullseye 提交：代码在截止日期之前就开始编写并提前完成，且几乎没有修改，影响程度较小到中等，并且经过了详细的审查。
- 英雄行为：频繁在最后一刻修正他人工作的倾向，可能由糟糕的授权或微观管理导致。
- 过度帮助：一个开发者花费不自然数量的时间来帮助另一个开发者完成工作，可能导致原作者缺乏独立掌握知识的机会。
- 清洁如你去：提交新代码时，也会修复代码库中相邻的代码，有助于减少技术债务。
- 在该区域：组织他们的一天以消除分心并专注于交付业务价值，工作非常一致，交付高质量的工作。
- 比特旋转：长时间专注于代码库中的某个特定区域且仅进行细微修改，可能因为对该问题或更改的上下文不够理解。
- 忙碌的身体：在代码库中四处跳跃，修复前端问题，然后跳转到一些重构工作，接着又在那边调整数据库，缺乏归属感。
- 范围蠕变：原本同意的范围在实施开始后增加或发生变化，通常由计划不足和设计过程中缺乏足够关注引起。
- 片状产品所有权：产品负责人提交不完整的需求或更改请求，导致额外的工程时间或错过最后期限。
- 扩展重构：原本打算作为优化练习的内容，变成批发重写，导致范围显著扩大。
- 还有一件事：晚期提交的拉取请求模式，可能由临期请求、规划或预估不足，以及工作流程中积压过多任务引起。
- 橡胶冲压：工程师批准他们同事的公关没有给它一个实质性的审查，可能导致代码质量降低。
- 知识孤岛：一组工程师仅审查彼此的工作，导致知识在团队中分布不均，形成错误工厂。
- 自合并 PR：工程师提交合并请求后自己批准该请求，跳过了所有形式的人类审查，容易引入错误。
- 长期运行的 PR：已开放时间非常长的拉取请求（超过一周），可能表明对代码存在不确定性或存在分歧。
- 高总线系数：知识和技能在团队成员之间的分布不均匀，风险较高。
- Sprint 回顾：利用数据提供团队进展的更全面视角，观察和管理工作模式，识别成就、发现瓶颈，并利用数据调试开发过程。
解决方案
- 承认和鼓励：认可并公开表彰积极的工作模式，如“清洁如你去”和“在该区域”，并鼓励团队成员追求这些标准。
- 挑战和多元化：挑战“领域冠军”过度专注于某一方面的倾向，并鼓励他们接受与其领域以外的小任务。
- 数据驱动决策：使用Pluralsight Flow等工具收集和分析数据，识别问题并采取行动。
- 改进流程：解决“还有一件事”和“范围蠕变”等问题，通过改进流程减少不必要的工作量和不确定性。
- 促进知识共享：打破“知识孤岛”，通过交叉培训、代码审查和团队协作促进知识在团队中的分布。
- 设定明确的标准：为代码审查、任务分配和项目范围设定明确的标准，减少误解和返工。
结论
数据驱动工程领导力可以帮助组织识别和解决工程团队中的问题，提高效率和能力。通过使用数据和分析工具，管理者可以更好地了解团队的工作方式，并采取行动改进流程、促进协作和知识共享，最终构建更健康、更高效的工程团队。
