一分钟读论文：《被掏空的一天：软件工程师的日常》

作为团队的 Leader，如何通过改进流程和⼯具，并最终提⾼团队⽣产⼒呢？可以参考微软研究院和英国伦敦大学、瑞士苏黎世大学信息学系合著的论文《Today was a Good Day: The Daily Life of Software Developers》。该论文分析了微软工程师的5,971份问卷结果，发现工程师「良好」和「典型」的工作日是怎么样，并总结了使良好的工作日成为典型的建议：

优化工程师的工作日的建议：

• 建议尽量减少管理任务和基础设施问题，并减少中断和会议。与开放式办公室相⽐，在仅与少数同事共享的⼩型办公室中可能更容易实现不间断的⼯作
• 安排不开会的工作日，没有安排会议的工作日可以让团队更专注地⼯作
• 在规划阶段安排少写代码的工作，将会议集中在⼀起的工作日让团队可以集中协作、讨论和计划
• 允许需要⼤量注意⼒和专注的任务在家办公，家⼯作以前被证明可以提⾼知识⼯作者的⼯作满意度

管理注意力和时间的建议： 在社会学中“个⼈独⽴⾏动和做出⾃⼰的⾃由选择的能⼒”被称为 Agency，既工程师可以选择拒绝会议或干扰，避免将会议分散在整个⼯作⽇，导致在会议之间留下很少的时间来取得进展。应该 积极努⼒减少开发阶段（以及开发繁忙的工作日）的⼲扰和会议，并在协作最关键的时候⿎励他们，例如规划/规范、测试和发布阶段。

工作贡献评估的建议： 工程师不仅会受到他们的经理的评估，还会受到他们的同⾏的评估。考虑工程师对其他团队成员的⽀持，以及对其他团队甚⾄外部（开源）项⽬的贡献，或者工程师可以向另⼀个工程师推荐奖励，以表彰他们完成的出⾊⼯作。

论文研究的问题和结论：

[RQ1] 哪些因素会影响良好且典型的工程师工作日？它们如何相互关联？

影响工程师评估良好工作日的11个关键因素可以归为三个维度：

• 价值创造：反馈比例68.0%。关键因素包含进度推进（35.6%）、写代码（13.8%）、有意义的工作内容（6.4%）、有建设性的讨论（4.7%）、学到新知识（4.7%）、帮助他人（4.7%）。
• 时间的有效利用：反馈比例54.0%。关键因素包含达到预期、能够专注。影响的原因有插入紧急事情、办公室吵闹、整天开会，不能写文档，被阻塞，花太多时间搞懂某些原理。
• 情绪：反馈比例9.3%。关键因素包含生产力（4.7%）、时间压力（2.5%）、工作时长（2.2%）。

[RQ2] 工程师如何度过美好而典型的工作日？

典型的工作日关键组成部分是工程师对⼯作⽇的期望与实际情况之间的匹配。64.2% 认为他们的⼯作⽇是典型，35.8%认为他们的⼯作⽇不典型的。7个关键因素：

• 项⽬阶段：在敏捷软件开发中，迭代通常从规划和规范阶段开始，接着是开发或质量/稳定阶段，最后以发布阶段结束。当阶段没进展时，工程师认为他们的⼯作⽇是⾮典型的（22.3%）。
• 工作日类型：“⽆会议⽇”是典型的工作日，通常安排在开发阶段，让工程师主要专注于在编码任务上取得进展。
• 外部因素：33.8% 的工程师反馈他们⼏乎⽆法控制的外部因素导致了⾮典型的⼯作⽇，因为它们经常使工程师⽆法在主要任务上取得进展⽽转向其他职责。
• 地点：工程师通常在办公室⼯作，5.8%反馈到任何其他地点工作通常被认为是⾮典型的。
• 主线任务：7.2% 反馈任务本⾝会影响他们是否认为⼯作⽇是典型的。比如非常规的任务（例如准备演讲或演讲）、⾮常简单的任务或⾮常具有挑战性的任务。
• 私人因素：仅有2.1%的工程师反馈情绪、睡眠质量或注意⼒集中等个⼈因素描述为影响⽇常⼯作的因素。
• 花在活动上的时间：51.8% 反馈包含在某项活动上花费⽐平时更多或更少时间，在⾮典型⼯作⽇，⽐平时花费更多时间在会议和调试或修复 bug。

[RQ3] 有哪些不同类型的工作日，哪些通常是好的和典型的？

反馈是好的和典型的6个不同类型的工作日占比：Testing Day（C1 - 24%）; Bugfixing Day （C2 - 23%）; Coding Day （C3 - 22%）; Collaborating Day （C4 - 21%）； Meeting Day （C5 - 8%） ；Various Day （C6 - 2%）

• 工程师认为什么是好的工作日也因他们的资历而异，高级工程师比初级工程师经历更多非典型的日子。
• 工程师在繁重的开发工作日 (C1-C3) 中经历的工作比其他工作日更为典型。
• 高级工程师有更多时间参与协作，例如会议、计划和规范，并且不太可能有开发繁重的工作日 (C1-C3)。
• 总体的平均工作日长度最多仅相差半小时。
• 经历过繁重开发工作日的受访者 (C1-C3) 的开发经验平均少 3 年。

[RQ4] 协作如何影响良好和典型的工作日？

• (5a) 工程师在工作日平均有 4.66 次中断。
• (5b) 工程师平均花费 10 分钟才能在中断后恢复。
• (5c) 工程师可以不间断地处理代码的最长平均时间是 47.3 分钟。
• (5d) 工程师更喜欢写代码而不是会议，但他们仍然认为大多数会议都是有用的。
• (5e) 即兴同步会议是工程师办公室同事为回答问题而进行的短暂打扰。
• (5f) 工程师很少有计划外的会议，每天少于一次。
• (5g) 在糟糕的工作日计划外的会议会花费更多的时间。
• (5h) 在良好的典型工作日，工程师花在会议上的时间低。花在会议上最高的是工程师认为好的和非典型的日子，这表明在非典型的日子举行的会议通常被认为是建设性的和有价值的。