※ 引述《oicejki (那裡有彩虹告訴我)》之銘言：
: 標題: [請益] 應如何和使用者做需求確認
: 時間: Mon Sep 5 19:45:51 2011
:
: 我們公司的編制,是需求訪談,CODING與相關文件,都是一手包辦.沒有分
: 什麼SA或SD.而我們最近開發系統時,遇到一些問題,想來問問大家的看法.
:
: 因為最近接到的專案,從頭做到尾大約要半年的時間,一開始當時是去找
: 使用者做需求訪談,大約先看了他們給的文件,然後我們出了需求確認書
: 給他們,先把大方向確定後就開始設計DB schema,再來是撰寫程式.
:
: 這裡想請問一下各位,在需求訪談時,會把所有的東西都確認完畢嗎??
: 因為系統中可能有報表,郵件等零星的小東西,我是想說把大架構確
: 定完後再來想這些東西應如何制作.但這樣需求確認書就不會出現
: 這些東西,這些小需求有沒有可能因為一開始交待不清而成為日後的包袱.
:
: 而最近剛好有朋友被上司罵,因為他上司覺得他已經談好需求了,
: 怎麼後來還要去改,好像罵的還挺凶的,於是我就想自己也沒有將
: 所有的需求都確認就開始開發程式,但背後的難題是需求確認書
: 給了一個月了,需求單位也沒有給回覆.如果統統都確認好才開始開發
: ,時程應該也不太允許.而一些小需求,都是要撰寫時才會去問使用者
: 應如何運作,一開始也不太想對太細節的東西先定下來,因此想問問各位的看法,謝謝!
:
: --
: ※ 發信站: 批踢踢實業坊(ptt.cc)
: ◆ From: 111.248.68.166
: → summerme:四個月後再來問你才能學到更多... 09/05 20:24
: → howardwch:只能看環境允許你做到甚麼程度，別忘了公司的目的是賺錢 09/05 20:24
: → howardwch:還有重點是誰能定下規則並扛下責任 09/05 20:25
: 推 atpx:要小心還沒談的模糊地帶以後變成包袱 09/05 21:12
: 推 OriginStar:我覺得可以分成幾個phase來處理，這不僅比較好確認需求 09/05 21:36
: → OriginStar:也比較好專注真正要處理的事上。而且應該要分清楚到底 09/05 21:36
: → OriginStar:這個需求背後是誰提出的，像我做不少案子後發現許多需 09/05 21:36
: → OriginStar:求做了是白做，許多需求不做也不影響結案。 09/05 21:37
: → OriginStar:而且客戶也有專案時程的壓力，你有壓力，客戶比你更 09/05 21:37
: → OriginStar:有壓力，知道意思了吧~~ 09/05 21:37
: → oicejki:我的方式也同樓上說的,分為幾個階段來開發 我只是在想真的 09/05 21:46
: → oicejki:要一開始統統都談好 真的需要很強的功力拉 09/05 21:48
: → zekewang:給個建議.如果經驗夠~在談需求的時候~邊談就要邊想怎麼做 09/05 23:54
: → zekewang:簡單的架構~用什麼方式存資料~資料的格式等 09/05 23:55
: → zekewang:如果心裡有個確切的方法~比較好抓時間~ 09/05 23:56
: → zekewang:不然等談完再回來想如何做~架構怎麼寫.用什麼技術作等等 09/05 23:57
: → zekewang:一定會搞死你~最後就應該會像你朋友一樣 09/05 23:58
: → andymai:樓上說的沒錯~但原PO看起來像是首次接觸?那也只好硬著頭皮 09/06 00:27
: → andymai:洗了~沒經驗是比較累~雖然...有經驗可能也要隨客戶擺佈XD 09/06 00:30
: → zekewang:沒經驗的話~~那就真的阿彌托佛了, 我也不知道怎麼辦.加油 09/06 00:41
: → repuslin:需求訪談,CODING與相關文件,都一手包辦,是台灣惡習 09/06 02:26
: → repuslin:請問你薪水多少? 上面的亂搞一通才是問題的成因 09/06 02:27
: → repuslin:案子的成敗是主管要負責,不是下面做事的人要負責 09/06 02:27
: → repuslin:請你主管自己去面對客戶 XD 09/06 02:28
: 推 repuslin:希望你不要只相信你主管講的話,應該自己想想怎樣才是對的 09/06 02:37
: → repuslin:如果讓你當主管,你會選擇如何去帶領團隊完成軟體開發 09/06 02:38
: → repuslin:在軟體工程上偷工減兩,還想要有好的品質輸出? XD 09/06 02:44
我還蠻同意zekewang的看法
邊談需求邊想想實作會比較好
不要想這是SD與PG階段要煩惱的事情
至於在SA階段就把後面的事情都想好...這難度很高
坦白講...我是辦不到啦
但你不做的話...你會更慘
談一些做不到的需求...肯定被罵
另外就客戶的角度來看...
他不會想管你實作怎麼樣
他想要的東西...尤其是你已經答應要做給他的東西...
他可以就像小孩一樣說"我不管我不管 我就是要那個"
訂出爛規格的SA就倒楣啦
客戶可以隨時想要增加新的需求
我是常遇到一開始就有送一些變更需求的空間給客戶的=.=+
也就是一些需求變更是免費贈送的
但是呢...SA想變更需求就不行了
這會讓人質疑你的專業...
你是怎麼搞的
為什麼一開始沒規劃好
像原PO的朋友被上司罵(偷偷問一下...你是不是就是你朋友=.=+)
從某個角度是合理的...
因為這種事情多了...
對之後的合作沒好處
但是考量到能力的問題
要求一個還在學走路的人
跑到可以跑百米花不到10秒(高標準)
這就強人所難了
(以下有點類似報怨XD)
不過我覺得...在台灣這很常見
又要馬兒好 又要馬兒不吃草
用買很便宜的車子的價錢買車子
然後要求車子能夠跑得像跑車一樣快
這當然不太可能
結果就會變成
1.找不到人(好人才真難找)
2.做得不太好(現在的XX生能力真差)
3.做一做就跑
(能力不夠好就是爛草莓 抗壓性太差
要是能力好 就是資訊業流動率太高)
反正 都有理由啦
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.42.226.21