很多系統分析師喜歡用技術的眼光來看客戶的需求。當客戶提出他們的看法之後，系統分析師便把客戶的語言直接「轉變」（Transform）成技術語言，然後在心中建構出軟體的藍圖；然而，當我們依此藍圖實作出資訊系統，交付給客戶之後，客戶卻告訴我們說：「是的，你所開發的系統看起來很酷；但它卻不是我所需要的」。
這就是導出客戶需求常發生的障礙之一，也就是所謂的「是的，但是～」症候群。但這種症候群的問題是出在那裡呢？其實是因為我們沒有花了解客戶在業務上真正所面臨的問題。當客戶告訴我們他所需要的功能時，其實是以為這些功能可以解決他們的問題，但這種假定可能是錯誤的，這也就是系統分析師必須要做的工作，了解客戶業務上面臨的問題，找出他們真正需要的是什麼，然後才提出資訊解決方案；如果我們只是照著客戶提出的功能來開發資訊系統，而沒有進一步地了解客戶需要解決的問題是什麼？他為什麼需要這些功能？當系統開發完成後，客戶會發現他的問題並沒有被解決，也就是認定我們所開發的資訊系統沒有符合他的需要。
系統分析師不要期待客戶告訴我們系統該做什麼；系統該做什麼應該是在充分了解客戶要解決的問題之後，透過我們專業知識來分析並規劃出來的成果。了解客戶要解決的問題並不需要技術能力，而是需要溝通及分析能力。技術人員最容易犯的迷思在於用技術來主導需求分析，可是那往往是災難的開始，因為這樣做我們抓不到問題的本質，我們的命題錯誤，用再好的技術也是罔然，一開始就走錯了，怎麼可能期待成功的到達目的地？
因此，需求分析絕對不是要客戶告訴我們他需什麼功能，然後系統分析人員把這些功能轉變成設計及程式碼。一個專業的系統分析人員，必須先了解客戶想要什麼東西（want），他關注的焦點是什麼（care what），再找出相關的原則及原理（what & why?），及形成的概念（know what）及理解原理（know why）。所以在需求導出時，不要只顧把客戶說的變成技術上的設計，記得問客戶「這個功能可以解決那些業務上的問題？」、「為什麼您覺得會有這個問題？」及「這個問題對公司有什麼影響？」這些問題。客戶對這些問題回饋才能讓我們思考並理解什麼是正確的事，系統設計及開發人員才能根據需求用正確的技術及方法掌握流程（know how）落實把事情做對，所以千萬別用技術來主需求分析。
我將此文章轉貼在EMBA的班網，有同學回應：
同學描述的情景很真確，寫了近二十年的程式，個人也經歷過那種求爽的階段，所追求的是一種創造的成就感；然而，記得在十幾年前，我所任職公司的總經理曾對我說，沒有永遠的程式設計師，最好要多花點時間在領域知識上充實。我當時雖認為這是金科玉律，但真正深切悟到箇中道理卻是最近幾年的感觸所得，關鍵就在於是否做到「不以技術來主導使用者的需求」。
如果我們沒有先了解客戶希望解決的問題，自然會存在需求範疇的風險，就會很容易發生需求變動的問題。解決之道必須改變系統分析的根本思維，從思考利害關係人的問題找出問題的基本概念與原理，再找出解決方案與驗證可行的方法，這樣便可有效地導出客戶真正的需求。
當然，陳正綱教授曾告誡的科技人員之基本心態也很重要，也就是：謙虛，多讀書，多幫助別人。謙虛會讓我們更能夠聽進使用者真正要表達的是什麼，這是需求分析所需要的行為（身）；多讀書讓我們了領更多跨領域的知識，這正是需求分析所需要的知識（心）；多幫助別人就會讓我們培養出為人服務的態度，這是系統分析所需要的心態（靈）。
自動引用通知: 同人的生活派對 » 軟體設計須面對現實
嗨！喲哪桑學長，
沒想到在我的網誌竟然也可以碰到學長，真是難得呀，有點令人又驚又喜。
在台科大上課的日子，第一個碰到的老師正是陳老師，第一堂課就讓我印象深刻，他說技術人不太容易成功，而在一個組織中比較容易成功的人有兩大類型，一種是搞行銷企劃；另一種則是搞財務的。所以技術人不要只活在自己的象牙塔中，而要多學習人家的優點，要懂得謙虛及尊重。到台科大進修，既然 on the right track，那應該多朝軟性技能多充實。
科技創新管理正是一種 social technology 觀點，除了技術之外，人際觀點更為重要。說不定我和喲哪桑學長見過面，只是互相不知道對方是誰。
自動引用通知: 同人的生活派對 » 軟體開發的沒問題症候群
我是06年1月畢業，但是2005/08/30上完李國光老師的策略知識管理之後，我就沒有修課專心跟著黃世禎老師寫論文，我猜，我們見過的機率不大…
屈指一算，你應該也正在拚論文吧！加油！
自動引用通知: 同人的生活派對 » 委外與流程整合
自動引用通知: 同人的生活派對 » 軟體開發是工藝還是工程？
自動引用通知: 同人的生活派對 » 溝通的關鍵時刻