[請益] 應如何和使用者做需求確認

[oicejki (那裡有彩虹告訴我)]

我們公司的編制,是需求訪談,CODING與相關文件,都是一手包辦.沒有分
什麼SA或SD.而我們最近開發系統時,遇到一些問題,想來問問大家的看法.

因為最近接到的專案,從頭做到尾大約要半年的時間,一開始當時是去找
使用者做需求訪談,大約先看了他們給的文件,然後我們出了需求確認書
給他們,先把大方向確定後就開始設計DB schema,再來是撰寫程式.

這裡想請問一下各位,在需求訪談時,會把所有的東西都確認完畢嗎??
因為系統中可能有報表,郵件等零星的小東西,我是想說把大架構確
定完後再來想這些東西應如何制作.但這樣需求確認書就不會出現
這些東西,這些小需求有沒有可能因為一開始交待不清而成為日後的包袱.

而最近剛好有朋友被上司罵,因為他上司覺得他已經談好需求了,
怎麼後來還要去改,好像罵的還挺凶的,於是我就想自己也沒有將
所有的需求都確認就開始開發程式,但背後的難題是需求確認書
給了一個月了,需求單位也沒有給回覆.如果統統都確認好才開始開發
,時程應該也不太允許.而一些小需求,都是要撰寫時才會去問使用者
應如何運作,一開始也不太想對太細節的東西先定下來,因此想問問各位的看法,謝謝!

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 111.248.68.166
→ summerme:四個月後再來問你才能學到更多...
→ howardwch:只能看環境允許你做到甚麼程度，別忘了公司的目的是賺錢
→ howardwch:還有重點是誰能定下規則並扛下責任
推 atpx:要小心還沒談的模糊地帶以後變成包袱
推 OriginStar:我覺得可以分成幾個phase來處理，這不僅比較好確認需求
→ OriginStar:也比較好專注真正要處理的事上。而且應該要分清楚到底
→ OriginStar:這個需求背後是誰提出的，像我做不少案子後發現許多需
→ OriginStar:求做了是白做，許多需求不做也不影響結案。
→ OriginStar:而且客戶也有專案時程的壓力，你有壓力，客戶比你更
→ OriginStar:有壓力，知道意思了吧~~
→ oicejki:我的方式也同樓上說的,分為幾個階段來開發 我只是在想真的
→ oicejki:要一開始統統都談好 真的需要很強的功力拉
→ zekewang:給個建議.如果經驗夠~在談需求的時候~邊談就要邊想怎麼做
→ zekewang:簡單的架構~用什麼方式存資料~資料的格式等
→ zekewang:如果心裡有個確切的方法~比較好抓時間~
→ zekewang:不然等談完再回來想如何做~架構怎麼寫.用什麼技術作等等
→ zekewang:一定會搞死你~最後就應該會像你朋友一樣
→ andymai:樓上說的沒錯~但原PO看起來像是首次接觸?那也只好硬著頭皮
→ andymai:洗了~沒經驗是比較累~雖然...有經驗可能也要隨客戶擺佈XD
→ zekewang:沒經驗的話~~那就真的阿彌托佛了, 我也不知道怎麼辦.加油
→ repuslin:需求訪談,CODING與相關文件,都一手包辦,是台灣惡習
→ repuslin:請問你薪水多少? 上面的亂搞一通才是問題的成因
→ repuslin:案子的成敗是主管要負責,不是下面做事的人要負責
→ repuslin:請你主管自己去面對客戶 XD
推 repuslin:希望你不要只相信你主管講的話,應該自己想想怎樣才是對的
→ repuslin:如果讓你當主管,你會選擇如何去帶領團隊完成軟體開發
→ repuslin:在軟體工程上偷工減兩,還想要有好的品質輸出? XD