作者fowei (小維)
看板Soft_Job
標題Re: [請益] 應如何和使用者做需求確認
時間Tue Sep 6 07:53:17 2011
※ 引述《oicejki (那裡有彩虹告訴我)》之銘言:
== 引言恕刪 ==
拿我做過2個案子來做例子好了.
第1個案子是由一開始跟著經理去談需求. 學著自己開SPEC, 最後帶新人CODING.
案子枱面上驗收後. 我花了三個月去做修改. 但很多是礙於一開始架構的問題.
無法再動. 雙方也不願再支出成本. 這案子的成品只有一半是有用的.
其他一半只是負擔.
在這案子中我學到幾個重點.
1. 跟你確認需求的人, 是否是"關鍵人物".
他是否懂這塊領域. 還是他只是身為高階主管?
訪談的人確認, 下面的人就要照著做嗎?
還是需要"使用者"認同 才算驗收?
如果主管不能做主. 那一定要跟"使用者"做確認.
2. 是否有提供"畫面樣本"及"流程"做確認.
3. 雙方對這確認書 是否都有簽字. 以此為準?
=========== 過渡分格線 ===================
第2個案子. 全部由我自己主導. 一開始跟著經驗去 KICK-OFF後. 就開始了.
在了解整體架構後. 自己由頭到尾構思好. 並基本串接OK後.
其實主架構就出來了. 這時其實可以開始開出一些簡單的SPEC...
而接下來的訪談就是都跟各流程的相關"關鍵人員"做確認.
關鍵人員. 可能是主管, 可能是操作人員. 這部份是要確認的.
最後這案子順利驗收. 當然到上線時也有些要修正的.
但因為有過經驗. 設計上有彈性. 怎麼變也都可以處理.
========== 結論分格線 ======================
其實你目前做的是最容易成長的工作. 因為統包.
但也是最累. 最幹的工作, 我工作第一年是週一到週日無休. 週一-週五是到晚上11點.
第三年都是準是上下班了... (看開了, 做好自己的事)
基本上在台灣的案子. 需求確認了. 還是會變. 這只能參考.
最大的用途在於最後在驗收吵架時. 它是一個依據.
而基本上. 案子的成功與否. 在一開始的需求訪談.
有經驗的. 再加上設計. 可以減少後面很多問題.
但如果一開始設計不良. 不管後面做再多. 也很難補回來.
更甚至一個案子. 一開始跟你需求確認的離職了.
後來驗收換人. 就真的是.........
ANYWAY..
有關需求要確認到什麼地方. 才能開始設計. 才能保證不會改. 我想要看經驗.
有時在設計時才會發現串不起來的地方. 有時客戶都保證了. 還是有"萬一"出現.
這時. 客戶的"沒想到". 有時不處理. 帳會對不起來. 你又不能加錢.
SO... 就做. 能確認就確認. 有問題就主動釐清.. 積極去追客戶..
有時東西丟過去了. 就打電話過去. 然後問何時可以回覆. 記下日期.
然後時間到再追. 若客戶在拖. 要知會對方主管. 知會自己主管.
不要把責任留在自己身上. 因為這樣才不會問題來了. 都是你在背.
不管怎樣. 如果今天你都覺得怪怪的. 那做出來的 怎麼會不奇怪?
多主動去確認. 多主動去要求. 客戶被動你就要主動. 懂得去處理.
至於如果使不上力. 我想被操個1-2年. 你自然有實力去到另一家好公司.
說真的. 我覺得有實力. 是不會有"沒工作"這件事的. ...
--
生活的藝術. 大概是只有被創造的人才能體會吧
http://www.wretch.cc/album/fowei
☑電影 ☑單車 ☑遊戲 ☑墮落
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.38.244.47
推 gname:推... 我們走過相同的路,這是寶貴的實戰經驗!! 09/06 10:25
推 ntddt:推實戰~~ 09/06 12:31
推 fsz570:推一個 09/06 22:18
推 hinaeddie:推一個 09/06 23:58
推 pingsky:推~走過相同的路+1 09/07 10:06
推 mervynW:推啊... ... 09/09 16:25
→ TonyQ:其實真實就是這樣啊,大家可以多多分享自己的經驗。:) 09/10 01:14