这大概是两个星期之前发生的事情了，这个星期一直很忙，于是没记下，再拖就一个月了，决定今天，现在，记下这个教训。
背景介绍：
一个新需求是关于老系统的升级的，要求team3准备一个升级包，里面包括自动解压安装的批处理和全部文件的升级包。客户发过来的需要升级的文件（注意，只有增量文件，不是全部文件）。
升级包是关于同步服务器组件包，这一块比较熟悉的是team1。
team3是新进团队的一个小伙子，对业务不太熟悉。
这个新需求开始之时，我告诉了小伙子大致的方向，以及他可以用到的资源，包括以前的自动解压安装的批处理，还有他可以求教的team1的同事，于是项目开始了。
项目持续了两天，到了发包的那天(deliverable day)的晚上，发现这个team3的小伙子还在准备包，自动解压安装已经没问题，可是新安装的Server运行不起来。一调查发现，这小伙子直接把这增量文件放到了客户目前的老系统包中，而不是我们目前手里的最新的包，也就是说他只升级了这次业务需要升级的文件，而最基础的Server组建还是用的老的，自然Server运行不起来了。而此时已经很晚了，即使你找到了最新的包，集成上去还不知道对不对，即使对，还需要大量的测试而此时已经没有时间。于是决定跟客户说今天不能发最终版本的包。
只不过有个小小的分歧：
到底应不应该把这个未完成的包发出去？
team3小伙子的观点以及其他团队成员的观点是：没完成就不该发。
我的观点是：这个包是没有完成，不过这个项目本身分为两块，第一是自动解压安装流程的批处理程序，第二是新升级后的Server要是运行无误的。我们虽然今天没能按规定时间完成，但是我们可以把我们已经做的工作给客户预览下，他可以提意见反馈。并且我们在邮件正文中强调告诉他这不是最终版本，里面有问题，我们明天会调查原因并完成它。由于客户本身也是技术部门，产品是他们做的，我也想让他看看新包是什么原因不能运行。
于是按照我的观点发出去了，而且邮件写得很清楚，包不是最终包，希望客户给点建议。
结果是客户有个不好的习惯--“他不喜欢看所有的邮件”，基于一系列机缘巧合，他知道我们发了包，但是不知道这不是最终的包！于是，开始责怪和质疑。根据“客户永远是对的”原则，这次错在我。
经验总结，关于该不该发未完成的包：
如果提交对象是非技术型客户，不能发，因为没有任何意义；
如果提交对象是技术客户，谨慎考虑，尽量不要发。如果实在有原因要发，要在邮件写清楚，并且注意把握可能发生的风险。
发未完成的包都会因为误解、沟通丢失等带来各种各样的问题，决定发的人要为此负责。
