小程序开发前先定什么：功能清单、页面流程与账号准备
小程序项目最容易出问题的阶段，往往不是写代码，而是启动前那几周。需求还在口头讨论，就先追问工期和报价，后面几乎一定会返工：页面改了三版，功能加了两轮，原本能两周定下来的事拖成一个多月。下面这套顺序，目的是在动工前把边界定清楚，让后面的排期和费用有共同的讨论基础。
先分清“想做的”和“这一版要做的”
内部讨论功能时天然是加法：每个人都能说出几个“顺便也能做”的点。定稿的原则不是把所有想法砍掉，而是这一版只跑通一条主线业务，其余进“以后再说”清单，并写清什么条件下再排期。清单上没有取舍，工期就没有意义。
第一步：把角色和场景写成完整的句子
不要写“员工可以提交申请”这种抽象描述，要写清谁、在什么设备上、什么情况下、完成什么动作、做完之后谁来处理。抽象描述看起来简洁，实际藏着一堆没决定的事。
- 门店店长在手机端拍照上传，提交后不需要再登录电脑端补录
- 审核人在收到提醒后可以直接通过或退回，退回时必须填写原因
- 管理层只看汇总结果，不逐条操作
这里有个容易漏的检查点：把角色数量数一遍。角色通常不超过三四个，一旦出现五六个角色、七八种状态，多半说明线下流程本身还没理顺，先梳理流程比先做界面更划算。
第二步：功能清单分三栏，每条标注依赖
把讨论出来的功能逐条落到三栏里，比开会争论有效：
- 一定要：缺了这条，主线业务跑不通
- 可以简化：能用现成工具替代，比如先用导出表格看数据，暂不做复杂报表
- 以后再说：写清触发条件，例如提交量明显上升、或某个岗位开始常态化使用之后再排期
每条功能后面再补两个标注：依赖哪个账号或接口，资料由谁提供。这两个空着的条目，后面一定会拖进度——不是开发慢，而是等人给东西。把负责人名字写上去，比写部门更有用。
第三步：页面流程只画主干，异常状态一起标
用纸笔或任意工具画主线即可，不必追求好看。重点是别只画“顺利的时候”，把三类状态一起写出来：列表没有数据时显示什么，提交失败提示什么，网络不好时能不能重复提交。这三处是上线后用户投诉最集中的地方，也是评审时最容易被一句“到时候再说”带过去的。
涉及支付、审批、消息通知的，还要写清通知发到哪里（小程序内、短信、企业微信等），以及用户关掉通知后回到小程序能不能看到待办。这类细节如果留到开发阶段再定，改的往往不是文案，而是页面结构。
第四步：账号、域名与接口归属先落到纸面
- 小程序账号主体是谁，管理员手机号和邮箱由谁持有
- 是否需要复用已有系统的登录状态，接口由谁提供、有没有可用的文档
- 数据最终存在哪里，导出和备份由谁负责
这一步不涉及技术判断，却是最常见的卡点。账号握在已离职人员手里、接口方排期未定、服务器归属不清，都应该在启动前暴露，而不是做到一半才发现。
确认稿应该包含什么
定稿不是一份排版漂亮的方案，而是几页能对着验收的东西：
- 角色与场景清单，每条是完整的一句话
- 三栏功能清单，附带依赖和资料提供方
- 主干流程图，标注空、错、慢三类状态
- 账号、接口、数据归属的确认结果
- 明确不做的范围，以及后续调整的排序方式
这份稿子的作用是减少返工，不是把需求一次写死。后续调整仍然会发生，有了基线，才能判断一次改动属于补充细节还是推翻结构——前者按排期插入，后者要重新评估。
什么情况下不适用这套顺序
如果业务本身还在试，规则每周都在变，硬做一份完整清单反而浪费。这时可以先做一个只跑通主流程的原型或最小版本，用真实使用情况反过来定清单。另外，页面结构固定的展示型小程序，流程梳理可以压缩，重心放在内容准备、上架审核和上线前的核对上，不必套用完整流程。
几个常被跳过的检查点
- 图文、资质、合同模板等资料由谁准备、什么时候交
- 测试用哪些账号，是否需要真实数据环境
- 上线后谁能修改内容，改动是否需要重新提交审核
- 使用中出现问题联系谁，以什么方式响应
这些在启动前问清楚，后面的工期和费用讨论才有依据。小程序、网站建设、定制软件在这件事上逻辑一致：先定边界，再谈排期。