降落傘的真實故事

降落傘的真實故事
　　——品質沒有折扣,多站在客戶的觀點想一想

不知道那位大師曾經說過這樣的話“品質沒有折扣”，品質就是按照客戶的要求執行！

這是一個發生在第二次世界大戰中期，美國空軍和降落傘製造商之間的真實故事。在當時，降落傘的安全度不夠完美，即使經過廠商努力的改善，使得降落傘製造商生產的降落傘的良品率已經達到了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米深”。

有的時候，只要我們轉變觀念，很麻煩的事情就會變得很簡單。一個優秀的項目經理就是不要等到客戶讓你自己使用自己的產品的時候才發現自己的產品的確很次，需要改進。主動思考、主動改進、精益求精，纔是一個優秀的項目經理應該具備的品質。