关注微信 欢迎致电:400-8310-286

你在这里

如何确保客户Demo的成功

前两天有个项目,客户要求在3月17号前要完成第一期工作,因为他在3月17号安排了一个重要的演示(Demonstrate),团队根据客户的要求,制定了在3月14号给客户提交版本的计划。3月14号当天,由于工作整合时发现有较多问题,未能成功交付,于是整个团队在3月15号(周六)主动加了一天班,终于在3月15号完成提交。3月17号(周一)来上班时,发现客户对交付物进行了验收,并且提了一些需要修改的Bug,要求尽量在当天改完。当天经过团队的努力,修改好了客户反馈的Bug,并且再次提交。晚上,客户发邮件说程序无法工作,未能成功演示,邮件中充斥着不满的情绪。为什么团队成员的努力工作,却未能换来客户的肯定和满意?到底是哪里出了问题?如何才能避免这样的场景呢?

 

仔细分析下这个案例,不难发现下面这几个事实:

A - 项目交付之后,客户总是需要一些时间来验收,团队也需要一些时间来修改Bug,程序才能达到稳定状态;

B - 总是会出现些预料之外的事情,譬如整合时的问题,譬如提交后客户无法运行的问题等,这些预料之外的事件会消耗掉不少时间和精力;

C - 上述两个问题是可以提前预见的,因而可提前规划对策,这样会将其负面影响降到最低;

 

对此,总结出来的经验教训是:

  1. 团队向客户提交的日期(Deliver Day)比客户的演示日期(Demo Day),至少要提前三个工作日;这段时间将用于客户验收测试、修改Bug、配置和部署演示环境、预演、以及应对预料外的事情;
  2. 如果中途情况发生变化,无法准时提交,需要尽早更新计划,并且及时跟客户协商对策;譬如Cut掉一两个功能、加班赶工、或是延后演示日期等;
  3. 建议客户提前一天进行一场预演;
    1. 调试好演示时要使用的环境和设备;
    2. 准备好演示时要用到的数据;
    3. 过一遍演示时将展示的功能;
  4. 提前获取客户的演示清单,包括将演示的功能列表、操作顺序等;团队内部根据演示清单测试,尽量保持与客户操作的一致性;
  5. 提前了解演示现场的环境,包括网络环境、设备、操作系统、浏览器等;
备案/许可证编号为:渝ICP备14000366号-1