开发指南 / 新 App 与首版开发
App 第一版要做什么？从一项完整工作定范围
第一版不必有很多功能，但用户要能完成主要工作。如果数据无法保存、申请没人处理，即使画面齐全，也还不能投入使用。
第一版要让使用者做完什么？
想做 App，通常已经有一个用途：客户申请服务、同事记录工作，或让现有业务可以在手机处理。接下来要想清楚的，是使用者会怎样操作，以及公司怎样接手处理。
例如客户成功提交申请，同事却没有地方查看、指派和回复，这个 App 仍未能处理一宗完整申请。规划首版时，把客户和管理员的步骤一起画出来，就较容易分清哪些功能现在要做。
用手机网站、App，还是先做原型？
客户偶尔填写表单、查看信息或预约，可以先比较手机网站和 App。需要离线工作、设备功能或频繁使用时，再明确 App 的必要能力。不同平台是否共用代码，要根据实际功能和后续维护判断。
把功能分成“少了便不能完成主要工作”及“之后再改善”。账户权限、必要后台、错误提示与数据保存通常影响整条流程，不能只按画面数量估算工作。
可点击原型
适合先观察使用者是否理解流程；可以用模拟资料。它不能证明正式数据保存、权限及集成已完成。
手机网站
使用者偶尔开启链接、填表或查看资料，可先评估。仍要按实际浏览器测试设备功能及离线需要。
正式 App
当反复使用、设备集成及分发方式有明确需要，再确认平台与实现。要把后台、测试及上架准备一并纳入。
服务申请 App，首版可以包括什么？
以下为说明方法的假设例子，并非客户案例或已交付成效。
假设要建立服务申请 App：客户注册、提交需求、查看处理状态；管理员接收、指派及更新申请。第一阶段先把这条流程连通，推荐奖赏、社交功能及复杂报表留待有实际使用资料后决定。
首版最容易漏掉的三件事
提交之后，谁真正处理？
管理员也是使用者。谁看得到申请、谁可以改状态、何时通知客户，都要有安排。初期由人工处理也可以，但要写清楚怎样交接，避免 App 显示“处理中”，实际没有人收到工作。
网络差的时候，画面说了什么？
同一个提交动作，可能是正在送出、已保存但未收到回复，或根本未能送出。使用者要知道现在属哪一种情况。测试时关掉网络再重试，核对记录及消息；单靠一个转圈图示，并不能处理资料是否重复的问题。
管理权与源代码，是否交到你手上？
开始前，明确源代码、开发者账户、服务器、第三方服务和发布文档由谁管理。交付不能只有一个安装链接。即使由同一位开发者继续维护，也应保留完整的账户和部署信息，方便后续修改与交接。
能展示、可试用、可上架，是不同里程碑
- 用一般账户及管理员账户走完整条流程，核对权限、数据保存及重新登录后的状态。
- 测试网络中断、重复提交、空白资料及第三方服务失败；需要付款时另核对付款与订单状态。
- 分别确认可操作的测试版、可提交审核的版本和正式发布。应用商店审核由平台决定，写完代码不等于已经获准上架。
日期很紧，应该删功能还是压缩测试？
比较 App 报价时，确认是否包括设计、前后台、账户权限、测试设备、第三方集成及交接。现成画面或 AI 生成界面可以是起点，但仍要核对背后的资料处理、错误情况及管理功能。
日期紧张时，可以缩小首版范围、分批测试，或先完成内部试用版。一项尚未准备好的集成可能阻碍整个流程。正式发布时间也要留出应用商店审核和修改的时间。
首版推出后，怎样决定下一步？
先看指定使用者能否完成主要工作、在哪一步停下来，以及是否愿意再次使用。假如申请送出后没有人回复，增加社交分享并不会解决眼前问题；应先改善完成申请所需的整条流程。
访谈时请对方做一次实际任务，观察后才追问原因。把想要的功能与已经遇到的障碍分开记录，再连同处理量、维护成本及业务价值排优先次序。首版的价值，是让下一次投资有更具体的依据。
把需要整理成一页简介
提供使用者、最重要的一条流程、现有设计或草图、数据来源，以及有权管理的开发者账户。估算时间时要一并安排设计确认、内容、集成测试、客户验收及商店回复；交接时确认源代码、账户、部署文件与维护方式。
开始前，还有这些常见问题
有 AI 做好的画面，是否已完成大部分开发？
画面有助讨论，但完成程度要看实际操作。用两种角色走完整流程，核对数据保存、权限、错误情况及部署，才知道哪些可沿用、哪些仍需开发。
第一版可以先不做所有平台吗？
可以按真正的使用者及工作情境评估。先选必要平台或内部试用方式，并记录暂未支持的需要；之后是否扩充，应按实际使用及维护成本决定。
