關於這個, 我可以提出我所採用的接案流程及原則僅供參考(因為不知道別人 是否有更好的做法?). 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] --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 211.74.193.210