pmp低于预算 符合预算

在上一篇文章中，我写道

（软件架构师的） 实际决定 应得出一个满足可用性，性能，可靠性，可伸缩性，可管理性和成本标准的解决方案。 （顺便说一句：应该满足前六个条件，最后一个条件至少应满足并最小化，但这是一个不同的故事。）

很多时候符合标准，无意将成本降到最低。 “有预算，我们必须适应预算。” 这是团队遵循的方法。 有几个原因。 但是这些原因并不一定意味着该方法还可以。 我什至可以接受这样的论点，即在大型组织中这种行为是不可避免的。

为什么这种方法不好？

当您出售某物时，您想以最高的价格出售它。 成本代表最低售价：如果可达到的价格低于复制成本，则生产将停止。 预算也是一个限制因素。 您去食品店，然后买满足您需求的面包，如果有钱，这是最便宜的面包。 如果您的资金有限，则将选择一种您可以支付的款项。 如果满足他们所需的所有其他条件，为什么要购买更贵的东西呢？

（不要开始谈论苹果产品：也需要感到自己有钱。）

即使购买开发项目的客户在同一家公司，对于开发项目也是如此。 如果您是内部团队，那么您的客户就是“企业”，或者如果您的公司为客户开发软件，那么您的客户就是销售人员。 在后一种情况下，“客户客户”是公司的客户。 开发团队的客户是销售。 同一家公司。 客户提供您必须满足的预算，但是

没有人抱怨过某个项目预算不足。

我不是在说降低预算承诺。 所有项目都有风险，所有风险都有财务影响。 降低风险的一种方法是在预算中计入应急费用。 但是，这又是预算，而不是实际支出。 仍然有团队，部门倾向于填补预算。 他们为什么这样做？ 可能有多种原因，并且确定我将无法列出所有可能的原因。

多花钱的原因

1。

一个部门花费越多， 它看起来就越重要 。 我见过这样的公司。 该公司是一家规模不断扩大的大型公司，多年来一直大量投资于资产，建设基础设施（例如电信基础设施，公路或铁路，我不会告诉您哪一个），而建设里程越长的公司业绩越好。 衡量的是花钱，而这种文化在IT支出时仍然存在。 奇怪的。

2。

在某些企业中，未花费的预算将减少部门未来的融资可能性。 如果您（作为软件架构师）可以从原始估算中节省下来，则意味着您的估算不佳。 下次您估计时将考虑到这一点。 因此，该部门宁愿浪费（通常是到年底）剩余的预算，而不是将其退还给国库。 这就像修复创建注释器的错误一样。 （单元测试部门如何？）

3。

一些公司在维护，开发人员培训，教育，设备或其他与IT相关的活动方面的融资不足，并且部门倾向于通过其他来源来纠正这种情况：预算过高的项目。 事情肯定会发生。 如果您想要一些东西，您不付钱就不会得到它。 如果您得到了它，您就为它付费了，只是您不知道在哪里，什么时候以及多少钱。 在某些情况下，开发人员，架构师，项目经理甚至可能没有意识到他们遵循这种做法。 我多次听到这样的论点： “我们为该项目选择了更昂贵的技术X，因为这样我们就可以学习它。” 这也是交叉融资。 您可以使用该项目来资助开发人员的教育。

所有这些都是不良做法。 我不需要解释第一个例子。 第二点也很明显。 最后，交叉融资不是很明显。

为什么交叉融资不好

当您选择更昂贵的技术时（因为它需要支付许可费，或者需要更多的开发和学习，它可能会更昂贵），您决定将公司的资金投入到某些事情上。 作为一名建筑师，这不是您的责任。 您可能会建议管理层，但即使您处于自己可以担任的职位，也不应决定（除非您同时也是小公司的管理层，但在这种情况下，您要戴上管理帽）。 只有管​​理层才能决定如何投资。 投资于人始终是一项不错的投资，即使他们后来离开公司也是如此。 （但是，如果您不进行投资而他们留下来怎么办？）但是，事实上，在那一刻，管理层可能会看到更有利可图的投资可能性。

不要难过

我是否建议您立即着手管理，并请他们减少预算？ 我认为作为软件架构师的您在预算和交叉财务中应该感到难过吗？

一点也不。 我说过交叉融资是一种不良做法，但我没有说这是您的不良做法。 这是在公司中实施的不良做法。 组织越大，更改它就越困难。 这不是您的任务，更重要的是，您可能没有能力做到这一点。

唯一需要做的是：知道您遵循的并不是最佳实践。 如果有任何机会可以改善它，那就去吧。 每个人只要踩一小步就能拯救世界。

翻译自: https://www.javacodegeeks.com/2016/05/not-meet-budget.html

pmp低于预算 符合预算