如何接到案子 vs 如何順利結案

文章來源：網站程式的接案原則，作者：TonyQ

網站程式的接案原則，這個話題是延續至差不多一年前有人問我說出來接案該注意什麼事情，那時候我整理出來四點，我這次更新成六點也補註一些這段期間來的經驗談。這是有關「如何接到案子 vs 如何順利結案」的個人守則。

參與技術討論、適時分享自己的學習成果、良好的提問或回應。（目的：讓你的程度可以讓人「看得見」，不管程度優劣至少能有個參考。）積極的找有興趣、能做的案主洽談，並且拓展技術人脈，技術人之間有案子pass來去是很正常的。而且通常由認識的人介紹的案子比較容易談成。（只是不容易結案。）

瞭解自己的能力跟環境，是否能達到案子的需求。如果不行，要準備到符合案子所需的內容，時程是否會太趕，應該根據自己的信心程度有多少。

比方說之前我接yahoo widget，雖然我之前完全沒寫過 ，但是我對 js 跟xml的操作非常有信心，所以雖然是三天的急案 ， 還是接下來。又比方說某一次接一個 fuzzy 演算法的case，那次時程開兩個月，我判斷能找時間充實相關資料 ， 所以也是接了。

然後，當你一看就信心滿滿的跟自己說絕對沒問題的時候，記得要再複核一下，畢竟魔鬼藏在細節裡，特別是一開始草擬的ERD，很容易不小心漏東漏西的，實作時才在更新欄位（暈）。也要從spec去小心看案主可能會臨時提出來的需求，預先在心裡做個準備，必要時先詢問案主這方面的需求。

ps.客戶要什麼就是什麼，不要有用手上模組拼樂高積木交差了事的想法，除非這個模組已經是為了這個客戶準備的。舉個例子，就算只是安裝 joomla 這類CMS模組，各使用者通常都還有需客製化 (logo/自製功能...etc)的地方，過去的模組通常不是拿了就可以直接用，鐵定還是會需要調整的。

很多案子我們都知道可能會有後續，但是不管後續的商機多大，眼前的案子自己能做的下來，吃得下來才是真的。因為只要中間一個環節你讓客戶印象不好，就沒有所謂後面的case了。很多客戶也會用以後繼續合作的理由來壓低價格，但是還是不要幹這種殺雞取卵的事情比較好。

同樣的，如果合作之後覺得客戶很難合作，也要做好隨時抽身的準備。（要走的順利就是盡量把技術文件準備好交接出去，免得落得只有你知道系統結構，客戶要求交接就把你整個半死。）

其實在這裡談到價格是非常敏感的，因為一個接案方一個發案方，一個想要低價一個想要高價，寫偏袒哪一方都是很容易引起紛爭的，寫高價好，就是得罪發案方，寫低價好，就是得罪接案方。不過我這裡談得不是要開多少價，而是怎麼開價。

我認為最重要的事情，開價的準則不能看心情開，自己要有個依據。通常我自己的作法是按照資料庫複雜度、控制介面的複雜度，從這去寫功能列表，在心中草擬整個case 的結構，整個起來大概對每個功能的細項有概念之後，再參考案主的預算跟可以觀察的資料，來用自己覺得的難易度跟報酬來計價、報價。（不過每個人的作法都不同啦～只是重點是自己要有個計算公式。）

通常我自己不會開超過案主的預算，除非案主有額外增加項目，如果我估起來之後完全就超過案主的預算，那除非案主主動諮詢，不然我不會去報價。理由很簡單，既然案主對價格已經有先入為主的成見，基本上你身為一個要賺他錢的人，還把價錢往上抬，先天就會先有負面印象，萬一到時候case有溝通上的問題，不歡而散的機率不小。

另外案主的需求，還需以自己能估計的延伸需求來做雙重參考，因為一方面案主可能是善變、善忘、需要「共體時艱」的，另一方面則是案主可能在規劃時無法做專業的細節規劃，像是表單有些案主可能就會認為表單驗證就該包含在表單裡面，有些則否。

這些延伸需求，使用者看得到的項目應該是明列給案主討論，一些隱性的需求（ex.正規化層級）或預留的擴充空間，甚至是程式碼註解，則是視案主預算跟合作態度增減。（哪些項目需要討論、解釋，哪些不用這很難拿捏，基本上案主花錢就是要你處理問題，有些過於技術的問題，還是應該要用自己的專業來協助判斷。）

總之，你開了這個價格，就要找能對這個感到價格有物超所值的案主再接。不要讓案主很勉強接受你這個價格，這樣你驗收可能會很難過，也不要讓自己很勉強接受案主的價格，這樣你會開發的很難過。盡量一開始斡旋時可以讓雙方的認知在比較一致的區間。

基本上可以的話最好瞭解一下案主的經費來源跟案主的類型，來判斷案主對預算的接受程度，根據經驗，公司行號外包的價格通常比較活。

若原為自己職務內容，但因種種理由轉介外包的價格通常比較死。（要看案主處理的態度，這種往往會有兩層以上的案主，驗收跟spec很容易出問題。舉個例子，我曾經碰過一個廠商轉包，請我做了東西之後，他們又要拿去讓他們某國的客戶點頭才願意付錢，（做完了才講...）於是就一直修一直改，那時候拖半年最後還是沒有搞好。-_-;不過這個例子主要是當時沒有簽約跟明定spec才會這麼棘手。）

學生的案子，價格通常也是沒得商量，但是學生的預算空間起伏大，有那種五百塊就想叫你寫GUI還包山包海的，也有幾千塊只希望你幫他搞定db connection string的，很難說。

如果是有點子，希望能找技術人員實作的創業家案子，視專案的不同期間有不同的預算空間，剛起步的通常很有錢，中期的普普，後期的可能就很摳。XD這也有例外啦，不過通常例外都不太會找外包，而是自己養人了。

千萬不要delay！原則上要把時程切分為三個階段跟一個可能的delay階段。

第一個是談，談妥spec後先進行初步的沙盤推演，有問題就繼續談，沒問題就開始簽約做案子。（談的時間跟案主希望做完的時間成反比，也就是案主希望越快做完的，就要談越久以確保全盤瞭解。

第二個是做，這階段你應該要定期跟案主對談，讓案主能夠瞭解你的進度，一方面是讓案主有參與感，二方面是進行各項功能可能的再確認，最重要的是把碰到的困難跟解決方案或者自己的意見提給案主，萬一時程真的有狀況，也比較好處理。盡量不要到要結案的時候才聯絡案主，不然驗收通常會拖很久，甚至是直接 delay 到。

第三個是驗，這個階段把握要則就是沒收到錢不給東西，不一定要收到全部的錢，但是至少要收到一定比例的案金。驗收的時候，如果有發現已知有功能有bug的就先不要讓案主測，直接跟案主告知，如果已知的BUG盡量不要讓案主自己測到 ，寧可自己先跟他說有bug ，以免造成不必要的誤會、誤解。如果到這個階段，但程式還沒做完，還是要驗！要讓案主瞭解目前的進度跟碰到的困難，以利進入後續的delay協商。

如果你不幸delay，那很不幸的，這個案子基本上已經砸一半了。基本上delay時，之前不管過程中間你答應幫忙額外多做什麼功能，只要不在原始簽約時協議好的，請先統統跳票。

理由很簡單，那些額外的功能會因為你delay 有額外的時間，而延伸出額外的發展空間（而且通常不會給錢），所以寧可先結掉眼前的案子拿到錢，再額外幫他做那些東西，也不適合先做完那些東西再結案。在案主的心態裡，如果你沒把眼前的案子給結掉，那你現在做的就都不是所謂的多做，而是你本就應該要幫案主做完的。但是如果你結案再回頭做，這兩種情境的心態就會不太一樣。

還有一個很顯而易見的理由，你的 delay 很有可能是這些額外的需求造成的。通常時程只要delay ，一方面鐵定會打壞一部分印象，另外會給案主不知何時能確實結案的感覺。（等同於案子無限期延期）

如果案主自己有時間壓力那就還好，他會比你還趕著結案。如果案主沒有時間壓力，那這時候根據經驗就是苦痛的開始。只要一有delay的現象，請認真評估自己是不是做的完，有時候會因為真的做不到而 delay ，而且通常接案方心理上會拒絕接受這個事實。orz

如果你認為是做不到時請毅然斷尾求生，違約如果有罰則的就認賠，沒有罰則的就明白跟案主說明清楚，自己這個案子做的就當白做，有收的訂金就退還。至於已經做好的東西要不要給案主就看個人良心。有時候案主也會同意你用比較差的東西來結案，不過更多的時候是會抓著你希望你做完啦。（這種時候如果做不到我是覺得就直接拒絕吧，已經花時間去做的東西還做不到，做更久也不會有好發展。）

再怎麼樣，我是覺得不要變成拿了錢又給不出東西就跑路，這種情況其實對你自己或發案方都是很大的折磨。反正碰到delay就要儘快結案，而且要讓案主感覺到你有結案的壓力，如果碰到覺得案子逾期沒什麼大不了的案主，請千萬記得他逾期他晚付錢還賺利息，你逾期你等於多上了個拿不到錢的死會，還不知道要繳多久。XD

自己做出去的東西，三不五時就去看看，跟案主聊聊看原本的系統有什麼不滿意的地方，如果是系統 bug 當然要幫忙修（提昇滿意度），如果是介面、資料的改善、維護，則可以考慮提新的維護需求或維護案。

這篇設定的瀏覽者是給接案方，如果您是發案方而文中有得罪之處還請見諒。如果文中您有任何不認同的地方歡迎直接討論、指正，這是我作到現在的一些感想，我也很想多看看大家的意見。 XD

描述、例子多，文字可能有點冗長，還請見諒，因為是臨時起意打的，可能有些部份沒有很周全，有興趣就再討論再研究囉:)有些很複雜的領域（ex.如何交付、驗收內容比較好，合約內容等），我的心得可能就不太適合給所有人參考，或許也可以一起討論看看～