關於山葵組
2016 年成立於台北的客製化系統開發團隊。
ORIGIN
從幾個網頁案子開始
山葵組成立於 2016 年。最初只是手邊剛好有幾個網頁案子，便決定開一間公司來接。
客戶使用一段時間後，需求開始不只是「網站好看」：有的要看數據、有的要管理內部流程、有的需要 APP。服務範圍跟著這些需求一項一項擴展，逐漸成為一間專門做客製化系統的公司。
NAME
為什麼叫山葵組
常有客戶問起這個名字的由來，然後說很好記。
真實版本是：當年在想公司名字時，有人點了一份山葵口味的三明治。
官方版本是：希望帶給世界「哇賽」的感受。
HOW WE WORK
做事的原則
1
合理，比有利重要
合作條件如果對客戶不合理，即使對公司有利，也會調整。
一個實際發生過的例子：過去的報價把原始碼交付包在裡面。有客戶反映，多數情況根本用不到原始碼，只有在不得已要自行找人接手時才需要，詢問這筆費用能否不付。這個意見合理，於是原始碼費用從報價中獨立出來、寫進合約，需要時再付。
2
先做一版，再一起調整
系統在實際被使用之前，需求都是想像的。做法是先把討論好的需求做成一個可以操作的版本，實際用過之後再決定調整方向。需求會因此變得具體，時間與預算也花在真正需要的地方。
因此預算傾向多保留在「上線後的調整」階段，而不是一開始把所有想到的功能全部做完。就算判斷某個功能之後用不到，也不會為了先收費而把它做進去。
3
能用現成工具解決的，會直接說
收到的需求裡，有一部分用現成的 SaaS 或 Google 的免費工具就能解決。遇到這種情況，會直接建議改用那些工具，而不是硬做一套系統。
例如曾有客戶想做一個內部表單蒐集加簡單統計的系統。討論後建議先用 Google 表單加試算表，跑三個月看清楚真正的需求，再決定要不要開發。後來對方一直用得很好，沒有再回來。這是正常結果。
4
不接超過負荷的案子
同時進行的專案數量有上限，超過就不接——接了就做不穩。
若新需求與現有客戶屬於同一產業、性質相近，會先徵詢現有客戶的意見，再決定是否承接。
5
技術選擇的原則：不產生依賴
主要以 Laravel 與 Vue 開發。選擇的理由很直接：市場使用率高、穩定、找得到人。即使有一天山葵組不在了，系統仍能找到資源接手維護。
第三方服務的帳號登記在客戶名下，原始碼的交付與歸屬在合約中明確約定。系統是客戶的資產。
CLIENTS
橫跨很多產業，因為需求都長得不一樣
最早的客戶從公司成立初期合作至今。這些年合作過的產業包括：
- 律師事務所
- 補習班
- 幼兒園
- 蔬果批發
- 食材批發
- 直播 APP
- 公家單位
- 非營利組織
- 藝術產業
- 電信業
- 生技業
- 長照
- 五金批發
- 紡織業
產業差異很大，但需求的起點很相似：現有的工具或系統與既有流程對不上，需要一套照自己方式運作的系統。
FIT
適合與不適合的情況
適合找山葵組的情況
- 現有套裝軟體或 SaaS 已經撐不住既有流程，改不動也繞不過去
- 需要把多套系統的資料接起來，減少重複輸入
- 想先做一個核心版本上線驗證，再逐步擴充
- 希望系統上線後有人長期維護，而不是做完就消失
- 在意原始碼與帳號的歸屬
建議先考慮其他做法的情況
- 需求用現成 SaaS 或 Google 工具就能解決
- 需要在很短時間內一次完成大範圍的功能
- 希望先拿到一份總價報價再決定，而不打算先進行需求討論
不確定屬於哪一種的話，直接把狀況描述過來即可，會得到明確的建議。