【 心得】我的接案報價學| WordPress 開發日常

以往我的報價方式是用我每月的生活成本來計算，一般來說如果是要架設企業官網的話，我會從企劃、設計到程式開發等工作項目估算很模糊的開發時間，假設我 ... 工具LINEPay外掛NEWLINE登入外掛文章接案學 全部實務經驗專案管理敏捷開發 外掛開發 全部WordPressWooCommerce佈景主題 學習資源 全部網站經營設計思考生活日常 服務關於我合作徵求與我聯絡管理序號下載購物車 我的接案報價學 2020-08-11 專案管理 21分鐘 目錄 摘要：我認為好的報價要能符合時間比例原則，並以單位時薪來展現自我價值，在這樣的前提之下，使用UserStory&任務拆解的工時估算法，從前置作業、頁面數量與功能開發三個大方向進行預估，並搭配透明化、定期主動回報工作進度的共同管理專案模式，讓客戶可以根據當月已開發時數(費用)決定優先順序，站在客戶立場，能隨時掌握專案進度並調整開發方向，減少時間成本的浪費，對於接案者來說，保持每月現金流是能持續自我精進的關鍵。

坦白說，接案這麼多年，我最討厭的部分就是洽談工作這個環節，從搭上線開始，初步了解需求，然後碰面洽談，整理會議記錄、網站規格、報價單、合約書，寄給客戶之後開始針對報價單的內容逐一刪減，被砍價是理所當然，而議價是我覺得最難受的過程，彷彿在說我這個人不值這個價，雖然理智上知道這是商業談判的一環，但心理上很容易就會跟自己過不去。

接下來就是合約書，要提交給客戶的法務審查，審完後提出修改，當然修改條件我也不可能全部接受，於是中間又是一連串的來回，最後，真正開案大概是第一次會面之後的三個月了，而這三個月所花費的時間還沒有產生任何一毛的收入。

以往我的報價方式是用我每月的生活成本來計算，一般來說如果是要架設企業官網的話，我會從企劃、設計到程式開發等工作項目估算很模糊的開發時間，假設我一個月生活成本10萬塊，而這個案子我估計兩個月可以做完，那我總價就會報20萬元，如果沒在兩個月內做完，我就開始賠本了。

所以我會想盡辦法用各種文件以及約定結案日期來讓專案可以在兩個月內完成，於是就給了自己很大的壓力，每週固定會議、追客戶資料、整理修改需求單、驗收確認表，同時還要處理設計、開發，但做這麼多行政作業的結果，真的能在設下的時間點內結掉的專案少之又少。

所以每當下一次專案開始的時候，又會給自己增加更多的行政作業來確保案件如期執行，然後樂觀地期待著這次應該沒問題了吧！當重複失敗了N次以後，才開始認真重新檢視自己的工作流程，歸納出以下三點原因： 自己個性的使然 我熱愛做網站，為了要做網站，我願意學習各種相關知識，更希望透過自己學到的知識，去幫助需要的人，同時也能讓自己有飯吃，所以我會成為自由接案者純粹是因為我喜歡接觸到不同領域的人，然後透過我的專業技能去解決他們的問題並讓自己獲得成就感。

這樣的理想主義是我做網站的初衷，但，接案久了就會不知道被第幾版的修改需求單給澆熄了熱情，每天在做的事情就是跟客戶爭執說這些功能並非在當初的報價範圍裡面所以沒辦法做，但更多時候就是睜一眼閉一眼做給客戶，因為爭論要做不做的時間已經夠我把這功能做完了，但背後更大的原因其實是我「害怕衝突」。

這樣最後的結果就是一直被凹，有苦自己吞，不停的告訴自己沒關係，這些新加的東西我應該很快就能處理完，多做就是多學，這些多做的客戶會感謝我、會介紹更多客戶給我，弄不完就加班拼，這次拼一下、撐過去就是我的了、男人就是要能忍耐，然後把自己變成只是為了要能結案收尾款的工作機器… 因此在結案時間不變的情況下，工作量卻是多了好幾倍，每多開發一個功能就要多一道修改驗收的流程，這樣完全不可能在原本預計的時間內完成。

客戶對於外包專案的認知 準時結案這事除了要靠自己的努力外，剩下九成九的關鍵都是要看客戶對於這個專案的認知，對於客戶來說，通常需要發包就代表他們公司內部沒有專人可以處理這件事，所以投資了預算無非就是希望可以得到預期的結果。

但很多公司往往忽略了外包的溝通成本，畢竟「預期的結果」公司內部不同職位的人會有不同的看法，更不用說還要傳達給公司外部的接案者，光是一個按鈕的位置可能就可以討論好幾個禮拜，而這些討論在還沒具體執行前都是一團謎，等公司內部討論出一個結論後，可能幾個禮拜的時間就用完了，而對我來說我卻還是要遵守結案時間。

再加上負責專案的窗口往往都有自己原本的工作要做，所以等待網站需要的資料、文案、素材也會花上很長一段時間，其他像是等待確認製作方向、驗收製作項目等等，這些全都不是我可以掌控的因素，在這樣的情況下要讓專案可以準時結束自然是難上加難。

其他外力因素 像是打籃球手指頭吃蘿蔔乾、小孩出生、家人生病、窗口離職、職務交接、老闆出差、颱風、武漢肺炎等等的各種外力因素，都可以造成專案的延宕。

總結以上三點人為與非人為因素，我得到了一個結論：「專案永遠不可能在一開始約定的結案日期結案」。

到底何謂結案？ 認清了這個事實以後，我開始反思結案的定義，依照傳統合約的定義方式，只要乙方把報價單裡面的項目全部製作完成，並且收回尾款就算是結案，但，這樣的定義有一個非常大的漏洞，所謂的「製作完成」只是乙方單方面的認知，對於甲方來說，乙方的產出到底能否符合商業上與管理上的需求，這樣的認知是非常主觀的。

最常聽到的就是當甲方看到成品時發現某個他認知「理所當然會有」的功能結果沒有，就會很驚訝的問說：「這功能不是基本的嗎」？然後乙方就會不爽，覺得自己的專業被質疑，開始解釋這功能當初沒有寫進報價單所以沒有開發，於是雙方就會進入僵持，直到某方退讓或是協調出雙方都能接受的作法。

事實上，要解決這問題在報價階段就要先討論出每個功能的細部規格，並且能讓雙方對於要執行的項目都有正確的認知，但實際情況是認知這件事每個人都會有所落差，而且窗口的認知跟他的老闆也不一定相同，窗口認可的成品到老闆那關被打槍也是屢見不鮮。

再來，如果我在還沒有得到任何收入前，都要幫每個客戶花這麼多的時間來確認每個功能，等到真正開工後早就餓死了，更不用說他們可以拿這份報價單去找其他更划算的團隊來執行，除非可以把確認規格這環節作為服務的收費項目，不然這樣的作法是不切實際的。

其次，雙方的目標不一樣是讓結案如此困難的原因，甲方要能透過這個專案的產出來達成商業目標，而乙方是要嚴守當初報價的內容，避免無止境的修改需求或新功能讓自己或公司陷入營運的困境，但商場上每天都是瞬息萬變，昨天討論的內容可能今天就會被推翻，更不用說是在兩個月前討論的規格，怎麼可能在兩個月後完全一模一樣，所以乙方就會非常辛苦，為了要結案可能要做某些退讓，同時也要堅守底線不然案子賠到脫褲子，還要不讓夥伴覺得被凹，這工作真的裡外不是人。

從這樣的合作關係衍伸思考下去，因為利益衝突，甲方也不可能得到乙方100%的專業協助，但甲方當初尋求外部廠商協助不就是為了獲得這些專業建議？雖然以職場道德來看，乙方收了錢就是要盡心盡力把工作做到100%，但人性不可能無時無刻永遠都保持完美，當修改到第101個版本、案子走了超過一年還沒收到第二筆款項，還能對這專案保有專注度並持續提供專業建議的人大概只剩下聖人，而我早就擺爛了。

所以我對於結案的認知，並非收到尾款或是過了約定結案時間後才算結案，而是乙方可以滿足甲方的商業目標而提供持續性的專業建議，當甲方決定暫停該專案或是結束與乙方的合作關係，這才是結案的時間點。

敏捷式接案 真正了解到自己為何每次接案都無法在預計時間內完成後，開始思考怎麼樣的合作方式是可以符合自己的個性又能滿足客戶需求，最後我得到了「敏捷式接案」這個答案。

敏捷式接案的核心精神是捨棄傳統的報價單、合約書，改用時薪估價、Email約定合作細節，並透明化開發過程，像是分享時間記錄、開放版本控管權限、每週固定回報進度等等，再根據實際花費時數來計算費用，以月結的方式來減少發案方的一次性大額開銷與維持接案方的固定現金流。

而且很多時候沒有做下去都不知道會發生什麼事，談的時候很愉快，結果實際做起跟彼此的想像落差很大，但真的發生也沒關係，就直接終止合作，敏捷式接案隨時都能「結案」，不需要為了硬撐合約書上的結案時間而折磨彼此，更不用吵已經做的進度佔專案總金額的多少比例。

敏捷式接案的具體執行步驟如下： 開發小時數預估 當第一次聽完客戶的需求描述後，一定會有一大堆實作的問題待確認，但這階段為了要讓客戶有預算上的心理準備，做出初步的開發小時數評估是必要的。

通常我會從三個方向切入： 前置作業–研究客戶參考網站的網站架構、清查哪些頁面是客戶所需，以及建置開發環境所需的小時數評估頁面設計–以完成單頁所需時間來評估，首頁或是已知的特殊頁面會花比較多的小時數，頁面設計的總小時數會依頁面數量而變動特定功能–客戶再三強調的特定功能，可能會有多個，每個功能加入需求確認的時數，然後初步拆解開發這個功能需要哪些步驟 這些任務需要花費多久的時間，全部都是建立在對自己工作習慣的認識，所以平常就要養成記錄工作時數的習慣，然後定期回顧有沒有造成什麼時間的浪費，久了自然而然就能越估越準。

當開始記錄工作小時數之後，任務拆解也就變得很自然，因為每個工作項目都要記錄的話，就能知道自己接下來要做的事情是什麼，雖然常常會有自己漏想的步驟，但因為有了記錄，在回顧的時候就會發現到原本做A功能只需10個task，結果做完後發現竟然變成15個，檢視多出來的項目就能知道自己少了什麼，下次再做類似功能的時候就能修正自己的評估。

假設今天接到一個需要開發某種平台的案件，小時數預估的範例如下： (一)前置作業–8小時 收集彙整參考平台之網站架構/功能–2hr資料欄位/網站架構確認–4hr頁面風格確認–1hr開發環境與程式碼部署配置–1hr (二)頁面切版–視頁數而定 基礎架構&RWD開發–4hr首頁前端程式開發–4hr首頁後端資料串接–4hr內頁前端程式開發–2hr/頁內頁後端資料串接–2hr/頁 (三)會員功能開發–5小時 會員註冊登入需求確認–1hr註冊/登入機制開發–2hrFacebookLogin整合–2hr (四)簡訊驗證功能開發–6小時 簡訊驗證流程確認–1hr簡訊廠商API文件研究–1hr會員註冊API串接–4hr (五)前台發文功能開發–9小時 發文管理需求確認–1hr介面設計–4hr介面功能–4hr (六)廣告管理功能–4小時 廣告管理需求確認–1hr廣告管理外掛API文件研究–1hr前台版面整合廣告管理外掛–2hr 把每項功能拆解任務後，粗估每個項目所需時間，再把所有小時數進行加總乘以時薪，就可以估算出開發這個平台至少要準備多少預算，萬一超出客戶預算太多，就直接從清單中去刪減，留下真正需要的功能，或是請客戶準備好需求文件，以減少每個項目的需求確認時間。

共同管理專案 待預算經過客戶確認後，就能開工了。

對，不用訂金、報價單、合約書，彼此合作的約定只需要透過Email保存即可，這時候只要在收信軟體開一個專案的資料夾，然後把關於這個案件的信件全都往裡面丟即可。

接下來各種工作上需要用到的工具都盡量採用雲端服務，主要目的是可以把文件分享給客戶，讓客戶可以清楚看到目前整理了什麼、執行到哪裡，並且可以直接在上面進行留言或討論。

以下列出我常用的工具： Google試算表–在清查網站架構、功能與資料欄位的時候使用，能直接在上面與客戶討論哪些頁面需要新增，或是刪除不需要的功能 Figma–雲端設計軟體，可以設計線框圖、介面、網站原型，支援多人同時編輯，並可以直接在上面註記留言 Markup–能直接在網站上註記留言的服務，這用來討論參考網站或是已經有網站雛形時非常好用，直接在畫面上標記留言可以清楚溝通要討論的地方，比起單純文字描述來得有效率的多 Github–程式碼版本控管服務，把客戶帳號加進來，讓客戶可以看到每一次的Commit，如果公司內部有工程師，也能同步檢視程式碼品質 Ora–看板管理工具，可以很靈活的分類工作項目，並整合多種不同的檢視模式，在看板、待辦清單、日曆檢視之間可以快速切換，同時還能記錄每個工作項目的執行時間，上傳該工作項目所需文件，最重要的是報表檢視功能，可以查看每個專案的花費時間 Freedcamp–彙整修改清單的工具，與Ora性質類似，但Ora我比較習慣用來管理自己所有專案的工作時間，Freedcamp主要提供給客戶管理修改驗收清單 以上的工具每一個都可以分享給客戶，讓他們隨時可以查看自己的工作狀況，有需要的時後也都可以在上面討論，透過Ora可以讓客戶知道我每天的工作小時數(費用)，進而隨時調整專案的方向 定期回顧 當然，這麼多工具客戶不可能每天都上去看，因此每週的定期摘要回顧非常重要。

我會在每週一上午發信給客戶，回報上週的工作內容、時間記錄以及本週預計要執行的項目，同時提醒客戶哪些東西待確認以及製作網站所需文件的準備。

在時間記錄的回報上，Ora的報表功能超級方便，它可以整理出如下的圖表： 另外還可以匯出CSV檔列出每項Task的開始與結束時間，透過這樣的回顧來讓合作透明化，進而產生信賴感，最重要的是可以隨時掌握專案的開發進度，如果發現某些次要功能花費了太多時間，而核心功能卻完全沒有進展，就可以立刻調整開發順序，專注在最重要的工作項目上面。

最後到了月底，就能以整月份的工作時數向客戶請款，因為每週的開銷客戶都能看得到，所以在請款上就能減少疑慮，相較於以往的請款方式，每一期的款項都必須要先檢查是否有達成合約上的付款條件，萬一在請款條約上有不同的認知，就會演變成接案方覺得該拿到款項，但發案方卻認為還沒有滿足付款條件的窘境，這時候就必須花時間討論出共識來。

在討論請款的過程中，對接案方來說感覺很差，因為做了事卻無法準時拿到酬勞，而發案方也會很害怕，害怕付了錢之後就找不到人，因此定期回顧+月結可以很大程度消弭彼此的不安感，讓接案者可以每月有固定的現金流，而發案方可以攤提大筆費用的一次性開銷。

結語 事實上國外的接案平台大部分都已經是採用時薪制了，國內的平台在這方面還是停留在固定金額的報價方式，這會導致發案者對於專案的預算評估過低，因為他們並不清楚開發一個網站到底需要多少時間成本，而很多小型工作室為了生存，就算賠錢也要先把案子簽下來，先拿到訂金撐過這個月再說。

因為案件金額低，接案者只能用量來彌補每月的資金缺口，當同時接了大量的案件後，要能順利準時結案除非多請人手幫忙，不然只能等著唱開天窗，但要請人經營成本又會上升，所以又要再接更多的案子，就這樣進入惡性的循環。

另一方面，當一個購物網站花5,000塊就可以找得到人做，對整體的接案市場並不是一件好事，從前期溝通、規劃、設計、開發、修改，就要花費非常多的時間，但發案者對於這樣的流程可能並不了解，所以價格普偏偏低，而剛出來接案的人以為這就是市場行情，長久下來的結果就是發案方得不到專業服務，接案方得不到應有報酬。

因此我認為好的報價要能符合時間比例原則，並以單位時薪來展現自我價值，同時搭配透明化、定期主動回報工作進度的共同管理專案模式，讓客戶可以根據當月已開發時數(費用)決定優先順序，站在客戶立場，能隨時掌握專案進度並調整開發方向，減少時間成本的浪費，對於接案者來說，保持每月現金流是能長久自我經營的關鍵。

敏捷式接案Q&A 當然，任何方法用在真實世界總是會遇到很多挑戰，下面整理出一些我常被問到的問題： Q1.沒訂金、沒報價單、沒合約會不會沒保障？ 就算有訂金、報價單、合約也常常會有做到一半人不見或是錢燒完收不回尾款的案子，所謂的保障，對雙方來說就是時間到了看得到成果並且拿得到酬勞，一堆文件作業也都是為了要確保雙方能信守承諾，萬一當其中一方背信時有求償損失的備案而已。

對接案者來說，時薪計價最大的風險就是在於一個月的款項請不到，也就是白做工一個月，相較於以往好幾個月才能請一次款，只損失一個月的工作小時數已經是不幸的大幸了，而且只花一個月的時間就可以認識一間公司或一個人，不用花上好幾個月或好幾年的時間才知道，已經算是少走很多冤枉路了。

當然，如果要上法院，每週定期回報記錄Email都能拿來作為證據，但還是要衡量官司打下去的成本是否會讓自己深陷泥沼，畢竟一般有規模的公司都會有法務部門來專責處理法律糾紛，個人或小型工作室這方面就會比較吃虧。

對發案方來說，合作一個月的過程當中就能知道對方的工作方式，像是有沒有定期回報進度、是否有固定產出，如果發現苗頭不對，不用等到一個月，可能幾週就能知道是否要提早結清工作時數並尋找下一間合作廠商，如果有合約在，片面解約都是需要付出成本的，所以為了避免罰則，縱使知道合作對象有問題，還是必須要硬撐下去走完合約，通常最後的結果都不會太好。

Q2.預估工作項目跟實際執行時間有落差？ 在網站還沒有完成架構圖、需求確認、操作流程確認等等的內容前，所有的估時都是憑著過去經驗來做預測的，就像要做一個購物網站，基本會有的功能像是購物車、結帳、金流、物流串接等等，這些都有過去的時數可以參考，但每家公司的商業情境不同，管理需求也不同，因此實際執行上一定會跟當初預估的工作項目有所落差。

但透過每週的定期回顧，就會慢慢釐清整個專案到底有多大，以及目前的完成進度百分比，所以重點應該是放在持續的追蹤與溝通，只要能透明化專案的資訊，客戶就不會覺得計時是黑箱作業而產生不信任感。

Q3.開會也要計時？ 一個專案最花時間的地方不是坐在電腦前面寫程式，而是釐清客戶的需求以及確認成品是否有滿足客戶需求，初期的需求溝通的越明確，就越能減少後期修改的時間，但要能協助沒有網站專業知識的客戶釐清需求是一門學問，而且很多時候懂得這些專業知識的客戶也會把需求變得錯綜複雜。

這是人之常情，在一個專案被發起時，公司內部會有許多的聲音需要整合，好的整合是可以排出優先順序，但大部分情況是包山包海，因此會產生矛盾與衝突，譬如說客服部希望在每頁的頁首可以放上明顯的客服信箱連結，以減少客服電話的量，但業務部希望放上聯絡電話，就能跟客戶進行直接銷售。

沒有整合好的需求就會變成Email跟聯絡電話同時以超巨大的48px顯示在頁首，什麼都要顯眼最後就會變成什麼都不顯眼，這時候釐清客戶的需求後就能提供相對應的作法，譬如說在電腦版顯示Email、手機版顯示電話號碼，或是採取A/Btest來實驗怎麼放會比較好，這些都是接案者的經驗，這些經驗沒有辦法Google得到，因為這是根據客戶的情境所設計的。

問出正確的問題、提出有效的作法、釐清真正重要的目標，這就是開會時接案者所提供的服務內容，就像美劇上常看到的心理醫生諮詢一樣，都是需要鐘點費的。

Q4.為何這個工作項目要花這麼多時間？ 有些客戶會質疑某些工作項目應該不會太複雜，花這麼多時間不太合理，這樣的情況有兩種，一種是任務沒有被正確的拆解，像是要做購物網站，購物功能只被當作是一個工作項目，購物功能包含有前台頁面的建置、商品管理、訂單管理、金物流串接、會員功能等等的細項，如果只列了一個購物功能可能就要會花費數十個小時來開發，從總小時數來看就會覺得這個單一工作項目花了太多時間。

另一種情況是客戶懂技術，他們以自己過去的經驗來判斷，所以會覺得某些時間的花費不合理。

當然，工程師程度有高有低，做事的方式也會有所不同，這時候版本控管就是很好的溝通管道，因為程式碼的透明，客戶可以看到專案的原始碼，進而提出改善建議，也能判斷承接的工程師是否有辦法勝任這個工作。

我自己是還沒遇過被質疑某個工作項目的花費時間，但每次卡關時我一定會先暫停計時，因為我的認知是只要卡關就是代表自身能力不足，需要花時間再學習、研究、實踐，而客戶不是花錢來讓我學習的，所以遇到卡關時一定會停止計時來避免客戶的花費。

Q5.程式的保固期間該如何計算？ 不用計算。

通常保固指的是當專案已經過了約定結案日期後，如果還有發生程式上的臭蟲需要被修復的維護期間，在保固期間內的Bug修改，接案方有責任協助處理，這時候問題就來了，到底什麼是「臭蟲」？網站開不了？功能無法正常使用？實際用起來應該這樣改比較好？ 關於臭蟲的定義也是一個吵不完的話題，常常客戶覺得是Bug的地方也許是某個邏輯沒有正確實現，但對於接案方來說這個邏輯並沒有在當初開發時接受到客戶的需求，而且結案時不都已經驗收過了，怎麼會現在才發現有這樣的問題？或是更多時候是使用者發現的Bug，可能是公司內部操作人員或是外部使用者，這些都讓臭蟲的定義很難有一個明確的標準。

回到保固的定義，指的是過了「約定結案日期」後的維護，以敏捷式接案的定義來看，並沒有所謂的結案日期，因此也就沒有保固這樣的概念。

網站上線後有問題，持續的以時薪計價進行修改臭蟲或是根據使用者回饋進行調整，就不用為了保固範圍而犧牲能讓網站變得更好的改進措施，而接案方也能提供更多實務上的建議讓網站達成商業目標。

認同請分享～ 如果你認同這樣的理念並想嘗試這樣的模式來進行專案的話，可以參考下方連結： 我的合作方式 目錄 系列文章 一天四小時工作術 賴俊吾/OberonLai 現為全職WordPress工程師，網站開發經歷11年，專攻前端工程與WordPress佈景主題、外掛客製化開發 關於我 訂閱電子報 Hi，我是Oberon，我會固定在每週五早上發送接案心得以及與WordPress相關的電子報，同時也會分享一些實用的開發知識，讓你在WordPress的接案路上不孤單！ 電子郵件 您的大名 立即訂閱 覺得文章寫得好再幫我鼓個掌吧！ 相關文章 工作與生活的失衡 當我剛出社會時覺得找工作超級困難，因為並非就讀資訊相關科技，在沒有任何學歷下要找... 專案管理 如何評估從未開發過的功能（三）-任務拆解 回顧前幾週的文章我們可以知道兩個基本原則，第一個是不要用報價單來逼死自己，而是採... 專案管理 發佈留言取消回覆發佈留言必須填寫的電子郵件地址不會公開。

必填欄位標示為*留言*顯示名稱* 電子郵件地址* 個人網站網址 在瀏覽器中儲存顯示名稱、電子郵件地址及個人網站網址，以供下次發佈留言時使用。

Δ 這個網站採用Akismet服務減少垃圾留言。

進一步了解Akismet如何處理網站訪客的留言資料。

專注於分享WordPress開發、接案技巧、專案管理等自由工作者必備知識與心得 ©2022想點創意科技有限公司 DesignedbyHendDesign | 隱私權政策 選單 工具 LINEPay外掛NEW LINE登入外掛 文章 接案學 全部 實務經驗 專案管理 敏捷開發 外掛開發 全部 WordPress WooCommerce 佈景主題 學習資源 全部 網站經營 設計思考 生活日常 服務 關於我 合作徵求 與我聯絡 管理 序號下載 購物車 訂閱電子報 Hi，我是Oberon，我會固定在每週五早上發送接案心得以及與WordPress相關的電子報，同時也會分享一些實用的開發知識，讓你在WordPress的接案路上不孤單！ 電子郵件 您的大名 立即訂閱 顯示所有結果