pmp低于预算 符合预算
在上一篇文章中,我写道
(软件架构师的) 实际决定 应得出一个满足可用性,性能,可靠性,可伸缩性,可管理性和成本标准的解决方案。 (顺便说一句:应该满足前六个条件,最后一个条件至少应满足并最小化,但这是一个不同的故事。)
很多时候符合标准,无意将成本降到最低。 “有预算,我们必须适应预算。” 这是团队遵循的方法。 有几个原因。 但是这些原因并不一定意味着该方法还可以。 我什至可以接受这样的论点,即在大型组织中这种行为是不可避免的。
为什么这种方法不好?
当您出售某物时,您想以最高的价格出售它。 成本代表最低售价:如果可达到的价格低于复制成本,则生产将停止。 预算也是一个限制因素。 您去食品店,然后买满足您需求的面包,如果有钱,这是最便宜的面包。 如果您的资金有限,则将选择一种您可以支付的款项。 如果满足他们所需的所有其他条件,为什么要购买更贵的东西呢?
(不要开始谈论苹果产品:也需要感到自己有钱。)
即使购买开发项目的客户在同一家公司,对于开发项目也是如此。 如果您是内部团队,那么您的客户就是“企业”,或者如果您的公司为客户开发软件,那么您的客户就是销售人员。 在后一种情况下,“客户客户”是公司的客户。 开发团队的客户是销售。 同一家公司。 客户提供您必须满足的预算,但是
没有人抱怨过某个项目预算不足。
我不是在说降低预算承诺。 所有项目都有风险,所有风险都有财务影响。 降低风险的一种方法是在预算中计入应急费用。 但是,这又是预算,而不是实际支出。 仍然有团队,部门倾向于填补预算。 他们为什么这样做? 可能有多种原因,并且确定我将无法列出所有可能的原因。
多花钱的原因
1。
一个部门花费越多, 它看起来就越重要 。 我见过这样的公司。 该公司是一家规模不断扩大的大型公司,多年来一直大量投资于资产,建设基础设施(例如电信基础设施,公路或铁路,我不会告诉您哪一个),而建设里程越长的公司业绩越好。 衡量的是花钱,而这种文化在IT支出时仍然存在。 奇怪的。
2。
在某些企业中,未花费的预算将减少部门未来的融资可能性。 如果您(作为软件架构师)可以从原始估算中节省下来,则意味着您的估算不佳。 下次您估计时将考虑到这一点。 因此,该部门宁愿浪费(通常是到年底)剩余的预算,而不是将其退还给国库。 这就像修复创建注释器的错误一样。 (单元测试部门如何?)
3。
一些公司在维护,开发人员培训,教育,设备或其他与IT相关的活动方面的融资不足,并且部门倾向于通过其他来源来纠正这种情况:预算过高的项目。 事情肯定会发生。 如果您想要一些东西,您不付钱就不会得到它。 如果您得到了它,您就为它付费了,只是您不知道在哪里,什么时候以及多少钱。 在某些情况下,开发人员,架构师,项目经理甚至可能没有意识到他们遵循这种做法。 我多次听到这样的论点: “我们为该项目选择了更昂贵的技术X,因为这样我们就可以学习它。” 这也是交叉融资。 您可以使用该项目来资助开发人员的教育。
所有这些都是不良做法。 我不需要解释第一个例子。 第二点也很明显。 最后,交叉融资不是很明显。
为什么交叉融资不好
当您选择更昂贵的技术时(因为它需要支付许可费,或者需要更多的开发和学习,它可能会更昂贵),您决定将公司的资金投入到某些事情上。 作为一名建筑师,这不是您的责任。 您可能会建议管理层,但即使您处于自己可以担任的职位,也不应决定(除非您同时也是小公司的管理层,但在这种情况下,您要戴上管理帽)。 只有管理层才能决定如何投资。 投资于人始终是一项不错的投资,即使他们后来离开公司也是如此。 (但是,如果您不进行投资而他们留下来怎么办?)但是,事实上,在那一刻,管理层可能会看到更有利可图的投资可能性。
不要难过
我是否建议您立即着手管理,并请他们减少预算? 我认为作为软件架构师的您在预算和交叉财务中应该感到难过吗?
一点也不。 我说过交叉融资是一种不良做法,但我没有说这是您的不良做法。 这是在公司中实施的不良做法。 组织越大,更改它就越困难。 这不是您的任务,更重要的是,您可能没有能力做到这一点。
唯一需要做的是:知道您遵循的并不是最佳实践。 如果有任何机会可以改善它,那就去吧。 每个人只要踩一小步就能拯救世界。
翻译自: https://www.javacodegeeks.com/2016/05/not-meet-budget.html
pmp低于预算 符合预算