前两天有个项目，客户要求在3月17号前要完成第一期工作，因为他在3月17号安排了一个重要的演示（Demonstrate），团队根据客户的要求，制定了在3月14号给客户提交版本的计划。3月14号当天，由于工作整合时发现有较多问题，未能成功交付，于是整个团队在3月15号（周六）主动加了一天班，终于在3月15号完成提交。3月17号（周一）来上班时，发现客户对交付物进行了验收，并且提了一些需要修改的Bug，要求尽量在当天改完。当天经过团队的努力，修改好了客户反馈的Bug，并且再次提交。晚上，客户发邮件说程序无法工作，未能成功演示，邮件中充斥着不满的情绪。为什么团队成员的努力工作，却未能换来客户的肯定和满意？到底是哪里出了问题？如何才能避免这样的场景呢？
仔细分析下这个案例，不难发现下面这几个事实：
A - 项目交付之后，客户总是需要一些时间来验收，团队也需要一些时间来修改Bug，程序才能达到稳定状态；
B - 总是会出现些预料之外的事情，譬如整合时的问题，譬如提交后客户无法运行的问题等，这些预料之外的事件会消耗掉不少时间和精力；
C - 上述两个问题是可以提前预见的，因而可提前规划对策，这样会将其负面影响降到最低；
对此，总结出来的经验教训是：
- 团队向客户提交的日期（Deliver Day）比客户的演示日期（Demo Day），至少要提前三个工作日；这段时间将用于客户验收测试、修改Bug、配置和部署演示环境、预演、以及应对预料外的事情；
- 如果中途情况发生变化，无法准时提交，需要尽早更新计划，并且及时跟客户协商对策；譬如Cut掉一两个功能、加班赶工、或是延后演示日期等；
- 建议客户提前一天进行一场预演；
- 调试好演示时要使用的环境和设备；
- 准备好演示时要用到的数据；
- 过一遍演示时将展示的功能；
- 提前获取客户的演示清单，包括将演示的功能列表、操作顺序等；团队内部根据演示清单测试，尽量保持与客户操作的一致性；
- 提前了解演示现场的环境，包括网络环境、设备、操作系统、浏览器等；