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)