经常可以听到为开发项目确定预算是一门艺术。考虑到所有的商业风险这看起来近似真实。项目的花费很容易就会成为完全不具实际意义的“模糊数学”的一个课题。以小时计算的开发时间，为了加快开发速度而增长预算，工具和其他资源的开销都应该在基于顾客所能支付的范围内上下波动。

要确保能够精确的制定项目预算并保证方案顺利交付，以下的方针会帮助你创建合理一致的预算并很有实际意义。

预算基础

公司内的许多部门都会涉及到预算的问题。对于开发人员来说，它代表在应用程序的特定部分需要花费多少时间。对于项目经理，它是确保项目正常运作的基线。对于销售人员或者客户来说，它直接关系到努力的成果。所以对于创建预算的最大的问题就是把它解释清楚这件事情不必太惊讶。 不考虑客观情况，一些基本的理论可以帮助你做无限预算，这样可以避免主观角度对你的影响。通过已经理解的概念以及保证那些相关的人理解这些概念，作出一个正确的规划是理所当然的:

项目的开销和项目预算是两码事。永远是从确定项目的开销开始
项目的开销不仅仅指花多少钱。包括了实际的花费，运费和税费，也包括软件和硬件的采购费用。如果采用已经购买的软硬件设备，把他们计算为时间量（使用的小时数）。同样的，开发人员花费也计算为时间而不是金钱。
一旦列出开销，确定会遭遇的风险，并量化每一个风险会对整个项目造成多大的影响，或者对部分项目造成影响的百分比。每一个开发团队都会被赋予一个风险值，用来处理有理由的开销，比如雇用一个临时工来保证不会超期，或者应付无法预料的超时工作。
这时候预算就是花销的总和，它被转化为现金表，加上总体风险花费。为设备和开发时间定义转换值。
预算并不是一张发票。一旦确定了你的报表，要呈报给公司的决策人员做调整。确保他们理解你的报表中反映的花销。
预算可能永远被标为评估，直到它结束或被认可。
不能由一个人来建立预算，至少需要：开发领导人，项目经理和商业决策人。

确定项目花费

当确定了开发过程的花销，要尽可能的贴近实际。通过观察团队内的成员在以往项目中的表现，感觉一下程序的编写工作需要多少时间。咨询开发负责人，有必要重复这句话，咨询开发负责人。提防过度自信的评估，把可能的超时记入风险。

别忘记把集成和发布的开销包括进去。会议、安全认证、许可证费用、质量检测耗时、除错、文档编写时间和资料费用，以及为经常遗漏的地方预留时间。尽管公司可能也可能不会要求客户为这些付费，这些都是合理的确切的项目开销。计算这些费用会帮助你精确的计算项目最终的收益率。

接下来，逐条的记录那些不包括的，但是在以后可能会涉及的特性，甚至可能是对最终产品有益的特性，把这些列为可选项。另外一件事是可以在产品发布后将开发人员支持时间延长到60天，通常当计划完成时，支持团队还没有就位或者会有大批的问题延迟交给开发人员。

一旦得到了开销的大概程度，就是时候来看看什么会导致开销的变化了。

风险费用

风险费用和分配对一个项目的成功至关紧要。没有它，当每个项目固有的风险周期性的发生时，就会影响项目基线。评估的价值中应该包括这部分的开销，但是可以不考虑销售的影响。风险的描述实际是对开发过程的评估。

可以考虑的风险会包括开发团队的经验，技术应用不熟练（可容忍的程度），计划时间不足，开发队伍的数量和地区，标准组件的数量，项目依赖的数据库或者第三方软件以及所有未知的因素。

确定可以导致风险的项目后，为每一个项目分配范围和百分比。举例说，如果应用程序由C和Java组成，而开发团队由C程序员组成，那么Java组件就是潜在的高风险，它会被记录到“开发经验”的项目中。

所有项目都不可避免的存在人为的风险，比如生病或者休假。通常也会分配一个百分比给它，对于一个拥有10个开发人员，6个月的项目，合适的百分比是占整个项目风险的5%。对于拥有较少开发人员而相对长期的项目该值会高一些，反之则会低些。

通常情况下，风险费用大体相当于总费用的20%-30%。是高还是低呢？实际的风险费用依赖于评估团队的经验和未来的努力。如果在经过计算评估后，数目过高，可以参考公司的其他计划。他们是不是实际上符合预算呢？如果不是，说明你可能是对的。如果是，那么可能是对你的团队不太信任。应当重新评估你的风险预算。

总结

不管离现实有多近，客户总是会对低于预算的项目感到高兴。不管怎样，过高的风险值都会使坚强的人动摇，表现的没有自信并导致对管理能力的忧虑。通过本篇方针，我们建议你使用一些常用的原则，你能让你的团队，项目管理人和客户都感到满意。