階段六
上線與教育訓練
上線前會確認部署環境、備份機制、監控設定與回復流程。若專案包含後台管理介面，會安排教育訓練，讓非工程背景的同事能自行更新內容，而不是每次改文案都要找工程師。
產出包含系統架構圖、資料表說明、部署步驟與常見問題處理方式。程式碼會交付到客戶自己的版本控制帳號，不綁在我們的環境裡。
需要客戶配合：確認上線時間與通知範圍、安排種子人員參與訓練、確認後續維護的負責窗口。
這頁怎麼用
你在任何時間點，都該知道專案走到哪裡
這頁說明 Nexovanta 承接專案時的實際流程，從第一次訪談到上線後的維運，包含每個階段的產出文件、需要客戶配合的事項與時間節奏。不同類型的專案會有些差異，但主體架構大致相同。
閱讀方式很簡單：下面每一個階段都寫清楚三件事——我們會交付什麼、你需要準備什麼、以及下一件事是什麼。若你只想先確認範圍與預算怎麼切，可以直接跳到架構規劃與範圍確認，或先預約需求訪談，我們會在報價前先把現況整理給你。
階段一 · 約兩到三小時
階段一：需求訪談與現況盤點
第一次訪談通常兩到三小時，對象包含實際使用系統的同事，不只是決策者。我們會問現在這個流程怎麼跑、哪裡最花時間、出錯時怎麼補救。這些細節往往比規格書更能決定架構。
產出是一份現況整理，內容包含現有系統清單與相依關係、資料來源與品質觀察、以及初步的問題定義。這份文件會在報價前提供。若評估後認為需求用現成工具就能解決，我們會直接說明，不會硬推專案。
需要你這邊配合
- 安排實際使用者參與訪談，而不是只有主管出席。
- 提供現有系統的存取權限，或至少畫面截圖與流程說明。
- 說明目前的預算範圍與期望時程，讓我們能把階段切得實際。
訪談以現行流程為主，畫面與截圖只是輔助。我們在意的是實際會出錯的地方，不是文件上寫的流程。
階段二 · 報價與範圍基準
階段二：架構規劃與範圍確認
這一階段把問題轉成技術方案，內容包含系統架構、資料流、第三方串接方式、部署環境與資安考量。同時會把專案切成可交付的階段，排定優先順序，讓預算可以分段投入。這份文件是後續開發的依據，也是變更管理的基準。
架構說明文件
系統分層與資料流
功能清單與階段劃分
可分段交付的範圍
時程與報價
依階段拆分的成本
變更管理基準
新增功能的評估依據
若中途要新增功能，會依這份基準評估對時程與成本的影響，而不是用「盡量做」帶過。
需要客戶配合的事項：確認階段順序與預算分配、指定專案對口與決策者。
同時確認第三方服務的帳號與權限，例如金流、簡訊、雲端主機與分析工具。
階段三
階段三：設計與使用者流程
設計階段從資訊架構開始，先確認頁面層級與使用者動線，再進入視覺設計。我們會把首頁當成問題清單來排：你是誰、解決什麼、憑什麼、多少錢、怎麼聯絡，每一項都要讓訪客快速找到。
產出包含頁面清單與流程圖、視覺設計稿、響應式版面規格，以及設計系統的基本元件。設計稿會標註行動裝置的呈現方式，避免開發階段才發現版面需要重排。
需要客戶配合的事項：提供品牌素材與既有識別規範、在約定時間內回覆設計意見、確認文案內容由誰負責撰寫。
階段四
階段四：開發與每週進度回報
開發採分階段交付，每個階段結束會有可測試的版本，而不是全部做完才一次驗收。這樣做的好處是問題能及早發現，避免在最後階段才大幅調整。
進度回報通常是每週一次書面更新加上雙週一次會議。書面內容包含本週完成項目、下週預計項目、以及需要客戶決定的事項。需要決策的事情會標明期限，避免因為等待回覆而讓時程往後推。
需要客戶配合的事項：在約定時間內回覆確認事項、提供測試用的資料與帳號、指派同仁參與階段測試。
階段五
階段五：測試與驗收
測試範圍包含功能測試、跨裝置與跨瀏覽器檢查、效能與載入速度、以及資安基本檢核。若專案涉及系統整合，會一併測試資料傳遞的完整性與錯誤處理。
驗收會依階段二的基準逐項確認。發現的問題會記錄、排優先順序並修正。驗收完成後才進入上線準備，避免帶著已知問題上線。
需要客戶配合的事項：安排實際使用者參與測試、提供真實情境的測試案例、確認驗收標準與負責人。
驗收涵蓋範圍
-
功能測試
依功能清單逐項操作，包含權限角色與邊界情境。
-
跨裝置與跨瀏覽器
手機、平板與桌機的版面與操作，常見瀏覽器各一輪。
-
效能與載入速度
頁面首次載入、圖片與腳本的載入順序與壓縮方式。
-
資安基本檢核
帳號權限、輸入驗證、常見弱點與第三方套件版本。
-
系統整合測試
資料傳遞完整性、錯誤處理與重試機制，含串接服務。
階段六與階段七：上線、訓練與後續維運
上線不是終點。作業系統會更新、第三方套件會停止維護、業務流程也會改變，這些都需要持續處理。我們把交付與維運分成兩件事寫清楚，讓你知道接手的是什麼。
階段七
上線後的維運與調整
維運範圍通常包含錯誤修正、套件更新、效能監控與小幅調整。我們會在報價時把上線後第一年的維護範圍寫清楚，包含回應時間與處理方式。
若你希望由內部團隊接手，我們會協助轉移並提供必要的技術說明，而不是把系統鎖在我們這邊。
需要客戶配合：指定維運窗口、回報異常狀況、定期檢視使用數據與改善需求。
專案節奏與溝通方式
每個專案會有固定的進度回報節奏，溝通以中文為主，技術文件與程式碼註解則依客戶習慣採中文或英文。我們在台北與喬治亞第比利斯都有團隊成員，會議時間以台灣上班時段為主。
小型專案通常八到十二週，整合型專案會分成多個階段，總時程依範圍而定。我們不會在時程上給不切實際的承諾，若範圍太大，會建議先做第一階段。
每週進度更新
書面，含待決事項與期限
雙週會議
以台灣上班時段為主
文件語言
中文或英文，依團隊習慣
小型專案時程
通常八到十二週
整合型專案
多階段，時程依範圍而定
專案開始前常被問到的幾件事
這些問題我們在第一次訪談前就會先聊，先有共識，後面的階段會走得順很多。若你的情況不在下面，直接預約訪談比較快。
需求還在討論階段，可以先預約訪談嗎？
可以。第一次訪談本來就是為了把需求講清楚，不需要事先寫好規格。我們會一起盤點現有流程與問題，並在報價前提供一份現況整理，讓你判斷值不值得往下走。
專案中途要新增功能怎麼辦？
會依階段二確認的功能清單與時程基準評估影響，包含對成本與後續階段的排程。若影響太大，我們會說明並建議放到下一階段，而不是口頭承諾然後延期。
網站或 App 的程式碼最後歸誰？
交付到客戶自己的版本控制帳號。我們不會把系統綁在自家環境，若你之後想由內部團隊接手，也會提供必要的技術說明與移轉協助。
維運一定要交給你們嗎？
不一定。我們會在報價時把第一年的維護範圍、回應時間與處理方式寫清楚，你可以依內部人力決定接手方式；要由我們承接、或轉回內部團隊，都可以事先討論。
先聊一次，再決定要不要做
把你的專案範圍、現有系統與期望時程告訴我們，我們會回覆一份現況整理與可行的階段切法。若需求用現成工具就能解決，我們也會直說。服務時間為週一至週五 09:00–18:00。