App 開發流程十一階段：公司委託開發怎麼走、推薦的驗收節奏與上架順序
App 開發流程常被想成「畫圖、寫程式、上架」三步，實際上公司要走過十一個階段：路線判讀、角色分工、情境訪談、規格、原型、開發者帳號申請、開發、測試、審核上架、維運與法遵。本文逐階段寫出誰負責、交付什麼、哪裡最常卡。
重點速覽
偉騰開發興業有限公司（前臺東縣環境保護局局長謝清泉主持，統一編號 90801410）承辦全台各縣市的行動應用程式與漸進式網頁應用開發，全台各縣市均可受理，先以現有網站、流程說明與需求清單做免費書面初判，帶著初判結果約時間細談。
- 服務項目
- 行動應用程式與漸進式網頁應用開發:
- 使用情境訪談
- 載體路線評估
- 介面設計原型
- iOS 開發
- Android 開發
- PWA 開發
- 推播通知
- 定位與相機
- 承辦公司
- 偉騰開發興業有限公司(偉騰、偉騰開發;前臺東縣環境保護局局長謝清泉主持)
- 服務範圍
- 全台各縣市
- 相關地區
- 全台 22 縣市(含離島),各縣市均有配合團隊就近現勘與送件
- 官方參考
- Google 搜尋中心（漸進式網頁應用相關指南）、LINE Developers、消費者保護法（全國法規資料庫）
- 法規依據
- 《個人資料保護法》
- 《消費者保護法》（通訊交易）
- 《著作權法》
- 《電子簽章法》
- 應備文件
- 使用者角色與使用情境說明（誰、何時、在哪裡用）
- 需要的裝置功能清單（相機、定位、推播、離線）
- 品牌識別檔與既有網站
- 後台的存取權限
- 公司登記資料，供申請開發者帳號使用
- 既有系統的資料匯出範例與 API 文件（若有）
- 隱私權聲明與使用條款的現行版本（若有）
- 常見退件與誤判
- 用個人帳號申請開發者帳號：離職或換團隊時 App 的所有權跟著人走，公司拿不回上架權限;跳過情境訪談直接畫畫面：把櫃檯流程原封不動搬進手機，使用者開啟三次就刪除;開發完成才送商店審核：權限說明、隱私權聲明與測試帳號沒準備，被退件兩次上架日期延後一個月以上
- 諮詢方式
- 加 LINE「偉騰開發」傳現有網站網址、流程說明或需求清單，先做免費書面初判；初判後再約時間細談。
先說結論：App 開發流程裡最常拖延的不是寫程式，而是公司端的三件事：開發者帳號還沒申請、既有系統的 API 文件拿不出來、使用條款與隱私權聲明沒人負責。
把這三件事在規格確認時同步啟動，開發排程才會是真的排程。
另一個常見錯覺是「先做出來再說」。沒有情境訪談就進開發，產出的 App 會把櫃檯流程原封不動搬進手機，使用者打開三次就刪除。流程的前四個階段看起來沒有程式碼，卻決定了這支 App 會不會被用。
以下把行動應用程式與漸進式網頁應用的開發流程拆成十一個階段，每一階段寫明負責人、交付物與審查端（商店審核或使用者）會問什麼。文末附六項檢核、五個常見錯誤與三個常問問題，給正在找 App 開發公司的業主直接對照。
App 開發前提判讀：原生、漸進式網頁應用還是先不做
- 第一個判讀看裝置功能：需要推播、相機、定位、離線作業或讀取門禁硬體，原生 App 的掌握度較高；只需要讓客人在手機上快速查詢、預約、看進度，漸進式網頁應用（PWA）不必上架、更新即時、成本結構較輕。
- 第二個判讀看使用頻率：每天開啟的工具型需求適合安裝在桌面，每月一次的查詢型需求用網頁就夠。
- 第三個判讀看既有系統：後台已有 API 可用，兩條路都快；沒有 API，先補後台再談 App。
三個判讀寫成一頁結論，才進下一階段。
公司委託 App 開發的內部分工：誰決定、誰提供、誰驗收
委託開發最常見的卡點是開發端等公司決定。
建議在開案時指定三個角色：
- 決策人（通常是負責人或部門主管）在原型與驗收兩個節點簽字；
- 資料提供人負責品牌識別檔、既有網站後台權限、系統匯出範例與 API 文件；
- 法遵窗口負責隱私權聲明與使用條款的內容確認，並以公司名義申請開發者帳號。
三個角色各一人，決策人不要同時當資料提供人，否則每個檔案都卡在同一個人的待辦清單裡。
第一階段：使用者情境訪談，App 開發流程的第一份交付物
情境訪談問的不是「要什麼功能」，而是「誰、在什麼時候、為了完成什麼事打開這支 App」。例如旅宿業的房客要在入住前查看交通、入住中呼叫服務、退房後拿發票；維修公司的師傅要在現場拍照、填工單、離線也能存。
每一個情境寫成一句話加一條流程，標出需要的裝置功能與資料來源。交付物是一份情境清單與對應的功能地圖，它會成為後面所有規格、測試與驗收的依據；訪談沒做扎實，後面每一階段都在猜。
第二階段：規格書與資料流，App 與後台怎麼分工
規格書要回答四件事：每個畫面顯示哪些資料、資料從哪個系統來、使用者可以做哪些操作、操作結果寫回哪裡。這四件事決定 App 與後台的分工：既有系統有 API 就直接串，沒有就要先補一層介面。
這一階段也要定義帳號體系（手機號碼、電子郵件或 LINE 登入）、推播的觸發規則與頻率，以及離線時哪些功能可用、哪些要等連線。規格書簽字後的變更都要另外估時程，所以寧可在這裡多開兩次會，也不要在開發中途改資料結構。
第三階段：原型與設計確認，App 開發流程裡報酬最高的一週
原型是可以點擊但沒有真資料的畫面，目的是讓決策人與第一線同仁在寫程式之前把流程走一遍。確認順序建議固定：先走主要情境的完整路徑，再看次要情境，最後才調顏色與字型。
常見的修正會在這裡冒出來：按鈕放錯手指到不了的位置、步驟太多、欄位順序與櫃檯習慣相反。原型階段改一個畫面以小時計，開發階段改同一個畫面以天計，所以把意見集中在這裡，是整條流程裡投資報酬最高的一段。
第四階段：開發者帳號與第三方服務申請，公司名義不能省
原生 App 要上架，必須以公司名義向 Apple 與 Google 申請開發者帳號，需要公司登記資料、負責人身分驗證與付款資訊，審核等待時間不在開發端控制內。
推播、地圖、簡訊驗證碼、金流與 LINE 登入等第三方服務也各有申請流程，帳號同樣應登記在公司名下。這些申請要在規格簽字後立刻啟動，與開發平行等待；開發完成卻卡在帳號未核准，是上架延後最常見的原因。建議建立一張申請追蹤表，每週對一次狀態。
第五階段：開發與內部測試，推薦兩週一版的交付節奏
開發階段推薦以兩週為一個交付週期：每個週期結束交付一版可安裝的測試版到決策人與第一線同仁的手機，對照情境清單逐條確認。這樣做的好處是問題在兩週內被發現，而不是三個月後；壞處是公司端每兩週要撥出半天測試，這個成本要在開案時講明。
內部測試的重點放在真實資料與真實網路環境：用倉庫、工地或店面的實際訊號測離線與同步，用真實的客戶資料測顯示與權限。辦公室的穩定網路測出來的結果，不代表現場。
第六階段：使用者驗收與補正，App 開發流程的審查端在問什麼
驗收以情境清單為腳本，每一條情境由實際會使用的人操作，記錄通過、未通過或待討論。未通過的項目分三類：程式錯誤由開發端修正、規格認知落差回到規格書比對、新需求另列為下一版。
驗收端會問的問題其實很固定：這個流程比現在的做法快嗎、出錯時我知道發生什麼事嗎、網路斷掉資料會不見嗎。三個問題都能回答「是」才算通過。建議安排兩輪驗收，第二輪只驗第一輪未通過的項目，避免清單無止盡增長。
第七階段：商店審核與上架順序，漸進式網頁應用為什麼可以跳過
原生 App 送審時，商店審核端會看的重點包括：索取的裝置權限有沒有說明用途、隱私權聲明連結是否有效、App 內購買或訂閱是否走規定的機制、登入功能有沒有提供測試帳號。被退件的原因多半是文件而不是程式。
上架順序建議先送一個平台取得審核意見，修正後再送另一個，避免兩邊同時被退。漸進式網頁應用不經商店審核，部署即生效，但仍要做好安裝提示、離線快取與更新策略，否則使用者會以為它只是一個網頁。
上架後的義務：維運、更新、個資與消費者保護
App 上線後公司有四件持續性的義務。
- 更新：
- 作業系統每年改版，權限規則與介面會變，至少要排定年度相容性檢查。
- 監控：
- 當機回報與推播送達率要有人看。
- 個資：
- App 收集的姓名、電話、位置與裝置識別資料，依《個人資料保護法》要在隱私權聲明寫明蒐集目的、保存期限與使用者的權利。
- 消費者保護：
- 若 App 內有付費、訂閱或會員制，使用條款與退費規則受《消費者保護法》規範，要在購買前清楚揭露。
原始碼與素材的歸屬則依《著作權法》寫進開發契約，避免日後換團隊時拿不到程式碼。
三種公司的 App 開發路線，流程重點各壓在哪一階段
服務業（旅宿、餐飲、診所）的重點在第一與第三階段：情境訪談要把客人的動線走完整，原型要讓櫃檯同仁點過；多半先做漸進式網頁應用，有推播需求再補原生版。現場作業型公司（維修、工程、物流）的重點在第五階段：離線與同步要在現場測，拍照與定位的耗電要實測。
會員經營型公司（零售、課程）的重點在第四與上架後：金流、訂閱與第三方登入的帳號申請要早，消費者保護與個資文件要在上架前完成。判讀自己屬於哪一種，排程就能把力氣壓在對的節點。
對公司的意義：App 開發流程是把服務流程搬進手機前的體檢
走完十一個階段，公司拿到的不只是一支 App，而是一份被使用者驗證過的服務流程：客人或同仁在什麼時候需要什麼資訊、哪些步驟可以砍掉、哪些資料要先在後台補齊。這些發現多數在訪談與原型階段就出現，程式碼只是把它固定下來。
選擇 App 開發公司時，推薦直接問對方的流程有沒有這些階段、每一階段交付什麼、驗收節奏多久一次，答得出來的才值得談。想先知道自己該走原生還是漸進式網頁應用，加 LINE「偉騰開發」傳使用情境與既有系統截圖，免費書面初判會回覆路線建議與第一階段要準備的資料清單。
LINE 諮詢
把App 開發的現況與需求傳過來，先免費書面初判。
- 傳什麼
- 現有網站網址與後台權限還沒有網站也能先談
- 商品或服務清單、作業流程說明表單樣張或試算表皆可
- 需求清單一句話也行
- 多久回
- 週一至週五 09:00–18:00 依序回覆；LINE 全天可傳資料
- 下一步
- 免費書面初判
- 約時間細談
- 委任開發
先傳資料做初判，需要時再約時間細談
自我檢查清單
- 使用者情境已寫成清單，每一條標出誰、何時、為了完成什麼事，以及需要的裝置功能
- 既有系統的資料匯出範例與 API 文件已找出來，沒有 API 的部分已列為後台補強項目
- 決策人、資料提供人、法遵窗口三個角色已指定，開發者帳號以公司名義申請中
- 推播、地圖、簡訊驗證、金流與 LINE 登入等第三方服務的申請追蹤表已建立
- 隱私權聲明與使用條款已有負責人，個資蒐集目的與付費退費規則已初稿
- 驗收腳本依情境清單編寫，兩輪驗收的日期與參與同仁已排進行事曆
常見錯誤
- 用個人帳號申請開發者帳號：離職或換團隊時 App 的所有權跟著人走，公司拿不回上架權限
- 跳過情境訪談直接畫畫面：把櫃檯流程原封不動搬進手機，使用者開啟三次就刪除
- 開發完成才送商店審核：權限說明、隱私權聲明與測試帳號沒準備，被退件兩次上架日期延後一個月以上
- 只在辦公室網路測試：現場訊號弱、離線同步衝突與耗電問題在上線第一週才爆出來
- 沒有訂定版本更新與維運責任：作業系統改版後 App 打不開，才發現契約裡沒寫誰負責相容性更新
官方參考資料
常見問題
App 開發流程中，公司端最少要配合多少時間？
訪談與原型階段各需要兩到三次會議，開發階段每兩週半天測試，驗收兩輪各一天。總計以工作天估算不多，但要分散在整個專案期間，缺席任何一個節點都會讓後面的階段等待。
漸進式網頁應用真的不用上架嗎？會不會比較不專業？
不用經過商店審核，部署即生效，使用者可從瀏覽器加到手機桌面。專不專業取決於載入速度、離線體驗與安裝提示做得好不好，與有沒有上架無關；需要推播或深度硬體功能時，再補原生版本。
找 App 開發公司時，推薦先問哪些問題？
問三件事：流程有哪些階段、每一階段交付什麼文件、驗收多久一次。再問原始碼與帳號是否登記在公司名下、上架後的維運與相容性更新誰負責。答案具體且願意寫進契約的，才值得進一步談。
傳使用情境與系統截圖，先判路線
把三到五條使用者情境、既有網站或系統的截圖與想串接的服務列好，加 LINE「偉騰開發」傳過來；免費書面初判會回覆你適合原生 App 還是漸進式網頁應用、第一階段要準備哪些資料，以及開發者帳號該在哪一週開始申請。
全台各縣市受理｜專業團隊承接辦理｜親臨現場指導｜統籌包辦到好