codejob 的員工薪資管理系統 - 網站

關於這個, 我可以提出我所採用的接案流程及原則僅供參考(因為不知道別人

是否有更好的做法?).

1 簽約一定要在訂出規格之前確定. 簽了約先收簽約金. 要不, 乾脆別做.

2 製訂功能規格書:

2.1 功能規格書有兩部份, 文字部份以階層樹的方式表達.

2.2 將功能規格以UI的方式呈現. 用繪圖工具畫圖. 每個功能的每一個操

作步驟就是一頁圖. 通常一個不大不小的系統(以CRUD操作為基礎,

產品管理/客戶管理/交易記錄報表/帳號管理/權限管理/系統設定),

大概要畫60頁左右的圖. 這部份的工作是不難, 因為圖面大致可以

copy-paste後再修要改的部份即可, 只是過程單調乏味.

2.3 在每頁圖上需要文字註解的地方做記號(編號, ex: 1, 1.1, 1.2.1 etc..)

2.4 製作功能規格的文字說明表格, 與2.3相對應.

上述這一段程序我也是跟別人學來的, 在此之前我從不認為這道程序值得花

時間去做, 尤其是UI, 程式寫出來就有畫面了, 還先刻意去畫圖? 豈非可笑?

但是後來體認到很多案子會有糾紛(自己及別人的經驗)都是因為規格不明確,

尤其是UI, 因為客戶看UI圖像比看文字會更有感覺. 所以我承認這道程序對於

確認規格有其必要性, 算是一道防火牆. 而且run過一次後, 這些文件化的東西

以後接案還用得著, 所以值得.

還有畫UI圖及寫文字描述很重要一點就是: 為自己後續的施工做準備. 其實我

個人覺得寫'程式'的邏輯是需要'圖像'及'文字'做指引的, 有些東西你事先在

'概念上'以為很簡單的, 沒有先做文字描述來整理邏輯就直接施工(coding),

往往會漏洞百出, 最後東挖西補反而更浪費自己時間, 施工品質很差.

3 功能規格書開出來後, 給客戶看過, 有問題要改現在提出來改, 我可以等

你1~2個禮拜時間去想看看哪裏需要改還是要加? 沒問題就簽規格同意書.

反正簽約金我先收了, 客戶若要賴皮拖時間或不做的話我不吃虧. 其實一般

看完後都沒意見.(這就是了, 其實後面會有爭議都是因為一開始規格沒橋好嘛

, 你主動出擊, 客戶就只能應你的招. 輪不到外行引導內行.)

客戶簽規格同意書後, 我的責任範圍就很清楚, 後面就算你拗我, 也要我爽才

行. 才開始按照規格施工.

施工也有施工的流程, 不過這部份跟客戶就比較沒關係了. 是跟我本身的技術

及時間管理比較有關係. 最後東西交給客戶, 就是請他照規格書上的圖去做驗

收的動作.

※ 引述《KiroKu ()》之銘言：
: 如果老闆是會寫程式，
: 通常有問題，去問通常提出的回答也比較具體
: 如果沒有的話，常常真是有裡說不清...
: 像之前接的案子，客戶圖要一直改就算了
: 有些地方規劃不知道要放什麼，就先空著
: 等到快結案時，pm就說了：
: 就把全部欄位放大好了
: 就把全部欄位放大好了
: 就把全部欄位放大好了
: 就把全部欄位放大好了
: 因為這樣結果設計師，至少就又改了三四張圖
: 加五六個排版吧..（設計師真是吃苦耐勞的行業）
: 要不然就是問我說：
: 為什麼google/yahoo有的功能我們沒有呢？
: （...為什麼會有呢？...
: 並不是拿免費的東西隨便改一改就跟yahoo/google一般了好嘛？）
: 其實我覺得做系統，起先一定要有個架構圖
: 哪邊未來需要能夠擴充的，一定要先想好，用有彈性的作法
: 不過一般客戶，要他一次把所有細節都弄出來，再開始做
: 真是有十足的困難...所以常常變成，邊做邊商討細節...
: ※ 引述《TonyQ (沉默是金)》之銘言：
: : 作者: TonyQ (沉默是金) 看板: CodeJob
: : 標題: Re: [詢價] 員工薪資管理系統
: : 時間: Wed Jan 21 08:07:35 2009
: : 講到這個我真的是心有戚戚焉. XDDD
: : 我作過兩次類似這種系統(出勤、薪資計算）的經驗 ,
: : 結論是好的案主帶你上天堂 , 壞的案主結不了.
: : 第一次是我剛出道接的第一個案子 , 給某大學某處室內部用的值勤系統 ,
: : 這個勒 , 基本上就是一天一張出勤表 + 勤務內容 ,
: : 假別六種還七種(公病例假補修特修...etc) , 比較麻煩的是出勤名單的維護 .
: : 填寫的資料也都很簡單 , 反正就是填表 ,
: : （主要是取代他們過去的紙本填寫 ,
: : 不過有趣的是最後還是要轉成word檔印出來讓主管蓋章.）
: : 需求談好後幾乎沒有任何變動 ,
: : 結案前夕多叫我做個值勤的行事曆, 讓人看看是哪個同仁當班就結束了.
: : 作為第一個案子來講 , 非常輕鬆愉快的案子 ,錢也還算可以.
: : 第二個狀況就完全不是這麼回事 ,
: : 規劃的時候劈頭就是說功能要多完善有多完善 ,
: : 畫面要多炫有多炫 ,(還拿outlook 的介面來比 orz)
: : 假別? 那種東西我不知道啦 ,
: : 但是你給我看的時候我就會想起來你還差哪些東西.
: : 績效獎金?
: : 喔 我們就基本的出缺勤上下班啊 , 全勤沒遲到有獎金 ...etc
: : 隔兩天做到一半去確認 , demo 並確認現在的狀況.
: : （喔 ... 對了 我們賣房子賣出去還有業務獎金...那個可以另外加(!!?)）
: : 然後做到一半我越作越覺得不對，需求竟然往內部 portal 的方向偏(!!!)，
: : 發現這是個無底洞 , 外加上面的又一直催成品(一邊要改需求一邊要出成品).
: : 總之 , 沒有收斂好需求的下場差不多就是這樣 ,
: : 最後變成龐大的需求怪物 + 感覺根本不可能做的完. XDDDD
: : ────────────────────────────────
: : 其實根據後來的工作經驗 , 這樣的狀況真的很常態就是了 ,
: : 難怪具 pm 角色的老闆(super user)跟 pg 往往很難相處得來 ,
: : pg 的苦他們不知道 , 然後又覺得自己只是改一點點 , 只是參考某些網站,
: : 而且改的那些東西有沒有意義還是蠻見仁見智的 ,
: : 比方說最近聽到的一個主管名言：
: : 我們不應該自己造輪子，所以參考xx網站就好了。
: : （xx請帶入yahoo/google/facebook...etc）
: : （參考歸參考 , 最後還不是我要做出這功能...murmur）
: : 一直改就會讓 pm (通常是具user身份的) ,
: : 有自己很會規劃很能指揮 pg 的信心 ,
: : 等到 pg 翻臉時 , 就能知道自己平時有沒有燒香了. :p
: : ---
: : 上面後來提到的那份case 因為只是拿時薪 110 的課後兼差工作 ,
: : 也就只有給他 110 的水準 , 後來有做到一個階段就沒辦法繼續往下做 ,
: : 因為需求面臨談不攏的狀況外加完全沒把握做完 , 只好認賠殺出, @@
: : 當然這個工作經驗也算是份無效履歷 , 白白用掉三個月 , 有夠累的. orz
: : (只是那時候老闆常常下班後又抓我去陪他喝酒 , 他大概也只是試試吧. XD)

--
稱我 Mr. Candy 也可以, 我的Email/msn: [email protected]

--