第一节 爷和孙子

都说客户是爷，我们是孙子，我想说的是爷爷总有糊涂的时候，孙子最好能及时提醒并纠正爷爷。企业上ERP的目的是用软件来规范公司的业务流程，一切按流程办事。但是跟实施人员沟通的具体客户往往意识不到这点，总是认为我们要满足他们的一切要求….. 拜托，如果你们什么都懂，什么都很规范，还要ERP做什么？所以当客户的要求不合规范或不合理的时候，要勇敢对客户Say No，以帮助客户解决实际问题的态度来提出更合理的解决方案。其实要做到这一点很不容易，客户花钱就是要我们做他们想要的事，拒绝客户就是跟钱过不去，所以偶觉得最重要的一点就是建立信任，信任是“基于对他人意愿和行为的正面预期而对其行动自觉跟从的意愿”，让客户相信我们是专业的，我们是来帮助他们的。这种信任要从项目开始时就慢慢建立，潜移默化，慢慢形成。比如客户出现A问题，而实施人员不仅顺利解决A问题，而且还能帮助客户顺带解决B，并提出更优化的建议C，这样就能建立良好的客户关系，相互信任。

第二节 你够专业么

前面说到了信任，但是前提是我们必须是专业的！方案要专业，解疑释惑要专业，提出看法要专业，言谈举止要专业，如果自身条件不够，那就不要处处抱怨客户的苛刻，多从提高自身经验来让自己更专业吧。

第三节 规范化及需求分析

对于technical team最头痛的就是需求不明确，前面说好的事情后面就变卦。这个需要functional team跟客户进行良好的沟通，尽量让客户说出需要什么样的东西，多数情况是客户自己并不清楚需求，这就要求functional team引导客户，用问答或建议的方式搜集需求，分析流程，然后写出规范的需求文档，并要求客户签字，这个对technical team的后期开发至关重要，避免很多无用功。 比如同客户开会讨论解决方案，会后起草一份简单的邮件，记录下会议内容，发给与会者以备后用。当solution或者需求基本确定后，functional team可以写一份简单的specification，并由客户确认后交由technical team开发。开发结束后，首先要经过functional review，然后交由客户review。

第四节

说点本行technical方面的吧，on-site项目基本都会出现人手不够的情况，导致代码质量不高，所以对于开发人员，完整的需求文档十分重要，开发结束后填写基本完整的test case，可以互相帮忙测试！这样既能保证质量，又能规避人员流失产生的风险！这一步很重要，不能等到UAT的时候让用户测试，否则UAT过程的进度会大大延迟。因为某些修改是牵一发而动全身的，测试过程往往会比预料的要复杂！ 某些比较复杂的开发程序，关键步骤最好经客户确认解决方案是否可行，安全性是否够高，系统资源消耗是否过大，风险在什么地方。否则拖到后期改动会导致成本会很高，时间很紧。

第五节

说说项目进度。项目的通病就是前松后紧，那就是项目进度没有控制好。实施人员之间应尽量多沟通，functional跟technical沟通客户需求和疑问，technical跟functional沟通开发进度和客户需求，这样有助于PM了解项目进展的难点，预计下一步的风险。比如如果客户数据很杂很乱，那么就可以预料到UAT测试时会举步维艰，错误的数据在系统里算出来的必定是错误的结果，所以在前期的项目计划里可以考虑把UAT的时间加长一些。