我诅咒我们客户……

the answer is: be honest. 首先自己要做到如实的记录工作时间，不虚记工作量。如果10小时完成了就收10小时的钱而不收20小时的。目前国内的公司有几家能做到这么诚实？然后是教育客户，让他们相信我们。总之第一次让客户相信我们是最难的。

有些客户担心的不仅是开发商故意拖延，而是自己根本无法发现开发商是否在故意拖延。所以他会希望通过价格和进度去控制开发商。这有点像以前的承包制。 毕竟很多客户没有懂行和胜任的IT部门，国内也基本没有合格的IT工程监理。

有些客户还会打这样的如意算盘，就是最好我出了10万，你给我值12万的系统。当然，这样的客户应该是少数。

这也要有个前提的，就是有个比较合理的人月单价。如果人月单价过低，软件公司自然只能通过虚报人月数来获取利润了。

对于企业而言，开口式合同一般不会被接受，不论是不是真的有用。对于预算、分笔金额确定和付款上都有操作上的问题.大概会有几个办法绕过这个问题.
最简单的是分期签订合同，前期双方合作满意，才继续下一期，有利于双方信任关系的建立，而且如有变故，涉及标的额也不会太大。在一个合同的价格估算上，以用户可见的功能点为基点。
稍微不可能的办法是企业找2-3个固定的战略合作伙伴，所有相关单子都通过这几个公司来走，其实有点像外包，但企业和合作商之间的关系比较紧密。这样做对企业的风险最小，能够在最大程度上避免开发方的短期行为。
另一个办法是信息监理公司介入，采用预决算方式，通过第三方来回避财务审计风险(对于项目成功与否的帮助并不是很大)，但需要按百分比支付监理公司的费用。
项目的需求变更，责任是双方的。缺乏行业中常识性的共识通常是项目变更的最重要原因之一，应该说这个问题开发方的责任更加大一些；本身业务流程的变化带来的变更，则是企业方的责任；而UI上的方便性以及用户发现计算能力之后的主动变更，则是双方的沟通问题，不过很大程度上取决于开发商的需求挖掘和沟通能力。毕竟需求的把握是开发方主导的行为，否则，如果甲方能够把需求理得一清二楚，只是找一个技术实现，那直接外包就行了,而不必作为一个项目来运作。
从变更的角度来说，对于增加需求或者业务变更而带来的变更代价，企业不会拒绝支付，但是对于沟通失效以及经验不足绕弯路导致的变更，不可能由企业来完全支付。就这一点，按照时间支付对企业而言是不利的。

这个很难判断。不同的团队在能力上有很大的区别，很难区分是出工不出力还是本身就只是那样的能力.
而且稍微大一些的项目，平台选定，硬件和系统软件的投资(我们这儿大概是项目总额的40-60%之间)下去以后，开发方的选择余地就小了很多。

我认为这是最理想的方式，无论对于企业还是开发商都是非常有利，非常能降低风险的方式。但是，国内很多企业根本不能把供应商（不仅仅是软件开发商）当成平等的合作伙伴，建立长期的合作关系，特别是双方在实力上差距比较大的时候。“客大欺店”的现象是普遍存在的。

但是，这种方式也并不是不可能的。我现在在日本。日本大企业在选择供应商的时候是非常谨慎的，会经过非常长的考察期。但是一旦建立合作关系以后，这种关系就是非常牢固的。只要开发商不犯大的错，这种合作关系一般都能稳定地长期持续下去。

只能希望国内的企业在管理上尽快成熟起来，除了重视客户关系以外，也能重视供应商关系管理。

现在的客户都这样，就觉得作什么都简单。

干8小时就收8小时的钱，干12小时就收12小时的钱么。别说晚上加班，春节加班都没问题，三倍工钱就是了。
可能某一个时间线对于客户很重要，他一定要在这天以前上线，不然就损失很多钱。那么没问题，加班也要给他干出来。但客户必须为此付出相应的成本。如果事实变成开发团队加班是客户白捡的钱包，你说还有什么能阻止每天都加班？

从“软件项目”的角度来说确实是这样没错。但从软件生命周期的角度来说，尤其是对于构成核心竞争力的IT系统，变化本身就是它的价值所在。软件开发（尤其是商用软件开发）不应该把自己局限于“项目成功”的态度，应该考虑如何为客户创造最大的价值；同时客户也必须承担相应的责任与风险。

其实现在的项目经费就是按时间收费算出来的。
估计项目需要多少个人月，人力成本再加上各种成本就成了项目的合同额。
还有一种按时间收费的方式就是卖人，也就是通常的把人派到客户方归客户管理的外包形式。
外包公司按人头收费，干了多长时间就拿多少钱。这也就是按时间收费啦