问题描述

“我们必须在5.1之前发布”相信任何一个软件项目团队都遇到过客户类似的要求,更郁闷的是在5.1之前客户还很可能提出别的要求。公司老板或者项目经理很可能会对程序员再说一次同样的话。结果是绝大多数都不能在5.1之前发布，或者发布了一个质量极差的版本，客户很生气后果很严重。客户可能会拒绝付款，甚至以后再也不跟你合作了，因为你根本没有提交有用的东西。

对问题的理解

5.1之前必须发布意味着客户希望5.1之前发布高质量的版本，而不是不可用的版本。假如时间是固定的，那么功能应当可以有削减的地方，绝大多数情况下需求都不可能定义的非常详细。可以削减的地方并不是整个功能都不要了，核心功能无论如何是要的。假如我们真的发现连核心功能都完不成，那我们应当尽早告诉客户，让客户尽早找其他的替代方案。最后一刻让客户知道提交不了是极其恐怖的一件事。

假如客户要求的软件是一辆汽车，那么发动机就是最重要的核心功能，底盘、轮胎等就是必须的辅助功能，少了这些汽车就没法运转。

最早的汽车没有音响，没有真皮座椅，没有空调，更没有导航，但这并不能说那些汽车质量就不好。

从本质上满足客户要求

一个成熟的团队应当学会如何“最高”程度上满足客户的要求，满足客户“本质”的要求，而不仅仅是他口头的和表面的要求。

这自然会有很多需要折中的情况，时间总是有限的。我们应该如何做决定呢？我的想法是：需要折中的是功能，假如时间不够我们可以不发布某个功能，但是只要一个功能要发布，就要把它做好。比如分页，如果时间足够我们可以支持让客户定义每页的行数，假如时间不够我们可以把它先写死，这就会节省一些时间，但质量仍然是好的。

如果想要砍掉稍微大一点的功能，必须明确地跟客户沟通，非常明确地告诉客户时间不够了，跟客户一起商量应该砍掉哪些。

质量是没有折中的。这将成为盛安德的文化。假如真的有一部分客户不在乎质量，我们宁愿放弃那些客户。

迭代开发

迭代开发并不是频繁的提交很烂的版本，而是提交很好用的一部分功能。

任何一次提交必须要保证质量，假如不能保证质量就不要提交。因为低质量的提交客户没法用，相当于没有提交，更坏的影响是，客户会以为你们的水平就是这么差。很喜欢奔驰的广告“The best or nothing”。

Peter曾经提到一种开发互联网应用的快速发布模式。迅速开发出核心功能，尽快上线并且得到客户反馈，经过一小部分市场验证成功后再全面铺开。那种快速模式跟高质量的要求并不冲突。假如你迅速发布出的功能很难用，你不可能得到正面的反馈。

现在互联网上每年都有无数个新玩意出来，让人觉得速度很快。不要被这种假象所迷惑。绝大多数新玩意都将成为过眼烟云。真正的好产品是经过深思熟虑的。我们不能相信运气。

一些题外话

最后，假如老板就是给你安排了不可能完成的任务，该怎么办？首先，如果这是常态，你该考虑换工作了。在这样的公司工作不可能有前途。短期内没法换工作，你应当把你的担心提出来，假如老板不同意你可以一笑了之，仍然努力地工作，但是完不成就完不成，老板不能一口把你吃了。实际的失败也许会让老板认识到他的决策是错误的，一般情况下老板都不会太笨，他们应当能从失败中吸取教训，客户不高兴公司的利润就得不到保证。

保持好心态，锻炼好身体，持续不断的学习，无论如何你都该这么做，遇到了不好的公司你更应该这么做，水平提高了不用愁找不到好工作。

另外一些题外话

最后，再次强调：一个公司存在的意义在于服务于客户。一个项目也是如此。所有行为必须都围绕“服务客户”来展开。如果满足不了客户所有的要求，那就尽量满足客户最重要的要求，这是一件很自然的事情。假如我想买一辆车，要很快的速度但是又不能烧太多汽油，汽车厂商满足不了我的要求，我可以退而求其次，速度对我来说是最重要的，能少耗油当然很好，但是我也可以接受速度快但耗油多的车。