jim yeh on 四月 19th, 2006

很多系統分析師喜歡用技術的眼光來看客戶的需求。當客戶提出他們的看法之後,系統分析師便把客戶的語言直接「轉變」(Transform)成技術語言,然後在心中建構出軟體的藍圖;然而,當我們依此藍圖實作出資訊系統,交付給客戶之後,客戶卻告訴我們說:「是的,你所開發的系統看起來很酷;但它卻不是我所需要的」。

這就是導出客戶需求常發生的障礙之一,也就是所謂的「是的,但是~」症候群。但這種症候群的問題是出在那裡呢?其實是因為我們沒有花了解客戶在業務上真正所面臨的問題。當客戶告訴我們他所需要的功能時,其實是以為這些功能可以解決他們的問題,但這種假定可能是錯誤的,這也就是系統分析師必須要做的工作,了解客戶業務上面臨的問題,找出他們真正需要的是什麼,然後才提出資訊解決方案;如果我們只是照著客戶提出的功能來開發資訊系統,而沒有進一步地了解客戶需要解決的問題是什麼?他為什麼需要這些功能?當系統開發完成後,客戶會發現他的問題並沒有被解決,也就是認定我們所開發的資訊系統沒有符合他的需要。

系統分析師不要期待客戶告訴我們系統該做什麼;系統該做什麼應該是在充分了解客戶要解決的問題之後,透過我們專業知識來分析並規劃出來的成果。了解客戶要解決的問題並不需要技術能力,而是需要溝通及分析能力。技術人員最容易犯的迷思在於用技術來主導需求分析,可是那往往是災難的開始,因為這樣做我們抓不到問題的本質,我們的命題錯誤,用再好的技術也是罔然,一開始就走錯了,怎麼可能期待成功的到達目的地?

因此,需求分析絕對不是要客戶告訴我們他需什麼功能,然後系統分析人員把這些功能轉變成設計及程式碼。一個專業的系統分析人員,必須先了解客戶想要什麼東西(want),他關注的焦點是什麼(care what),再找出相關的原則及原理(what & why?),及形成的概念(know what)及理解原理(know why)。所以在需求導出時,不要只顧把客戶說的變成技術上的設計,記得問客戶「這個功能可以解決那些業務上的問題?」、「為什麼您覺得會有這個問題?」及「這個問題對公司有什麼影響?」這些問題。客戶對這些問題回饋才能讓我們思考並理解什麼是正確的事,系統設計及開發人員才能根據需求用正確的技術及方法掌握流程(know how)落實把事情做對,所以千萬別用技術來主需求分析



     

8 Responses to “不要用技術來主導需求分析”

  1. jim yeh 說道:

    我將此文章轉貼在EMBA的班網,有同學回應:

    通常it人員不求名,不求利,只求爽!

    公司的設備用最好的,程式寫的很COOL,但也花很多時間。user也不鳥你,因為,做的並非他們想的,原因也可以說是需求不明確,但通常也是系統分析師要特別注意的問題。需求要弄的很完整,實務上不是太容易,這都要考驗sa的功力,我想,要靠許多實務的經驗和理論配合,才能達成,也可以請各位有經驗的同學多多提供寶貴的想法。

    同學描述的情景很真確,寫了近二十年的程式,個人也經歷過那種求爽的階段,所追求的是一種創造的成就感;然而,記得在十幾年前,我所任職公司的總經理曾對我說,沒有永遠的程式設計師,最好要多花點時間在領域知識上充實。我當時雖認為這是金科玉律,但真正深切悟到箇中道理卻是最近幾年的感觸所得,關鍵就在於是否做到「不以技術來主導使用者的需求」。

    如果我們沒有先了解客戶希望解決的問題,自然會存在需求範疇的風險,就會很容易發生需求變動的問題。解決之道必須改變系統分析的根本思維,從思考利害關係人的問題找出問題的基本概念與原理,再找出解決方案與驗證可行的方法,這樣便可有效地導出客戶真正的需求。

    當然,陳正綱教授曾告誡的科技人員之基本心態也很重要,也就是:謙虛,多讀書,多幫助別人。謙虛會讓我們更能夠聽進使用者真正要表達的是什麼,這是需求分析所需要的行為(身);多讀書讓我們了領更多跨領域的知識,這正是需求分析所需要的知識(心);多幫助別人就會讓我們培養出為人服務的態度,這是系統分析所需要的心態(靈)。

  2. [...] 如此設計就可以變得更單純些,等到我們需要區分出不同的客戶的共通行為再運用角色塑模(Dealing with Roles)來增加設計的彈性,這就是用面對問題的方式來設計,而不是以技術實作的觀點來設計,因為後者常常會讓我們離遠使用者需求。 [...]

  3. jim yeh 說道:

    嗨!喲哪桑學長,

    沒想到在我的網誌竟然也可以碰到學長,真是難得呀,有點令人又驚又喜。

    在台科大上課的日子,第一個碰到的老師正是陳老師,第一堂課就讓我印象深刻,他說技術人不太容易成功,而在一個組織中比較容易成功的人有兩大類型,一種是搞行銷企劃;另一種則是搞財務的。所以技術人不要只活在自己的象牙塔中,而要多學習人家的優點,要懂得謙虛尊重。到台科大進修,既然 on the right track,那應該多朝軟性技能多充實。

    科技創新管理正是一種 social technology 觀點,除了技術之外,人際觀點更為重要。說不定我和喲哪桑學長見過面,只是互相不知道對方是誰。

  4. [...] 這件事情其實透露著我們對問題管理的態度問題-我們是不是該針對問題來規劃與控制,很多程式設計師喜歡想到那裡寫到那裡,然而當問題規模的複雜度已演變到您所無法掌握時,這種變化無常的做法會為軟體開發過程中帶來許多的意外,所以我們必須要針對我們想解決的問題來計劃,並且依照問題演變來控制使事情的結果趨進我們的預期。如果我們找不到問題,卻有解決方案產生,很有可能我們正在以技術來主導需求,然而沒有找到正確的問題,做的事情只是徒然浪費時間罷了,這跟溺水的人胡亂掙扎卻愈弄愈糟的情況有何兩樣呢? [...]

  5. Jonathan 說道:

    我是06年1月畢業,但是2005/08/30上完李國光老師的策略知識管理之後,我就沒有修課專心跟著黃世禎老師寫論文,我猜,我們見過的機率不大…

    屈指一算,你應該也正在拚論文吧!加油!

  6. [...] 以資訊產業發展現況來看,由於經濟情勢的改變,資訊支出軟為保守,企業對資訊的投資趨於精準化,轉向競爭力的思考,大型資訊基礎建置不容易看見[4]。所以,站在「專門包別人的人」的立場來看資訊委外服務,委外資訊服務的策略定位應放在整合既有系統而非建置全新的資訊系統。對於系統分析與設計人員而言,其難度與複雜度更甚於過去。所以,他們更須具備有問題的分析能力,誠如我之前曾說過的: 當客戶告訴我們他所需要的功能時,其實是以為這些功能可以解決他們的問題,但這種假定可能是錯誤的,這也就是系統分析師必須要做的工作,了解客戶業務上面臨的問題,找出他們真正需要的是什麼,然後才提出資訊解決方案;如果我們只是照著客戶提出的功能來開發資訊系統,而沒有進一步地了解客戶需要解決的問題是什麼?他為什麼需要這些功能?當系統開發完成後,客戶會發現他的問題並沒有被解決,也就是認定我們所開發的資訊系統沒有符合他的需要。 [...]

  7. [...] 有了這樣的推論,我們可以假設軟體開發是工藝,可是,依同人實務上的觀察,問題好像沒有那麼簡單,尤其是要「把客戶想要的軟體做出來」,說起來簡單,做起來卻很困難。雖然減少了開發者之間了的溝通界面,但這樣一來,開發者就必須直接和客戶溝通來導出客戶需求。開發者往往會發現,導出客戶需求有三大障礙[1]:客戶常常不知道他們真正需要的是什麼、永遠會有需求被遺漏、開發者與客戶之間的不同語言而導致溝通不良。而工藝技術在這方面卻使不上一點力,卻常常會有反效果。溝通在軟體專案的開發過程中,永遠是最重要的呀。沒有足夠溝通,軟體開發很容易造成不知所託或所知非託的現象,而結論都是一樣-導致專案失敗。 [...]

  8. [...] 因為增加或修改系統功能這件事本身並不是客戶真正的目的,而只是客戶以為可以達到目的的策略。開發者應該要去探詢這個策略其背後的真正的需要,才能發展出可以解決客戶問題的需求,而 CRIB 法正可以協助開發者與客戶達成在對需求認知上的共識。 [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">