降落伞的真实故事

降落伞的真实故事
　　――品质没有折扣 , 多站在客户的观点想一想

不知道那位大师曾经说过这样的话“品质没有折扣”，品质就是按照客户的要求执行！

这是一个发生在第二次世界大战中期，美国空军和降落伞制造商之间的真实故事。在当时，降落伞的安全度不够完美，即使经过厂商努力的改善，使得降落伞制造商生产的降落伞的良品率已经达到了 99.9% ，应该说这个良品率即使现在许多企业也很难达到。但是美国空军却对此公司说 No, 他们要求所交降落伞的良品率必须达到 100% 。于是降落伞制造商的总经理便专程去飞行大队商讨此事，看是否能够降低这个水准？因为厂商认为，能够达到这个程度已接近完美了，没有什么必要再改。当然美国空军一口回绝，因为品质没有折扣。

后来，军方要求改变了检查品质的方法。那就是从厂商前一周交货的降落伞中，随机挑出一个，让厂商负责人装备上身后，亲自从飞行中的机身跳下。这个方法实施后，不良率立刻变成零。

在软件设计过程中，一些项目经理满足于能用就行，从不站在用户的角度去考虑是否好用，做出的程序漏洞百出。其实，这不是技能问题，是观念问题！没有以客户为中心的观念，没有为客户设身处地的思想，是设计不出好的软件的。

有一个项目，客户提出要做一个选项，第一天提出的是四个： 1 、附检测报告； 2 、附送货清单； 3 、外箱加固； 4 、可以临时自定义输入（发起人输入）。到了第二天再去确认的时候，客户的要求又变成了六个： 1 、附检测报告； 2 、附送货清单； 3 、外箱加固； 4 、外箱标注产品名称及数量； 5 、外箱标注相应产品件号； 6 、可以临时自定义输入（发起人输入）。

于是项目经理就抱怨，客户总是变化。下面是这个项目经理就这个问题回复的邮件：

各位领导： 

     您好。 

由于销售部近阶段销售发货测试，在这个测试过程中，

产生了一些新的需求，在各销售部门提出需求的时候， 

OA希望销售部改善下提需求的方式，以便加快双方的

处理问题的工作效率。 

     在这个过程中现列举一个相对典型的事例。 

     关于销售发货监控标备注栏的内容问题， 

该问题主要是方便计划员可以少输入几个字。

昨天下午用户明确要求：1、附检测报告；

2、附送货清单；3、外箱加固；

4、可以临时自定义输入（发起人输入）共四项内容，

其中自定义可以任意输入各种方式。 

    但今天上午某某（这里我隐去了具体人员名字

――笔者注）工程师去调研的时候，

又增加第4点和第5点，其实这新增的两点完全可以

在自定义筐中输入。我觉得这种提需求的方式有待

改善（是客户提需求的方式有待改善，

还是我们的观念有待改善？）。 

我想软件目前为止还不能完全智能化，

我们也只能通过合理的方式尽量让使用人员少输入一

些信息，所以希望销售各部门提出需求的时候尽量

的能相互协调，阶段性的确认需求。 

    希望得到各位领导的谅解。 

           OA小组： 某某（这里我隐去了具体人员名字

――笔者注） 

 

也许对于许多人来说，项目经理说的合情合理，如果客户总是没完没了的提要求，项目什么时候才能结束？

可是当你站到客户的角度去看问题的话，情况往往就不一样！客户每一天可能要处理上千笔记录，没有你每笔记录让他多输入 5 各汉字，假设共花费 30 秒钟（他们不是专业的打字人员，这个速度是基本合理的），那么 1000 笔记录就是 100 分钟，折合 1 小时 40 分钟。也就是由于我们程序设计的不合理每天要浪费客户 1 小时 40 分钟。假设这个员工每月的工资 4400 元，则每每小时约 25 元，即每天浪费客户约 40 元，一个月约 800 元，一年就是 9600 元， 10 年就是 96000 元。而且对于客户来说更重要的损失并不在这里，也许就因为这个原因，本来一个人可以完成的工作，现在变成了一个人完成不了，企业需要在这个岗位上再设置一个人，那么每月的损失就是 4400 元了。或者还有可能因为来不及而丢失业务。

本来这是一个很简单的问题，只要我们在数据库上建一个表，将所有的选项放到表里面，然后客户端选项的数量由后台的表决定。那么你还怕客户不断提出新的需求吗？最多给客户一个维护后台表的界面，让客户自己去维护。在一个完整的项目中，出现这样的情况，是屡见不鲜的，做过项目的有几个人没有碰到过这种情况？

对于软件项目，我们确定做的范围一定要窄，但既然决定了要做，就一定要做好！就像我前一篇文章说的那样“要将 1 米 宽的井挖成 100 米 深”。

有的时候，只要我们转变观念，很麻烦的事情就会变得很简单。一个优秀的项目经理就是不要等到客户让你自己使用自己的产品的时候才发现自己的产品的确很次，需要改进。主动思考、主动改进、精益求精，才是一个优秀的项目经理应该具备的品质。