应用开发者的工作与完整旅程
本章目标：理解“开发业务应用”究竟在做什么，知道一套可靠的开发过程为什么必须从业务开始，而不是从设计器开始。
1. 应用不是一张电子表格
一张电子表格可以记录数据，但一个业务应用还必须回答更多问题：
- 谁可以发起这项业务？
- 需要填写哪些信息，哪些信息由系统自动得到？
- 哪些情况不允许保存或提交？
- 提交后由谁处理，遇到不同条件走哪条路线？
- 处理过程中哪些内容还可以修改？
- 谁能查看哪些数据？
- 管理者怎样知道积压、金额、进度和异常？
- 业务发生变化后，怎样安全地调整应用？
所以，应用开发的本质不是“画页面”，而是把一套业务运作方式表达清楚，再让应用稳定执行这套方式。
可以把一个应用理解为六个相互配合的部分：
| 部分 | 回答的问题 |
|---|---|
| 业务数据 | 这项业务需要记录什么？ |
| 表单体验 | 用户如何输入、查看和修改？ |
| 业务规则 | 什么条件下允许或禁止什么？ |
| 自动动作 | 哪些重复工作可以自动完成？ |
| 流程协作 | 事情交给谁、按什么顺序处理？ |
| 权限与视图 | 谁能做什么、看到什么、怎样管理？ |
只完成其中一部分，通常只能得到一个演示页面，而不是可交付的应用。
2. 应用开发者的责任
应用开发者处在业务人员与 Kimpo 之间，主要承担四类责任。
2.1 把业务听明白
业务人员常用自己的工作语言描述需求，例如：
- “金额大了要再批一下。”
- “主管应该能看本部门的。”
- “以前的单不能随便改。”
- “选了物品以后价格要自己出来。”
应用开发者要继续追问，把这些说法变成没有歧义的规则：
- “金额大”具体从多少开始？
- 金额等于边界值时走哪条路线？
- “主管”是发起人的直属主管，还是固定角色？
- 本部门是按当前部门，还是申请发生时的部门？
- 哪些状态算“以前的单”？谁仍然可以改？
- 价格从哪里取得？没有价格时怎么办？允许人工覆盖吗？
2.2 把业务设计清楚
需求并不会自动变成一个好的应用。应用开发者需要决定：
- 哪些内容属于同一个业务对象；
- 哪些内容需要单独管理；
- 一条业务记录会经历哪些状态；
- 哪些规则适合自动计算，哪些必须由人判断；
- 哪些步骤需要审批，哪些只需要通知；
- 权限应该按角色、部门还是记录归属控制。
这些都是业务设计决定，不是技术细节。
2.3 把设计搭建出来
在 Kimpo 中把蓝图转成可以使用的应用，包括数据、表单、动作、流程、权限、视图和输出。
可靠的做法是分小步搭建，每完成一小段就试用，而不是一次配置几十个字段和多条流程，最后才发现基础设计错了。
2.4 证明应用真的可用
“保存成功”只是一个很小的检查。真正的验证包括：
- 普通用户能完成正常业务；
- 错误输入会被清楚拦截；
- 不同金额走正确流程；
- 未授权用户看不到或不能操作；
- 退回、撤回、作废等情况符合约定；
- 保存后重新打开，内容和状态仍然正确；
- 管理者能从视图中得到需要的信息。
3. 四类角色的边界
| 角色 | 主要关注点 | 不应被默认要求承担的工作 |
|---|---|---|
| 业务负责人 | 业务目标、制度和最终决策 | 亲自完成所有配置 |
| 一线用户 | 实际工作步骤、常见问题、使用体验 | 替所有部门决定规则 |
| 应用开发者 | 需求分析、应用设计、搭建与验证 | 决定企业级账号和平台运维政策 |
| 实例管理者 | 用户组织、平台服务、安全与运维 | 替业务部门定义采购或审批制度 |
小团队中一个人可能同时承担多个角色，但做决定时仍然要区分自己当前代表哪一种立场。
4. 从零到上线的七个阶段
阶段一：定义问题
明确为什么要做、问题影响谁、什么结果算成功。
阶段二：研究现状
访谈真实人员，观察真实工作，收集现有单据、表格和制度，找出正常路径与异常路径。
阶段三：分析业务
识别业务对象、状态、规则、责任、权限、查询和统计需要。
阶段四：设计应用
形成应用结构、数据字典、表单草图、动作说明、流程图和权限矩阵。
阶段五：增量开发
先完成最小闭环，再逐步加入自动化、审批、权限和管理视图。
阶段六：验证交付
用真实业务场景测试，组织代表性用户验收，准备初始数据、权限和使用说明。
阶段七：运营迭代
观察真实使用，区分缺陷、设计遗漏和新需求，小步调整并持续验证。
5. 贯穿案例如何走这条路
采购申请案例一开始只有一句话：
“我们想做一个采购审批应用。”
经过完整开发过程，它会逐步变成：
- 目标：减少遗漏和重复登记，让审批记录可查询；
- 人员：申请人、直属主管、行政采购员、财务、应用管理员；
- 对象：采购申请、采购明细、物品信息；
- 规则：数量和单价必须大于零，总额自动计算；
- 流程：低金额主管审批，高金额增加负责人审批；
- 权限：申请人看自己的，主管看职责范围内的，行政看已批准事项；
- 视图：我的申请、待采购、采购进度、月度采购统计；
- 验收：正常申请、超额申请、退回修改、撤回、越权访问等场景全部通过。
6. 三条开发原则
原则一：先问业务结果，再问需要什么页面
页面只是承载方式。业务目标和规则不清楚，页面做得再漂亮也会频繁返工。
原则二：先跑通最小闭环，再增加复杂度
第一个版本可以只有少量字段和最简单流程，但必须能完整地“创建—处理—查询”。一个可运行的小闭环比一个配置了一半的大系统更有价值。
原则三：每一个设计决定都要能被业务场景验证
如果无法说明“由谁、在什么情况下、做什么、应该看到什么结果”，这个设计通常还不够清楚。
7. 本章完成标准
- [ ] 能用自己的话解释业务应用与电子表格的区别；
- [ ] 知道应用开发者不只是配置页面；
- [ ] 能列出从问题到上线的七个阶段；
- [ ] 已选择一个准备在后续章节中练习的业务问题；
- [ ] 没有在业务尚未分析前急着创建正式应用。
下一步
下一章先不讨论任何功能，专门学习如何把一句模糊的“想做个系统”转成清楚的业务问题和成功目标。