軟體專案啟動前業主要準備什麼：決策窗口、資料盤點與第一次會議

「什麼時候可以開工？」通常是簽約後業主最關心的問題。但專案真正的起跑點不是開工日，而是業主把資料、帳號與決策權準備好的那一天。廠商排好人力進場，第一週卡在舊系統沒人有權限匯出資料，第二週卡在首頁文案還在等老闆看過——時程就是這樣一點一點被吃掉的，而且這段延誤通常不會被記在任何人的帳上。

好消息是，這些準備沒有一項需要技術背景。以下依照實際會卡住的順序，整理業主在啟動會議之前該完成的事，以及第一次會議該把什麼東西帶進去。

為什麼啟動前的準備會決定整個專案節奏

專案延誤的根因另有專文討論，這一段只處理其中一種——開工前就能消除掉的那一段等待。

開發工作有很強的前後依賴。登入方式還沒決定，會員相關的畫面就無法定稿；商品欄位還沒盤點完，資料結構就收斂不了。前置決定一旦拖延，排好的工作只能空轉或先做次要項目，等決定終於下來，往往又要回頭改已經做過的部分。更麻煩的是，這類延誤通常發生在雙方都覺得「不是我的問題」的灰色地帶：廠商在等業主給資料，業主以為廠商還在忙別的事，兩週就這樣過去。啟動前準備的價值，就是把這些等待壓縮到專案正式開始之前，讓開發期只處理開發本身的事。

怎麼判斷自己準備得夠不夠：設想廠商明天一次丟十個細節問題給你，你能不能在幾個工作天內全部回覆？回答不出來的項目，就是接下來要補的功課。

第一件事：指派一位能拍板的決策窗口

這是所有準備裡最關鍵、也最常被輕忽的一項。窗口不需要懂技術，但必須具備三個條件：知道公司內部流程實際怎麼跑、能在一定範圍內直接決定、以及真的有時間回覆。

最常踩到的一步是把窗口交給最有空的人，而不是最有權的人。設想一個情境：窗口每次收到問題都要往上層層呈報，每次往返動輒數日，一個月累積下來會吃掉可觀的有效工時。這種成本不會出現在報價單上，但確實存在。

如果組織規模讓單一窗口不可行，至少要明確分工：誰負責畫面與文案、誰負責流程與規則、誰負責資訊安全與帳號、誰是最終拍板的人。同時事先講好回覆時效，例如一般問題兩個工作天內回覆、需要開會討論的一週內排會。窗口要投入多少時間，也跟合作模式有關，這點可以參考固定報價還是敏捷開發的說明。

盤點既有系統：你正在用的東西比想像中多

多數公司都低估自己手上有多少系統。除了大家都想得到的官網與進銷存，還有各部門自己找來的工具：客服用的通訊軟體、業務自己維護的試算表、行銷在用的電子報平台、會計端的發票系統。

盤點的方式很單純，請每個部門回答四個問題：平常會打開哪些網站或軟體、用它做什麼、資料存在哪裡、誰有帳號。把答案整理成一張表就好，不需要任何技術描述。

這份表的用途有三個：讓廠商判斷哪些系統需要串接、哪些可以在新系統上線後退場；提早發現「只有一位同事在用但整條流程都靠它」的隱形關鍵工具；以及估算資料轉移的工作量。

最常踩到的一步是只盤點「公司正式採購的系統」，漏掉部門自行使用的工具。那些沒有出現在採購紀錄裡的東西，往往才是上線後跳出來喊「我的資料呢」的來源。

第三方帳號與權限：最常卡住上線的一關

開發要能進行，通常需要接觸幾類帳號：網域註冊商、主機或雲端平台、金流與物流服務、社群與廣告平台、分析工具、郵件寄送服務。這些東西的共同問題是——公司往往不知道帳號在誰手上。

比較常見的狀況包括：網域是好幾年前某位離職同事用個人信箱註冊的、金流後台只有老闆本人的手機能收驗證碼、主機是前一家廠商代管而公司從未持有登入資訊。這些事單獨看都不難處理，但每一件都可能耗掉好幾個工作天，而且往往在最不能等的上線前才被發現。

建議在啟動前就做三件事：確認每個帳號的持有人與登入方式、把註冊信箱換成公司的共用信箱而非個人信箱、以及確認能不能開立子帳號給廠商，而不是直接交出主帳號密碼。網域與主機之間的關係如果不清楚，可以先讀網域與 DNS 白話指南再來盤點。

素材與資料：內容準備往往比開發還慢

畫面做好了、功能也通了，上線前才發現產品照片只有十張、服務說明還是五年前的版本——這是相當典型的結尾困境。內容的準備速度通常慢於開發速度，因為它需要的是業主端的時間，而不是廠商的人力。

啟動前該先確認的有幾項：文字內容誰來寫、照片是既有的還是要重拍、有沒有可用的品牌識別檔案（標誌的原始檔、標準色、字體授權）、要匯入的資料目前是什麼格式。

判斷方法：把網站或系統的每一個頁面列出來，在每一項後面寫上「內容由誰提供、預計何時給」。填不出日期的那幾項，就是需要現在決定的事——是要外包撰寫、要延後上線，還是第一版先不做。

把「現在怎麼做」寫下來：內部流程確認

系統是把現有流程數位化，所以流程本身如果講不清楚，系統也做不出來。這一步的工作是把日常作業寫成一條一條的步驟，包括每個步驟由誰執行、需要什麼資訊、做完之後交給誰。

寫的時候要特別記錄兩種情況：例外處理與人工判斷。「訂單金額超過一定額度要主管核准」「老客戶可以先出貨後付款」這類規則平常靠默契運作，但系統無法靠默契。把這些寫下來，往往會發現同一件事各部門的做法並不一致——這種發現本身就有價值，而且在開發前發現遠比上線後便宜。

這一步也是需求文件的雛形。如果不確定該記錄到多細，可以照軟體需求怎麼寫的結構整理，不需要寫得像規格書，能讓外人看懂就夠了。

第一次啟動會議該談什麼

啟動會議的目的不是簡報公司歷史，而是把接下來幾個月的運作方式講定。值得花時間談的有這幾項：

• 專案目標與成功定義：這個系統要解決什麼問題，什麼情況下算做對了。
• 優先順序：如果只能做一半，哪些是第一版必要的。
• 雙方窗口與回覆時效：誰對誰、多久內要回。
• 溝通管道與頻率：固定會議排在什麼時候、日常問題走哪個管道、什麼事要留下書面紀錄。
• 驗收方式與時間點：誰來測、測什麼、多久內要給回饋。
• 已知的限制：不能更動的舊系統、必須配合的內部稽核程序、無法錯過的檔期。

最常踩到的一步是把啟動會議開成需求討論會，三小時全花在爭論某個按鈕的位置，卻沒談到誰能拍板、驗收怎麼算。細節可以慢慢談，規則要先講清楚。選擇合作對象時該問的問題，如何挑選軟體開發公司裡有更完整的清單。

啟動前的最後自我檢查

在開工日之前，用這幾個問題確認一次：

• 決策窗口是誰？他能在多少範圍內直接決定？
• 所有相關系統與帳號都盤點過了嗎？登入資訊拿得到嗎？
• 第一版的優先順序，內部有共識了嗎？
• 內容與資料由誰提供、什麼時候給，有明確日期嗎？
• 現有流程有沒有寫下來，包含例外狀況？
• 驗收由誰負責，他知道自己要投入時間嗎？

六題都能明確回答，專案的前兩週就不會浪費在等待上。有兩題以上答不出來，建議把開工日往後挪，先把準備做完——延後開工把準備補齊，通常比帶著空白硬上少延很多。

上面這份清單如果對照下來有幾格填不出來，那幾格就是值得先拿出來談的地方。把你的現況跟 NETVANA 聊一聊，我們可以陪你把清單走一遍，判斷哪些一定要在開工前補齊、哪些可以邊做邊補。軟體服務沒有固定套餐，一律先了解需求再報價；想知道每項服務實際交付什麼，看軟體服務介紹。

延伸閱讀：想知道時程通常是怎麼被吃掉的，看軟體專案為什麼總是延誤；驗收該由誰負責、怎麼綁付款節點，看軟體驗收怎麼做；第一版該做什麼不該做什麼，看MVP 最小可行產品開發指南；如果要做的是內部使用的系統，可以先讀內部後台系統開發指南。