Devs.tw 是讓工程師寫筆記、網誌的平台。歡迎您隨手紀錄、寫作，方便日後搜尋！
Devs.tw 是讓工程師寫筆記、網誌的平台。歡迎您隨手紀錄、寫作，方便日後搜尋！
最近接網站開發的案子，特別是新創團隊的案子，我發現用週工時的兼職方式報價，比報固定價格的傳統接案方式好很多。
報價方式會像這樣：
N、M、X、Y、Z 的原理如下：
這種報價方式看似含糊曖昧、對雙方來說都有風險。實際上卻正好相反，它比傳統報價方式符合雙方需求得多，也比較符合現實狀況。
舉例來說，我最近一次替新創團隊做網站的接案對話如下。我先說明報價方式：
接著補充說明一些：
案主很爽快的答應了，後續也進行得非常順利。這種兼職方式解決了傳統報價方式會遇到的3個問題：
軟體工程幾乎不可能準確規劃規格與細節，因此案件總金額、總工時根本估不準。
按照傳統的方式，雙方只能各憑經驗，討論出一個價格。這價格簡直是兩邊各猜一個數字之後妥協的，一點都不準，價格很少是公平的。常常導致接案者覺得自己被凹了，或是是案主覺得自己被當肥羊宰了。
其實，對很多案件來說，特別是新創團隊的案件，這種固定價格式的接案本來就不合理。
現在創業的商業方法論，講求執行、靈敏。趕快先開始，過幾天有新想法、新功能想做，再調整開發的優先順序。需求與規格本來就會跟一開始不同。
接案者要案主一開始就把規格訂得非常清楚，實在是強人所難。
而這種情況下，案主在一開始就想確認一個絕對數字的預算，也是強人所難。
除此之外，光是為了報價，就必須花一堆時間確認規格、需求。這些開會討論的時間成本很高，卻又不可能跟案主說「我給報價是要收費的」。
於是接案者為了保護自己，會演化出一種習慣：防禦式報價。
那就是把情況都往壞的方向預想，一律只給偏高金額的報價。這對整個接案市場都不是什麼健康的事情。
週薪式兼職不會出現防禦式報價。只要大致溝通一下需求，接案方大概了解情況，馬上就可以開始動工。
對案主來說，什麼都沒拿到就要先付訂金，還經常是總額的1/3到1/2，壓力不小。
對工程師來說，一大部份費用卡在尾款，還有可能一拖再拖，結不了案，同樣可怕。
每 Z 週結帳一次，雙方觀察對方的時間多了許多，不用再賭人品。
傳統接案方式，雙方可能從頭到尾都彼此怕怕的，因為兩個沒合作過的人，要在一開始就互相綁定一個大承諾，也不知道案件會不會進行順利、對方人品到底怎麼樣。
而週薪式兼職，對案主來說，最糟的情況就是幾週之後工程師擺爛失聯了，損失幾週的錢。就算這樣也比傳統報價方式搞砸時，損失50%總金額的訂金好。
對工程師來說，最糟的情況就是定期結帳時，案主不付錢失聯了，損失幾週的錢。就算這樣也比傳統報價方式搞砸時，損失50%總金額的尾款好。
這種方式不但可以逐步培養互信，也對溝通很有幫助。
因為雙方每 Z 週必須真實面對彼此一次（付錢/要錢的時候，就是真實面對彼此的時候）。有什麼誤會都會被迫儘早說開，不會拖拖拖好幾個月，到要結案才發現雙方距離彼此期待差超多。屆時的誤解跟憤怒都會高到無法溝通了。
本文一開始提到的接案經驗，雖然規模很小（我1人+案主方2人參與），但是執行得非常順利、非常愉快。連一開始的報價我都只看了一份 UI 的 pdf 檔一眼，5分鐘就給出報價。
我們甚至連合約都沒簽，隔天就開工，只花費 4 週就完成了這個案件。每週見面1-3次，搭配頻繁的線上討論，總金額新台幣 48,000 元。一點浪費時間的感覺都沒有，是一次非常理想的商業合作經驗。
下次接案、發案時，碰到傳統接案方式的困境的話，不妨以這種方式接案、發案，根據個別情況調整一下 N、M、X、Y、Z 參數即可。
傳統合作產生的商業糾紛，或許只是 pricing model 的問題而已。
跟案主見面開會完之後的閒話家常，算不算工時？ 工程師通勤去開會的時間，算不算工時？ 工程師吃晚餐、出門散步的時候腦中在想演算法，算不算工時？ 案主要求的技術工具太有趣，工程師自行額外看了一堆進階文件，算不算工時？
每件小事都要定義清楚算不算工時，有點不切實際，對雙方來說都很煩，而且斤斤計較這些東西有點傷感情。區間讓案主、接案者雙方都更自在。
不如承認這點曖昧性，兩邊都知道會有彈性，彼此守住一些議價的立場就好了。而且是區間的話，你也不用一直拿手錶計時了。每週抓固定幾個時段工作就差不多了。案主也不用每次開會要一直看手錶了。
除此之外，區間工時可以保護接案者的時薪高低的彈性。未來再接案時，你會有立場在 X/N 到 X/M 附近的範圍報價。
（完）
(Photo by Maya Maceka on Unsplash)
