傳統的系統分析人員是由資工資管背景養成的,他們對技術很在行,可是對於使用者業務知識多半是沒概念。所以在需求訪談時往往掌握不到要點,要不就是使用者無法適切表達出來,以致於分析人員及使用者的認知往往差距很大,開發出來的系統便不符合實際需要或不好用。

除非需求者也有資訊背景及管理的素養
否則要達到您說的境界也是有點難

市面的套裝軟體一堆,不用開發軟體,也不用提需求
光是拿來用,學習如何用.....就有很多客戶上線失敗,原因是 ???

基於以上問題,於是乎就有 "顧問" 這行業出現.....騙吃騙喝,拿政府預算,弄一些數據嚇人

------
---------------------------------------
偶爾才來 KTOP ,交流條碼問題,在 FB [條碼標籤達人] 社團留言,感恩.

編輯記錄

===================引 用 pedro 文 章===================
傳統的系統分析人員是由資工資管背景養成的,他們對技術很在行,可是對於使用者業務知識多半是沒概念。

------
---------------------------------------
偶爾才來 KTOP ,交流條碼問題,在 FB [條碼標籤達人] 社團留言,感恩.

花錢的出嘴, 拿錢的出力; 巧者拙之奴

------
能力不足，求助於人；有能力時，幫幫別人；如果您滿意答覆，請適時結案！

子曰：問有三種，不懂則問，雖懂有疑則問，雖懂而想知更多則問！

謝謝ANDY8C&pcboy前輩的回應

之所以有這樣的想法,是最近跟朋友聊天
說軟體業的常態是這樣的
某單位外包一專案,規格開的不是很詳細,軟體商根據不詳細的規格搶標成功,
後來跟使用單位幾經反覆式訪談後,才了解具體需求,可是案子的規模已經不是當初接下時的規模,
有兩種作法,一種是先照實做,等後續的案子來賺得攤平,
另一種作法是做出功能不確實的成果來,再以下年度追加預算的方式.

使用者需求不是一次性就能了解的,所以軟體商在不了解下接下不符合成本的案子,在低獲利的空間下勉強生存,
需求不明確,做出來的程式,無法驗收,收不到尾款,就趕緊接下一個案子來彌補開銷,如此惡性循環,讓軟體業無法強大起來,

所以提出一帖假設性的良藥,
如果使用者能開出具體要什麼的規格,
那麼軟體商錯估規模的機會相對減少,
合理的成本和合理的需求,

假設使用者相當明瞭自己的需求,又能確實讓軟體商了解,
那麼是不是能夠減少導入失敗的可能

===================引 用 ANDY8C 文 章===================
除非需求者也有資訊背景及管理的素養
否則要達到您說的境界也是有點難

市面的套裝軟體一堆,不用開發軟體,也不用提需求
光是拿來用,學習如何用.....就有很多客戶上線失敗,原因是 ???

基於以上問題,於是乎就有 "顧問" 這行業出現.....騙吃騙喝,拿政府預算,弄一些數據嚇人

編輯記錄

有這樣的問題要說誰的問題，其實都很難說..
對於一般的使用者，別說是技術規格，光是業務邏輯，很多根本就是自己也搞不清楚，每個人對於業務流程多半只懂自己負責的部份( 不熟的就更不用說了)，而系統商則要在完全不懂此邏輯的狀況下，把所有的零碎的流程拼起來，並以電腦系統的方式來表現。以臺灣的「單位」來說，我想公家私人單位都一樣，除非這個系統已經非常的制度化，甚至資訊化有相當的程度，否則，沒有人能夠或也可以說是不敢去對整個系統提出整體業務架構與規劃。那麼，就使用者來，最不願變更的一件事就是，改變自己既有的行為/行事模式，問題是，既然是系統，既然沒有足夠的制度與資訊化，相對的在流程上、架構上就容易有矛盾或窒礙難行的部份，通常也是系統商頭大的問題其一。

所以，使用單位，除非有人專司其職，否則很難有人可以懂完整的業務架構是其一，沒有人想要對整個系統架構負責是其二。
再者，通常使用單位對於資訊系統的了解較少，有時會一味的去綁住特定的技術規格或架構，造成在整合上也相當的吃力。

而且在這個市場上，當使用單位若能夠徹底的了解系統規格，那麼相對的價格也容易透明，對於系統商來說，要維持一定的利潤，相對的應該也有些許的困難點。

當然最理想的狀況下就如同先前暗黑大說過的，乾脆把一票使用者丟去學電腦，學完之後再來自己寫，
但是現下這樣的狀況，應該是有困難..:P

===================引 用 pedro 文 章===================
謝謝ANDY8C&pcboy前輩的回應

之所以有這樣的想法,是最近跟朋友聊天
說軟體業的常態是這樣的
某單位外包一專案,規格開的不是很詳細,軟體商根據不詳細的規格搶標成功,
後來跟使用單位幾經反覆式訪談後,才了解具體需求,可是案子的規模已經不是當初接下時的規模,
有兩種作法,一種是先照實做,等後續的案子來賺得攤平,
另一種作法是做出功能不確實的成果來,再以下年度追加預算的方式.

使用者需求不是一次性就能了解的,所以軟體商在不了解下接下不符合成本的案子,在低獲利的空間下勉強生存,
需求不明確,做出來的程式,無法驗收,收不到尾款,就趕緊接下一個案子來彌補開銷,如此惡性循環,讓軟體業無法強大起來,

所以提出一帖假設性的良藥,
如果使用者能開出具體要什麼的規格,
那麼軟體商錯估規模的機會相對減少,
合理的成本和合理的需求,

假設使用者相當明瞭自己的需求,又能確實讓軟體商了解,
那麼是不是能夠減少導入失敗的可能

===================引 用 ANDY8C 文 章===================
除非需求者也有資訊背景及管理的素養
否則要達到您說的境界也是有點難

市面的套裝軟體一堆,不用開發軟體,也不用提需求
光是拿來用,學習如何用.....就有很多客戶上線失敗,原因是 ???

基於以上問題,於是乎就有 "顧問" 這行業出現.....騙吃騙喝,拿政府預算,弄一些數據嚇人

------
不論是否我發的文，在能力範圍皆很樂意為大家回答問題。
為了補我的能力不足之處，以及讓答案可以被重複的使用，希望大家能儘量以公開的方式問問題。
在引述到我的文時自然會儘量替各位想辦法，謝謝大家！

外包搞不清需求, 沒能力具體提出規格的很多, 要這種單位開規格, 有些公司就乾脆把貴公司除名

如果原先規格非正式文件, 那就當自己估計錯誤, 花錢學教訓
( 做生意有賺有賠, 估計能力太差 or 禁不起賠, 就要考慮是否合適開公司)

如果對方是有正式的開標規格文件 , 後來訪談和規格和原先不同, 就早點提出追加預算, 或者解約大家一拍兩散

===================引 用 pedro 文 章===================
謝謝ANDY8C&pcboy前輩的回應

之所以有這樣的想法,是最近跟朋友聊天
說軟體業的常態是這樣的
某單位外包一專案,規格開的不是很詳細,軟體商根據不詳細的規格搶標成功,
後來跟使用單位幾經反覆式訪談後,才了解具體需求,可是案子的規模已經不是當初接下時的規模,
有兩種作法,一種是先照實做,等後續的案子來賺得攤平,
另一種作法是做出功能不確實的成果來,再以下年度追加預算的方式.

使用者需求不是一次性就能了解的,所以軟體商在不了解下接下不符合成本的案子,在低獲利的空間下勉強生存,
需求不明確,做出來的程式,無法驗收,收不到尾款,就趕緊接下一個案子來彌補開銷,如此惡性循環,讓軟體業無法強大起來,

所以提出一帖假設性的良藥,
如果使用者能開出具體要什麼的規格,
那麼軟體商錯估規模的機會相對減少,
合理的成本和合理的需求,

假設使用者相當明瞭自己的需求,又能確實讓軟體商了解,
那麼是不是能夠減少導入失敗的可能

------
能力不足，求助於人；有能力時，幫幫別人；如果您滿意答覆，請適時結案！

子曰：問有三種，不懂則問，雖懂有疑則問，雖懂而想知更多則問！

劣幣驅逐良幣! 大招牌壓過技術! 接案越來越難囉!
外包有>80%以上是提不出具體規格的, 300人以下公司, 更是常連規格都無;
接案常須先看報價及招牌大小, 然後才談規格的比比是.
是否要接, 就看自己如何拿捏了!

以自已的經驗分享一下..
1、需求，時常遇到的是主事者(如：主管)與使用者(小職員)的關念上不同，導致軟體一直在改變，有時為了驗收，不得以總要改變軟體的做法。
2、引導的觀念，這時常被User問到(當分析時)，總問我，我該如何做...
(Ps.心裡的OS...到底是你在做事還是我在做你的事...= =||)
但這一部份卻可以從經驗中去引導User，以經驗的分享方式去告知可能的做法，但這要有一些時間的經歷。
3、需求規格書要定義，但分析出來不見得會正確，必竟只有真正在用時，User就會跟你講出晴天霹靂的事...這不是他要的..= =||
(Ps.心裡的另一份OS...馬的那當初分析時為什麼不說清楚...= =||)
4、沒有辦法體會User他們的專業領域，不過這是滿少遇到，我遇過的是如會計，那做帳方式真是令人無法分析不出他的需求。
(Ps.心中想著會計老師...當初在學時沒學好...@@)
5、除了User所提供的規格以外，最好是能拿到他日常用的文件報表格式，這往往會與規格有關，但User卻不經意的忘記...
6、這一點我認為比較重要...要對方簽名以示負責(對於分析的文件)，就算做錯了還是可以驗收，有憑證的啦...
就算User不想驗，只要一些承諾會改好他要的東西，但時間上的驗收不能等，我遇過的User不會太為難。
7、甚至有遇過User希望軟體要如何、如何，那要求是可以做出來，但整個系統變更複雜，相對的User要做的事情更多，
變成User始料未及，以為加更多功能可以做更少事，但事與願為，反而要做更多事..@@
(Ps.功能總要有人維護...不可能是我們去幫他們維護)
由單位來分析真的有點難，有的User總以為他要做的是「腳踏車」但因系統的連動性其實他要做的是「太空梭」，
至少目前輔助的分析(適時的跟User說別做太空梭...@@)可能是必要的。

------
初學、初學、學了很久...還是在初學階段..Orz

編輯記錄

 1.系統分析未必資工背景就一定能做的好, SA 包含的範圍太廣了, 一個資工到底在學校老師教了什麼, 說真的在SA這方面是很有限的。
2.由需求單位提需求是對的, 但不是提規格書, 如果規格書一旦提出來, 那SA上那去了! 所以這個觀念不對, 使用者(或者業主)往往只和你提他要的結果論, 所以的確這樣的論點是錯的, 一般設計一個專案應該是 用戶->SA->PD(Program Designer), 所以很明顯SA在其中扮演了一個很重要的角色, 在一般的設計公司, SA拿的薪資通常是PD的三到四倍, 因為SA必須在與客戶紡談之間, 運用他的經驗模式, 把客戶的結果化成可執行的結構, 並且與用戶要達成至少7-8成協議, 包含資料庫結構, 資料欄位, 長度, 晝面, 用戶希望操作方式, 這都是要SA提出來再向客戶確認的, 當然在我的經歷中, 不乏用戶有這樣的知識, 不過說真的, 少之又少, 最麻煩的是用戶半桶水, 似懂非懂, 這種用戶是最難溝通的, 因此SA也要具備凌人的氣勢, 要展現自的技術與能力絶對是超越用戶, 這樣才能壓過, 否則往後設計案一旦簽下, 苦的就是設計人員了, 因為會一改再改, 所以我比較喜歡的用戶是完全信任我們, 什麼都不懂的, 我只要把結果給他們就滿足的, 或者完全掌控規劃的用戶, 但在簽約時就表明, 如果程式寫出有任何不符用戶的規格是他們的事, 這樣我們可以減少一些責任問題

3.程式設計沒什麼困難, 這句話也有瑕疵, 就好像現在寫網頁被業主認為是那麼沒有價值, 到處充斥劣質的網頁, 造成我們擁有高品質及高技術的設計人員找不到案子可以成交, 這是一種劣幣驅逐良幣的現象, 我們常接到要幫人家擦屁股的爛案子, 往往前一個寫的人可能是在學, 可能是用戶自己的親朋好友, 灌輸了用戶網頁沒有什麼, 對打工而言, 5000, 10000就算很多了, 但之後用戶想擴充或改個東東, 找不到人了, 或者原設計不願意再做, 這種狀況比比恉是, 當我們接手, 看了網頁的規劃內容真是傻了眼, 向用戶提出報價, 他們看到價格簡直難以相信(常常會和你說, 前一個才多少錢, 你報這種價格我們沒辦法接受), 所以寫程式不是沒有價值的, 隨隨便便寫一支程式很簡單, 但要考慮到人性? 考慮到現場作業? 考慮到使用者對電腦的認知? 考慮到親和力? 如果這些都要納入規劃, 這支程式價值可太了, 一支程式用個十年二十年客戶都還在用, 這就是有價值
===================引 用 pedro 文 章===================
傳統的系統分析人員是由資工資管背景養成的,他們對技術很在行,可是對

編輯記錄

支持 PD 版主的論點.
不懂管路、保溫、油漆的工程, 無法寫出好用的檢料、工時計算等的程式.
不懂會計、財務運作, 無法寫出好用的財會系統.
要 User 提出規格書不太切實際, SA 應比 User 更瞭解 User 需求並開出規格書給程式設計人遵循才恰當.

不過, User 使用數十年還再用, 也是堅持品質的軟體業的困擾－高成本、沒維護費!

編輯記錄

感謝認同, 不過長久使用不代表沒有維護費, 一般我都會和客戶提維護的觀念(使用者付費, 服務有價), 在合理的狀況下可以不收, 但在協定之外的就打死不退, 否則到時回頭求我那費用是DOUBLE, 因此我會寫出一支高品質的系統, 但不代表是十全十美, 我就不相信用戶用了之後一輩子不要換電腦, 不要出狀況, 何況十多年的使用, 絶對不會沒有想昇級, 想加功能, 所以只要讓用戶使用的感覺很好, 其實後續不怕沒有交到這個朋友, 也不愁沒有後續的維護收入!
我接過的專案有二十來件, 有醫尞, 布料, 廟宇, 電子業, 製造業, 批發業, 門市系統....雖然不一定每一個案子都有認真的使用到現在, 但現存的用戶也都和我成了朋友, 甚至有一家港商投資的原本大頭家要求撤下我的系統, 換成他們的, 但業主堅持要我的持續上架, 否則就拆夥, 像這樣讓人感到窩心就值得(註:該收的還是要收, 但收便宜一點)
===================引 用 herbert2 文 章===================
支持 PD 版主的論點.
不懂管路、保溫、油漆的工程, 無法寫出好用的檢料、工時計算等的程式.
不懂會計、財務運作, 無法寫出好用的財會系統.
要 User 提出規格書不太切實際, SA 應比 User 更瞭解 User 需求並開出規格書給程式設計人遵循才恰當.

不過, User 使用數十年還再用, 也是堅持品質的軟體業的困擾－高成本、沒維護費!

編輯記錄

個人倒是覺得期望由客戶提規格書，是有點不太可能的期望（沒有任何批評之意，請勿誤會），若可以我會很高興，但是我從來沒遇過，除非是程式碼少於1000行以下的小程式，很多人連自己平日每天作的作業，都無法理出頭緒，你要如何期望他提出規格？舉個例子，我曾經做過一案子，案子有一部份是屬於罰款，使用單位希望系統自動開立罰單，但是負責人連罰單要怎麼開立的規則都說不清楚、前後矛盾，這時要如何處理？這個案子，我最後是做成彈性，除了一些規格清楚的部分，其餘的都要求使用者自行輸入，使用者沒辦法只能接受，誰叫使用者連規則都說不出來

各位可以去各大學，去看資工的課程，除了一些基礎課程，例如作業系統、資料結構等等，剩下低程式設計只是其中的一小部分，反而演算法、軟體工程等相關課程，倒是很多（每所大學各有不同），原因無他單論寫CODE，用一年的時間也就學的差不多了（有的大學每種語言只排一個學期）

個人認為軟體工程師的價值在於，把使用者的期望或願望，轉化成系統分析文件，最後再轉換成程式碼，這本身就是一門大學問了，這也是軟體工程類似的課存在的意義，不然單寫CODE，能寫到幾歲？40歲以後要怎麼拼得過25歲的年輕人.....難不成跟老闆說～～40歲還是一條活龍嗎？

===================引 用 pedro 文 章===================
傳統的系統分析人員是由資工資管背景養成的,他們對技術很在行,可是對於使用者業務知識多半是沒概念。所以在需求訪談時往往掌握不到要點,要不就是使用者無法適切表達出來,以致於分析人員及使用者的認知往往差距很大,開發出來的系統便不符合實際需要或不好用。

支持~論點程式設計是一件難事!!
SA才是簡單的工作~只是他最繁雜需要人與人之間的溝通技巧
與導正USER的能力

其實重點是我遇到的SA怎麼都不幫客戶DEBUG
維護都變成程式設計者!! WHY!!

------
======================
昏睡~
不昏睡~
不由昏睡~

沒錯, 本身SA不涉及CODE DESIGN, 如何叫SA DEBUG? 除非是流程控管問題, CODE還是要設計師來才合理, 不過台灣有多少 SA 與 PROGRAMMER 是分開的, 這個比例大約只佔1成而已, 所以9成的人都是二合一, 甚至是三合一(SA, 設計, SERVICE), 像我的話更是五合一(SALES, SA, DESIGN, SERVICE, ACCOUNTANT)
===================引 用 ko 文 章===================
支持~論點程式設計是一件難事!!
SA才是簡單的工作~只是他最繁雜需要人與人之間的溝通技巧
與導正USER的能力

其實重點是我遇到的SA怎麼都不幫客戶DEBUG
維護都變成程式設計者!! WHY!!

引起這麼大的迴響,想必大家對這個議題的感觸還蠻多的,而且挺值得深入討論
我一直不知道怎麼回應,重覆看了好幾遍前輩們的意見,試著再述說我吸收或想表達的意見,也許不是很適切

至少有兩個共同點
1)要求使用者做需求分析是不切實際的,因為使用者往往也不太能說清楚。但如果往另一個方向來思考,如果使用者對自己的需求不清楚,怎麼能讓系統分析師清楚。舉個細節例子,如果商業會計法或統一發票使用辦法一些概念,收到款項便要入帳開發票,所以收款明細表上收款日等於發票日,報表的撈資料的語法條件就清楚了。
如果要使用者整理一些業務需求進而分析也許是說的過去,畢竟要怎麼讓電腦這樣工具符合日常所需,好不好用的系統,一線的人員最清楚。如果使用者學習一些初步的分析方法技巧,也許就可以利用word陳述一些需求項目。

2)由需求到程式,中間免不了PM、SA、SD、PD、DBA等人員涉入,這樣的職能分工在國內好像不是很清楚,每個角色工作卻也是很重,往往一人身兼數職。

編輯記錄

有限的時間.有限的經費.
絕對是正確的.
http://www.ithome.com.tw/plog/index.php?op=ViewArticle&articleId=5148&blogId=579
這個方法.早就有人提出來寫成書了.

我個人的經驗是,用這種把另一個專業的人"綁"在身邊.
才能順利的把幾個已經在"安寧病房"的專案.順利救回.