App 開發範圍，寫五行寄出去就夠了

每一家算的是不同的 App

「大概像二手交易 App 那樣。」需求用這一句話寄出去，收到的人各自畫出不同的東西。有人想到的是刊登和列表兩個畫面，有人預設聊天、身分驗證、檢舉處理本來就在裡面。算的 App 不一樣，回來的金額當然不一樣。問過幾家的人，最先被嚇到的都是報價的落差。那不是誰在灌水。

會把範圍拉開的位置只有五個：畫面有幾個、要上哪個商店、登入金流推播要不要、需不需要後端、營運用的功能做到哪裡。這五行填好寄出去，收回來的報價才第一次站在同一條基準線上。

先數畫面

把使用者從打開 App 到達成目的會經過的畫面，一個一個寫下來。導覽、註冊、首頁、列表、詳情、發佈、個人頁、設定。這裡最常漏掉的是狀態畫面：一筆資料都還沒有的時候看到什麼、出錯的時候看到什麼、搜尋沒有結果的時候看到什麼。連這些一起寫，「很單純的 App」清單馬上就長了。畫面數會同時乘在設計和開發兩邊，這份清單的長度就是時程和費用的骨架。

不用會畫圖。紙上畫方塊，用箭頭連起來就行。畫得漂亮是設計師的事，業主要做的是確認沒有漏掉的畫面。這份清單會變成你跟開發團隊的共同語言，日後「這個本來就不在範圍裡」的爭執也會少。

上哪個商店，什麼時候上

iOS 和 Android 都要上，做法先分岔。兩邊各寫一套原生程式，接近同一個 App 做兩遍，工作量整個往上跳。跨平台框架用一套程式碼蓋住兩個商店，不過相機、通知這種貼著裝置的功能，還是得按平台分別再處理一次。WebView 把網站裝進 App 外殼，三種裡最輕，代價是只把網站包起來的應用有被 App Store 退件的風險，內容型服務也得先想好加一個只有 App 做得到的功能。

要問的是兩件事：上哪個商店，以及是不是一開始就兩邊都上。早期使用者集中在某一邊的話，先做一個平台、把範圍砍掉一半，完全站得住。

登入、金流、推播後面拖著的東西

需求清單上一行字的項目，實作起來是一整塊。登入不是一顆按鈕，是一整套帳號體系。有註冊就要有忘記密碼，也要有刪除帳號。每接一種社群登入，就多一份串接工作。金流也不是把付款畫面做出來就結束，前面有金流服務商的簽約，後面接著取消、退款，還有付款失敗要怎麼處理。推播是發送端的服務和接收端的設定頁面成對出現，屬於行銷訊息的話，還要加上取得同意的流程。

資料離開手機的那一刻

五個面向裡，把範圍拉得最開的是後端。有了帳號、要在多台裝置上看到同一份資料、使用者之間看得到彼此發的內容，從這些條件成立的那一刻起，伺服器和資料庫就進了範圍。資料只待在使用者自己手機裡的 App，這一欄可以整個空著。

使用者看不到的那些畫面

發公告、處理檢舉、管理會員、看幾個基本數字。使用者一輩子不會打開這些畫面，可是服務要轉起來就得有人用。第一版做到哪裡，哪些工作先讓人手撐著，這個取捨本身就算在範圍估算裡面。

五行還沒填滿也沒關係

只有一句「我想做一個這樣的 App」，就足夠開場了。Weple 的 App 開發從跟業主一起填這五個面向開始，先做出一份範圍文件，再用那份文件開時程和費用。已經收到別家的報價單，我們可以一起拆開看金額差在哪一欄。一項一項怎麼算，價格說明裡寫了。