[碎碎念] 程式開發領域由菜鳥到老鳥的成長歷程 (16) - 中鳥階段-需求是挖出來的。

當到了中鳥階段,表示已經工作了至少一年以上,對程式開發的工作有了最起碼的經驗,當然大多數都是 Coding 比較多,但是從中鳥階段開始,要接觸的可能就不只是 Coding,其中一項就是和使用者談需求。

如果是在中小企業工作,在一人分飾多角的情況下,很難不和使用者面對面接觸,有些人可能在菜鳥階段就要和使用者直接面對,但通常沒有一些實務經驗的話,公司不太會派菜鳥去和使用者接觸的,一來是因為經驗不足,二來也是怕會對使用者的需求發生誤判,以致於系統設計的方向偏掉或不正確,和使用者確認的時間也會跟著拉長,專案時程也會受到影響。當然,通常談需求這件事都是由業務或企畫出馬的,只是為了確保技術的可行性,在一些需要較高技術面的案子,業務會帶著技術人員一起參與,由技術人員提供專業的意見,以判斷功能需求的可行性。

只是多數使用者其實都不知道自己要的是什麼,只憑一些簡單的記憶,或是去某某網站看看,就把功能劃進專案中,通常是不會想到可行性的,例如畫面上要加什麼欄位啦,哪個功能必須要有某某能力啦,報表一定要有什麼圖 (即便該圖和資料一點關係都沒有) 之類的,這在一些形象或是公司門面 (ex: Portal) 會更明顯,尤其是視覺的設計上。

只是以程式開發的角度而言,虛無漂渺的需求無助於系統的開發,反而有可能會誤導 SA/SD 設計出與需求完全不同的系統,就像這張圖一樣:

(Source: http://roger-deliah.blogspot.com/2008/01/blog-post_18.html)

只是,要使用者自己說出真正的需求,在大多數情況下是幾乎不可能的,所以身為一位需求擷取的人員,除了一些系統分析與設計的教科書上提的方法外,基本上還需要一些技巧,才能由使用者的身上挖出真正的需求,例如:

1. 由使用者描繪流程,並以流程圖來確認。
2. 由使用者提供表格,並和使用者討論欄位,以作為表單設計的依據。
3. 用引導的方式,由使用者提出的需求中萃取出真實的需求。
4. 畫一些草圖,並與使用者討論畫面布局。
5. 提供一些範本或案例,由使用者挑選最接近的,再討論出真實的需要。

在挖需求時,圖說是很重要的,古人云 "一圖勝千言",如果有圖可以輔助的話,使用者看得到畫面也比較容易判斷與確認,而程式師在設計程式時,也有一些流程和布局上的依據。這些經驗都是需要真實的去和使用者接觸,才能夠累積的。所以如果有機會去見客戶談需求時,不要急著推掉,因為它在未來會成為在無形中正確判斷使用者需求所需要的經驗。

More Reference:
http://www.bestwise.com.tw/_trial_files/52mit00604/ch03.pdf