其他开发者的收益递减

是否有一个术语来描述在软件项目中增加更多开发人员将带来越来越少的回报的观点？

我认识到，从较高的层次看，要使项目达到生产能力的开发人员（项目的前/后状态，添加的开发人员的质量）要复杂得多，但是我想提出一种通过重复将其与非技术管理联系起来的方法。我基本上是在寻找一个能唤起诸如“终极速度”之类的强烈心理意象的术语，布鲁克定律除外。

您的问题包括答案：收益递减点。在这一点上，添加更多的资源要比这些资源的生产效果花费更多。这是一个基本的经济概念，因此希望您的管理层能内心地知道这一点。

“ 在一个较晚的软件项目中增加人力会使工作变得更晚。一个工作月的概念是工作单位与工作人数乘以工作时间成正比；布鲁克定律说这种关系是神话，因此，这是这本书的核心。 ”-资料来源：Wiki-Mythical_Man_Month。

注定要重复

可怜的弗雷德·布鲁克斯（Fred Brooks）就像荷马的《伊利亚特》中的卡桑德拉（Cassandra）。如果您读了电影《特洛伊》（Troy）来的那本书，那么她就是那个不在乎（Trojan）马的人。她准确地预测了未来，但直到预测发生之后，没人亲自相信她，他们才亲自看到了。

不抗击管理/被动抵抗或谨慎雇佣吗？

我的建议是，这可能不是个好日子，如果您的经理希望您雇用更多的员工，那就去做吧。建议一些参数，例如找一个有特定经验的人和使用快速筛选技术，将使搜索时间增加三倍，也许您会在破坏者到达之前达到最后期限。

减少您花在不太可能的候选人身上的时间将节省大量时间。例如，在简历的前1/3中没有您的前三名要求的任何简历都会被扔掉，应聘者必须经过30分钟的电话屏幕才能进行任何现场面试，而忽略了没有根据您的需求进行预筛选的招聘人员。其他技术比比皆是，请确保您使用的任何东西都是有效的。

控制新员工整合的负担

如果您确实在截止日期之前进行了录用，并且需要与新员工打交道，请从不在培训关键路径上的人员预算时间。让团队中的成员看到一个，然后做一个，然后再显示一个会很有帮助。如果您的团队成员具有中低经验，那么它将增强他们对您的流程，工具集和代码库的理解，以指导这些领域的新员工。

希望您有一些文档，因此指派新人员阅读可以帮助他们逐步发展的文档是一项不错的短期和长期投资。应该逐步将它们引入您的流程中，并应由可以阻止他们通过大胆但有害的变更推动项目发展的人员来审查他们的工作。

最佳和最差工作分配

如果您有单独的项目或某些技术开发，他们可以做准备在将来的项目中使用，这也可能是一个很大的好处。学习您的特定工具集，进行自己的本地构建，单元测试，可用性测试，文档以及参与审核，这些都是新员工的绝佳选择。新员工可能具有全新的观点，并且可以对您的团队学会生活并且不再可见的事情提供有价值的重要评论。

对新员工不利的使用可能包括与经理和非开发人员利益相关者进行团队会议，评估，要求和管理（除非他们在竞争对手工作后才是专家），专利，采访新候选人或以其他方式帮助人员。

保持团队和谐，设定未来期望

新员工优先事项仍然发挥作用。如果您的团队经历了组建，发展，规范，绩效的演变，则必须给新员工以期望，以期望他在团队中的表现和计划职责。您一定不能使新员工的工作比团队中其他角色的要求低。如果您的团队积极争取截止日期，那么新员工应该有办法证明他正在积极争取实现整合。

我不知道减少人力回报的标准术语。由于目标是说服人们，请尝试改写一个短语：

• “可分解性的限制”对于中型项目可能尤其重要。
• “通信开销障碍”唤起了大型项目的经典布鲁克定律。
• “设计迭代需求”是一种奇特的说法，“如果您想要的东西不是废话，则需要花费一些时间才能正确地完成它。”

一个合理的近似术语是“ 弹性范围”：比喻为价格无弹性区域，当进一步降低价格不会增加您的销售额时，应与管理层保持警惕。