網站外包最怕做到一半沒人接？六個能事前確認的風險點

文章導讀

網站上線兩年，行銷想改首頁的一段介紹、修一個收不到信的表單。這時才發現，當初那位工程師已經聯絡不上，也沒有人說得清網站是怎麼組起來的。這是網站外包最常見的狀況之一。沒有人被騙，網站也順利做完、順利上線，卡住的是之後的事。

這篇不談怎麼挑便宜的廠商，只拆一件更實際的事：什麼樣的合作結構，會讓網站在中途卡住。還沒簽約的洽談階段，就有六個面向看得出來。你不需要懂程式，只要聽得出對方的回答站不站得住腳。

網站外包「沒人接」，多半是單點斷了

先講清楚一件事：網站外包做到一半停擺，絕大多數跟惡意無關，是結構造成的。接案的人生病、換工作、接了更大的案子，這些都不是誰的錯。只是專案的知識與執行都集中在他身上，他一離線，你們的網站就跟著離線。

這類情況有個共通點：網站能不能繼續往前，取決於一個特定的人在不在。跟你們付了多少錢、合約寫了什麼，沒有太大關係。合約可以規範賠償，但換不回時間。

三種最常見的斷點

• 建置期斷在中途

  版型做了一半、功能還沒串完，檔案散在對方的電腦裡。專案能不能再動起來，要看完成到哪裡、用的架構常不常見。完成度愈低、做法愈冷門，代價就愈高，有時光是摸清現況，花的時間就比重做還久。

• 上線後失聯

  網站還在跑，看起來沒事，但沒有人在更新、沒有人在備份，也沒有人在看有沒有異常。這種「活著但沒人管」的狀態可以維持很久，直到某個到期日到了才爆出來。可能是網域到期、主機方案到期、憑證過期，或是系統版本落後太多，一更新就壞。

• 窗口換人，知識沒有留下來

  廠商還在，也願意服務，但原本負責的人離職了，新來的同事對這個網站一無所知。同樣一個需求，你會發現講第二次比講第一次還費力。

風險點一：承接的是一個團隊還是一個人

個人接案和團隊承接，差在工作停下來時，還有沒有第二個人能繼續。誰的技術比較好，倒在其次。這一點對交易型或會員型網站影響最大；純形象網站的重點，在後面談的資產歸屬與收尾。個人接案也有它的優點：溝通直接、彈性高，報價通常也比較低。

這類網站的工作是連續的。工作一旦中斷，重新動手之前，都得先重建對現況的理解。這段成本，不會因為中斷得短就等比例縮小。

• 常見誤解

  公司規模大，就等於接得住

  看到有辦公室、有官網、有作品集就放心了。但實際執行的，可能仍是外包出去的自由工作者，公司只是中間的接單方。

• 實際情況

  關鍵在專案內部有沒有分工

  值得留意的，是這個專案裡的企劃、設計、前端與系統維運，是不是由不同的人在做。有分工，知識本來就分散在幾個人身上，不會集中在一顆腦袋裡。

報價單也看得出端倪。分工明確的團隊，報價會依階段拆開；一個人全包的案子，通常是一個總價、一段描述。總價報法本身沒有問題，只是你看不出中間有幾個人參與。可以參考網站專案的合作流程，對照你手上的報價落在哪個環節。

風險點二：這個網站的來龍去脈有沒有被記下來

一個網站最難說清楚的，是決策。這個功能為什麼這樣做？當初為什麼選這個外掛？某個頁面為什麼有例外處理？這些答案只要還留在某個人的記憶裡，就是專案最脆弱的地方。

這裡要分兩層看。你們公司內部要接得上的是營運面：誰負責上稿、內容更新的流程怎麼走、後台操作怎麼教給下一個人。這一層在人員異動時最容易斷掉，也是公司自己要留紀錄的部分。

技術面是另一層：網站用了哪些主要元件與版本、哪些地方做了特別處理、環境設定的變更歷程。這些屬於維運層的專業工作，由維護團隊持續保管與更新。你們公司不需要自己掌握，需要知道的是有沒有人在管。

怎麼在洽談時判斷

有沒有留紀錄的習慣，洽談時就聽得出來。有這個習慣的團隊，談起過去的專案，說得出當時的技術取捨與理由。只講「做得很漂亮」的，通常沒有這個習慣。談到上線之後，他們說得出維護怎麼安排、由哪一組人持續負責。你臨時提出一個修改，他們也說得清楚會動到哪些地方、有沒有連帶影響。

風險點三：出狀況時，誰回應、排在第幾順位

先給答案：出狀況時要先講清楚的，是誰會回應、這件事排在第幾順位。修好要多久，取決於問題本身；怎麼排順位，則可以事先談好。

網站的故障有等級之分，混在一起談就會失焦。整站打不開、結帳流程中斷、表單收不到資料，屬於營運停擺，通常排在所有工作的最前面。頁面樣式跑掉、圖片顯示異常，難看但不影響交易，一般會併入既有的維護排程。我們接到異常回報時，第一步也是先判斷它屬於哪一級，再決定和手上其他工作怎麼排。

狀況等級	典型情形	常見的處理順位	沒有先分級會怎樣
營運停擺	網站打不開、無法結帳、表單失效	最高順位，與其他需求分開排	雙方對「急」的認知不同
功能異常	某個區塊失效、資料顯示錯誤	排在營運停擺之後	被無限期往後排
外觀瑕疵	版面跑位、圖片比例不對	隨下一次維護排程一起處理	累積成一長串沒人處理的小問題
新增需求	加頁面、加功能、改版	不併入維護，另行評估	與維護混為一談，雙方認知落差

等級先分開，雙方對「急」的定義才會一致。實際的處理節奏依合作內容事前談定，不必套用通用的數字。

另一個容易被忽略的，是唯一負責的那個人休假時怎麼辦。備援人力的意思，是這個網站的現況不只存在一個人的記憶裡，用不著一整排人待命。團隊內部換手時，接的人看得到它長什麼樣子、上次動過什麼。

風險點四：網域與各項服務的歸屬清不清楚

看歸屬，重點是每一項服務都找得到負責的人，鑰匙在誰手上多，說明不了什麼。網域是公司資產。內容與資料也屬於公司，需要時以通用格式匯出提供（各層的關係見網站的組成與名詞白話對照）。主機與系統環境，則需要有人統一維運。三者的性質本來就不同。

其中最該堅持的是網域。用了幾年之後，名片、發票、廣告投放與搜尋索引都綁在上面，換掉的代價很高。網域和商標、公司名稱不同：它是向註冊商年繳承租、先到先得，到期沒續約就會釋出。所以，理應以公司名義註冊。這一點在業界少有爭議。一開始講明登記在公司名下，續約追蹤與解析設定交給維護團隊執行就好。

主機與系統環境需要的是即時處置的能力：更新要排、備份要跑、憑證會到期、遇到異常流量要當下處理。這一層由維護團隊統一管理，是為了讓應變不被卡住，權限分散往往正是拖慢處置的原因。你們公司內部保有營運需要的操作介面，發文章、上架商品這些日常工作照常進行。頁面編排與系統層的調整，則由維護團隊統一執行。

項目	性質	日常由誰處理
網域	公司資產，以公司名義註冊	維護團隊協助續約追蹤與解析設定
網站內容與資料	公司所有	公司自行編輯與上稿
主機與系統環境	維護層，由維護團隊統一維運	備份、更新、資安與效能處置
金流與發票服務	依法以公司統編申請	維護團隊負責串接、對帳異常與規格更新

四種項目的性質不同，日常處理的人也不同。心裡有這個輪廓，遇到問題就知道該找誰。

想看這樣的分工實際運作的樣子，可以看看網站作品實例。也可以先讀我們寫過的官網維護需要哪些角色，更容易理解每一層對應的是誰的工作。

風險點五：網站用的技術，還有沒有人在維護

技術選型是網站外包裡最容易被跳過的一項。它對你們的實際影響，只有一句話：這個網站要長期活下去時，它所依賴的技術是不是還有人在維護、也還在持續更新。

用常見的內容管理系統與主流架構做出來的網站，背後有大量開發者持續更新、修補漏洞。熟悉它的人也多，團隊內部換手時容易銜接。反過來，整個網站若是某個人自己寫的框架，或用了很冷門的工具，就得看作者還更不更新。作者一停手，安全修補與相容性就沒人跟上。說明留得再詳細，也補不回這一段。

幾個判斷的角度

• 先弄清楚網站是用什麼做的

  你不需要懂技術細節，只需要一個明確的名稱。底層是哪一套成熟的內容管理系統或框架？在它之上，又做了哪些延伸與整合？說得出這兩層的團隊，通常也清楚自己長期在維護什麼。

• 再聽這個選擇的理由

  好的理由會連回你們的需求：要自己上稿、之後要加會員、商品數量會成長。只回一句「我們都用這個」，你就聽不出它跟你們的需求有什麼關係。

• 看它跟既有工具搭不搭

  如果公司已經在用某套金流、會員系統或進銷存，選型要能對得上，不然之後每一次串接，都得另外客製。

• 看客製的部分佔多少

  完全不客製會綁手綁腳；全部客製，所有的更新與修補都得從頭處理，沒有成熟方案的社群可以分擔。合理的做法是主體用成熟方案，只在必要的地方客製。

如果你們的需求本來就偏客製，例如串接既有系統或做特殊流程，客製就是必要的。重點在客製的範圍要清楚，和成熟方案的主體分開，並記在維護團隊持續保管與更新的內部維運紀錄裡。可以參考客製化功能案例，看看哪些屬於合理的客製範圍。

風險點六：合作結束時，收尾是怎麼進行的

沒有人喜歡在開始合作時談結束，但這一點最能看出對方的體質。願意一開始就把收尾方式講清楚的一方，通常也是平常做事有紀錄的一方。

收尾容易變成爭議，多半是雙方對「網站是什麼」的認知一開始就不同，跟誰配不配合關係不大。網站上的營運資料和網站的開發成果，在權利上是兩件事。這個區分先講清楚，收尾就只是例行確認，用不著談判。

• 常見誤解

  付了建置費用，整個網站就能原封不動搬走

  連同背後的功能模組與程式在內，都被假設為一併取得。這個認知通常要到合作結束時才被發現不成立，到時雙方都不好處理。

• 實際情況

  內容是公司的，開發成果通常是授權使用

  文章、圖片、商品與訂單、會員這些營運資料屬於公司，需要時會以通用格式匯出提供。為專案開發的功能模組與客製前端，多數情況屬於開發方的著作權，以授權方式供這個網站使用。

這是軟體產業的通用觀念。同一套元件會用在多個專案上，可重複使用正是它的價值。如果每次合作結束都一併移轉，這個模式就無法成立。公司如果確實需要完整取得這部分的權利，一般另以買斷計價，而且在合作開始前就談定，不會等到結束時才提。

• 營運資料（文章、圖片、商品與訂單、會員）屬於公司、以通用格式匯出提供，你們的合約有沒有寫到這一點？
• 客製開發的部分，合約寫的是授權使用還是買斷？要買斷的話，怎麼計價？
• 網域是不是以公司名義註冊，續約狀態你們公司自己查得到？

這也是判斷一段合作值不值得長期走下去的方式。對方在這個題目上顧左右而言他，通常代表他們自己也沒想清楚，這比價格差異更值得放進考量。

網站外包洽談時就看得出來的風險訊號

這六點用不著拿著清單一題一題問，多數訊號會在洽談過程中自己浮現。

• 回答問題的方式

  有經驗的一方，會主動指出你沒想到的風險，甚至會說「這個功能你們現階段用不到」。什麼都說沒問題的，通常還沒認真想過怎麼做。

• 報價的顆粒度

  階段、工項與後續維護分開列的報價，代表對方清楚自己要做哪些事，你也看得出錢花在哪裡。一句話一個總價，你無從判斷中間發生什麼。

• 談維護的態度

  把上線當成專案終點的，和一開始就把維護納入討論的，是兩種不同的合作模式。前者報價通常較低，但後面那一段要你們自己承擔。

最後提醒一個判斷順序：這六個風險點的權重，會隨網站型態改變。純形象網站的風險集中在資產歸屬與收尾；有交易或會員的網站，備援人力與處理順位會排到最前面。先確認自己屬於哪一類，再決定注意力放在哪幾點。如果不確定需求落在哪個量級，看看電商購物車案例與形象網站案例的差異，會比看規格表更有感覺。

我們怎麼讓一個網站長期接得住

談新網站時，參考的做法是先問一個跟技術無關的問題。上線之後，你們公司內部由誰負責上稿、誰回報營運上的狀況？營運面有人接得上，技術面才有固定的對口。

技術面這一段，我們用團隊分工承接。企劃、設計、工程與系統維運，各有負責的人。環境設定的變更，連同當時為什麼這樣設定，都會記進團隊持續保管與更新的內部維運紀錄。團隊內部換手時，接的人打開紀錄，就知道網站上次動過什麼。網域以你們公司名義註冊，日常上稿與營運由你們自己掌握。

服務範圍可以看網站架設與主機代管，我們負責的項目則列在服務項目。也可以直接把網站的型態與現況告訴我們。

常見問題