降落傘的真實故事
——品質沒有折扣
,
多站在客戶的觀點想想
不知道那位大師曾經說過這樣的話「品質沒有折扣」,品質就是按照客戶的要求執行!
這是一個發生在第二次世界大戰中期,美國空軍和降落傘製造商之間的真實故事。在當時,降落傘的安全度不夠完美,即便通過廠商努力的改善,使得降落傘製造商生產的降落傘的良品率已經達到了
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
米
深」。
有的時候,只要咱們轉變觀念,很麻煩的事情就會變得很簡單。一個優秀的項目經理就是不要等到客戶讓你本身使用本身的產品的時候才發現本身的產品的確很次,須要改進。主動思考、主動改進、精益求精,纔是一個優秀的項目經理應該具有的品質。