2012年1月31日 星期二

需求?!需要先分析還是直接硬幹

從事IT業這麼多年

有一半以上的時間都是在開發中的日子度過

其中開發的熱情當然是自己對於這個工作能做這麼長的其中一個原因

剛入行時對於 PG=>SD=>SA=>PM  這個歷程似乎覺得是理所當的路程

不過似乎又不是這麼一事*註

最近這份工作個人掛的頭銜是系統分析,做的事情卻是當初剛入行時所做的UI Coding

按照了一份美編的版面設計,一份Protocal(server端會傳什麼格式資料過來,client該傳什麼格式資料過去)

然後按圖索冀,開始寫吧

似乎別的案子都是這麼做的,每一款都是也還能正常上線,營運賺錢

這樣的流程也沒什麼不對的地方,總之能賺錢最重要,是吧~~

在前一陣子,接觸到了一個詢問,開了頭就問”你會不會做什麼什麼網站?報價是多少?”

個人按第一時間所聽到的感覺是要做沒什麼不能做的 ?!

問題是這個網站的需求內容到底是多少內容或多大的規格?

接著對方給了我一張圖(心裡早有底,因為對方也不過只是會美工的工作室)

若是按現階在工作上的流程,不就是如此,有一張圖按圖索冀,理當可以按這個圖去做出系統分析的事情

早在先前的公司,我給使用者一個這樣的保證”資料需求交給我,包您馬上得結果”順口溜(我)

對於需求,今天早上浮現了,需求應該會分成三種

  1. 客戶的需求
  2. 透過問題所產生的需求
  3. 自發性創造的需求

這三種需求是否都要透過分析才可以包您馬上得結果?!

硬幹就沒法馬上得結果嗎?

其實多數系統也是透過不斷的堆疊功能才成就一個系統的

(又讓我想到若是不斷的產生的只有分析,卻缺少了功能的實現,是如何成為系統 ?!)

上述的三個需求發生點,似乎變成了如何把需求變成營利的前期練功步驟

(是的對於那個評估的邀約,必然是對方無法接受我不想硬幹的說法,我還說明從PM到PG的流程)

 

*註 a.用了一個非該技術專業(.Net)的人來領隊不同技術專業(JAVA)的團隊

          (是低現在公司也有這樣的事,事實證明這樣想法是一個很大的錯誤,二個採這個想法專案,最終都是讓專案不斷的延誤)

     b.在之前工作的經歷中有主管找SA是她不在乎有沒有技術背景

     c.另一個工作PM也是沒有寫過任何一行CODE