發(fā)一個功能強大的客戶數據清理工具，通過工具可以自動識別出這些混亂的數據，并且提供一些合并、匯總、刪除功能”。
隨著這個功能的開發(fā)，項目的范圍也不斷擴展，針對這個功能的需求也層出不窮。這就是軟件開發(fā)過程中的“充電站”，成本付出了，但真的對項目有好處嗎？
這樣做合適嗎？似乎很多人會舉手贊成，但是也付出了巨大的成本。如果我們細究一下，這個問題是怎么產生的呢？為什么數據會混亂呢？實際上根源問題是在用戶輸入數據時，系統(tǒng)對數據的校驗不足，因此更科學的方法是加強輸入時的數據校驗，而不是開發(fā)一個大“充電站”來事后補救。
隱喻：
在萬般無奈下，有人提出了一個蹩腳的主意：在出口立一個大牌，上面寫上“如果是白天，并且車燈開著，請熄滅車燈；如果天色已晚，并且車燈沒開，請打開車燈；如果是白天，并且車燈沒打，就別打開它；如果天色已晚，并且車燈開著，請別關掉它”。
這樣能夠解決問題嗎？顯然不能呀，在汽車行駛過程中誰能夠閱讀完這么長的一段話呢？
有些時候，軟件開發(fā)人員也會采用類似的提示語，例如安裝過程中的向導就是這樣的例子：明知道大家都是閉著眼睛點擊“下一步”按鈕的，那么為什么還要不斷地重復這樣的設計呢？這難道不就是這個蹩腳的標牌嗎？
那么怎樣才能夠解決這個問題呢？關鍵在于對問題的定義，先確定這里到底存在什么樣的問題？如果從這個角度來看，不難發(fā)現：
圖4尋找問題的本源
表現出來的問題是車沒電了，而為什么沒電了呢？因為司機忘了關大燈。為什么會忘了關大燈呢？往往是沒有人提醒他而造成了疏忽。通過這樣的分析，我們就知道需要的解決方案是“提醒機制”，這時就不難得出有效的解決方案：
隱喻：
最后終于有一個清醒的人提出了一個有效的解決方案，那就是在出口出立一個標牌，上面寫上“你的燈亮著嗎？”。
我想這時讓你給出類似的解決方案也并非難事，為什么前面會繞了一圈呢？關鍵就是沒有正確地認識到什么是問題？這個案例詮釋了“對問題進行了正確的定義，意味著成功解決了一半”的內涵。