因为拙作《软件项目经理不可不知的18种技能》（培训PPT下载处）发行的缘故，很偶然地被神舟软件的朋友也关注到了，他们的一位资深的项目经理动作也很快，希望我能到他们总部做一次交流，专门讲一天，讲一讲关于管理软件销售和实施的问题。
我的朋友希望重点谈一谈如下问题：
实施方面：项目调研、需求管理、软件问题管理、沟通、进度控制、验收、实施人员应当具备那些素质，如何在工作中提升自己的能力。
销售方面：如何做好方案、售前演示等
产品方面：简单介绍软件发展战略、对用户需求如何在软件中按照什么方式实现、如何管理软件版本及升级、产品链之间的整合方式等。
当然因为我们做管理软件这行的，人都是跑来跑去，凑齐一次也不容易，所以时间就先定了一天，主要是实施人员，销售能来多少来多少。至于内容一天能全部讲到也不现实，企业希望我重点讲针对实施人员的，有时间兼顾销售，另外一些一时谈不完的问题争取用交流的方式来谈。
到了企业，一切都安排得很妥当，讲课过程也很顺利，还发现很多人虽然现在是在一家公司，但都是来自不同对手，大家相件一笑，原来你就是“秋叶”，早就听说过你了，呵呵，这个圈子真小，抬头不见低头见。
培训过程中有两个问题大家提出来得非常多，值得我们进行深入思考。
第一个问题是：实施人员要不要对回款负责？
第二个问题是：要不要响应用户需求？如何在版本中响应用户需求？
第一个问题其实是一个实施模式的问题。
实施人员本质上是一类特殊的技术人员，就是经常有机会接触用户，在用户现场工作的人员，这样的人员对项目实际把握和了解可能超过很多商务人员，这样的人员不负责回款好还是不好？
我原来接触过很多实施人员，我见过这么几种心态。
第一种沟通能力比较强，控制项目欲望也很强，有时候甚至很看不上商务对项目的敷衍态度，很想自己操刀，你要不回来我要回来。
而且有时候商务已经在售前透支了信用，根本就是怕见用户，和用户说不上话了，售后要钱很困难，这个时候实施人员反而通过技术服务取得了用户信任，也许在要钱方面有自己的优势。
第二种技术能力比较强，但不喜欢搞商务活动，工作就是工作，和用户属于比较公对公的行为模式，对流程规范很在乎，让他们要钱开不了这个口不说，还感觉降低了自己的身份，而且有一句观点很流行：一个人又做技术又做商务，可能吗？
第三种无可无不可，公司怎么要求怎么做，反正项目总是有人要负责。
我对这个问题的意见是具体分析。
实施的工作质量对售后回款影响很大，如果实施人员个人收入和工作质量没有任何关系，就必然产生这样的一种导向，大家都不关心项目的真实质量，只关心领导的评价。
如果部门领导英明神武，而且领导有方，和用户沟通畅通，那还问题不大，否则长期下去必然有人在项目中偷工减料而不被发现，但具体做事的大家心知肚明，心理不平衡，自然是有样学样，把部门风气就带坏了。
如果实施的项目难度很大，非某几个人不可，那你是买他的专业技术，自然可以高薪养人，不谈回款责任。
但问题是我们的PDM/ERP一类的项目实施还不至于哪个公司说离开某人就玩不转，更不至于说某聪明好学之人想学技术学一年还入不了门，而且就我所知我们这个行业从来都不是以实施人员薪酬高而名声在外。
所以既然不能提供高薪待遇（实施人员因为担心失去好的工作待遇而努力工作，保住自己的岗位，类似很多进了外企的人的心态），把回款压力和实施工作脱钩我个人以为是失去了约束工作质量的一张利益砝码。
当然收入和回款挂钩不等同于实施人员就负责回款。回款这个工作确实是偏商务的，实施人员中只有那些既懂技术有会做人的人才有这样的潜力直接做回款工作，这样的人最适合培养成项目经理，专门负责多个项目控制和回款，以及团队资源调度和建设，是很合适的。
所以我个人建议公司还是要考虑结合企业项目规模和行业特色，设计方案，让实施人员收入和项目质量挂钩，挂钩最好的办法就是回款，用户不是傻子，项目完全失败他给钱你？就是通过商务运做实施也要能做出个门面功夫吧？
第二个问题其实是实施和开发如何协同响应项目需求的问题。
要解决这个问题必须先建立三个正确的认识，这三个正确的认识不建立，所有后续的想法都要出问题。
1）PDM项目是按产品做好还是按项目做好？
这个问题我是先提做产品赚钱还是做项目赚钱？
大家都认为是做产品，因为做扣子都可以出亿万富翁，但做PDM的目前为止没听说过发大财的。
那么我继续问你认为PDM行业你所见过的企业有没有能按产品实施的？有没有没有定制个性需求的项目？
大家全部摇头，没有人举出反例。
我问了第三个问题：公司是鼓励做项目还是做产品？或者我们大家心里想做产品还是做项目？
大家都陷入沉思。
我说判断一个公司想做项目还是想做产品，我的办法很简单，看企业是否要求签订标准技术协议就好了，要求标准化才能签的就是想做产品，否则就是做项目。
我说第一个问题我的结论是，PDM项目由于现有产品的能力，现有企业的模式很难产品化，最好的管理模式就是项目运做，如果这个观念不建立，实施和开发人员永远都要抱怨销售签订大量不平等条约。
既然和市场都闹翻了，后面谈版本规划就是制造矛盾，而不是沟通妥协并加以消化。
这个观念有了就很清楚，一个PDM公司是努力找到快速响应市场个性化的手段才能很好生存，而不是现在就想着把自己产品化。
产品化的前提要么是你的公司足够有钱有强势品牌运做优势，要么是你的产品架构足够的好，要么是用户需求足够简单，思维足够理性，这些至少对很多公司都不成立。
2）实施和开发是什么关系？
很多人认为开发应该是实施的后盾，实施是开发的灵感源泉，应该是一个战壕统一对外的团队，是对友，但实际上我的认识是实施和开发是一对无法化解的天然的矛盾关系，不认识到这是一对矛盾关系，就无法化解。
开发总是抱怨实施不断提出新的要求，要求改变现有的版本边界，总是破坏流程响应自己的需求，而这样做总是带来开发不断延期；
而实施总是抱怨开发除了会项目延期还会干什么？一提需求就以描述不清楚打回来，不断伤害我们实施人员在外已经被用户无数次蹂躏的心灵，要知道内部的不理解比用户的不理解更伤害自己。
很多公司总是天真的想找寻双赢的模式，其实他们恰恰忘了矛盾在没有新的资源加入的情况下很难双赢，只能选择总体伤害最小的方式。
3）项目开发需求是对内成本高还是对外成本高？
满足用户需求有两种方式，一种是满足，要开发，额外增加项目成本；一种是不满足，但说服用户理解和接受。
哪一种方式最好？
我提了一组问题：
第一、你认为一个中等规模的制造业企业（年产值5~10亿），研发人员100~200人的企业上PDM应该投入多少？
第二、你自己做的项目到了这个金额吗？
第三、你认为这样的项目赚钱吗？
第四、不赚钱的项目不断增加新的乙方投入会提高项目成功的概率吗？
第五、用户到底是想要很多功能还是要项目成功？
第六、是否有了某些功能项目就能成功？
第七、如果你的回答不是功能决定项目成功那你为什么还找这么多开发不作为做你项目陷入困境的借口？难道作为一个项目经理还不知道真正帮助用户的路吗？
我的答案很简单：在项目中创造性的使用一切方法把项目边界砍下来是唯一对中国大部分PDM项目认真负责的态度。
我就是这样的一个人，我就是这样做项目的，我还可以告诉各位，很多用户很认可我，因为我看到了本质，抓住本质才能找到出路。
实施的本质是项目需要成功，用户需要成功，而其它的一切都是可以替换的，包括哪些所谓非开发的需求（根据我们原来所在公司的统计，这些需求80%开发出来后没有真正被使用上，这次培训现场调研大家基本同意这个结论）。
有了这三个认识，其实其它策略都可以结合公司情况推导，没有一成不变的答案。
讲了整整一天，自然很难一下子写到这里，把我自己感触最深的两点写在这里，和大家分享，以后有好的培训心得，我也会继续写出来的。
