项目的费用是一个项目是否能谈成的关键因素，也是团队与客户之间争论的焦点。究其原因，是因为软件是人的脑力劳动的成果，所以它不像硬件产品那么好定价。一部手机，只要把CPU、摄像头、电池、主板等等配件的进货价加上装配的成本及销售成本等再加上利润，就可以定出价格，但是软件就不同了。

本人就在某个网站，看到做同一个软件，有的人竞标价为几千元，有的人竞标价为几十万元，价格相差了100多倍。问题出在混乱的供方市场，混淆了客户的视线，让发包方无法客观评估项目的成本情况，尤其各种组织形式比如个人、学生、公司、团队都积极参与外包市场的情形，每一种组织形式的开发成本又都不尽相同。所以不但是客户，甚至软件开发人员本身，都对项目的费用的确定感到万分疑惑。

那么对于外包的费用有没有一个统一的标准呢？当然有的。学过经济学的都知道，商品的价格由商品的价值来决定，而商品的价值又由生产商品的社会必要劳动时间决定。有形的物质产品是这样定价，无形的软件产品也同样是这样来定价的。软件外包也有一个统一的计价标准，具体来说，外包费用＝每位程序员每天的人工成本×项目所需要的工期（天数）×人数。

这里的人工成本是由很多因素构成的。比如一个软件公司的每天的人工成本的计算方式是：公司付出的一个月工资、奖金、福利、办公成本、国家各种税费、管理费用以及企业利润的总和，除以企业员工人数，再除以30天。项目所需要的工期是指按正常的每天八小时工作制估算，该项目所需要的平均一般工作时间。注意，有些兼职者只能用业余时间来做项目，因而工期就长，但真正的计算工期是以平均的社会必要劳动时间来决定的，所以计算工期只能以正常的每天八小时工作制所需的时间为准。

至于人数，因为有的项目不是一个人就可以完成的，比如一个网站项目，就需要有后台程序员、 前台设计师以及美工共同配合完成。所以需要的人数至少是3人。举例来说吧，比如一个软件项目， 要求设计方在1个月内完成，大概需要4人的协作，如果该公司的人工成本是200元/天，那么项目的 费用就是：200(元/天) x 30(天) x 4 = 24000 元。所以该项目的合理定价应该是2万4千元。

以上的费用计算方式是以软件公司为例来确定的，作为团队可以省却办公成本、国家各种税费及管理费用等等。所以相对软件公司，软件团队在承接外包时有一定的价格优势，但是必要的费用还是要与客户核算清楚的。实际外包时，外包费用的确定应该是在需求确定之后，我方就依据客户的需求来确定项目所需要的工期以及人数，再套用前面的公式就可以得出外包的费用是多少。我们应该把计算出的价格详细解释给客户听，如果双方有争议还可以进一步讨论。这样订出来的价格双方都会觉得满意，也有利于项目的顺利实施。

在实际的外包时，除了开发人员工资及开发周期外, 还需要考虑的几个方面包括：模块量及功 能, 开发难易程度, 客户特殊要求,代码数量, 是否是定制(如果是开发通用的程序,费用可以大幅 降低),周期要求长短短（加急开发是要增加收费的），还要把加班的费用补贴也算进去。另外，团 队的盈利也必须计算在内，这是一个很重要的,却也是现在最被大部分个人和开发团队所忽略的。

建议每一个团队在接单前，都要根据以上的计算方法，算出本团队一人一天的费用价格，比如 500元/人日。这个是为了以后在客户需要一个当场的报价时计算价格用的。一个项目，如果你估计 需要你们团队4人干10天，那么大概的费用就可以算出来了，总费用 = 500元/人日 x 4人 x 10日 = 20000元。那么你报价就可以是2万元左右，具体还要根据客户的情况以及竞争者的情况加以考 虑之后再报一个合适的价格。

另外说明一点，程序员不能因为开发软件的难易程度的改变和开发周期的缩短,而去随意降低价格。现实中，确实由于每个人的技术水平、项目经验不同，对于同样开发一个软件，会觉得难易程度不同。有时开发一个软件觉得很难，有时又觉得很容易。但是我们不能把这个作为依据来降低项目开发价格，而要按照公认的、标准的开发日费用及周期来计算价格。

当然在项目的竞争比较激烈的情况下，费用在标准的基础上可以适当地减少一些，适当的让步 会让双方能更好地达成意向。但是，你作为接包方要明白，价格不仅关系到了你的生存问题，也关 系到你的设计水平以及你的身价，如果你选择几百元的网站设计单的时候，就意味着你的设计已经 定位在这个档次了。价钱意味着客户对于承接方的态度，也决定了最后你出来作品的水平，最关键， 是和你的身价有关系。就好比同样都是能计时的手表，便宜的几元人民币就可以买到，贵的比如百 达翡丽(Patek Philippe）牌的一只要卖到几百万美元。

切记，千万不要一上来就随便报一个价格，哪怕价格再低，客户也不会买账。因为客户都不是傻子，你报价要有理有据，比如一共划分多少模块，每个模块工作量多少，大概多少代码，每个模块需要多少人，多长时间完成，客户听到你说的有理，会对你产生信任感，也就会给你时间仔细分析工作量、写方案。上来就仓促报价，给人的感觉很不专业，没有人愿意找一个不专业的人干活。

在这方面，我有过一次沉痛的教训。那次是有一个客户需要做一个公司的信息系统，要求可以 发布、管理和统计任务信息，接收和处理任务信息，各功能的权限管理，部门裁撤修改等等，涉及 到工作流，要求用 B/S的形式实现，30天内搞定。休息时间匆忙交谈了半小时，我本想晚上回家好 好研究一番再决定报多少，但现在客户急着要我先报价给他听。由于第一次没经验，且对市场行情 不知，我随口就报了个1000元，结果对方大惊之下就匆匆结束了与我的谈判，另找他人去了。

报价离谱，给人感觉你对这个行业不了解，你没有认真分析需求和设计，或是你根本没有耐心去分析，态度差，或根本就是把问题想的太简单的菜鸟级人物，什么都不懂，以为所有的一切都是对数据库的增删查改。还有，项目是要不断维护和改进的，如果你报价太低，会让人觉得你不专业，不是因为你要的钱少，是因为这钱数你肯定维护的不好。你能提出这个价格，说明你明显没有接项目的经验，即使你要价再便宜人家也不会考虑你的。

实际上首次交流一般是不能报价的，因为需求并没有完全明确，你还不能确定工作量到底有多少，所以这时你只能告诉客户你的报价原则，比如做一天需要多少钱，为什么需要这么多钱。你的后期服务能达到什么程度。不能只说个价格，不说服务内容。如果客户一定坚持要你报一个价（有时联系客户的承接方比较多，客户希望大家都报一个价，然后好进行比较），你可以报一个比较宽 的范围，比如 5000至20000元，然后说具体的要仔细分析需求后才能给出详细的报价。这样客户也 比较容易接受。

另外还有一个重要的一点是，报价还要看对方是什么样的客户类型。比如是大集团？政府部门？中小企业？私人企业？还是个人？学生？等等。不同的客户对于价格的敏感程度是不一样的：比如政府部门的客户一般不在乎项目的费用是多是少，而在于多少回扣或者有什么好处。对于这样的客户，你要知道他们的心理回扣是多少，然后就可以走形式了，如竞标招标等流程。

再比如集团和企业，这样的客户一般比较注重你们的实力和资质，他们是出的起钱，但是相应地对你的资历和技术比较关心。所以你要有心理准备，要想说服他们接受你，就要准备好完整的文档和演示，事先要下足功夫，然后报价一般在十万元以上报直至几百万元，具体看项目大小。

再就是一般企业或私营，这样的老板比较扣门，你拿一个演示或现成的给他看下，然后告诉自己专门做这个的，价钱可以给适当优惠，以分析需求或其它理由多交谈几次，绕个弯问下心理承受的价位，再根据他的底限价相应开一个对方容易接受的价格一般就可以接到项目了。

如果客户是个人或学生，那项目的价格绝对高不了。这类客户一般只肯出几百上千元，很少有超过一万元的费用，所以如果你没有时间的话，就不用理会他们了。除非他想要的东西你已经有现成的，那就赚一个顺手钱好了。

这里要注意的是，如果对方是个人用户、小企业用户，报价时一般不需要详细的需求分析文档，只需要一张表格，上面列举可能用到的项目模块，然后后面标注价格。当然，表格是临时打的，但这样让客户觉得你是明码标价而且专业。

如，新闻发布模块，500元，用户系统，400元，论坛系统，500元，其他的模块多少钱，由客户自由选择模块。但是对于集团、大型企业、政府类的客户一定要需求分析文档，而且要厚。别在意费了几张纸，一本书厚就行，往客户面前一扔，慢慢看吧，报价什么都有，如果你能走到这步，基本可以谈下来啦。

我认为一个项目如果你觉得价格太低你就干脆不要接，但是一旦接下来就要做好，这不但是对客户负责，还是对自己负责，更重要的是有利于提高自己的水平。反过来，要是做多了价格低而质量也低的项目，那自己的技术水平也会一落千丈，久而久之，你就是想再压低价格也没有人会请你做了。

这里有一点需要说明，客户在发布项目时，也会公布一个所谓的预算费用，其实这只是一个单方面的心里预期价格，或者说是买方理想价格，这个是不能当真的。对于接单方来说，这个价格只具有参考意义。为什么这么说呢？因为客户不是承接方，他不懂得如何核算费用。他只能根据自己的经济实力，以及自己大略的估计，就信口开出一个价格，所以接包方只能据此判断出客户的经济能力以及支付能力，并不能以此价格来达成最后的交易。这也是我不愿意上猪八戒网接项目的最主要原因，在那里，价格都我认为一个项目如果你觉得价格太低你就干脆不要接，但是一旦接下来就要做好，这不但是对客户负责，还是对自己负责，更重要的是有利于提高自己的水平。反过来，要是做多了价格低而质量也低的项目，那自己的技术水平也会一落千丈，久而久之，你就是想再压低价格也没有人会请你做了。这样让客户觉得你是明码标价而且专业。如，新闻发布模块，500元，用户系统，400元，论坛系统，500元，其他的模块多少钱，由客户自由选择模块。但是对于集团、大型企业、政府类的客户一定要需求分析文档，而且要厚。别在意费了几张纸，一本书厚就行，往客户面前一扔，慢慢看吧，报价什么都有，如果你能走到这步，基本可以谈下来啦。是由客户按照自己的经济能力来单方面决定，完全不是根据承接方实际付出的劳动来衡量项目的费用。

还有，客户发布的项目的开发周期，也是他单方面的期望的工期。客户都希望开发周期短些，一来他们可以早点拿到项目的成果，而来也是想减少项目费用，因为工期短了项目的价格自然也就低了。但是真正的项目工期的确定，还是需要团队的领头人，根据团队成员的人数、技术及项目的复杂程度来综合提出一个合理的时间，并与客户协商确定。如果低估项目周期会造成成本预算低估、项目无法如期完成，最终人力资源耗尽，成本超出预算，为完成项目不得不赶工，影响项目质量，甚至导致项目失败。

下来我来详细谈谈项目的工期的估计，一般来说，你划分好功能模块后就可以大概估计出工作量和时间了。既然是估计，就是建立在经验和对现有项目的了解之上的，了解的越多，估计的越准，这也是在与客户谈判的过程中要做的。

应该是做完比较详细的用户需求分析后，才能写出项目的设计方案。然后在根据以往的经验，估算工作量，估算出项目的费用。否则时间和费用就会与实际出入很大，最后使项目不能如期完成，使开发者和用户之间产生很多的冲突。

另外，需求的更改也很影响到工期。软件项目在开发过程中出现变更的可能性很大，所以开始必须将用户的需求界定清楚，并双方签字同意。这样后期有变动，就能够分辨清是由于客户原因还是自己的原因。如果变更需求是客户造成的，他们才会愿意在时间上甚至费用上给予一定的补偿的。

首先是评估这个项目所需要的技术，而这些技术是否自己熟悉，然后是评估这个项目的业务逻辑，是否复杂。在业务上多花一些时间，然后做起来就比较得心应手了。这个评估也是需要项目经验的基础上的，当然评估出来的时间需要留有余地，好在关键时刻能够缓冲一下。估算剩余工作量、完工时间一定要充分。多考虑风险，留有余地。就算客户对新的完工时间不满意也要坚持。一般你要对整个团队的效率有一个大致的把握，对项目也有深刻的认识，比如技术难点，然后你再考虑各个功能模块得花多长时间，当然前期的沟通和后期的测试你也得算上。具体的评估可以包括以下三个步骤：

第一步，把用户的需求细化，最好能达到功能需求的程度。并且保证这些需求是用户确认过的。 第二步，一个功能一个功能地评估，看自己要做这个需要多长时间，然后除以团队的人数。比如有 三个人一起做，那么你就用自己评估的时间除以3。如：一个功能模块自己做要10天。那3个人一起 做差不多就是4天时间就 Ok了。第三步，在以上时间基础上加上沟通与测试的时间。前期的沟通和 后期的测试也需要时间，一般来说是将评估时间乘以系数（根据项目难度，一般是 1.5-2）。比如 前面估计的4天x1.5=6天。

从需求分析的角度上来说，基本上有两类用户。第一类对新系统有着明确详细的计划，这类用户你几乎第一次就能把需求作到位。而且这类客户基本上会有专门的高层负责人直接负责这个项目，对其中的规划具体负责。如果你遇到这类用户，那么你是很幸运的。这类用户在项目验收的时候，项目负责人敢于根据需求规格说明签字负责。你不需要求爷爷告奶奶地让业务部门逐个验收。

第二类用户对信息系统充满美好的期望，但从来没有具体的规划，也没有耐心看你写的书面的各种报告，可以为你写的任何东西签字，但绝不负责。所有的细节都得有你来替他们做，经常是看到可运行的代码后他们会从根本上推翻原来的设想，不满意就不给钱，这类系统失败的机率几乎是100%。不幸的是大部分客户都属于这种类型。这类用户在项目验收的时候，项目负责人不敢需求规格说明签字负责。你必须得到所有业务部门的签字验收后，才有负责人敢给你验收。

对于占大多数的第二类，一定不要在项目已开始就为他们编写详尽的规格说明，因为这类用户在项目验收的时候不会看这份材料的。需求写得再具体，你也不能保证没有一点含糊的地方。对这类用户，一开始就应该以业务部门和使用本系统的业务人员为线索编写验收大纲。只能编写纲领性性的东西。然后根据大纲选择最关键的业务功能开始系统一个小的增量，细化验收标准，组织该增量的验收。

注意，一定要有书面的验收材料。每个增量一旦验收，除非有充分的理由，客户不得反悔。如 果反悔必须增加费用（起码得让他们有愧疚感）。具体过程参考一下 RUP方面的资料吧。要有完整 的需求分析阶段。在分析时撰写用例，和客户一起从中提炼主要需求和次要需求，当需求内容和等 级确定以后，形成一份双方认可的需求分析书。然后再根据该分析进行项目设计和编码。

在高层设计的时候，允许客户对需求提交修改申请，同时在设计的时候要为今后需求变动做出预估，留有余量。进入详细设计时，如果客户提出需求变动，视其变动大小决定是否变更设计。如果可以变更，要求客户提交详细的需求变更申请书（不过一般这也是你们写，但一定要客户签字认可）。进入编码阶段以后，如果有变动申请，则提出在第二阶段或软件升级换代的时候再考虑。当然，这里讨论的只是需求变动的状况，对于客户和程序员因为对需求理解不一致而导致的偏差不在讨论范围内。

所以说对于用户的需求变更申请不能想当然地立即同意或否定。要有一定的需求管理，要经过技术专家组对变更申请进行详细评估，确认变更不会导致设计上的重构，则可以认可该变更。如果确定变更有可能导致一些不可知的后果，则要将后果向用户指明，同时说明需求变更的风险与可能的代价。用户自己会据此进行考虑的。

如果确认变更会导致设计整体发生严重的重构，导致原先的设计无法继续进行，这样就要坚决否定用户的变更申请。正如我提到的，如果要拒绝用户的需求变更申请，最合适的办法就是将变更所导致的严重后果向用户阐明，用户自己会权衡。如果用户坚持变更，这只能说明当初需求分析没有做到位，这时就需要用户在项目的费用和完工日期方面做出让步。

这里还有一个小技巧，可以在用户权衡时作为改变决策平衡的杀手锏：建议冻结现有需求，所有变更申请在系统下一期升级时完成。这样，用户在无可奈何之下也就只有同意了，而你顺便还把二期的合同也拿到了。如果是因为项目开始的时候没有经过需求分析阶段而导致目前用户需求与架构设计之间出现了严重背离，那我建议冻结现有设计，和客户一起从用户需求设计开始重新分析需求。

如果客户自己写有详细的需求说明书，那么你得到开发需求文档后，一定要详细的阅读客户的需求文档，千万不要漏掉某些细节，因为很可能那些细节就要花掉你一两天，甚至更多时间才能实现和完成它。遇到不清楚或模棱两可的需求功能，一定要及时向客户了解清楚，再进行报价。很多程序员就是这一点不了解清楚而吃了亏，看起来很简单的要求和文档，实际做起来，你才会发现工作量要大于你预计的一倍甚至多倍，相信很多人都有过这种经历。

一般来说，谈判时客户总会说价格定得太高。其实客户说你的价格高，有时只是他们的习惯，或者说只是一个本能反应。这个时候，你先不要急着去否定客户。一般他这样说只有两个原因。一是他现在还不急于外包项目，所以不管你给他什么价格他都会觉得高，你只能等他真正需要该软件时再来主动找你。而大多数的情况都是客户想从你这里得到一个更好的价格。人人都希望买到的东西既物美又价廉，这是人的本性，即使是你自己去市场买东西也是这个心态。

对于这种情况，你需要证明你的价格并不贵，一般最简单的回应方法就是：“您觉得贵了多少？”如果客户把你的价格与竞争对手做比较，你只需要证明你的价格与竞争对手之间的差距是合理的就可以了。比如你可以说：“对方这么便宜，他应该只是个人来做这个项目，时间无法保证，另外也没有专门的美工，做出来的东西也不一定能达到你的要求，到时候你还是要返回头来找我们”。然后把你们团队的实力再大大地宣传一遍，相信客户会有所让步。而此时你也应该做出相应的让步，让客户觉得还是占了些便宜，这样就能顺利地把单签下来。

在与客户的谈判中，很关键的一点就是要想办法摸透用户的心理价位或预算额度，心里底价是有较多因素构成：如客户的背景（是属于政府部门，还是大集团，还是小企业，或只是个人）、客户的收入情况、对购买软件的必须程度、对软件产品的认知、对软件行业市场价格的了解等等。但作为我们来说很难短时间内了解到这莫多的心理需求，那么我建议你不妨试一试以下方式：

首先通过交流粗略估算出客户所处的社会层次及从事的工作，以及客户的背景是属于政府部门，还是大集团，还是小企业，或只是个人，甚至只是个没有什么支付能力的学生。通过报一个相对较高的价格来测试客户的反应，看看他对这个价格是怎么看的，你就大概知道他属于什么类型的客户了。当然，报价不要高的离谱，否则他就可能掉头就走，再不理你了。逐步地降低价格，慢慢接近他的价格底线。只要试探出了他的大概的心理价位，你就成功了大半。剩下的就是通过你的分析需求来说服他接受你的价格了。

在本人的实际接单中，也经常碰上过那些希望只用几百元就做过一个类似腾讯QQ那样的软件的 客户，程序员一般称这种人为“垃圾客户”。他们要么是经济能力很一般的个人，要么就是根本没 有钱的学生（一般都是找人代做毕业设计）。他们经常挂在嘴边的话是：“我这个软件很简单，你 只要用一天时间就可以做出来的”。对于这些人，开始还是要客客气气地把价格的计算方法告诉他 们，让他们明白软件不是一拍脑袋就可以做得出来的，也是要经过繁重的脑力劳动才能制作出来的 产品。如果他们还是坚持原来的价格的话，那就只好和和气气地道声“bye bye”了。

还有一些价格较低的项目是二手项目，就是别人接下来以后转给你做的项目。一般的转包二手项目的人，在与你谈判时都会与你说明这是转包的项目。但即使他不说，你也很容易进行判断，比如本身对其行业知识也一问三不知的人，或者谈到需求总是说要回去问问的人，一般都是二手转包者。二手转包项目比较麻烦，一来是项目的价格比较低，因为转包方已经从中赚了一手；二来需求的确定也是比较难沟通，因为转包方并不是最终的用户，他对于需求也是并不十分了解。

至于这类项目要不要接，要看具体的情况而定。如果你们团队还是接项目的新手，想通过接项目来进行磨合锻炼；或者你们的成功案例比较少，想通过做一些项目来积累案例；或者你们团队急需要一笔资金，而该转包项目的费用还不算太少，这时就可以考虑接下来，否则的话，还是远离这些转包项目为好。特别是对于转了多次手的项目，更是碰都不要碰。