3.1 项目商务管理

3.1.1 制定信息化项目商务合同的几个关键问题

【案例故事】

一家从事企业信息化咨询与服务的公司，向客户提供ERP、办公自动化（OA）系统等信息系统规划设计与实施服务。

公司成立三年，一边开发产品，一边拿项目。客户倒是开发了不少，但项目合同金额都不大，而且因自主开发的产品不是很成熟，客户定制开发的工作量较大，人工投入很多，上线后的维护成本也很高。为此客户的满意度不高，验收回款很困难。

市场部与技术部门互相指责：市场部认为技术部交付能力需要提高，技术部认为市场部合同签得不合理，项目可行性很差！老板各打五十板，要求各自回去分析问题，提出整改方案。

孙超是市场部工作了两年的销售经理，这些天孙超十分苦恼，手上的几个项目合同，执行的效果都不太好，见表3-1。

表3-1 合同执行情况分析表

表中第一个合同是与两年前上系统的一个老客户签的。当时急于开拓市场想积累一些实施案例，签单的价格很低，30万元含产品和实施，再加两年免费维护。几年下来，开发和实施维护人员的工资都入不敷出了，本来总价就不高，客户还押着10%的质量准备金不肯付。一边是开发和实施部经理的抱怨：“两年的免费维护，本来就已经超出一年免费期的常规了，还把不是维护的新功能也放在维护中做，这怎么搞？”另一边是客户的不满：“你们承诺了两年免费，怎么成了一句空话？一大堆的问题提出来，一两个月也没有解决，还说要收二次开发的钱？”

“唉……”孙超也一筹莫展。

第二个项目是去年签的一个单，当时挺得意的，是开始业务以来最大的一个项目，合同金额一百多万元。项目进行了快一年，承诺给客户的系统功能，开发部门认为已经交付了，客户却认为还要修改，上线时间也比合同中承诺的三个月推迟了一个月。按完成的工作量对照合同，差不多应该付80%的钱了，目前只拿到合同签订后的第一笔15%的付款。最近一个月跑客户单位已经跑断腿了，该找的领导也找了，就是不验收。客户也说得很直白：“现在系统还不稳定，时常有问题，谁敢在验收单上签字？出了问题谁负责？”

其余还有几个合同，系统已经上线，需要进一步签订合同，进行二次开发，开展优化应用。开发部写了几个功能，报了价，客户却不认可：“只是在原来的基础上优化，怎么赶上做一个新系统的价格了？”孙超也弄不明白开发部报价的依据，开发经理却说：“这些需求是专门为客户定制的，其他客户都用不上，不是产品标准功能，以后还要专人维护，当然是要贵一点！”

唉，可是客户看不到值这么多，合同没法签哪！

想想这些合同，好像没有一个能体现自己的工作业绩，这可如何是好？

【案例分析】

孙超的这个案例中涉及的合同，属于软件开发、销售与实施服务等信息系统应用合同。此类合同所涉及的项目，往往不只是一个软件产品的单纯销售。以最典型的ERP项目合同为例，它除了向客户提供企业人、财、物等资源的管理软件，还需要梳理客户的业务流程，推动流程的重组优化，分析标准软件功能与客户流程的差异，并进行适当的客户化的开发，将软件与业务流程匹配，同时培训关键用户，推动用户使用系统。

在这个过程中，往往涉及对客户企业流程的再造，由此带来企业各部门业务权限的变化、用户工作习惯的变更、用户对软件功能适用性的开发与调整需求等。因此，这一类合同在商务阶段对合同的工作内容界定比较困难，对项目执行效果的评估标准也较难定量化，如果没有对后续项目执行过程的实施经验，在合同的把握上欠缺考虑，就会出现孙超这样的情况。

作为专门负责信息化项目合同的商务负责人，面对已经既成事实的项目合同，笔者建议孙超首先应该面对项目的困难和问题，除了对每个合同有针对性地采取措施一一应对以外，更重要的是总结经验教训，从根本上提出改善的方案，提升今后的商务合同质量，从源头采取措施，规避未来合同的风险。

基于这一思路，要依据信息化项目的特点深入研究合同的条款，将合同范本化、标准化，总结出共性的规律反映到合同条款中，并以此指导商务人员对关键问题的处理，降低合同的执行风险。

以下是信息化合同条款的几个关键问题分析，可供参考。

1.分解细化工作项作为合同价格依据

价格是合同中首要的问题，信息化项目，尤其是软件开发和软件实施服务，在其价值评估方面，相当长的一段时间内没有统一的标准。国外大型软件厂商、国内本土产品，以及以项目为单位的定制化开发的软件系统，在不同的行业、不同的地区、不同的客户、不同的服务商之间，价格差别很大，可比性不高。案例中孙超面对的情况，建议还是从《工作说明书》（Statement of Work，SOW）入手。

《工作说明书》的核心内容是对项目工作内容进行WBS分解。大多数的信息化项目，在这些年的发展中已经形成了一些通用的WBS，如表3-2所示。

建议孙超组织富有经验的实施和开发工程师，依据本企业自行开发的ERP产品的特点及行业的特点，以通用的信息化项目WBS为参照，形成自己的项目工作说明书模板，并在以往项目数据和行业同类项目数据的参照下形成每项工作的标准时间和工作量估算，以使得自己与客户双方对于合同的价格都有据可依。

表3-2 ××信息化项目WBS示例

还要特别说明的是，关于信息化项目中的二次开发，也就是专门为客户定制开发的部分，尤其要做好功能点的分析和度量，以便让客户理解这部分的工作量和价值。

认真对待《工作说明书》，可以明确项目的工作范围，对于客户说不清楚的工作，可以依照需求阶段制定的《需求规格说明书》（Software Requirements Specification，SRS）为准，再有不明确的，可以划定工作量的范围，将未知部分的上限做出约定，如果有超出，可以另行拟定补充合同。

2.承诺保证条款要留有余地

在签合同的阶段，商务人员普遍的心态是签下合同再说，否则项目可能就花落别家了。所以经常在面对客户的要求时，不管合不合理，总是先应承下来。很少真正去弄清楚要实现客户个性化的需求，工作量有多大，费用是多少，进度上能不能满足，实施与开发团队有没有资源投入，是否具备准时交付能力。

在孙超的这些合同中，仔细分析起来，在很多方面都做了一些过度的承诺。

●第一个合同：30万元含产品和实施，再加两年免费维护。很典型的在投入资源方面，做了过度承诺，在合同总价很低的情况下，还加上了两年免费维护的成本。实施开发队伍没有积极性，对客户的响应度也会比较低，客户会觉得承诺的没有做到。

●第二个合同：承诺了系统功能，承诺了三个月上线的时间计划。而项目过程中，交付能力又没有跟上，或者可能受各种环境和因素的影响，没有全部兑现承诺。

因此，孙超应该总结经验教训，在涉及系统功能范围、时间计划、资源投入等方面的合同条款中，尽量避免“过度承诺”。如果客户提出要求，在合同中明确加入这些内容之前，一定要与实施和开发团队充分沟通达成一致，同时为自己留有余地。

系统功能范围方面，除了使用SOW约定工作范围，还要增加一些对未知需求的估价弹性，例如，留出10%～20%的合同款余量处理例外事务的预算。

时间计划方面，阶段性交付的时间设置为一个时间段而不是一个时间点，此外增加一些达成目标的条件约束和不可控因素的考虑。比如，上线前客户各方面数据的准备程度、软硬件环境的到位，以及排除因客户因素导致的计划延迟责任等。

3.缜密考虑验收与付款计划

验收与付款计划是新手签合同时容易忽略的一个问题，菜鸟商务人员或项目经理经常埋头狠算成本，眼睛盯着合同总价，在总价上与客户讨价还价，却没有去思考后面如何一步步把钱收回来。有经验的项目经理都知道，项目的各阶段验收与付款安排对项目现金流、资源的及时调配、人员的激励，以及收款的可能性等都是非常重要的。

比如，在孙超的合同中“按完成的工作量对照合同，差不多应该付80%的钱了，目前只拿到合同签订后的第一笔15%的付款”，从这里分析，65%的工作是先付出去了还收不回来的，如果验收方面出点什么问题，时间一拖下去，垫付的成本就会很高了，那剩下的20%工作还做不做？做，继续付出，不做，时间等各方面成本就会很大，甚至如果问题得不到解决，最后拖成坏账。

因此，这种情况一定要通过合理确定验收时间与付款比例来尽量降低风险。表3-3中的比例是乙方应该尽量争取的。

表3-3 付款计划参考

首先，第一笔付款，一般在合同签订后几个工作日内，客户要先付款，工作才启动。双方刚刚才亲密结盟，第一笔款往往都会比较顺利，因此应该利用这个机会，尽量将第一笔付款比例提高到20%～35%，越高越好。

其次，把尾款的比例考虑好，尽量控制在最小范围，如5%～10%。一般合同会将尾款限制在要有一年的质保与维护服务期作为付款条件，而这一年内系统如果出现问题或者客户对系统不满意，尾款的回收是非常困难的，很多时候都会被扣掉了。

在掐头去尾以后，中间过程的付款就与阶段验收紧密相关了。原则上尽可能设置一些关键里程碑，达到里程碑后及时组织验收与付款。里程碑的划分，可以按项目开展的阶段，也可以按系统各功能模块的交付进行设置。例如，按项目开展阶段可分为提交系统设计方案、完成系统部署、完成培训、上线试运行等，按系统各功能模块可分为财务模块、供应链模块、人资模块、工程管理模块等，各模块分别验收与付款。

细分了验收的阶段，还要注意验收的标准。孙超的合同中，在验收组织时间上没有对客户的制约，结果客户不愿验收就不能推动工作。如果在合同中增加对客户组织验收的义务，或者约定在交付后一定期限内，客户没有提出异议或继续实施和使用系统，则视为客户已通过验收，那么这些约束条件就将组织验收的压力和责任转移到了客户方，以避免客户对验收的故意拖延。

同时，在验收组织上，可以引入一些中间机构、中立组织参与验收，避免客户单方面的意见左右验收结果。在验收条款中也需要约定付款期限和违约赔偿责任，如逾期处以每日一定百分比的罚款等条约来保护乙方的权益。

4.注意客户在合同履约中的责任

在此过程中，还要提醒孙超的是，别忘了规范客户在合同履约中的责任。由于甲方处于优势地位，往往针对乙方的责任约束和违约赔偿条款比较多，比如，“如果因为乙方原因不能如期上线，自规定系统上线之日起每天按合同总额的1%收取乙方赔偿金”“如果验收时系统功能不满足用户需求，甲方按照相应比例扣除乙方合同金额”，等等。但对于甲方应该承担的责任，却着墨不多。

甲乙双方作为合同主体，在合同中的责任和义务应该是对等的，应对赔偿金的上限有所限定，一般情况下限定为合同总额的一定比例，最好不超出合同的总额。曾经发生过这样的案例：由于合同对此没有限定，在双方出现严重分歧后又迟迟没有解决，结果三年后上法庭，依合同条款（拖延一天赔偿合同总额的5%）判一方要赔偿对方数十倍的合同额。

在信息化项目中，甲方一般应该承担的责任见表3-4。

表3-4 信息化项目合同甲方责任

（续）

5.别忘了对运行维护的约定

初上信息系统的用户，往往认识不到系统运行维护期间的问题和可能发生的工作量。不管是甲方还是乙方，在项目预算和合同签订的过程中，都容易忽略对系统维护责任和成本的考虑。

在此案例的第一个合同中，孙超许诺客户两年的免费维护，更惨的是没有划清维护责任：哪些是运行维护的范围，哪些是超出范围新增加的开发工作。其结果必然是对自己非常不利。因此在签订合同，在SOW中一定要对维护的内容、范围及期限做出明确的约定。有必要的话，还可以对运行维护另行制定专门的运维合同列出详细约定。

以上合同的几个关键问题，如果孙超都能仔细总结，订立合同制度与规范，相信能有效减少项目执行过程的争议。

【小结】

由于信息化服务对技术性和专业性的要求较强，信息化项目的商务合同，往往对项目的后续实施和交付产生较大的影响。如果项目销售经理不太关注技术的细节，在售前阶段缺乏与技术人员的沟通，忽略交付过程的难度，对合同条款也没有细心地琢磨，常常会导致合同执行期间出现争议，客户不验收、拿不到回款，或者陷入无休止的系统维护。

因此，谨慎处理合同中的关键条款，对于项目的顺利交付相当重要。

3.1.2 如何进行信息系统建设项目的范围管理

【案例故事】

小李是国内某知名IT企业的项目经理，负责西南某省的一个企业管理信息系统建设项目的管理。在该项目合同中，简单地列出了几条项目承建方应完成的工作，据此小李自己制订了项目的工作说明书。

甲方的有关工作由其信息中心组织和领导，信息中心主任兼任该项目的甲方经理。可是在项目实施过程中，有时是甲方的财务部直接向小李提出变更要求，有时是甲方的销售部直接向小李提出变更要求，而且有时这些要求是相互矛盾的。面对这些变更要求，小李试图用范围说明书来说服甲方，甲方却动辄引用合同的相应条款作为依据，而这些条款要么太粗、不够明确，要么双方有不同的理解。小李因对这些变更要求不能简单地接受或拒绝而左右为难，他感到很沮丧。如果不改变这种状况，项目完成看来要遥遥无期了。

小李很困惑，他一直在思考两件事：

1）该问题产生的原因是什么？如何解决？

2）项目经理应该怎样在合同谈判、计划和执行阶段分别进行范围管理？

【案例分析】

根据项目信息，笔者将案例中的问题列出，并给出原因分析和解决方案，见表3-5。

表3-5 某信息化项目原因分析

（续）

信息系统建设作为一类项目，具有几个鲜明特点。

（1）目标不精确、任务边界模糊。在信息系统开发中，客户方也就是甲方常常在项目开始时只有一些初步的功能要求，没有明确的想法，也提不出确切的需求，信息系统项目的任务范围很大程度上取决于乙方项目团队为其所做的系统规划和需求分析。因此，最开始形成文字的工作范围，往往就如本案例中的项目合同，“简单、太粗、不够明确”。

（2）客户需求随项目进展而变，导致项目进度、费用等不断变更。尽管已经做好了系统规划、可行性研究，签了实施合同，然而随着系统分析、系统设计和系统实施的进展，客户的需求不断地被激发，导致程序、界面及相关文档需要经常修改。正因为一开始很难界定清楚，后面的变更才在所难免。而且，信息化系统一般都涉及客户的业务流程，跟多个部门都相关，各个部门对信息化的理解、认知和应用不同，很容易造成不一致，如本案例中财务部和销售部对小李提出的需求互相矛盾。

（3）信息系统项目是智力密集、劳动密集型项目，受人力资源影响最大，项目成员的结构、责任心、能力和稳定性对信息系统项目的质量以及是否成功有决定性的影响。这一条充分说明了信息系统项目的“软”特性，非常依赖于人的主观创造性、工作态度等。

那么，对于一个信息系统的项目经理，应该如何做才能较好地进行项目范围管理呢？下面是笔者的一些经验之谈。

（1）合同谈判阶段。项目经理参与工作，将SOW作为合同附件。

商务是销售的事情，但是合同中有关双方应该承担的责任和义务、对工作范围说明书的要求，以及付款的条件等，只要与实施相关，项目经理都应该拿出自己的意见，甚至是起主导作用（这跟项目经理个人能力有关，不同公司做法不一定完全一样）。一定要说明，合同一般只是对项目的范围一个粗略的概要说明，详细内容是作为合同附件的SOW，而SOW一定是项目经理编写，和客户进行沟通后的结果。

有时候，合同里的一句话包含一大块功能，如“构架包括项目管理全部要素、覆盖项目管理全过程、涵盖各类项目管理类型，整体关联关系明确、基础数据库设计灵活，人机界面友好实用”等类似词语，不同的人很容易产生不同的理解，这些只能作为建设原则，而不能作为需求，如果不事先说明，自然就容易出现本案例中的问题。

有的时候，SOW也不能完全说明工作范围，可以在合同中进一步规定，进入客户现场工作后双方认可的《需求分析报告》《实施方案》之类的文件可作为项目实施的标准。

（2）关于甲方项目经理的人选和职责。正如前面所述，信息系统项目的特点是多学科，多部门合作。信息化建设项目的甲方项目经理往往都是由信息中心主任担任，如本案例。但信息中心一般是传统行业的技术支持部门，不是业务部门。所以企业中的信息中心主任往往又处于“弱势”的地位，并没有协调企业各业务部门的职能，话语权不高，不仅在项目实施过程中困难重重，如本案例中的财务和销售的行为信息中心主任就很难协调，而且即便系统上线后，系统的推广和使用也较难开展。尽量争取让甲方的“实权”人物能够领导信息系统项目建设，否则，按照历史经验，信息化系统建设真的是举步维艰。

一些企业，在合同签订之后，和甲方签订一个项目章程，作为项目管理的依据。在项目章程中，对双方的项目管理活动都做了很多规定。例如商定：“甲方需要由一名高层领导担任项目负责人，并指派一名项目经理具体负责，该项目经理在甲方内部具有协调各相关业务部门的职权，能够协调甲方内部不一致的需求，并在项目期间作为甲方唯一的接口人与乙方进行沟通和协调。”

以上工作建议在项目计划阶段提出，为后面的范围管理打好基础。

1.做好需求调研

合同签好，项目章程定好，项目组进入客户现场工作，才是真正的需求调研开始。信息系统建设就是如此，不同的系统调研内容不同，但方式大同小异，都是访谈、查阅资料、考察原有老系统等。总的说来，了解客户现有的业务流程，整理出客户需求，做好工作量估算，制订出合理的实施计划，让客户签字认可，这是基本的业务能力。同时，作为项目经理，这个时候就要考虑后期出现变更怎么办的问题，要考虑好制定需求变更流程。

信息化系统的需求说明，要保证可操作、可测试、可评估，否则就会出现扯皮现象。尽量使用用户界面来表达需求，或者先做出原型让客户看到效果。关于需求表达有很多方法，此处不再赘述。

2.建立完善的需求变更流程

在项目执行阶段，需求变更在所难免，有关需求变更流程，本书中已有很多案例分析，如“关于应对客户需求变更的两种方式的讨论”，标准流程大同小异，关键在于解决执行。

【小结】

信息系统项目建设是一个综合性的、面向管理决策、管理方法和手段相结合的系统工程，范围管理是其中一个难点，对项目管理者是一个很大的挑战。项目经理常常陷入困境，要摆脱困境，只有依靠规范的项目管理体系和科学的方法去降低项目风险，取得项目成功。

3.1.3 在软件开发项目中，与客户谈判的要点

【案例故事】

小李从一个著名的IT企业辞职了，为了创业的梦想，自己开了个公司，想运用十多年软件技术和项目经验的积累，自己当一回老板。凭着多年的开发经验和典型的技术员气质，很快在朋友的介绍下，取得了一个客户的信任，准备承接一个文化教育类网站开发的项目。

客户方的团队成员是清一色的文艺青年，不大擅长IT技术那些事儿，不清楚软件是如何产生的。不过生活在信息的时代，又有丰富的想象和活力，它们很想将一些线下业务，如教育培训、活动、俱乐部等文化产品搬到网上，运用流行的这些信息技术，如社交圈子、网络视频、网上论坛与用户拉近距离，线上线下互动发展。小李的出现，正好迎合了客户的需求。

小李也挺兴奋，做教育和文化这个行业很有意义，这些需求也没什么技术难度，作为自己公司的第一个项目，应该是不错的开端。

双方的初次接触，都留下了很好的印象。接下来的日子里，开始了需求的讨论。小李很认真地记下客户的每个问题和想法，很快把需求整理出来，技术方案也选定了一个比较领先的框架，整理好报价发了过去。

第二天客户电话来了：“我们原来的需求挺简单，怎么搞出了这么多需求？”“都是你们的成员提的啊！”小李答。“大家提的也不一定都是需要的，可能没考虑成熟，你作为专家，要把把关，替我们管理人员多考虑和平衡一下，再讨论讨论吧。”“好吧。”小李又花了两周时间，扎在客户单位，与文艺青年们反复说明讨论，唾沫都说干了，终于又整理出一稿。“这回差不多了吧，”小李想。

一周过去了，没有回音。“什么意思呢？不是很急吗？”与小李关系不错的一个客户成员告诉小李：“这阵子老板正找别的商家谈呢！说你报价太高了，就那么一点需求，怎么要那么多钱？连美工的报价都这么高，我们这儿一大把搞美工的，随便适应一下也都能用吧。”小李挺不爽：“我已经是报的最低价了。这些需求看起来容易，要实现起来，可不是那么简单。还有网站前台的设计，不能影响用户的感观和体验，要做就做一个好的产品，我选的是做展会网站的高级美工，当然贵了一点了，但是物有所值啊。再说我选了一个很好的技术框架，把旧的系统完全替换，虽然现在工作量大一点，但以后的开发与维护都省钱了。如果用原来的框架继续做，开发的钱倒是省了，维护该麻烦了，说不定还要花更多钱去弥补。”

“我这些都是为他们着想啊，怎么就不理解呢？就这么一点事就来来回回折腾这么久，时间都花在和他们谈来谈去的解释中了，这个时间已经可以把东西做出来了，唉……”一想到还要去找客户再商谈，技术出身的小李感觉头昏脑涨。

【案例分析】

技术与商务，是不同的学科、不同的领域，需要的知识与技能有很大的不同。IT行业，有不少工程师，尤其是软件工程师，在从事软件开发、技术经理的时期，能够自如应对，一旦开始自主创业，才发现当老板不是自己想象的那么容易。很多人不能适应商务的特点，业务发展失败，铩羽而归重操旧业。

案例中的小李遇到的问题，是很多软件开发出身的工程师们在从事商务活动时遇到的尴尬。作为开发人员，主要是关注如何运用技术，开发出满足客户需求的产品。而作为一个项目经理或老板，在接单的时候需要考虑的就不只是“一个好的技术框架”的问题。

对于小李遇到的问题，在重新去跟客户进行商谈前，应该首先对客户进行仔细的分析。

首先，想清楚这个客户的价值与定位。

商务谈判时对客户采取的策略，取决于这个客户对业务的作用与重要程度。作为创业的第一个项目，客户的重要性不言而喻。第一个项目，对一个刚起步的企业，积累经验、获得成功案例比取得利润更重要。

另外，从行业发展趋势来分析，这个行业是不是一个朝阳行业，是不是新兴产业，软件应用系统在这个行业的发展前景如何？小李是否能借助这个客户的成功案例，对这一行业的特点与业务深入了解，并创造和引导其他的项目机会？

分析清楚这些问题后，再看看客户的规模、在行业的影响力、业务状况、财务状况、资信情况等。判断它是不是一个有价值的客户，想好客户的定位。

其次，搞清楚关键决策人是谁，特点是什么，到底要什么。

商务谈判，一定要搞清楚谈判的对手是谁，谈判的关键决策人是谁，有什么特点，他代表的客户的真实需求是什么。从案例来分析，小李为客户需求下了不少的工夫，但是为什么整理出来的需求客户都觉得不满意？是否搞清楚了关键决策人要什么？参与需求调研的客户提出的需求，能不能代表关键决策人的需求？

在商务谈判过程中对软件的需求分析，项目经理一定要注意对各层次需求的识别和把握。搞清楚哪些需求是关键决策人的需求，哪些需求是一般用户的需求，哪些是必需的，哪些是非必需的，各层次需求之间有没有矛盾，能不能找到平衡点等。比如，在此案例中，客户成员提的各种需求，如果不加以识别，全部开发实现的成本可能较高，可能不符合关键决策人的成本控制需求。这有可能是关键决策人不满意的原因。

因此，再次商谈前，小李一定要分析关键决策人，搞清楚他的利益重点、权限范围，对项目的总体期望和定位，以及项目预算、时间要求、交付物的要求等。

最后，设定自己的底线和目标。

分析清楚客户的同时，还要分析清楚自己——自己做这件事情的成本是多少，需要投入多少的资源、时间和精力。如果有外包的工作，还要评估好外包的工作量、成本。在知己又知彼的情况下，确定合同的价格谈判区间，确定向客户的报价，并做好对报价的标准说明，包括工作量清单等。

同时要清楚，底线和目标不仅仅是价格，还要考虑除了价格以外的其他因素。例如，合同分几期付款、每期付款的比例和条件、客户付款的程序和习惯；工作范围的边界是否清晰，要预留多大的弹性；交付物包括哪些内容，对工作量的影响如何；客户对外包有没有限定条件，对成本有没有较大的影响；客户对软硬件采购是否有特殊的要求等。对非价格因素准备得越细，在谈判中越能够与报价互相配合，争取自己的利益。有时候，在价格做出妥协的同时，争取一些非价格因素的利益，可以加强综合的项目收益。

通过以上几个方面的分析，在知己知彼的前提下，把商务谈判的总体策略确定下来。

接下来，适当运用谈判的技巧。

谈判技巧是很重要的，不过这不是一朝一夕的功夫，需要在长期的商务实践中一点点积累。可以先从一些基本点做起，比如：

1）搞清楚竞争者，明确自己的优势。充分展现你为客户提供的核心价值是什么，如在软件技术框架的先进性方面、在功能与非功能需求的符合度方面、在性能方面、以及在软件售后服务方面的优势和特点等。

2）把握商讨的氛围。不卑不亢，切忌一味迎合。很多的软件开发项目，为了赢得客户订单，对客户需求一一应承，什么都能做，签单后无法控制需求和工作量，于是又百般推诿。这样常常造成项目难以收款，开发成本也很难控制。

3）把握让步的时机和幅度。在充分陈述报价理由的基础的同时，也要准备好让步与适当的妥协方案，并在商谈过程中把握好让步的时机和幅度。

如果让步过早，对方会认为你报价水分太大，反而有可能得寸进尺，步步紧逼。如果让步时间过晚，又往往会让对方觉得你的合作性和诚意欠佳。可以将让步的内容细化分成几部分，在谈判中把握时机，分次进行。例如，在每个功能点的单价上、在每人月的服务价格上、在功能点的总体工作量上、在不可预测的工作范围上，或者在付款条件上等进行细分。

另外，最后让步的幅度问题也很重要。如果让步的幅度太大，对方反而不相信这是最后的让步；如果让步的幅度太小，对方认为微不足道，难以满足。所以事前要做足功课，在报价与底线之间留出合理的让步幅度。满足客户在商务谈判中取得成效的心理需求。

【小结】

与客户谈判，对于软件开发项目经理是综合素质与能力的考验。商务合同、需求变更、执行的推动、验收、付款等，整个项目过程，关键节点上都需要项目经理与客户协商、交涉，对问题找到解决办法、对事件取得一致的意见、对利益达成妥协或者平衡。与客户的谈判不仅需要清楚自身的底线和诉求，还要洞察客户的利益，同时掌握一些谈判沟通的技巧。这些对新任项目经理，尤其是由技术出身的项目经理，往往极具挑战。