写在前面：考虑到公司对社交媒体的管理和审查办法，本文将特别隐去公司名称和部门名称，请大家知悉和见谅。
在 2022 年 12 月初，我们发起了部门内软件研发体验年度调查问卷，有 324 位同学参与了调查并贡献了自己的想法，大约占总人数比的 50%，基本反应了当前部门的软件研发现状，分析报告如下。
第一部分：团队概况
开始部分主要统计了参与人员的分布情况，从角色、定位、工作经验以及团队规模了解目前研发部门的基本状况。
开发团队人员占据了 80%的人员比例，UX 和 Support 都没有参与本次问卷。
管理层和独立贡献者刚好二八开，是一个符合预期的团队结构。
从工作经验看，10 年工作经验以内的同事占据了 85%人员比例，按时间推算他们应该都是 90 后，他们是团队的中坚力量。
从团队规模的答案看，发现一个有趣的现象，接近 45%的人认为平时自己会跟 13 个人以上频繁打交道，说明平时大家协作沟通成本非常高。按照亚马逊推荐的两个披萨团队理论，一个敏捷的团队不应该超过 8 个人，否则沟通效率会积极下降。从本次调查结果中应该反思，到底是什么原因导致大家需要和如此多人频繁合作？ 我们还可以做一些有意思的交叉分析，看看独立贡献者和管理层的年龄分布大概是怎么样的。
结果也还是意料之中，不过可能因为有一些脏数据导致了小小的误差。
第二部分：软件交付体验
第二部分主要为了了解软件交付体验的状况和存在的问题。
从问卷结果看，85%以上的同学认为自己所在的项目组的软件交付体验还 OK，这不仅是每个团队在工程卓越上的努力的结果，也是公司在软件交付投入的效果。当然这并不能说明我们做得已经很好了，抱怨和吐槽的声音还是很响亮的。 针对影响交付体验的因素，这是一个开放性话题，我们对大家的抱怨和吐槽做了归类，展示如下。
可以看出来，需求管理的好不好，是改善软件交付体验的关键。当然，需求清晰不变更，这是理想的世界，现实世界里是不存在的。外在的环境一直在变化，我们应该做的是用开放和拥抱变化的心态去预期和处理可能的变更和风险，在不确定性中寻找确定性。比如敏捷开发中多用迭代、快速寻求反馈的思想，尽可能早发现错误并敢于调整方向和做出取舍。在持续交付中践行 DevOps 理念，尽可能将软件交付过程中的手工重复部分自动化掉，多用标准化的工具，这样才能减少需求频繁变更和手工重复的痛苦。我们能确定的是，不变的只有变化。
在《认知觉醒》一书中提到，人的一生就是一场“消除模糊”的游戏，具体事情一旦变模糊，边界就会无限扩大，唯一的办法就是正视它、拆解它。
第三部分：研发效率部分
这一部分主要为了了解每个工程师的工作效率和瓶颈因素。
问题偏主观，不过从结果上看，还是有解决 90%的同学认为自己的工作效率还挺好的，对目前的工作难度和结果还算满意。
对于大家的开放式吐槽，我们将答案做了归类，结果展示如下。
从分类后的结果看，上下文切换是大家公认的效率杀手。所谓的上下文切换，可以换个说法叫无法专注。你本来要做 A，临时来个 B。你本来要看书的，手机亮了起来。很多时候事情没做完就是因为你不知不觉被切换到了另外一个场景，大家抱怨比较多的就是临时任务，没计划的安排，突然老板叫去开会等等，不一而足。其次就是跨团队合作，毕竟每个团队都有自己的目标和优先级，相对于合作而言，当然还是先想办法让自己的团队完成任务活下来。孙子兵法有云，上下同欲者胜。我们需要思考，怎么样才能让上下游团队跟自己有共同目标，步调一致，这对每个人都是一个不小的挑战。
作为独立贡献者，想要提高自己的价值就必须想办法专注于最重要的事情，绩效还是以结果为导向的。 作为团队管理者，更应该思考，怎样帮助下属减少上下文切换，怎样高效跨部门合作。
第四部分：如果你有超能力
如果你有超能力可以改变软件研发过程中的任何部分，你希望改变什么？
答案当然就很天马行空，不过也颇有趣味。从底层逻辑看，我们希望改变的东西无非几种：文化、流程、工具、协作或者其他。所以针对这个开放性的问题的答案，我们也做了归类，得出这样的结论。
流程上的优化是大家最希望看到的，复杂的流程一定程度上是为了帮助企业规避风险，但带来的效率降低也是很可怕的。在这个方面企业只能尽可能去平衡优化的利弊，并不能直接简化或者消除流程，尽可能用自动化的方式去降低手动执行的代价。 第五部分：技术工具推荐
为了发现好用的技术和工具，避免重复造轮子，我们专门设计了这样两个问题。
-
在公司内部，你有什么好用的技术，工具，流程或实践可以让大家去尝试？
-
在公司外部，你有什么好用的技术，工具，流程或实践可以让大家去尝试？
以上答案仅供参考查阅，相信在软件研发领域也没有什么银弹，很多时候还是需要根据自身情况量体裁衣，别人说好用放你这不一定行，一个组织里最可贵的还是人才梯队的培养，《从优秀到卓越》里有这样一句话，卓越的管理者知道要先找到合适的人上车，而不是先想好车要开到哪里。
第六部分：尾声
在做这样的调查的同时，我们也很担心不能得到大家的支持，毕竟每个问题都需要仔细思考后才能回答，就算回答了也不一定马上能带来什么改变。但是我们真心希望每个人都能在一个阶段结束后（比如年底）花一些时间去回顾和思考成长和不足。我们还是冒昧问了大家这样一个问题。
很高兴看到有接近 70%的同学还是支持这样的调查的，毛主席说了，没有调查就没有发言权。这样的调查更多是为了明白我们现在在哪，我们最大的痛点在哪，我们可以改进什么，用数据和事实去思考比用感觉去思考更可靠。 问卷被 584 人浏览过，平均完成时间 13 分钟，其实并不需要很多时间。 新的一年开始了，人类最重要的能力就是反思和改进，希望这样一份研究报告对你有所启发，对你和你团队工作有所帮助。
最后，我们也祝愿每个团队有更大的成就，我们一起拥抱变化，走向卓越。
彩蛋：金句摘选
此部分摘录了开放性问题的一些精彩回答，与君共赏。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
问：阻碍需求流畅交付的主要因素是什么？
答：需求会膨胀
答：需求感觉自己被理解了，其实并没有
答：有些需求没买票乱插队
答：项目年纪很大，亲戚很多
问：影响我工作效率的主要因素是什么？
答：时间太碎了，总是被打断
答：上下游响应不及时，甚至不响
答：精神欠佳，身体欠安
答：友军的 bug 太多了
答：没有文档，找不到人，我新来的
答：开发两分钟，部署两小时
问：如果你有超能力，你希望改变什么？
答：不是所有用户需求都要做的
答：老板拍板的魄力，别让下面人猜来猜去
答：开箱即用的开发环境，大大的 CPU 和内存
答：瞬间打包发布，越快越好，快到极致
答：别突如其来，别说变就变
答：都有责任心，没有甩锅的心态
答：专业专注，氛围融洽
问：对研发效能的改进，你有何建议？
答：一起讨论代码，一起提高产品质量
答：流程更规范，需求更详尽
答：使用科学的衡量标准
答：统一基础框架和平台，确保稳定性和可靠性
答：减少开发人员在非开发工作上的时间投入
答：听取意见并改进，不要局限在小圈子里