高斯金字塔 拉普拉斯金字塔_人员金字塔

高斯金字塔 拉普拉斯金字塔

当我看到开发团队时，我期望看到的程序员比需求人员（BA，产品经理等）更多，并且期望看到更少的管理类型。 可以认为它就像一个人员配置金字塔结构：

程序员（通常是测试人员）应该组成最大的群体，没有程序员就没有软件，而在理想的世界中，不需要测试人员的事实是缺少测试人员通常是问题的征兆，尽管并非总是如此，我他不是唯一观察过没有测试人员的高性能开发团队的人，但是例外。

尽管您偶尔在这里遇到IBM或Microsoft聘用的测试人员多于程序员的故事，但我从未见过这种情况，我最近遇到的情况是每2个程序员有1个测试人员的团队。 程序员的测试人员数量应取决于程序员产生的初始质量，但更多的是取决于管理层对测试的重视程度以及公司所处的法规环境。

无论如何，程序员-生产原始产品，源代码的人应该是最大的一群。 测试人员落后一些，但是这两个小组应该组成开发团队的大部分。 在此之后，我希望可以看到一些需求人员（业务分析师，产品经理，产品负责人，需求工程师以及他们所获得的职位。）这种混合可能还有其他一些人：客户，业务发起人等等。

（从概念上讲，用户体验/设计人员与程序员是同一层，但通常他们与需求人员在同一层。无论哪种方式，您都不希望看到其中的很多人，并且他们当然不应超过团队中的程序员。）

除此之外，还有几种管理类型，无论是项目经理，开发经理还是其他某种类型的经理都不重要。 我知道有些人想罢免所有经理，但我不同意他们的看法，但我同意不应有太多人。

在一个健康的团队中，有很多工作人员（程序员，测试人员，UXD），为这些人员提供食物（需求）的人员更少，甚至管理所有事务的人员也更少。 要求人员和经理充当程序员（行动者）的乘数，这些家伙通过组织得很好，并要求他们提供合适的金蛋，来产金蛋，金蛋的价值应该更高。

顺便说一句，当我谈论别人时，我是在考虑绝对数字，而不是“全职员工”，甚至“全职员工”。 金字塔较高的人可能会承担多重任务。 重要的不是要花时间在一件工作上，而是要花多少时间在发生的事情上发表意见，而不是用手指指点的人数。 因此，兼职人员，有虚线的人员，有责任感和关心但无责任的人，都算在金字塔编号中。

然后…

我经常会遇到金字塔倒置的公司：这几乎总是一件坏事，一件真正的坏事。

在极端情况下，底层只有一名程序员，没有测试人员，并且很多人对所创建的内容都感兴趣。 有意见的人很多–他们有产品负责人，产品经理，业务分析师，主题专家，业务合作伙伴，需求专家，项目经理和开发经理以及（可能）团队负责人。

这些金字塔似乎来自这样一种心态：

软件开发确实很昂贵，而且很慢，而且很痛苦，因此我们必须绝对少做，

这些人中很多人都对“建造的东西”有所了解，他们是工作的一部分，他们有权干涉，但对所发生的事情不承担任何责任。 工作需要花费数年才能开始，但似乎永远不会完成–也许开发人员会分散在各个项目之间。

当我看到倒金字塔的时候，我觉得这些公司都害怕自己的影子。 我想起了伍迪·艾伦（Woody Allen）关于一家餐厅的两名老妇的古老笑话：

第一夫人：这里的食物太糟糕了

第二夫人：是的，而且分量很小

简而言之，要重复我在《 商业模式》中所说的话： 程序员在开发软件时，绝对只有一个角色。 所有其他角色都是可选的，或者可能是上下文相关的。 （即使您将实际的代码外包，仍然有一个程序员，如果没有代码，就没有程序，而在某个地方有程序员，那不是软件开发。）

程序员是制造产品的角色，他们是下金蛋的人。 如果您没有人下金蛋，那么其他人推纸的能力也没关系，就不会创造价值。 （对于Hitch Hiker Fans爱好者：程序员在C方舟上，其他人都是B方舟。）

翻译自: https://www.javacodegeeks.com/2016/01/the-staffing-pyramid.html

高斯金字塔 拉普拉斯金字塔