WebConf Taiwan 2024──接案失敗學：前端、後端、設計端，我還要具備什麼端才能出來江湖闖盪？談小白鼠闖入黑森林被XXX的淒慘故事
在個人和小型團隊的接案市場中，僅僅掌握前端、後端或設計技能並不足以保證成功。更多的挑戰在於如何應對現實中的各種情境及困難。成功很難被複製，但是失敗可以。本演講將從失敗學的角度出發，分享接案小白在接案過程中可能遇到的各種意料之外的狀況，以及如何從這些經歷中學習與成長。
OUTLINE
1. 前言
2. 自我介紹
3. 技術能力越好，接案就沒煩惱？
4. 接案流程舉例
5. 定價策略的種類與擬定眉角
6. 需求變更：接案中的隱形殺手
7. 總結與反思自我介紹
我是Web 軟體工程師，工作內容涵蓋前端與後端開發，但我個人比較擅長前端領域。在接案方面，我有一些個人接案、兼職，以及小團隊合作的經驗。
個人接案經驗
在個人接案方面，我常處理的項目包括產品官網、前台服務與後台服務，涵蓋從零開始開發、專案維護、小型需求調整等多樣工作內容。服務的領域則包含線上課程平台、NFT 公司、遊戲產業、社團法人、基金會，以及電商網站等。
團隊接案經驗
在團隊接案方面，我們的團隊由工程師和設計師組成，特別是在 UI/UX 設計上擁有較強的優勢。因此，我們的接案重點以企業官網、個人形象網站和作品集網站為主；此外，也會承接一些企業內部系統的設計與開發專案。
因此，今天的分享會以個人接案與小團隊接案為核心，並以 Web 相關產品的接案實例作為探討的主要範疇。
前言：程式寫得好/設計做得好，接案就沒煩惱？
與專業接案公司不同，個人接案與小團隊的運作有其獨特的優勢與市場定位。接案公司通常擁有完整的團隊架構，每個人分工明確，流程也高度標準化。而個人或小團隊的接案，則更靈活且具人情味，能滿足一些特殊或小規模的需求。
對於許多工程師或設計師來說，隨著經驗的累積與名聲的建立，自然會有機會透過關係性接到案子。可能是朋友、同事、甚至親戚的介紹…等等。
因此，我們會得到這些機會，是因為「程式寫得好」或「設計做得好」。
然而，問題來了：「程式寫得好，或設計做得好，就一定代表接案會做得好嗎？」這就是今天想要探討的核心議題。我相信，曾經接案的人，對這個問題應該會深有共鳴，甚至會想起一些相關的經歷。而還沒有接案經驗的人，可能你一開始會覺得這一題答案是對的，但是，被我這麼一問，你可能會開始懷疑這個答案。
今天我們要對這部分做深入的討論。
沒有人想要獲得低報酬，但是…
我想，沒有人希望自己出來接案，是獲得低報酬、賠錢、希望自己接案不順利，對吧？
雖然沒有人希望接案不順、賠錢，但是這些事情卻在我們生活中隨處可見。各位回想自己過去接案的經驗，或是看看那些不順利的經驗，都是技術能力不好的人嗎？我覺得不見得。
我們可以根據技術能力與報酬(包含接案是否順利、成功)的相關性來進行個別討論。
- 高能力、高報酬
這個組合大家應該不會覺得奇怪。能力出眾，自然能爭取到更高的報酬，這符合常理。 - 低能力、高報酬
雖然技術能力不是頂尖，但能成功接案並獲得不錯報酬的人也不少。他們可能有很好的機緣，或者做事方式很有一套，懂得如何展現價值。 - 低能力、低報酬
能力不足的情況下，要成功接案並獲得高報酬自然會比較困難，因為少了一個談判條件。對於這種情況，我的建議是多磨練技術，紮實地提升自己的專業能力，為未來鋪路。 - 高能力、低報酬
這一組合特別值得討論，因為它違反我們的直覺，但在現實中卻常常發生。
這種現象背後的原因有很多，今天無法逐一列舉。我挑幾個常見的狀況來分享，希望能帶來一些啟發。
高能力低報酬原因一：忽略技術範疇以外的工作
讓我先簡單列出一個常見接案流程，供大家參考：
工程師的專業在於寫程式，有人專攻前端、有人擅長後端，也有全端一條龍包辦；設計師則擅長 UI/UX，能讓介面既美觀又好用。
然而，我們可以仔細看看上述接案流程，這些專業技術其實僅佔整個接案流程中的一小部分，即「專案執行」階段。
這也意味著，在個人或小團隊接案中，我們必須處理許多除了技術範疇以外的工作。這些看似與專業無關的環節，卻是接案過程中不可或缺的一部分。如果輕忽或省略，往往會導致專案陷入困境。
另一方面，我們所擅長和認知的範圍常常僅止於「專案執行」，因此對於接案流程當中的其他項目，在沒有遇過之前，我們可能沒有想過我們要去做這些事，那更不用說我們對於這些技術範疇外的項目是多麽的陌生、生疏。
想想看，我們請一個零經驗的工程師來進入專案、請一個零經驗的設計師來畫設計稿，那在我們來看，是不是有許多令人擔憂的地方？
同樣的情境，我們可能在業務能力面、專案管理面…等等，也是一個零經驗的人，那是不是進入到這個戰場上也應該是會令人十分擔憂呢？
因此，在接案之前，我們必須要有所認知，並且不要排斥去接觸技術範疇以外的工作，甚至要想辦法在這些面向精進自己、累積經驗。
高能力低報酬原因二：技術專業和商業價值的脫節
第二個原因是「技術專業與商業價值的脫節」。
剛開始接案時，因為過去只有求職面試的經驗，缺乏談生意的經驗，許多人會不自覺地把「求職面試」的技巧帶進「談生意」。但求職與談生意其實有本質上的差異，因此，使用錯誤的策略往往難以達到理想結果。
舉例來說，在求職面試時，我們會極力展現自身能力，例如效能優化的能力（如降低 bundle size、提升載入速度）、高品質程式碼（unit test coverage 高）、或良好的團隊合作能力。這些對用人主管來說很有吸引力，因為他們需要能力出色的人才。然而，談生意時，這套說法卻不一定奏效。甚至有可能帶來反效果。
在接案中，我們面對的往往是業主，例如新創公司的老闆或老闆委託的高階主管，他們的背景可能與軟體開發毫無關聯。當你向他們講述效能優化或技術能力時，儘管他們可能認為你很厲害，但這些資訊無法真正打動他們。
我們需要練習換位思考一下，假設今天我們身為業主，要外包一個網站，我們關心的是什麼？
業主真正關心的是：
- 你的報價是否划算？
- 你的信用、服務品質好不好？
- 你是否有成功案例？
- 你的團隊經驗、規模、名氣如何？
- 其他
因此，單純展現技術能力，無法讓客戶理解其背後的商業價值。
舉例來說：
你說你在 performance 處理很厲害，但對我的網站而言，我並沒有感受到差那幾毫秒是不是真的有差？而且就算真的有點感覺好了，那值不值得我再多付這麼多錢處理這個問題？我可能不願意。
另外你說你嚴格遵守 coding style 規範，你有 Eslint、你有 TypeScript，你的 unit test 覆蓋率很高，所以呢？我又看不懂 code，我怎麼知道你說的是真的？那覆蓋率 10% 跟 80% 差在哪裡？我感受不到，我的客戶也感受不到，那我為什麼要花這一筆錢？還是你不要寫測試，有問題我們再來改，你看這樣能不能讓我省點錢。
因此，談生意時需要站在業主的立場，回答他們真正關心的問題，而不是一味強調自己的專業技術。
客戶翻譯機
網路上我們常常可以看到許多直男踩到了女友的地雷，因為他們沒有使用「女友翻譯機」。所以他們字面上去理解女友的意思，結果就悲劇了……。接案何嘗不是如此？
業主他關心的問題，通常不會直接說出來給你聽，但是你要懂的去翻譯、去揣測。
上述這些問題，你遇過幾個呢？這些問題表面看似簡單，但如果只是直白回答，容易掉入陷阱。最好的方式是揣摩背後的真正用意。我們一個一個來解析。
你有做過這個嗎？
業主：你有做過這個嗎？
接案者：開玩笑！？我超勇的好不好？
相信這一題是蠻多人會遇到的。如果你直接回答「我超勇的」，那這部教育影片後續的發展，我應該不用再多解釋……。
咳咳，回歸正題！
當業主問「你有做過這個嗎？」時，他背後有可能是擔心你的能力不足、擔心你做不出來我想要的感覺/風格。因此，最能讓對方心服口服的方法就是適度地展現你的作品集，展示的過程中要展現自己的專業。
但從心理學的角度來看，他問出這個問題很巧妙的，讓你們之間的關係透過這一個問題傾斜，你們不再是對等的，而是他在審視你。因此，你需要冷靜處理，避免急於證明自己、或怕他會看不起你而匆忙回答。你需要在回答這個問題時，既展現專業能力，又避免讓自己處於較低的地位，並試圖把對話導回平等的合作關係。不然會變成有點像是一個評審在幫一個表演者評分的感覺。若處於這樣的劣勢，將不利於我們未來的談判。
- 展現自信，從容應對
當被問到「你有做過這個嗎？」時，不要急於給出詳盡的答案或匆忙地展示自己的能力，而是先從容回應，例如：「這是個很好的問題，我之前確實有做過類似的項目，讓我和您分享一些相關的經驗。」這樣的回答既不失禮貌，又能傳遞自信，避免顯得過於急切或不安。 - 將話題導向對方的需求
與其過多地解釋自己的經驗，不如把焦點放在對方的需求上。例如：「過往的經驗能幫助我更好地理解您的需求，不過我更想了解您這邊的具體想法和期待，這樣我們可以一起探索最佳的解決方案。」這樣可以自然地將對話拉回合作的基礎上，而非單方面的能力評估。 - 巧妙地平衡關係
如果感覺對方的提問讓關係變得不對等，可以主動提出問題，讓對方也投入到討論中。例如：「在過去的項目中，我發現了解客戶的細節需求非常關鍵，能否請您再多說一些這部分的想法？」這樣的方式不僅能緩解審視氛圍，還能顯示你的專業性和對合作的重視。
我的需求很簡單
「我的需求很簡單，我只需要一個跟 Apple 或 SpaceX 一樣的官網。」
「我的需求很簡單，我想要一個聊天機器人跟 ChatGPT 一樣。或是 Gemini 也行。」
「我的需求很簡單，就是一個簡單的文字編輯器，我要的功能就跟 Google doc 或是 Notion 一樣。」
上面這些聽起來很誇張、很像幹話的話，我是常常在聽，是真實案例。
「需求很簡單」這句話本身並沒有問題，但由客戶自己講出來，那可是大有問題。其實我內心最想講的話是：
「需求簡不簡單不是你說了算，是我說了算。」
「不是所有的需求前面用”簡單”兩個字來修飾，他就真的會變得簡單。」
確實，真的有些需求並不是那麼複雜。但即使遇到簡單的需求，我也不建議直接順著對方的話回答說「沒錯，這確實不難。」。我認為這樣的回答會有點 NG。
理由是因為，當對方說出這句話時，他背後真正的含義是「我預期這個不會花太多錢」或是「我覺得這個功能很便宜」。
所以當你順著他的話回答之後，也就間接的讓他覺得這不用花很多錢。這會造成雙方的誤解、認知上的落差。
想想看，如果你跟他說「對呀！這個不難！」之後，報價給他，他會怎麼回答你？他勢必會說「你不是說這個很簡單？那為什麼還這麼貴？」。
當然，對我們而言，不管是工程還是設計，簡不簡單是一回事，便不便宜又是另外一回事，這兩個之間不見得成正比。這個東西對我們而言之所以簡單，是因為我們在技術方面過去有努力和累積，所以我們的努力和累積不應該是廉價的，就像大廚做一道看似簡單的家常菜，雖然動作輕鬆，但背後的功夫是長年累積的結果。對我來說很簡單，但對你來說就不是。
但切記，談生意並不是在吵架，上面雖然很有道理，但是聽道理不見得會聽得爽，一但不爽，合作就會破局。因此我們要找一些比較圓融的方式來跟對方說明，並且留意不要掉入對方言語上的陷阱。
例如你可以跳脫他的問題，說「我們會評估需求的完整實現需要多少時間與資源，然後給您一個具體的報價，這樣您可以有更清楚的參考基準。」
溝通時，我們需要留意，目標是能維護自己的專業形象，又不至於讓對方感到不舒服，達到溝通雙贏的局面。
這樣的東西多久可以完工交付？
在公司裡面，PM 問我們這個問題，我們會很自然地、沒有戒心地回答他，因為他是一個在狀況內的人，他有軟體開發經驗，他需要你預估時間是為了妥善的安排專案時程，並且好好跟客戶溝通。
但是客戶直接問你這個問題呢？他背後就不見得是這個意思，他很有可能意思是「我希望越快越好，若你慢了，我會懷疑你的能力」。
記住，先前我們提到，接案的流程中不是只有「專案執行」這個階段。因此，我們除了考慮實作、測試、部署的時間之外，也要把其他部分會花費的時間成本考慮進去，因為這些部分是很容易遺漏的。
如果你不是接案老手，用過去在公司面對 PM 的習慣，或是在沒有十足的把握下給對方一個時間，很容易讓自己吃虧。因此我們在回答問題的時候，一方面不要草率給對方一個時間，另一方面，也不要讓對方覺得我們估的時間超出合理範圍，以避免有失自己的專業。
例如你可以讓他知道，這個項目不是只有專案執行，還有包含前期後期的準備，所以你可以說「目前看來，我們大概可以在 X 週完成，但這還需要進一步確認需求細節，並且留一些空間給修改和優化的時間，這樣能保證成果符合您的預期。」
如果客戶的語氣有壓迫感，可以巧妙地將焦點轉移到「如何提升專案品質」或「確保目標達成」上。例如你可以說「我們也希望越快越好，但最重要的是要確保功能完整、符合您的期待。我會根據詳細需求，快速提出一個階段性的計劃，確保每一步都在掌控之中。」讓客戶理解，快並不等於好，並用專業的計劃來展示可靠性。
另一方面，更好的做法是你已經擬定好你的定價策略，上面已經有項目、定價以及時程，這是你在私底下已經做過研究和評估，是對自己或團隊適合的節奏，那有這個定價策略，我們就能夠更有效率地跟客戶來溝通。
你能根據我的想法，給我一些建議嗎？
這一題跟你的女朋友問你「今天晚餐吃什麼？」的意思是一樣的，你沒有講出他心中所想，他是不會滿意的。例如你換個語句「對於今天晚餐你有什麼建議嗎？」是不是聽起來有 87% 像？
這樣你是不是就知道該怎麼做了？
很多時候，業主問你建議，他不見得是要你的建議，他只是想要博取你的認同。可是當我們被問這個問題的時候，我們容易會急著想要展現自己的專業，甚至有可能會反駁業主的想法。有時候，你會發現他不太想聽。當你付出了專業，對方卻不重視時，這會讓自己的專業變得廉價，也會讓自己灰心。
另一方面，別忘了，我們的專業建議其實是有價的，如果這樣隨便讓我們的專業被無視，對我們而言也是很不好的一件事情。因此，如果你觀察出來，他只是想要博取你的認同，那就好好安撫他的心情。但如果他是認真想要取得你的建議，在合理的範圍下你要告訴他，向你做專業諮詢是需要付費的，可以跟他約一個需要付費的會議，在裡面你可以盡情展現你的專業，因為業主是付費了來跟你開會，所以他必定也會特別認真。
小結
總結來說，談生意時我們不能只強調技術實力，而是要了解對方問題背後的需求。回答問題前，先思考對方的用意，避免無意中進入不利的局面。
高能力低報酬原因三：定價策略錯誤、定價策略模糊
第三個我認為高能力卻獲得低報酬的原因，常常是因為「定價策略錯誤」。
沒有一個清晰的定價策略，意味著你在這方面缺乏原則，容易因為「人情」或「一時大意」而被壓低價格，甚至被壓榨工時。
如果事前沒有準備好定價策略，可能會因為當下沒有時間仔細思考而漏掉許多隱藏成本，這樣不僅會讓自己吃虧，還容易做得不甘心。
接下來我們會針對「定價策略」這件事情來做仔細的討論
四種常見報價方式
時薪計價 ✅
- 根據每小時的工時來計算報價，客戶支付的是實際工作時間或預估的工時數量。
- ex: 兼職類型的接案、專案長期配合
專案計價 ✅
- 根據專案的總體需求、預估工時、製作條件等因素，給出固定的報價，通常不以時間為單位，而是根據專案的範圍與要求來設定。
- ex: 幫企業設計官網、後台網站、個人形象網站、Logo 設計、名片設計
包月計價
- 每月收取固定費用，並規範每月的工作天數與時數，適用於長期合作的專案或需定期維護的工作。
- 理解成：每週/每月固定時數的時薪計價
價值計價(分潤)
- 根據專案能為客戶帶來的商業價值來設定報價，通常是以專案為客戶帶來的利潤比例或其他商業指標作為定價基準。
個人接案和小團隊接案中，時薪計價、專案計價是最常見的。我們會針對這兩個部分來介紹。
包月計價其實有點類似時薪計價，只是我們把一個月要做多少小時先約定好。而價值計價是會牽涉到分潤，這部分在個人、小團隊接案中比較少會這樣談，所以這一題我們改天有機會再談。
關於時薪計價
講到時薪計價就會讓我想到少林足球的名言「我一秒鐘幾十萬上下」。這已經不是時薪了，已經是「秒薪」，在此祝大家接案都能夠一秒鐘幾十萬上下。
回到正題～
薪資的設定其實取決於市場機制和雙方的協議。「你認為自己每小時提供的服務值多少，那就是多少。」
如果對自己的市場價位不確定，可以參考正職工作的時薪，並根據接案的性質適當調整，例如乘上 1.5 倍或 2 倍。乘上這個權重是因為你是利用下班之餘的時間來進行接案、兼職，甚至犧牲你的假日。因此平日上班時間的價格跟犧牲假日加班的價格是不同的。
有些求職平台上的職缺也會標明時薪範圍，你願意接受這個價格，你就可以去應徵。
今天我們無法深入探討如何提高薪資，但可以分享一些「避免在薪資上吃虧」的技巧。
雖然「時薪計價」看似比較不會吃虧，但這種方式還是有模糊空間。
我認為，關鍵在於，雙方對於「有做事」的認知是否一致。如果認為只有「寫程式」和「畫設計稿」才算工作，這樣就容易被吃虧。
大多數業主直覺上認為，只有「實作的部分」才是勞力與專業的投入。然而，接案過程中你會發現，除了實作，還有很多隱性成本。例如：
開會
開會有助於建立彼此的信任和資訊流通，但過多的會議會影響效率。例如：有些業主會把你這個接案者或外包商當作他自己公司的開發團隊，要求要每日跟你 standup meeting。或者，我也有遇過業主急著要找我開會，我也排除萬難跟他開會了，結果內容是，他今天跟哪一個他們公司重要客戶吃飯，談成了什麼生意，所以他們公司未來展望很好，我們能有機會幫這麼有前景的公司做產品，是很棒的一件事。
功能盤點和估價
長期配合的專案當中，業主有時候會請我們對新設計好的頁面做功能評估，例如估時、估價。但整個功能估下來可能要花你幾天的時間，或是幾小時的時間。假設後來盤點出了 20 個 Task，結果他只想做裡面的 2 個 Task，如果你只有做這兩個可以拿到錢，那你評估其他 18 個 Task 的時間就是在做白工。
調查問題
一個 Web 專案在測試中，或運行一段時間後，若出了問題，業主第一個會找的大部分會是前端工程師。以前端工程師來舉例，假設你花了大半時間追這個 Bug，後來發現問題是出在後端 API 的邏輯，或者資料庫髒了，或是甚至業主他自己根本就搞錯 Spec…等等非前端的問題，當然這個問題沒有你的責任，可是你花時間去查這個問題也是不爭的事實。
研究功能可行性
有時候業主想要做一些冷門的功能，這些功能的可行性需要做評估，又或者你需要做一些小研究、小實驗來確保接下來專案執行的方向，你花時間去研究也是有付出你的時間和努力。
日常的即時通訊溝通
現在即時通訊軟體非常多元且方便，對於溝通來說是一大利器，但同時也是兇器，很有可能對方一直不斷地透過通訊軟體跟你溝通、聊天、詢問，你必須要花心思來回答他的問題，當然，也需要花時間。
上述這些都消耗了大量時間，卻不容易被計入工時。如果忽視這些隱性時間成本，你可能會發現雖然工作了8小時，但只有2小時能算工時，這樣就會虧大了。
時薪計價避免吃虧的策略
為了解決上述這些問題，我們必須要擬定一些策略，以下是你可能可以嘗試的幾個方向：
在簽約前與業主溝通工時範疇
你可以先在簽約前，跟業主溝通好這個觀念，上述這些部分也要包含進去合約裡面，也就是工時不限於實作工程所花費的時間，開會、對功能估時、提供建議以及即時通訊上的討論，也需要計算工時。
採取分纇計價策略
若業主有成本考量覺得很為難，那退一步，可以考慮在非實作的工時採用另外一個價格計算，例如實作的工時開600/hr，其他的工時開400/hr。有機會透過這種方式來說服對方。
設定會議次數及時間限制
如果還是有困難，我們可以先跟業主溝通要限制開會次數和時間，這樣至少你在工時上面的損失不會那麼多。
在估工時時納入所有時間成本
如果上述都有困難，最後一個策略，你在估工時的時候，不能只估算實作時間，也要把上述的時間成本算進去
工時報高不代表一定賺得到錢，反之亦然
正如之前所說，報高工時不代表一定能賺更多，同樣，報低工時也不一定賺不到錢。
例如，請你做一個任務，你估 1.5 小時和估 1 小時，業主通常不會有太大區別（多報時間並非故意灌水，而是隱藏成本沒算進去）。但如果時薪高，業主會對你報的工時更敏感，容易跟你斤斤計較。
那我們來計算看看：
例如，1.5 小時 x 600 元 = 900 元，1 小時 x 800 元 = 800 元。同樣完成任務，報 600 元時薪不一定會虧錢(以結果來看)。
小節
低時薪有時能讓業主接受更多的時間，因此，我們不必過於執著於時薪，而是可以根據不同情況調整計算工時的策略，避免吃虧。
關於專案計價
接下來我們來講專案計價。根據專案的總體需求、預估工時、製作條件等因素，給出固定的報價，通常不以時間為單位，而是根據專案的範圍與要求來設定。
在這一類的專案中，通常業主會先給出大致的需求，讓你估算工時和報價。但對於模糊的需求進行估價，風險很高，因為你無法確定是否有忽略某些部分，或者業主的期望是否與你的理解一致。經驗顯示，這樣的誤差常常發生。
因此，在不明確的情況下給出報價容易吃虧。
反過來說，若能夠將需求具體化，風險會降低，因此花時間與業主溝通並釐清需求是非常重要的。
但是，「花時間」這一點來說，對我們而言就是在付出無形的成本。畢竟時間就是金錢，我們不想要付出沒有報酬的時間。
舉例：跟業主開三次會、回家整理需求兩次，花的時間值多少錢？
舉一個自己過去做得不好的例子：
有一天，有一個企業委託我們做他們的內部系統，流程是這樣的：
第一次會議
首先第一次跟業主直接碰面，這也是很合理的，畢竟見面三分情。主要是瞭解一下業主詳細的需求、業務情境，做紀錄。業主也希望我們給他一個估價，因此我們回家詳細規劃之後再回覆他。
第一次回家整理
開完會之後，回家規劃一下，包含需要的頁面、功能、每一個頁面需要多少 API…等等。當然，這個過程如果是小團隊接案，也要約團隊會議討論。
第二次會議
第二次會議核對一下規劃後的結果，業主一開始會感謝你為他做的規劃，但他會告訴你哪些地方跟他想的不同，或是臨時他又想要加什麼功能，因此你在你的規格書上面註記哪些部分要改。
第二次回家整理
然後你再回家把它會議上講的調整一下，過程中也是很有可能團隊內部需要再開個會，然後估出一個價格、報價單。
第三次會議
第三次會議跟對方說明你的報價單，業主很開心，說回去內部討論一下，或是說要回去跟老闆報告，請老闆批准。
一週後回覆
過了一個禮拜，業主跟你說他想要請別人做，謝謝你這次的付出。
所以以上述例子來說，你總共開了三次會，然後花時間回家規劃兩次，前前後後，短的話你花了一兩週，慘的話可能花了兩三週甚至更多時間，最後的結果就是你幫別人規劃做白工，然後什麼都沒得到。
上面的狀況可能還算幸運，因為有可能對方一直約你開會跟你更新需求，一下子想到這個，一下子想到那個。然後你又一直基於「需求不清楚不進行估價原則」而一直跟他來回，時間就會拖得越長。
自我檢討、擬定策略、減少自己風險
當然，談生意本來就是有成功、有失敗，很難保證每次你付出時間就一定會得到些什麼，所以我們必須要擬定一些策略，來降低自己的風險。
所以根據上述，我們的策略方向可能有：
- 想辦法減少時間的投入
- 想辦法讓所付出的都能得到回報
因此，如果希望「付出的時間盡量都能夠獲得回報」的這一個方向，你可以考慮收取估價費、顧問費。
另一個方向「想辦法減少時間的投入」，我們可以事先訂一個常見方案的定價設略，以企業官網來說(這個比較好舉例)，你可以訂好固定的規格，例如：可以制訂經濟方案、一頁式方案、半客製化方案、全客製化方案，每種不同方案包含哪一些項目。因為你的定價公式已經很確定，所以你可以在最短的時間內估出一個讓自己不會吃虧的價格，所以在前面的案例當中，我們就可以節省開會時間和溝通來回的成本。
策略適用情境
但上面這兩個策略也有他適用的情境。假設業主的需求是希望你幫忙做一個 3~5 萬元的網站，他可能不會想要花個五千元或一萬元請你估價，但如果業主是希望做一個 60 萬的內部系統，對他而言花個五千或一萬元請人估價，也感覺比較能夠接受。估完價可以提供他規格書、介面線圖 wireframe，讓他不會覺得好像付了一筆錢但沒有拿到東西回來，好像白白買了一個空氣。
對我們來說也是一樣的，3~5 萬元的網站，你在估工時和估價應該不會花太多時間，因此你也不會損失太多。
但要做到金額很高的系統，複雜度相對一定會比較高，因此也會比較有收取估價費的必要。
小節
提供這些策略給大家做參考，但其實方法不限於上述，大家可以按照自己的情況來思考和調整。
接案中的隱形殺手：需求變更
對於需求變更的議題，我相信是每一個接案人心中的痛。舉幾個最近遇到的例子。
案例一：滑鼠樣式變更
有一次接企業官網的案子，進行到一半時，業主問設計師：「客製滑鼠樣式會很難嗎？我想要有企業特色的滑鼠。」
這對我們設計師來說當然不難，當下沒有想太多就回答：「當然不難。」想説做個好人，於是免費花時間設計了一個滑鼠樣式，還實際實現到網站上。業主一開始看到很開心，但一兩天後卻說：「用起來不太習慣，還是改回去吧。」設計師瞬間無言，白忙了一場然後一毛錢都沒賺到。
案例二：文字對齊樣式變更
另外一個例子，企業官網上有一個三欄式的文字，置左對齊「text-align: left;」，業主看一看，覺得這樣文字欄位的右側不太整齊，所以要求要左右對齊「text-align: justify;」，但在改之前有先提醒業主，會因此造成文字中間的間隔不一致(因為這個網站有中英文多語系，特別是在英文的時候)，業主說沒關係，你就幫我做。
做完之後，業主發現真的如我們所說的，會有間隔太大的問題，特別是三欄式中間那一欄的文字特別明顯。
所以他又提了一個要求，希望左右兩欄左右對齊，中間那一欄置左對齊。
不過可想而知這樣會造成對齊不一致，有些對齊左邊，有些左右對齊，所以改完之後他又不滿意，所以最後的結果又全部調回去置左對齊。
自我檢討、造成原因
那經歷過這件事情，當然我們就覺得這樣的流程很不好。
因為我們在這件事情上面跟他來回很多次，但是最後又改回來。這中間所付出的時間，都沒有辦法轉換成報酬。
雖然改動這些部分並不是很難，但過程中很多這種事情的時候，就會做到心很累。
所以我就開始反省這件事情造成的原因，和如何改善。我認為造成的原因：
- 業主提出需求變更時，不需要付出代價
- 我們一時心軟，造成惡性循環
- 我們未設定需求變更流程
需求變更流程
為了解決上述問題，我重新檢討了接案流程，並新增了「需求變更流程」。
這個流程的重點在於，當業主在專案進行中提出任何需求變更或功能新增時，就算再小的事情，也要提供一份需求變更報價單。透過這個動作，可以清楚地讓對方了解，這是需要額外付費的正式事項。
當業主確認後，需簽名並完成付款，然後才開始執行新的需求。
另一種處理方式是，對需求變更或功能新增先提出報價單，但等到該專案執行完畢、驗收完成並收取尾款後，再將這些變更事項另立新案處理。
導入需求變更流程的前後比較
有沒有導入「需求變更流程」前後的差異是很大的。
他可以改變業主面對這個專案的心態，從隨便、浪費資源，轉換成嚴謹面對，仔細評估。
對於接案者而言，原本要做的事情沒有改變，但因為流程改變了，所以我們面對起來心情也會輕鬆許多。
痛苦的事情，也會轉變成開心的事情。
總結與反思
接案過程中的挑戰，遠遠不止今天提到的這些主題，這些鬼故事不勝枚舉。
但是我覺得重點是，當我們遇到這些垃圾事、鬼故事的時候，我們帶著怎麼樣的心態和想法來面對他呢？
我們是一直讓他成為鬼故事，寫進死亡筆記本裡面，之後可以常常跟人家閒話家常、茶餘飯後。還是這些鬼故事能夠幫助我們反省自己，成為我們成長中的養分？
端看我們怎麼思考、怎麼選擇，會決定我們接下來的路要怎麼走、好不好走。
想法會決定行動，行動會決定命運
希望今天的分享，能夠帶給大家一些不同的想法，能讓大家有所收穫，謝謝。
工商時間
感謝今年有機會受邀成為 2024 WebConf 的講者。
關注過我的人可能知道我過去參加鐵人賽有過幾次出書的經驗。這次 WebConf 的題目公告在 FB 之後，就再次引起了博碩出版社的注意和興趣，他認為這個題目很不錯，很適合出書。
因此，在這次演講之後，我將會開始準備寫一本關於「接案」主題的書。題目還待定，但主要內容是一本接案的指南，內容一定會比今天的演講更詳細、更完整、更乾貨滿滿、更精彩。歡迎對接案有興趣的朋友、和正在接案的朋友關注和交流。
如果對這本書有任何期待和想法，非常歡迎大家直接 Email 給我，或是丟我私訊，我很期待收到大家的期待和回饋！真的！
目前這本書的進度是，已經寫好新書規劃，出版社那邊提案也過了，然後也已經簽訂合約完畢。出版社跟我押的日期是六月底前要完稿，九月底前會出版。所以明年對我而言也是非常令人期待和刺激的一年。
另外，如果有需要外包案子，或有案子要介紹、找合作，也非常歡迎跟我聯絡～～
幕後花絮
