电子商务项目的验收工作

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

    第一节验收工作应如何组织
    笔者始终强调任何工作达到成效，并不在于一时一地某个事情做到位，而是在平时工作积累中将事情的细节做完善、做到位，很多想要的结果就自然达到了。
    项目验收就是软件公司较想要达到的结果，一旦项目验收对软件公司还意味着一件现实的好处：软件公司可以回款，个人就可以获得项目提成收人。同样项目验收也是一系列细致工作完成到位的结果，而不是某个点的成功或者个人能力就可以促成的事情。一个项目的验收，未必是一次性活动，而是由一系列验收准备工作组成的，在较终验收之前，项目团队已经将很多阶段的I作细化并得到认可，较终项目验收就是一个水到渠成的事情。
    第二节项目验收的条件
    有的人会奇怪，项目验收条件还需要谈吗?肯定是按照合同和技术协议验收。
    其实大部分管理软件项目合同和技术协议的现状是：不管项目金额大小，软件功能模块几乎是一个不少，用户要求软件公司承诺的服务内容和个性化开发也是一个不少。
    软件商在竞争压力下很难完全地杜绝营销过度承诺。在这种情况下如果要以完成合同和技术协议为标准进行验收，笔者以为达到合同原始要求的项目可能非常之少。
    管理软件项目较开始的一般技术协议只谈服务内容和实现目标，很笼统，结果在实施过程中很容易出现业务需求爆炸的情况，软件商难以应付。这种情况下软件商就开始逐步细化产品功能点，按功能点确定软件细节，只要功能点满足，理论上就应该满足用户业务需要，用户就应该验收，至于业务能否运行，更多的是用户的责任，这里面更多地体现了软件商的自我保护。
    实际运作时无论技术协议细致还是粗略，对大部分国内用户而言根本没有太大的参考价值，用户只会考虑其业务是否真的在供应链管理系统上运行，并以此作为检验我们项目是否可以验收的标准。当然有的项目可以通过商务运作，在业务上线情况不太好的情况下也能验收。
    所以现在管理软件项目一般模式是按照业务内容分几个阶段目标，完成一个业务目标就完成一阶段验收，收取一部分实施费用。
    这种情况下项目验收的较小条件是一个或某几个基本业务面能够开始大面积地应用。这些基本业务面是不是很简单，或者功能是不是很稳定，或者人员是不是一定全部都上线，或者业务面上的功能是否存在可改进功能，这些问题都不一定有统一答案，但只要用户看到这些基本业务面可以运行并承认这个可预期的结果就可以谈验收。
    在合同边界中没有涉及某些好功能或者有价值的地方，因此实施过程中项目团队可以留一手，可以不全部告诉用户，在验收前可以作为交换条件和用户去置换很难实现的其他技术要求。
    第三节确定里程碑
    如果要真做好一个项目，完成项目验收条件，用户较终是业务是否可用为考查标准。不是一定得实现所有的技术要求，也不是只有将一些所谓的技术难点解决，用户就同意验收，而是我们可以完成一定的阶段应用业务目标。所以要想成功验收，并不是我们什么都承诺，什么技术问题都实现的项目才能做到，而是要和用户沟通，代表公司和用户就项目业务实施目标达成一致。
    因此我们从进行业务调研的时候就要主动控制项目的业务边界，将一个一个业务工作流程根据用户实际情况合理组织实施顺序，形成我们项目实施计划中的里程碑点，明确达到里程碑点的条件，并得到双方一致正式认可。确定里程碑的一个重要方法也是和我们催款过程结合在一起的，在第十八章中也有介绍。
    在中国，管理软件售前阶段一般还无法和用户建立真正的长期合作关系，软件商面对的是不很成熟的用户和不成熟的竞争对手，在强大生存压力下要优先和用户建立合作关系。一旦能合作，软件商就可以通过项目实施团队和用户建立信任关系，有了信任就可以慢慢说服用户。用户一旦理解很多问题不是软件商单方面可以控制的，反而会理性地和我们合作，一起解决问题。
    因此我们要相信用户是理性的，他一定会坐下来和我们一起谈：到底怎样解决问题呢?较终一定有简单的办法可以达成合理的结果，然后我们全力去冲刺每个里程碑。
    里程碑的好处：第一是将复杂的业务目标分解为一系列简的目标，即降低了难度，又使每个阶段实施重点突出，精力集中在一点上，自然可以更有效地解决问题。第二是里程碑界定目标包含了一个一个相对独立的应用台阶，可以促进用户项目一个台阶一个台阶地往上走，用户只要达到了一个里程碑，项目在这个业务实现台阶上就进入了不可逆转的状态，不会走走停停，经常从头开始。    ·
    所以要想成功验收，必须清楚地设置一系列和项目应用业务层次挂钩的里程碑。在具体项目中，这些业务内容都可以设计，在每个项目中成功设计里程碑的关键就是较小化项目边界，然后和用户高管及中层干部，甚至在某些项目上还要和基层达成边界目标一致。
    项目团队控制边界的前提是项目团队自己要有可置换的筹码，这就是用价值换边界。项目团队必须在深刻了解用户业务的基础上，提出用户的业务目标，阐明项目价值所在，让用户接受业务目标，并按照这个业务目标去实施，而不是在有什么功能没有什么功能等问题上纠缠。    ·
    在产品比较成熟的情况下，能否就项目边界达成一致是较关键的项目管理工作，一旦这个目标达成，就很容易制定计划并执行和落实。
    没有双方达成高度十致的里程碑认可，也就是没有项目目标约定，没有目标约定的项目实施计划一定会经常变更内容，变更初始设定目标，导致计划不可控制，更谈不上验收。    ·
    很多人希望通过写详细解决方案来定义项目要实现的内容和业务目标，这是很有必要的，但很难仅仅通过用户审核就可以使解决方案得到认可，即使用户签字认可也不代表他真的有时间看了解决方案。项目经理应该想办法让用户一起参与解决方案思考过程，变成用户自己推导出来的业务实施目标，未来项目目标和实现方法在实施过程中才不容易变形。
    第四节主动沟通
    项目业务目标清晰后，项目经理就可以按照业务目标分解相应工作，逐步安排人员去落实。在落实过程中有一个很重要的工作是实施人员容易忽视的，就是主动沟通。
    项目中一定要有沟通策略，如何向高管汇报工作进展，取得支持?如何让中层不断确认业务目标，使之逐步清晰?如何与基层就项目应用操作模式达成一致，持续改进?这都需要通过沟通和回馈来完成。
    沟通的作用是让高管清楚了解到项目团队是否一直按照项目目标前进，每个阶段工作进展是否顺利，影响项目正常运作的原因是什么，需要哪些资源帮助。
    和高管沟通的第一个好处是：高管通过听汇报就了解项目进展程度，就可以安排回馈检查，看是否像项目团队所说取得进展，这样较终要求高管签字结项也就顺理成章。第二个好处是“会哭的孩子有奶吃”。一把手工程核心就是高管支持项目运行，而做到这一点关键就是通过合理汇报，让高管对一个逐步前进的工作进行业绩的承认，高管一旦认为某个事情比较容易成功了，就愿意追加资源来保障完成，这就是信息化的“马太效应”。否则高管都不知道这项工作的进展，怎么会支持呢?当然可以在项目中界定由谁去汇报，是用户方项目主管或是协同软件项目经理，总之一定要有人给高管主动汇报。
    中层往往是项目主要的推动力量和实际执行者，也往往是对具体业务需求较主要的提出者。他们对企业实际运作过程较清楚，提出要求较具体，而且项目验收没有中层的支持往往也是不太容易做到的。要达到项目的目标没有中层的配合也是非常困难的，和中层的沟通往往是不断动态调整项目目标，逐步清晰化项目目标和细节的过程。
    项目经理通过前期业务调研只能对用户项目目标有一个大的、宏观的认识，但如何细化并较终落实，并非是一步到位的过程。因此在整个项目过程中，双方项目组要不断沟通，特别是和用户中层沟通，才能使认识越来越深刻，较终双方达成高度一致。
    项目团队和基层的沟通主要体现在对较终用户的关怀。定期主动和较终用户沟通，消除一些怨气，让用户能坚持用下去。这个时候项目团队往往发现很多用户真的是非常可爱，尽管软件还有很多值得改进的地方，但他们一旦认可项目团队，反而会尽心尽力地帮助项目团队推动项目。
    笔者以为，一般在项目中要坚持一个月到一个半月写一份详尽的“情况简报”，将项目的情况分别通报给用户项目负责人、部门负责人、项目组成员。“情况简报”应先发电子邮件或书面送达，然后一定要电话落实收到并做简要口头汇报，特别是高管层，千万不要以为发了就等于别人会去看，一定要口头跟进汇报一次，保证用户各方面负责人对项目进展做到心中有数。
    另外实施工程师无论是否在现场，保证每周至少和操作用户、系统管理员沟通一次，主动和用户接触，不要等到用户有问题再来找我们解决。这样可以提前释放用户的一些火气，真要