设计交付物 — 谁看着什么在开发
一句话总结
设计成果的读者是开发者，目的是一致的——**让用户可以直接编写代码而不需要再次询问。**如果问题再次出现，那么该成果就是失败的。
为什么需要这个
一旦把设计书视为形式，该项目就会在开发阶段停止。如果产出物不合格，开发者每次都要问策划者，策划者一天要被问二十个同样的问题，答案不是在文件上，而是分散在邮件中。两个月后新开发者加入，就无法阅读邮件。
更大的问题是无法同时进行工作。如果屏幕开发者和后端开发者要分担同一屏幕，他们都需要看相同的明细，如果没有明细，一方就会等待另一方。产出的真正用途不是记录，而是并行化。
设计成果是“发送给开发者的明细”
分析阶段结束后进入设计阶段。这个阶段的成果的读者是开发者， 目的只有一个——让开发者可以编写代码而不必再问策划者。 如果问题再次出现，那么该结果就是失败了。
实际在现场使用的大概有这五个。
| 产出物 | 读者 | 如果没有的话会发生的事情 |
|---|---|---|
| 菜单结构也 | 全员 | 画面ID系统因人而异 |
| 画面定义书 | 画面开发者、出版商、QA | 每次都问一个按钮的动作 |
| ERD/表定义书 | 后端、DBA | 列类型和长度因开发者而异 |
| 界面定义书 | 双方系统开发者 | 联动测试第一天一整天都浪费了 |
| 项目目录 | PL, QA | 没有以单元为单位的进度率，以感觉报告 |
画面定义书——不是画，而是“动作”才是正文
看新人制作的画面定义书，只有画面截图大大地贴着。其实开发者需要的是 应该是画下面应该有的表格。
- 项目定义：项目名/是否必填/输入格式/最大长度/初始值/代码参考
- 活动定义：按哪个按钮→进行什么验证→去哪里
- 错误处理：验证失败时语句，服务器错误时语句
- 权限：谁可以看到这个画面，哪些按钮对谁失效
特别是缺少权限的画面定义书在综合测试中一定会出现错误。 只有管理员才能看到的按钮被普通用户看到，这个缺陷越晚发现越贵。
表格定义书——标准单词优先
公共项目有《公共机构的数据库标准化指南》， 私营大企业也大部分都有内部数据标准。顺序如下。
표준단어사전 (주문 → ORD, 고객 → CUST, 명칭 → NM, 일자 → DT, 금액 → AMT)
↓
표준도메인 (금액 → NUMBER(15,2), 일자 → CHAR(8), 여부 → CHAR(1) Y/N)
↓
표준용어 (주문금액 → ORD_AMT, 고객명 → CUST_NM)
↓
테이블정의서 (ORD_AMT NUMBER(15,2) NOT NULL DEFAULT 0)
遵守这个顺序的话，即使在不同团队制作的桌子上CUST_NM总是顾客姓名
总是同一条路。不遵守的话CUST_NAME，CUSTOMER_NM，CUST_NM在这个DB里
共存，3年后数据转移时付出代价。
是否栏是Y/N一个座位，日期是CHAR(8) YYYYMMDD罗的做法仍然
很多。虽然可能不喜欢，但如果必须与已经那样创造的遗产联系起来的话
只有把新桌子弄得不一样才是最大的代价。标准不是“最好”，而是“达成一致”。
接口定义书——发生事故最多的文件
系统间的联动是双方公司不同，开发者不同，测试日程不同。 所以在条约上没有写的东西100%会以不同的方式实现。
必须写的东西：
- 接口ID、业务名称、发送/接收系统、关联方式（REST/文件/队列/DB链接）
- 周期（实时/日分配/时间分配）和视觉，以及再处理规则
- 专业布局：项目名/类型/长度/必填/样本值/备注
- 字符集（UTF-8? EUC-KR?）、日期格式、金额的小数位、符号表示
- 响应代码体系和对每个代码的接收方措施(重新尝试/中断/负责人通知)
- 故障时联系体系和SLA
短信集和日期格式——即使只写了这两项，联动测试的第一天也会结束。 有现场格言：“接口定义书中没有的东西一定被不同的实现。”
设计成果的真正用途是“同时工作”
如果问为什么用这么多文档，答案是并行化。 SI项目人数几十人，期限固定。画面开发者、API开发者、 DBA，联动负责人如果不互相等待，同时工作的话，在这期间 必须有“商定的接口”作为文件存在。
敏捷团队能够减少文件的原因是每天在同一个房间里对话。 SI是公司不同，楼层不同，甚至网格分离。在这种条件下 文件不是官僚主义，而是激励协议。
在成果审查（评论）中需要实际看的东西
在审查会议上纠正错别字是在浪费时间。应该看的是这个。
- 附有要求事项ID吗（可以追踪吗）
- 有数字吗（长度、件数、周期、超时）
- 有例外流程吗（只有正常流程的设计书是半份的）
- 对方签名了吗（接口定义书是双方协商的文件）
在现场相遇的样子
设计文件不完善时，最先崩溃的是联动测试的第一天。
如果接口定义书中字段长度或必填状态为空，则双方开发者各自合理猜测后制作。而且在第一次联动测试中，专业不一致。那天不是开发，而是通过协商完成整个过程，协商结果通常不是留在定义书中，而是留在信使中——所以两个月后同样的问题再次出现。
在画面定义书中以其他方式表现出来。如果只有画幅大大的贴着，没有动作表的话，开发者会问每个按钮的策划者。策划者不在的时候，那个画面就会停止。如果没有成果物，人就会成为瓶颈。
所以在产出物审查中要看的是，不是句子的一致性，而是“看到这个，开发者能不能一个人拍下来”。