最近終於結束了一個搞了很久的 case 。
我其實沒什麼接案經驗，這次也是剛好算是學校單位找我做個活動的宣傳網站，我心想既然是學校的應該也不太容易被騙，就來試試看所謂的接案。
在這次經驗中其實也是學到不少東西、踩了很多雷，大部份都是因為沒什麼經驗導致踩到的很多很多算專案管理相關的雷。
如果還有下次的話，一定要注意一些事情才可以讓整個案子的進行更加順利。
一定要寫好合約
這看起來是基本中的基本，但我當初就是沒做(掩面
當初只有口頭說好而已。
這件事情之所以重要，是因為這是個最基本的保障，不論是對我們或是對客戶方，
和約可以說清楚講明白我們到底要做什麼?哪些是我們的負責範圍、哪些不是?
然後當然還有其他的細節，包含價格，時程等等都應該要寫在合約。
一定要訂好時程
在這次的案子中我遇到最大的問題就是：我們開發好了 ，但是客戶卻一直沒時間驗收，導致每次來回 feedback 就可能拖了好幾個月。
這樣造成很多問題一個是實在是拖太久了，隔好幾個月才又重起專案做起來真的很煩；另一方面客戶方也會覺得我們做得很慢。因為我們做出來的東西不一定是客戶想要的，一來一回修正就花掉太多時間，整體而言就會有我們也開發得很慢的感覺。
如果當初可以在合約中訂好幾次 check point 的時間點，至少就可以確保不會無限期拖延下去。
一定要找好對口
我這邊指得對口是指:「 可以快速獲得 feedback 的人」。
因為我們這一次的開發包含了所有的設計，都是我們負責。但是呢，扯到設計這種比較主觀的東西，我們做出來的並不一定客戶接受。所以與其等到 check point 再來被客戶打槍要求重做，不如當初就先確保一個客戶方的對口，才可以在我們做 prototype 時就迅速的確認到底是不是符合他們想要的。
簡單來說，確認對口就是可以使我們少做很多白工。
不要使用別人不熟悉的工具
這個點其實跟上一點有一點關係。案子開發到後期勢必是有一些 BUG 或其他要調整的部分。所以也是必須要追蹤這些 issue。
那當然大家都認為 github issue tracker 很好用很棒，但事實上客戶這邊根本不會使用這種工具，最後就會變成他們根本沒在看。
所以與其用我們工程師覺得好用的工具，不如使用大家都會用的工具。像是在這一次的案子裡我的 issue tracker 是簡單的用 Google sheet 拉一拉表格，這樣反而更能讓客戶清楚知道我們的進度。
即時通訊也是，工程師可能覺得 Slack 很棒很適合案子的溝通，但事實上就是客戶那邊永遠都不會上線 XD
所以反而使用私人的 Facebook Messanger 還比較有效率。
錢的事情要講清楚
有一件事情我體會深刻，就是「錢的事情一定要講清楚」。
也不要覺得自己的開價會不會太貴，因為會不會太貴是客戶那邊該煩惱的 XD
雖然每一個案子可能順利的程度不同，但是我個人認為接案一定會比想像中的麻煩。
所以在錢的方面一定要開一個確保自己不會做到覺得「很不划算」。
具體而言大概就是你覺得可以的價格再乘以 1.5 倍，到時候你會覺得這才只是「剛剛好的價格」。
另外，錢也是應該要有先付、後付的部分，才比較有點保障，至少不會一毛錢都拿不到的風險。
像我這一次的案子就因為也沒有寫合約所以最後變成是結案了才要付錢，那這樣子其實對於接案方非常虧，因為他們隨時可以突然說案子不要做了，然後我就會變成做一堆但啥都拿不到。
總而言之，錢的事情就幾個原則：
- 開一個比自己覺得 ok 的價格高一點的價格，因為接案的過程肯定會比想像中的麻煩。
- 先付後付、怎麼分配都應該於一開始的合約中訂好。
雜談
- 自從決定要弄個部落格以後，就一直督促自己一個月起碼要寫個一篇文章，自今也滿一年了，可喜可賀～
- 最近剛修正了身體的一個 BUG，看來要痛苦一陣子了。
- 正事依舊沒啥進展，果然我吃草吃太久了QQ