我应该首先改进公司的哪个工作流程？

我会这样看：

• 任何影响生产力的事情都应该首先解决
• 影响盈利能力的事情排在第二位（大多数生产力修复也是盈利能力修复）
• 挑剔的东西最后

因此，您应该拥有以下内容（按我的意见排序）：

1. 7 - 编译后重新启动服务器
2. 5 - 增量构建速度
3. 6 - 仅远程调试
4. 8 - 从命令行编译
5. 12 - 颠覆整合（与上述5.在同一联盟中）
6. 2 - 生成的文件
7. 11 - 未正确使用泛型

然后

1. 1 - svnignore
2. 9 - 项目依赖关系（我相信这将花费大量时间）
3. 10 - 混合专家 + 蚂蚁
4. 3 - IDE 警告
5. 4 - 约定

从这个意义上说，我之所以有排序，是因为时间与收益。如果用户需要16分钟来编译和检查他们的代码，那么说实话，这是血腥的疯狂。假设开发人员每天编译5次，我们大约需要80分钟，什么都不做。

之后是生产力。如果您加快开发人员完成工作的速度，则已完成工作的营业额将大幅增加。(Profitability++)

在这之后是“挑剔”的东西。我这么说并不是为了推断它们不重要，但事实是，从外观上看，你有更大的鱼要炸，所以在纠正代码中的大小写之前，先完成这些工作。

我不是一个熟练的用户，我不能对上面的一些发表评论，但你列表中的大多数东西看起来都是需要改进的好地方。我认为我能给出的最好的建议是：

• 慢慢来。他们可能多年来一直以这种方式这样做，并可能抵制改变。
• 让团队（可能还有经理）参与更改。召开一次会议，讨论您看到的改进（保持简单，只是几个），他们对它们的看法，以及他们是否认为实施这些改进是明智的。然后，如果同意，请与某人配对以使改进到位。
• 提供有关易于更改的工作实践的演示文稿。例如，在调试会话期间，在实时设置中向它们显示动态类加载的差异。
• 优先考虑上面的列表，并一次专注于几个。
• 要温柔。改变是很难的！一次做很多事情可能会疏远或脱离人们。
• 从快速获胜开始，这将对团队中的开发人员产生直接和积极的影响。这将建立他们接受更困难变化的信心。

祝你好运...