;
圖3 路線指引牌示例
我對此深有感觸，回來之后與一位做嘉年華游樂場的朋友談起這個事情?？梢运幕貞?yīng)卻是：“吃飽了沒事干呀，有必要管到這么細(xì)嗎？”
……
我接下來告訴他：“我當(dāng)時用手表掐了一下時間，每換一船人花掉的時間是2分50秒以內(nèi)，我們現(xiàn)在到你那掐一下”。
當(dāng)我們用秒表掐了一下時間，就發(fā)現(xiàn)在他這里，每換一船人花掉的時間都在5分鐘上下。
我就趁熱打鐵地說到：“你看看，你這一天要少賺多少錢呢？”這時這位朋友說：“我馬上去做一些這樣的牌子……”。
為什么這位朋友前后判若兩人呢？因為前面的溝通聽起來是“管理的成本”，后面的溝通則提到了“經(jīng)營的效益”。信息系統(tǒng)很多時間都給人一種“管理成本”的印象，因此如果能夠多從“經(jīng)營效益”的角度來溝通，一定會達(dá)到更好的效果，這也是高層管理層真正有興趣的角度。
抓住問題的本質(zhì)
問題經(jīng)常會被表象所掩蓋，如果不能在問題定義時揭開這個表象，那么經(jīng)常會給解決方案帶來問題。而對此類技巧闡釋得最完美的當(dāng)屬溫伯格先生的大作《你的燈亮著嗎？—發(fā)現(xiàn)問題的真正所在》，在這本書中收錄了十余個很有意思的故事，而書名正是其中最有代表性的一個。
下面我們就簡要地回顧一下這個故事，看看它背后的哲理對日常的軟件開發(fā)工作有什么樣的啟示：
隱喻：
話日內(nèi)瓦湖上的山脈中建成了一條很長的汽車隧道，為了防止停電時發(fā)生災(zāi)難，必須提醒司機(jī)進(jìn)入隧道之前把車燈打開。針對這個問題，大家提出了解決方案：“警告！前有隧道請打開車頭燈” 。
但不久之后，路政部門接到了一些反饋與投訴：隧道出口風(fēng)景很美，返回時發(fā)現(xiàn)汽車沒電，原來是忘了關(guān)車頭燈??！
這個問題看起來并不難解決，有人馬上提出了一個解決方案：在出口處立一個標(biāo)牌，寫上“關(guān)掉車燈”。
這樣問題解決了嗎？當(dāng)然沒有！如果夜行車經(jīng)過這個隧道時，看到寫著這個“關(guān)掉車燈”的標(biāo)題應(yīng)該作何處理？難道真的關(guān)掉車燈，那是多么危險的行為呀！在軟件開發(fā)過程中，經(jīng)常也會出現(xiàn)類似的“慣性思維”，看上去解決了問題，實際上將會產(chǎn)生更麻煩的問題。
案例&場景：
小林在一次電子政務(wù)項目中遇到了這樣一個問題，用戶要求對每個政務(wù)申請的各種處理都需要記錄時間。由于他們選擇的是C/S結(jié)構(gòu)，因此取時間時就遇到問題，每臺機(jī)器上的時間都不盡相同。
“不就是時間不統(tǒng)一嗎，讓所有客戶端登錄時先從時間服務(wù)器上取一個時間就搞定了！”。
但這個方案在實際的運(yùn)行時卻帶來了不小的麻煩，由于時間服務(wù)器寫得不夠穩(wěn)定，經(jīng)常會自動退出，當(dāng)這種情況出現(xiàn)時客戶端軟件就根本無法進(jìn)入，嚴(yán)重影響了客戶的正常使用。
其實解決這個問題的方法有很多，例如在數(shù)據(jù)庫存儲時來處理，即取數(shù)據(jù)庫服務(wù)器的當(dāng)前時間。而且即使采用這種方法，也不應(yīng)該在時間服務(wù)器同步失敗時阻止用戶登錄系統(tǒng)。
隱喻：
既然“關(guān)掉車燈”的解決方案是不可行的，那么就換個思路吧：前面的思路是事前預(yù)防，那就改成事后補(bǔ)救吧。因此就有人提出一個新的解決方案，那就是建設(shè)一個充電站。
但是建充電站也有問題，不僅維護(hù)開支很大，而且本身也會出故障。要解決這個矛盾，又有人提出是否將充電站交給私人經(jīng)營，但這又不符合當(dāng)?shù)氐姆ㄒ?guī)。
“用一個成本很大的解決方案去彌補(bǔ)自己的錯誤”是很常見的問題，原本不是什么大問題，卻花費(fèi)了巨大的成本。這種現(xiàn)象在軟件開發(fā)過程中也不少見：
案例&場景：
在小陳負(fù)責(zé)的一個客戶關(guān)系管理系統(tǒng)項目中，用戶在使用了一段時間之后提出了這樣一個問題：客戶數(shù)據(jù)庫的數(shù)據(jù)比較亂，有重名、同客戶多條記錄等現(xiàn)象。
小陳毫不猶豫地說：“沒關(guān)系，我可以為你們開