Updated: 2026-02-03
Release on:2/3/2026

table of content

---

網站架設流程與專案管理

架設一個網站從來不是一件簡單的事情。許多人低估了網站建置的複雜性，認為只需要購買網域、租用主機、選擇一套現成的系統，然後把內容放上去就完成了。現實中，這種過於簡化的觀點往往導致專案延期、預算超支、最終成果與預期相去甚遠。一個成功的網站建置專案需要系統性的規劃、專業的執行和有效的管理，這正是本課程要探討的核心內容。

無論你是要建立一個簡單的個人品牌官網，還是要開發一個複雜的電子商務平台，網站架設的基本流程和專案管理原則都是通用的。差別在於規模的大小、複雜程度的高低、以及投入資源的多寡。本課程將從專案啟動開始，逐步帶你了解網站建置的完整生命週期，包括需求分析、規劃設計、開發測試、部署上線和後續維護等各個階段。我們也會深入討論專案管理的各種方法論和實務技巧，幫助你提升專案成功的機率。

值得強調的是，網站架設不僅僅是技術工作，更是一個涉及策略思維、設計判斷、資源協調、風險管理的綜合性專案。許多技術能力很強的開發者因為缺乏專案管理經驗，最終無法準時交付符合客戶需求的產品；而許多行銷人員因為不了解技術限制，制定了無法實現的創意方案。只有兼具技術理解和專案管理能力的人，才能成功駕馭網站建置專案的複雜性。

table of content

---

網站專案的啟動階段

專案目標的定義與確認

任何專案的失敗，往往可以追溯到專案啟動階段的目標不清或定義不當。在開始動手之前，必須先回答一個根本性的問題：這個網站專案究竟要達成什麼目標？這個問題看似簡單，但在實際專案中，因為目標模糊而導致專案範圍不斷擴大、最終偏離初衷的情況非常常見。

定義專案目標需要從多個維度來思考。首先是商業目標，你希望這個網站為你的業務帶來什麼？是增加品牌曝光、獲取潛在客戶、直接產生銷售、還是提供客戶服務？不同的商業目標會導向不同的網站設計和功能優先級。其次是用户目標，你的目標用戶是誰？他們使用網站的目的是什麼？他們期望獲得什麼樣的體驗？理解用戶需求是網站成功的關鍵。第三是技術目標，你的網站需要什麼樣的功能？需要整合哪些外部系統？對效能和安全性有什麼要求？

將這些目標具體化、可衡量化，是專案啟動階段的重要工作。避免使用模糊的目標描述，如「提升品牌形象」或「增加網站流量」。相反，應該設定具體的指標，例如「在網站上線後六個月內，將品牌關鍵字的搜尋量提升百分之三十」或「上線後第一個月，達成一千筆線上訂單」。有了可衡量的目標，後續的專案規劃和成效評估才有依據。

專案目標定義完成後，應該形成一份正式的專案概述文件，清楚記錄專案的目的、範圍、主要交付物、成功標準等基本資訊。這份文件需要所有關鍵利害關係人的確認，作為後續專案執行的參照基準。當專案進行過程中出現意見分歧或範圍爭議時，這份文件就是解決問題的依據。

利害關係人的識別與期望管理

網站專案通常涉及多個利害關係人，他們各自有不同的利益訴求和期望。有效識別這些利害關係人並管理他們的期望，是專案成功的重要因素。

利害關係人可能包括：專案的發起人或業主，他們通常是專案的投資者和最終受益者；業務部門，他們負責定義網站的業務需求和使用場景；行銷部門，他們關注網站的推廣效果和用戶獲取；技術部門，他們負責網站的技術實現和後續維護；外部合作夥伴，如設計公司、開發商、系統整合商等；以及最終用戶，他們是網站服務的對象，其體驗是網站成功與否的最終判準。

每個利害關係人對專案可能有不同的期望和優先考量。例如，業務部門可能希望盡快上線以趕上促銷檔期；技術部門可能傾向於選擇更穩妥但耗時較長的技術方案；行銷部門可能希望在網站中加入更多便於推廣的功能。當這些期望相互衝突時，專案經理需要進行協調，尋求平衡點。

期望管理的一個核心原則是「降低期望，提高交付」。不是說要讓利害關係人失望，而是要在一開始就設定合理的期望，避免過度承諾導致最後無法兌現。定期與利害關係人溝通專案進度，及時告知可能影響預期成果的風險和問題，也是期望管理的重要部分。當專案出現無法按原計劃執行的情況時，早點溝通比瞞著不說要好，因為利害關係人還有時間和機會來調整他們的計劃。

專案範圍的界定與文件化

專案範圍是指專案需要交付的所有工作及其邊界。清晰的專案範圍界定是防止「範圍蔓延」的關鍵。範圍蔓延是指在專案執行過程中，專案範圍不斷擴大，但相應的時間和預算卻沒有增加，最終導致專案無法按時、按質、按預算完成。

界定專案範圍時，首先要明確什麼是「在範圍內」，什麼是「在範圍外」。例如，一個企業官網專案的範圍可能包括首頁、關於我們、產品介紹、聯絡表單等頁面，以及響應式設計、SEO 基礎優化、管理後台等功能；但可能不包括多語言版本、電子商務功能、會員系統等，這些可能作為第二階段的擴充項目。

功能清單是界定專案範圍的常用工具。這份清單應該詳細列出所有需要開發的功能，並對每個功能進行優先級排序。高優先級的功能是必須在第一版實現的，低優先級的功能可以留待後續版本再加入。優先級排序也有助於在專案後期時間或預算不足時進行取捨。

範圍說明書是專案範圍的正式文件，應該包含：專案目標和背景的簡要說明、主要交付物的描述、專案邊界的說明（明確哪些不在範圍內）、驗收標準（如何判斷交付物是否符合要求）、假設條件和限制因素。這份文件需要獲得專案發起人和主要利害關係人的簽署確認，作為後續專案執行的正式依據。

table of content

---

需求分析與規劃

功能需求的收集與整理

需求分析是網站專案中極其重要但經常被低估的階段。許多專案的失敗並非技術能力不足，而是因為對需求的理解有偏差，導致做出來的產品不是客戶真正需要的。投入足夠的時間和精力在需求收集和分析上，是避免這種情況的關鍵。

收集需求的方法有多種，各有其適用情境。訪談是最直接的方法，通過與業務負責人、用戶代表等進行一對一或小組訪談，了解他們的需求和期望。訪談時要注意傾聽，不僅要聽他們說了什麼，還要理解他們真正想要解決的問題是什麼。觀察法是了解用戶實際行為的有效方式，通過觀察現有系統的使用情況或用戶的工作流程，可以發現用戶可能沒有明確說出的需求。問卷調查適合在需要收集大量用戶意見時使用，但設計問卷需要專業技巧，避免誘導性的問題。

需求收集上來後，需要進行整理和分類。常見的分類方式包括功能需求和非功能需求。功能需求描述系統應該做什麼，例如「用戶應該能夠在線下單購買商品」；非功能需求描述系統應該具備的品質屬性，例如「網站首頁載入時間應該在三秒以內」。另一種分類方式是按照業務領域或模組來組織需求，例如將需求分為會員管理、商品管理、訂單管理、支付配送等模組。

需求文件應該盡可能具體和明確。避免使用模糊的描述，如「系統應該反應快速」，而應該具體化為「系統頁面回應時間應該在兩秒以內」。對於複雜的功能需求，可以使用使用者故事的方式來描述，格式為「作為某種用戶，我希望達成某個目標，以便於獲得某種價值」。例如，「作為訪客，我希望能够通過電子郵件註冊會員，以便於保存我的購買記錄和偏好設定」。

技術方案的初步規劃

在了解功能需求的基礎上，需要規劃實現這些需求的技術方案。技術方案的選擇會影響專案的開發成本、開發週期、後續維護難度以及系統的可擴展性，是專案規劃的重要環節。

首先需要決定的是網站的技術架構。對於大多數網站專案，選擇成熟的 CMS 系統如 WordPress、結合適合的主題和擴充功能，可能是最快速且成本效益最高的方案。對於有特殊功能需求或需要高度客製化的專案，可能需要選擇更靈活的開發框架如 React、Vue 等前端框架配合 Node.js、Django、Laravel 等後端框架。選擇技術方案時，需要考慮團隊的技術能力、維護的便利性、以及未來擴展的可能性。

主機和託管方案的選擇也是技術規劃的重要部分。對於流量較小、功能需求標準的網站，共享主機或雲端主機商的標準方案可能就足夠了。對於流量較大或對效能要求較高的網站，可能需要考慮專屬伺服器或更高端的雲端託管方案。選擇主機時需要考慮的因素包括：效能和穩定性、擴展性、價格、安全性、支援服務等。對於重要的網站，主機的備援機制和災難復原能力也是需要評估的要點。

資料庫的選擇對於需要儲存大量資料的網站尤為重要。關聯式資料庫如 MySQL、PostgreSQL 適合需要複雜查詢和交易管理的場景；文件資料庫如 MongoDB 適合靈活的資料結構和非關聯式存取需求。在規劃時需要預估資料量和存取壓力，選擇能夠負荷的資料庫方案。

第三方服務的整合規劃也是技術方案的一部分。網站通常需要整合各種外部服務，如支付閘道（Stripe、PayPal、綠界科技等）、郵件發送服務（Mailgun、SendGrid 等）、分析工具（Google Analytics）、客服系統（Chatbot、在线客服等）、社群媒體整合等。規劃時需要列出所有需要整合的服務，了解各服務的技術規格和費用結構。

專案時程與資源規劃

在明確需求和技術方案後，就可以開始規劃專案的時程和所需資源。時程規劃需要考慮各個階段的工作內容、工作量估算、任務之間的依賴關係，以及可用的資源。

工作分解結構是時程規劃的起點。將整個專案分解為較大的工作階段（如需求分析、設計、開發、測試、上線），每個階段再細分為更具體的工作任務，直到任務顆粒度適合分配和追蹤。對於每個任務，需要估算所需的工作量，通常以人天或人時為單位。估算工作量需要考慮任務的複雜度、團隊成員的能力、以及可能遇到的風險因素。

任務之間往往存在依賴關係。例如，頁面設計需要等待需求分析完成後才能開始；前端開發需要等待設計稿完成後才能進行；功能測試需要等待開發完成後才能開始。識別這些依賴關係並安排合理的順序，是時程規劃的關鍵。關鍵路徑法可以幫助識別哪些任務序列決定了專案的總時長，這些任務需要特別關注以避免延誤。

資源規劃需要考慮人力資源和物質資源兩個方面。人力資源規劃要確定每個階段需要什麼角色的人員參與多少時間，是否需要外部資源的支援。物質資源規劃要確定需要購買或租用的設備、軟體、服務等。資源規劃需要與時程規劃配合，確保在需要資源的時間點資源已經到位。

時程規劃的輸出通常是一份專案時程表，清楚地顯示各任務的開始時間、結束時間、持續時間、負責人以及任務之間的依賴關係。時程表可以使用甘特圖的形式來呈視覺化呈現。規劃時程時應該留有一定的缓冲時間，以應對不可預見的延誤因素。過於樂觀的時程規劃往往是專案失敗的根源之一。

預算規劃與成本控制

專案預算是專案規劃的另一個核心要素。準確的預算規劃和有效的成本控制，是確保專案在財務上可行的關鍵。

網站專案的成本通常包括以下幾個類別。人力成本是最主要的開支，包括專案經理、設計師、前端工程師、後端工程師、測試工程師等的人員費用。如果使用內部團隊，這是薪資成本；如果外包給廠商，這是服務費用。軟體和工具成本包括設計軟體（Adobe Creative Suite 等）、開發工具、專案管理工具、測試工具等的授權費用。主機和域名成本包括網域註冊費、伺服器託管費、SSL 憑證費用等。第三方服務成本包括支付閘道費用、郵件發送服務費用、分析工具費用等。素材成本包括購買圖庫素材、影片素材、字體等的費用。差旅和其他費用可能包括拜訪客戶、參加會議等的開支。

估算成本時，需要將各項成本分類估算，然後加總。對於外包專案，通常會以報價單的形式呈現；對於內部專案，需要各部門的成本估算然後整合。成本估算應該有一定的彈性空間，預留一定比例的應急費用，通常是總預算的百分之十到二十，用於應對不可預見的支出。

成本控制是專案執行期間的重要工作。需要建立機制來追蹤實際支出與預算的差異，及時發現和處理預算偏差。當預期會超支時，需要評估原因並考慮對策，可能是調整範圍、延長時間、增加資源或尋求額外預算。定期的成本審查會議是進行成本控制的常見做法。

table of content

---

設計階段的管理

資訊架構與使用者流程設計

資訊架構是網站的骨架，定義了網站的內容如何組織、頁面如何分類、使用者如何導航。一個好的資訊架構能夠讓使用者快速找到他們需要的資訊，而不會在網站中迷失。資訊架構的設計需要基於對使用者需求和內容結構的深入理解。

進行資訊架構設計時，首先要盤點網站需要呈現的所有內容和功能，將它們列成清單。然後根據內容的性質和使用者的需求，將相關的內容和功能歸類在一起，形成分類結構。常見的分類方式包括按主題分類、按使用者族群分類、按時間順序分類等。選擇分類方式時，應該考慮使用者的心智模型，讓分類方式符合使用者的預期。

導航系統的設計是資訊架構的重要組成部分。主導航應該包含網站最重要的類別，通常不超過七個項目。子導航可以進一步細分每個主要類別下的內容。每個頁面都應該有清晰的路徑，讓使用者知道自己身在何處、如何回到上一層或首頁。對於複雜的網站，可能需要提供搜尋功能作為導航的輔助。

使用者流程設計關注的是使用者完成特定任務時需要經歷的步驟。例如，一個購物流程可能包括瀏覽商品、加入購物車、填寫配送資訊、選擇支付方式、確認訂單等步驟。設計使用者流程時，要考慮各步驟之間的邏輯關係、資訊的完整性、以及使用者的認知負擔。流程應該盡量簡化，去除不必要的步驟，讓使用者能夠以最少的點擊次數完成任務。

資訊架構和使用者流程的設計產出通常包括網站地圖（sitemap），顯示網站的頁面層級結構；以及流程圖（flowchart），顯示特定任務的操作流程。這些文件是設計階段的基礎，也是後續設計和開發的參考依據。

視覺設計與設計系統

在資訊架構確定之後，就進入視覺設計階段。視覺設計將抽象的資訊架構轉化為具體的視覺呈現，包括版型、色彩、字型、圖示、圖片等元素。視覺設計不僅是美學的追求，更是品牌傳達和使用者體驗的重要組成部分。

視覺設計首先需要確立設計風格和方向。這通常基於品牌識別手冊、企業的視覺形象、以及目標使用者的偏好。設計風格應該與品牌的調性一致，例如科技公司可能選擇簡潔、現代的設計風格，而傳統產業可能選擇穩重、典雅的風格。確定設計方向後，可以創建情緒板（moodboard）來彙整視覺參考，統一設計團隊的視覺語言。

版型設計是視覺設計的核心工作。需要為首頁、各類內頁、功能頁面等設計不同的版型。版型設計要考慮內容的優先級和視覺層次，讓使用者的視線能夠按照設計者的意圖流動。常見的視覺模式包括 F 型模式和 Z 型模式，反映了使用者在瀏覽網頁時的視覺路徑。響應式設計是現代網站設計的必要要求，需要為不同的螢幕尺寸（桌上型、筆記型、平板、手機）設計適配的版型。

設計系統是近年來網站設計的重要趨勢。設計系統是一套完整的設計規範和元件庫，包括色彩規範、字型規範、間距規範、按鈕樣式、表單樣式、卡片樣式等各種可重複使用的元件。設計系統的好處是確保整個網站的視覺一致性，同時提高設計和開發的效率。建立設計系統需要前期的投入，但對於規模較大的網站或需要長期維護的專案，這個投資是值得的。

設計稿的產出通常包括各類型的頁面設計稿，以及設計規範文件。為了便於開發團隊實現，設計稿應該標示詳細的尺寸、間距、顏色代碼等規格資訊。設計交付前應該仔細檢查，確保設計的一致性、完整性和可實現性。

設計審核與確認流程

設計階段的產出需要經過適當的審核和確認，才能進入下一階段的開發工作。完善的設計審核流程可以確保設計符合需求、沒有明顯問題，並獲得利害關係人的認可。

設計審核通常分為幾個層面。首先是功能可行性審核，由技術團隊評估設計是否能夠實現，是否有技術上的困難或限制。這種審核最好在設計早期就進行，避免設計完成後發現難以實現而需要大幅修改。其次是使用者體驗審核，由對使用者需求有深入了解的人評估設計是否符合使用者的心智模型和使用習慣，操作流程是否順暢。這可以通過內部評審或使用者測試來進行。第三是品牌一致性審核，確保設計符合品牌的視覺識別規範，傳達正確的品牌形象。

設計確認是將設計稿提交給專案發起人或主要利害關係人進行批准的過程。設計確認不應該只是發送設計稿了事，而應該準備設計說明文件，解釋設計的考量、決策的依據、以及如何滿足專案目標。在確認會議上，設計團隊應該詳細說明設計的各個部分，回答利害關係人的問題，記錄回饋和修改意見。

設計確認後的修改應該有明確的範圍和限制。過度頻繁的修改需求是專案延誤的常見原因。可以在專案開始時就約定修改的次數和範圍，例如「提供兩輪設計修改，每輪修改不超過若干處」，超出範圍的修改需要額外評估和報價。對於已經確認的設計，如果需要進行重大修改，應該重新進行確認流程。

table of content

---

開發階段的管理

開發團隊的組織與分工

網站開發通常需要多種專業角色的協作。根據專案的規模和性質，這些角色可能由不同的人擔任，也可能由同一人兼任多個角色。合理的團隊組織和明確的分工是開發工作順利進行的基礎。

專案經理是開發團隊的統籌者，負責專案的規劃、執行、監控和收尾。專案經理需要協調各角色之間的工作，追蹤專案進度，處理問題和風險，與利害關係人溝通。對於較大的專案，專案經理可能需要專職擔任；對於較小的專案，可能由開發負責人或設計師兼任。

前端工程師負責網站的用戶端開發，將設計稿轉化為可互動的網頁。前端工程師需要精通 HTML、CSS、JavaScript 等基礎技術，以及現代前端框架如 React、Vue、Angular 等。對於需要與後端系統整合的前端功能，前端工程師也需要與後端工程師密切配合。

後端工程師負責網站的伺服器端開發，實現業務邏輯、數據處理、系統整合等功能。後端工程師需要熟悉伺服器端程式語言如 PHP、Python、Node.js 等，以及資料庫設計和系統架構。後端工程師還需要考慮系統的安全性、效能和可擴展性。

全端工程師是兼具前端和後端能力的工程師，能夠獨立完成一個功能模組的完整開發。在小型專案或資源有限的情況下，全端工程師可以提高開發效率。

UI/UX 設計師負責使用者介面和使用者體驗的設計，雖然視覺設計通常由專門的視覺設計師負責，但 UI/UX 設計師更專注於使用流程、互動設計和使用者研究。在較大的專案中，視覺設計和 UX 設計可能是分開的角色。

測試工程師負責網站的品質保證工作，包括功能測試、效能測試、相容性測試、安全測試等。測試工程師需要設計測試案例、執行測試、記錄和追蹤問題。

開發方法論的選擇

不同的專案適合不同的開發方法論。選擇合適的方法論可以提高開發效率、降低風險、更好地滿足專案需求。以下介紹幾種常見的開發方法論及其適用情境。

瀑布式開發是最傳統的開發方法，專案嚴格按照線性的順序進行，每個階段完成後才進入下一個階段。需求分析完成後開始設計，設計完成後開始開發，開發完成後才進行測試，最後部署上線。瀑布式的好處是流程清晰、易於管理、文件完整；但缺點是缺乏彈性，後期發現問題很難回溯修改。瀑布式適合需求明確、變化可能性小的專案。

敏捷開發是一種迭代式的開發方法，將專案分為多個短週期（通常兩到四週）稱為衝刺（Sprint），每個衝刺交付可用的產品增量。敏捷開發強調適應變化、快速回饋、持續改進。常見的敏捷框架包括 Scrum 和 Kanban。敏捷的好處是能夠快速回應需求變化、及早發現問題、持續交付價值；但需要團隊有較好的自組織能力，專案範圍可能不如瀑布式那麼可控。敏捷適合需求可能變化、需要快速迭代的專案。

混合式方法結合了瀑布式和敏捷的特點，在專案的不同階段或針對不同的部分採用不同的方法。例如，整體框架和核心功能採用瀑布式確保穩定性，附加功能和小規模迭代採用敏捷提高靈活性。混合式方法需要根據專案特性靈活運用。

選擇開發方法論時，需要考慮專案的特性、團隊的能力、組織的文化等因素。沒有放諸四海皆準的最佳方法，只有最適合當前情境的方法。即使選擇了某種方法，也可以根據實際情況進行調整和改良。

版本控制與協作流程

版本控制是現代軟體開發的必備工具，對於網站開發專案也不例外。版本控制系統記錄程式碼的每次變更，讓開發者可以追蹤歷史、比較差異、恢復到之前的版本、以及多人協作開發。

Git 是目前最流行的版本控制系統。Git 的核心概念包括倉庫（repository）、提交（commit）、分支（branch）、合併（merge）等。開發者在本地進行開發，將變更提交到本地倉庫，然後推送（push）到遠端倉庫與團隊成員共享。分支功能讓開發者可以在獨立的分支上進行實驗性開發，不影響主分支的穩定性，完成後再合併（merge）回主分支。

Git 託管平台如 GitHub、GitLab、Bitbucket 等提供了協作和管理功能，包括問題追蹤、程式碼審查、合併請求等。使用這些平台可以建立更規範的協作流程，例如：主分支（main 或 master）應該是穩定的、可部署的程式碼；新功能在功能分支上開發，開發完成後透過合併請求（pull request）審核後合併到主分支；每次合併前需要通過自動化測試和程式碼審查。

除了程式碼版本控制，設計稿和文件也需要版本控制。設計稿可以使用像 Figma 這樣支援版本歷史的工具，或者手動管理版本號和變更記錄。專案文件可以使用雲端協作工具如 Google Docs 的版本歷史功能。總之，確保所有重要的產出都有版本記錄，可以追溯每次變更。

協作流程的規範化是團隊高效運作的關鍵。應該建立清晰的命名規範、提交訊息規範、分支命名規範等。程式碼提交應該是有意義的原子提交，每個提交完成一個相對獨立的功能或修正。提交訊息應該清楚說明這次提交的目的和內容。定期進行程式碼審查（code review）可以提高程式碼品質、分享知識、發現問題。

開發進度的追蹤與報告

有效的進度追蹤是專案管理的基本功。通過持續監控開發進度，可以及早發現延誤和問題，採取必要的措施來確保專案按計劃進行。

任務分解和工時估算是進度追蹤的基礎。將專案分解為明確的任務，估算每個任務所需的工作量，分配給具體的負責人。任務的顆粒度要適中，夠細到可以準確追蹤，又不會細到管理成本過高。通常以半天到一天的工作量作為一個任務顆粒度是比較合理的。

追蹤工具可以幫助管理任務和進度。常見的工具包括專案管理軟體如 Jira、Trello、Asana、Notion 等，也可用簡易的試算表如 Google Sheets 或 Excel。這些工具可以創建任務清單、分配任務、設定截止日期、追蹤完成狀態。可視化的看板或甘特圖可以讓進度一目了然。

每日站會是敏捷開發中常用的進度同步機制。團隊成員每天花費十到十五分鐘，簡短報告昨天完成了什麼、今天計劃做什麼、是否有阻礙。這種方式可以讓團隊保持同步，及時發現和處理阻礙。對於非敏捷團隊，也可以每週進行類似的進度會議。

進度報告是向利害關係人溝通專案狀況的重要工具。報告的頻率和詳細程度根據專案階段和利害關係人的需求而定。報告內容通常包括：已完成的工作、計劃進行的工作、遇到的問題和風險、需要的決策或支援。好的進度報告應該簡潔明瞭，重點突出，數據驅動。

進度偏差的處理是專案管理的重要工作。當實際進度落後於計劃時，需要分析原因，評估影響，決定對策。可能的原因包括：任務估計過於樂觀、突發問題佔用時間、資源不足或能力不足、需求變更等。對策可能包括：加班趕工、調整優先級、尋求額外資源、重新評估時程等。重要的是及早發現偏差，及早處理，避免偏差累積到無法挽回的程度。

table of content

---

測試與品質保證

測試策略的制定

網站上線前必須經過充分的測試，確保功能正常、效能合格、安全無虞。制定全面的測試策略是品質保證的關鍵步驟。測試策略應該根據專案的特性、預算和時程來設計，平衡測試的深度和廣度。

測試類型可以分為以下幾種。功能測試驗證各功能是否按照需求正確運作，包括連結是否正確、表單是否正常提交、搜尋是否準確等基本功能測試，以及複雜業務流程的端到端測試。相容性測試驗證網站在不同的瀏覽器（Chrome、Firefox、Safari、Edge 等）和不同裝置（桌上型、筆記型、平板、手機）上的顯示和功能是否正常。效能測試驗證網站在正常負載和高峰負載下的回應時間、吞吐量、資源使用等效能指標。安全性測試檢測網站的安全漏洞，包括注入攻擊、跨站腳本攻击、敏感資料洩漏等問題。可及性測試驗證網站是否符合無障礙標準，讓身心障礙人士也能使用。

測試環境的規劃也是測試策略的重要部分。開發環境用於開發過程中的基本測試；測試環境用於完整的功能測試和回歸測試；預上線環境用於接近正式環境的最終驗證；正式環境是實際提供服務的環境。不同環境應該盡量模擬正式環境的設定，避免「在我機器上可以運作」的問題。

測試資料的準備也需要考慮。功能測試可能需要特定的使用者帳號、商品資料、訂單資料等。效能測試需要模擬真實資料量級的測試資料。可以使用匿名化的真實資料、產生的假資料、或兩者結合。確保測試資料符合資料隱私法規的要求。

自動化測試和手動測試應該相結合。自動化測試適合Regression Testing（回歸測試），確保新功能不影響現有功能；適合執行頻繁、邏輯固定的測試案例；適合需要跨多個瀏覽器和裝置執行的相容性測試。手動測試適合探索性測試，發現預期外的問題；適合需要人工判斷的使用者體驗測試；適合初期的功能驗證和緊急的小修改測試。

問題追蹤與管理

測試過程中會發現各種各樣的問題，需要有效的問題追蹤系統來記錄、分類、優先級排序、分配和追蹤處理狀態。

問題追蹤系統是管理問題的必備工具。專業的問題追蹤軟體如 Jira、Azure DevOps、YouTrack 等提供完整的功能，包括問題記錄、自定義欄位、工作流程、權限控制、報告統計等。對於小型專案，也可以使用輕量級的工具如 Trello 或 Notion，甚至試算表。選擇工具時要考慮團隊的習慣和專案的需求。

問題的記錄應該包含足夠的資訊以便於理解和處理。這些資訊包括：問題的標題和描述、問題的重現步驟、環境資訊（瀏覽器、裝置、作業系統）、預期結果和實際結果、螢幕截圖或影片、嚴重程度和優先級、分配給誰、處理的狀態等。好的問題描述應該讓開發人員能夠重現問題，不需要額外猜測或詢問。

問題的優先級排序需要綜合考慮多個因素：問題的嚴重程度（是完全無法使用，還是輕微的不便）、影響的範圍（影響所有使用者還是只有特定族群）、修復的難度和成本、以及與業務目標的關聯度。通常會將問題分為幾個優先級，如Critical（嚴重）、High（高）、Medium（中）、Low（低），不同優先級的問題有不同的處理時限要求。

問題的處理流程應該是清晰的：發現並記錄問題、分類和優先級排序、分配給負責人、修復並驗證、關閉。對於每個問題，應該記錄處理的過程，包括誰在什麼時間做了什麼。如果問題無法在當前版本修復，應該記錄為待處理事項，在後續版本中解決。

使用者驗收測試

使用者驗收測試（User Acceptance Testing，簡稱 UAT）是讓實際使用者或業務代表參與的最終測試，驗證網站是否滿足業務需求和預期。這是網站上線前的最後把關環節。

UAT 的參與者應該是熟悉業務需求的人，可能是業務負責人、關鍵使用者代表、或客戶本身。他們從使用者的角度來測試網站，驗證功能是否正確、操作是否順暢、是否滿足業務場景的需求。UAT 與技術測試的區別在於：技術測試關注「系統是否按照規格運作」，UAT 關注「系統是否能夠達成業務目標」。

UAT 的準備工作包括：制定 UAT 測試案例，涵蓋所有關鍵的業務場景和使用流程；準備測試資料和測試環境；對 UAT 參與者進行培訓，讓他們了解測試的目的和流程；設定 UAT 的時間框架和交付標準。測試案例應該是可執行的、可驗證的，避免模糊的描述如「檢查首頁看起來是否正確」。

UAT 的執行過程中，參與者按照測試案例進行測試，記錄發現的問題和意見。測試團隊應該提供支援，回答參與者的問題，幫助處理技術問題。鼓勵參與者不只檢查預期的功能，也從使用者的角度探索網站，可能發現測試案例沒有涵蓋的問題。

UAT 的結果評估應該基於事先定義的驗收標準。如果所有關鍵功能都通過測試，沒有重大問題，則可以確認驗收通過。如果存在需要修復的問題，則需要區分哪些是必須在上線前修復的阻礙項，哪些是可以在上線後修復的非阻礙項。UAT 的通過應該獲得正式的確認，記錄為專案驗收的依據。

table of content

---

部署與上線

部署環境的準備

部署是將開發完成的網站從測試環境發布到正式環境的過程。完善的部署環境準備和流程規劃，可以確保部署順利完成，減少風險。

伺服器環境的準備是部署的第一步。根據技術方案的規劃，準備所需的伺服器資源。這可能包括：網頁伺服器（如 Apache、Nginx）、應用程式伺服器（如 PHP-FPM、Node.js）、資料庫伺服器（如 MySQL、PostgreSQL）、快取伺服器（如 Redis、Memcached）、檔案儲存等。對於使用雲端服務的專案，需要在雲端平台上配置相應的資源；對於使用傳統主機的專案，需要通過控制面板或命令行進行設定。

環境配置的管理是部署的重要課題。開發環境、測試環境、預上線環境和正式環境的設定應該盡量一致，避免「在我的環境中可以運作」的問題。環境變數（如資料庫連線字串、API 金鑰等）應該通過環境變數或配置檔案來管理，而不是寫死在程式碼中。基礎設施即程式碼（Infrastructure as Code）的工具如 Terraform、Ansible 等可以幫助自動化和管理環境配置。

網域和 SSL 憑證的設定也需要在上線前完成。網域應該指向正確的伺服器 IP 位址，DNS 設定可能需要一些時間才能生效，建議提前進行。SSL 憑證確保網站使用 HTTPS 加密連線，保護使用者資料安全。可以使用 Let's Encrypt 的免費憑證，或購買商業憑證。憑證的安裝和更新應該納入維護流程。

備份和災難復原計畫是部署環境的重要組成部分。在正式上線前，應該建立完善的備份機制，包括資料庫備份、檔案備份、系統快照等。應該測試備份是否能夠正確恢復。災難復原計畫應該定義各種故障情境（如伺服器當機、資料中心故障）的應對措施和復原時間目標。

上線流程與回滾計畫

上線是將網站發布到正式環境供使用者存取的關鍵時刻。雖然經過充分的測試，上線過程仍可能遇到各種問題，因此需要完善的上線流程和回滾計畫。

上線流程應該詳細定義各個步驟、負責人和檢查點。一個典型的上線流程包括：確認所有測試已經完成且通過、關閉預上線環境的維護模式、備份正式環境的資料和設定、執行部署指令或腳本、驗證部署結果（檢查版本、檔案、資料庫遷移等）、開啟正式環境的服務、監控系統狀態和效能、通知相關人員上線完成。整個過程應該有詳盡的記錄，以便問題發生時進行排查。

選擇上線的時間點也是重要的考量。對於主要面向台灣使用者的網站，通常選擇週間的凌晨時段進行上線，以減少對使用者的影響。上線前應該避免與行銷活動、業務高峰期等時間衝突。節假日或週末可能不是最佳選擇，因為萬一出現問題，可能無法及時獲得支援。

回滾計畫是在上線失敗時能夠快速恢復到上線前狀態的方案。回滾應該是簡單、快速、可執行的。可能的回滾方式包括：使用版本控制系統還原程式碼、使用備份還原資料庫、從備份伺服器恢復服務等。回滾的觸發條件和決策流程應該事先定義清楚，避免在慌亂中做出錯誤的決定。在正式上線前，應該演練回滾流程，確認其可行性和效率。

上線後的監控是必要的。部署完成後，應該持續監控系統的運行狀態、效能指標、錯誤日誌等。準備好監控儀表板和報警機制，一旦出現異常能夠及時發現和處理。首日的監控尤其重要，許多問題在流量進入後才會顯現。

監控與效能優化

網站上線後，持續的監控和效能優化是確保網站穩定運行的重要工作。

系統監控包括伺服器監控和應用監控。伺服器監控追蹤 CPU 使用率、記憶體使用率、磁碟空間和 I/O、網路流量等基礎指標。應用監控追蹤應用程式的運行狀態、錯誤日誌、回應時間等。常見的監控工具包括 Prometheus、Grafana、New Relic、Datadog 等。設定適當的閾值和報警規則，當指標超過正常範圍時能夠及時通知相關人員。

效能監控關注使用者的實際體驗。頁面載入時間、回應時間、錯誤率等是關鍵指標。可以使用真實使用者監控（RUM）工具如 Google Analytics、SpeedCurve 等，收集真實使用者的效能數據。效能數據的分析可以幫助發現效能瓶頸和優化機會。

效能優化是持續的工作。常見的效能優化方向包括：前端優化，如壓縮圖片、使用延遲載入、最小化 CSS 和 JavaScript、使用瀏覽器快取等；後端優化，如資料庫查詢優化、程式碼優化、使用快取等；伺服器優化，如調整伺服器配置、使用 CDN 加速等。效能優化應該基於數據驅動，針對實際的瓶頸進行優化，而不是憑感覺猜測。

錯誤追蹤是監控的重要組成部分。及時發現和修復錯誤是維持網站品質的關鍵。錯誤追蹤工具如 Sentry、Rollbar 等可以自動收集應用程式的錯誤資訊，包括錯誤類型、堆疊追蹤、使用者環境等，幫助快速定位和修復問題。

table of content

---

專案風險管理

風險識別與評估

風險管理是專案管理的重要組成部分。通過系統性地識別、評估和應對風險，可以降低風險對專案的影響，提高專案成功的可能性。

風險識別是風險管理的起點。識別風險的方法包括：頭腦風暴，邀請團隊成員列出可能的風險；檢查表，參考過去專案的經驗和行業的最佳實踐；SWOT 分析，評估專案的優勢、劣勢、機會和威脅；專家訪談，向有經驗的人請教可能的問題。識別出的風險應該記錄在風險登錄表中，包含風險描述、可能的原因、影響範圍等資訊。

風險評估對每個識別出的風險進行可能性和影響程度的評估。可能性可以分為高、中、低三個等級；影響程度可以從輕微到災難分成幾個等級。根據可能性和影響程度的組合，計算風險優先級。高優先級的風險需要優先關注和處理。

風險可以分為多種類型。技術風險包括技術方案不可行、技術難題無法解決、相容性問題等。範圍風險包括需求變更、範圍蔓延、需求理解偏差等。時間風險包括時程延誤、關鍵路徑任務延遲等。資源風險包括人員不足、關鍵人員離開、資源衝突等。外部風險包括政策變化、第三方服務中斷、市場環境變化等。

風險應對策略

針對不同類型和優先級的風險，應該制定相應的應對策略。常見的風險應對策略包括：規避、轉移、減輕、接受。

規避策略是通過改變計畫來消除風險或避開風險情境。例如，如果某個技術方案風險過高，可以選擇更成熟但可能成本較高的替代方案。規避策略適用於高可能性、高影響的風險。

轉移策略是將風險的後果轉移給第三方。例如，通過購買保險來轉移財務風險；通過合約條款將特定風險轉移給承包商；通過購買 SLA 保障來轉移服務中斷的風險。轉移策略適用於你不擅長處理、但第三方有能力和意願承擔的風險。

減輕策略是採取措施降低風險的可能性或影響程度。例如，增加測試覆蓋率來降低軟體缺陷的風險；增加緩冲時間來降低時程延誤的風險；建立備援系統來降低伺服器故障的風險。減輕策略是最常用的風險應對方式。

接受策略是承認風險存在但不採取預防措施，準備在風險發生時應對。接受可以是主動的（經過評估後決定風險可接受）或被動的（沒有更好的應對方式）。接受策略適用於可能性低、影響小的風險，或者應對成本高於風險成本的風險。

對於高優先級的風險，應該制定詳細的應對計畫，包含具體的行動、負責人、時間表、所需資源。對於中優先級的風險，應該有基本的應對計畫。對於低優先級的風險，記錄在案但不需要投入過多資源。

應急計畫的制定

對於影響重大且難以完全規避的風險，應該制定應急計畫，定義在風險發生時的具體應對措施。應急計畫是風險管理的最後一道防線。

應急計畫應該包含：觸發條件，什麼情況下啟動應急計畫；行動步驟，具體要做什麼、由誰執行；資源需求，啟動應急計畫需要什麼資源；通訊計畫，需要通知哪些人、如何溝通；終止條件，什麼情況下可以結束應急狀態。

常見的專案應急情境和應對措施包括：關鍵技術問題無法解決，應急措施可能是尋求外部專家支援、切換到替代技術方案、調整功能範圍；核心人員突然離開，應急措施可能是知識轉移、招募替代人選、重新分配工作；第三方服務中斷，應急措施可能是使用備援服務、手動處理、聯繫服務提供商；上線時出現嚴重問題，應急措施可能是回滾到上一版本、緊急修復、延期上線。

應急計畫應該定期檢視和更新，確保仍然適用。重要的應急計畫可以進行演練，確認其可行性，讓相關人員熟悉流程。例如，資料庫恢復演練可以確認備份和恢復流程是否正常運作。

table of content

---

專案收尾與後續維護

專案驗收與交付

當網站開發完成、測試通過、上線穩定後，就進入專案收尾階段。專案收尾不僅是交付最終成果，也包括整理專案文件、總結經驗教訓、妥善處理資源。

專案驗收是確認專案交付物符合需求的正式程序。驗收的標準應該在專案啟動階段就已經定義清楚，記錄在需求文件或驗收標準文件中。驗收過程可能包括：功能驗證，確認所有需求功能都已實現且正常運作；效能驗證，確認效能符合預定的指標；安全性驗證，確認沒有重大安全漏洞；文件驗證，確認所有應該交付的文件都已交付且完整。

專案交付的內容通常包括：可運行的網站系統、原始程式碼和相關技術文件、使用者操作手冊和管理操作手師、系統架構和部署文件、測試報告和驗收記錄等。交付的內容和格式應該事先約定清楚。對於外包專案，交付物通常在合約中有明確規定。

驗收通過後，專案正式結束。專案收尾的正式程序包括：完成驗收報告並獲得相關方簽署、處理專案的財務結算、釋放專案資源、通知所有相關方專案已完成。有時候會舉辦專案結案會議，回顧專案過程，總結經驗。

經驗教訓的總結

每個專案都是學習的機會。無論專案成功與否，都應該進行經驗教訓的總結，為未來的專案提供參考。

經驗教訓總結的內容可以包括：做得好的地方，未來專案可以繼續保持和發揚；需要改進的地方，未來專案應該避免或改進；意外發現的問題和解決方案；對流程、工具、方法論的建議等。總結應該具體、客觀、有建設性，而不是泛泛而談或相互指責。

經驗教訓總結的方法可以是：個人反思，邀請專案成員各自回顧並記錄心得；團隊討論，舉辦回顧會議讓團隊共同討論；文件分析，回顧專案過程中的文件和記錄。回顧會議是一種常見的做法，團隊成員在輕鬆的氛圍中分享觀點和建議。會議的引導者應該營造安全的環境，讓大家願意說出真實的想法。

經驗教訓應該被記錄和分享。記錄的格式可以是專門的經驗教訓報告，或者簡單的清單和要點。這些記錄應該存放在容易存取的地方，讓未來專案的成員可以參考。對於重要的經驗教訓，可以組織培訓或分享會，讓更多人了解。

網站的後續維護

專案結束並不意味著工作完成了。網站上線後需要持續的維護，才能保持穩定運行、持續改進。維護工作應該在專案規劃階段就納入考慮，並有相應的資源和預算支持。

日常維護工作包括：監控和報警處理，及時發現和處理系統問題；錯誤修復，修復使用者回報或監控發現的錯誤；安全更新，定期更新系統和軟體的安全修補程式；內容更新，根據業務需要更新網站內容；效能監控和優化，持續監控效能並進行優化。

定期維護工作包括：備份驗證，定期測試備份是否能夠正確恢復；安全審計，定期檢查系統的安全性；效能評估，定期評估系統效能並規劃優化；容量規劃，評估資源使用趨勢並規劃擴容；法規合規檢查，確保網站合乎法規要求。

功能迭代是根據業務需求和用戶回饋持續增加新功能和改進現有功能。這通常按照專案的方式來管理，有獨立的規劃、開發、測試和上線流程。功能迭代的優先級應該基於業務價值和用戶需求的評估。

維護服務級別協議（SLA）是定義維護服務品質標準的協議。SLA 可能定義系統可用性目標（如百分之九十九點九的正常運行時間）、回應時間目標（如嚴重問題在四小時內回應）、修復時間目標（如嚴重問題在二十四小時內修復）等。對於重要的網站，可以考慮與專業的維護服務提供商簽訂 SLA 保障的服務合約。

---

在這一章節中，我們全面探討了網站架設流程與專案管理的各個面向。從專案啟動的目標定義，到需求分析與規劃；從設計階段的管理，到開發階段的團隊協作和進度追蹤；從測試策略的制定，到部署上線的流程；從專案風險的管理，到後續的維護規劃——這些知識構成了成功執行網站專案的完整框架。

網站專案的成功不僅取決於技術能力，更取決於專案管理的有效性。清晰的目標定義、充分的規劃、有效的執行、持續的監控和改進，這些都是確保專案成功的關鍵要素。希望本課程提供的知識和工具能夠幫助你更從容地管理網站專案，提高專案成功的機率。

在接下來的課程中，我們將探討網站部署與維護管理的相關主題，幫助你建立一個完整、專業、合規的線上品牌和業務體系。

---

學術引用：

A Guide to the Project Management Body of Knowledge (PMBOK Guide) (7th ed.). (2021). Project Management Institute.

Cervone, H. F. (2011). Agile project management: A new approach to managing complex projects. OCLC Systems & Services, 27(4), 174-178.

Cohn, M. (2005). Agile estimating and planning. Prentice Hall.

Dingsøyr, T., Moe, N. B., & Seim, E. A. (2019). Coordination challenges and practices in agile software outsourcing. IEEE Software, 36(2), 83-90.

Highsmith, J. (2002). Agile software development ecosystems. Addison-Wesley.

Kerzner, H. (2017). Project management: A systems approach to planning, scheduling, and controlling (12th ed.). Wiley.

Martin, R. C. (2003). Agile software development: Principles, patterns, and practices. Prentice Hall.

Pressman, R. S., & Maxim, B. R. (2020). Software engineering: A practitioner's approach (9th ed.). McGraw-Hill.

Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org.

Sommerville, I. (2015). Software engineering (10th ed.). Pearson.