01
一开始就要求接近成品的原型
原型验证的重点不是完成度，而是要做出哪个判断。过早加入演出和细节，反而会让真正要验证的问题变得不清楚。
容易发生
- 验证范围不断扩大
- 保留或舍弃的判断变晚
- 正式开发前的工时先被消耗
避免方法
- 把验证问题限制在 1 到 3 个
- 先写清楚不做的范围
- 明确每次确认版本要看的事项
委托 Unity 原型前应先决定什么
委托 Unity 原型前，先明确要判断的问题、操作体验、可用素材、确认版本和可以舍弃的范围。
开发咨询中的常见失败模式
如果咨询前的前提没有整理清楚，报价、验证、实现和交接都容易出现返工。这里整理常见的失败模式，以及咨询前可以先准备的事项。
Failure Patterns
咨询前先拆开的事项
不需要一开始就决定所有细节。只要先区分需要判断的事、要做的范围和暂时不做的范围，第一次沟通就会更有效。
02
临近公开才开始处理 Steamworks
成就、排行榜、商店文案和测试权限理论上可以后补，但如果集中到上线前处理，确认时间很容易不够。
容易发生
- 解锁条件和保存时机确认太晚
- 构建与商店设置存在差异
- 测试账号和权限调整耗时超预期
避免方法
- 从公开 3 个月前拆分确认事项
- 尽早整理成就和排行榜条件
- 先确认测试账号和权限
Steamworks 接入上线前应确认的项目
Steamworks 接入应提前整理成就、排行榜、本地化、构建、权限和测试流程，而不是全部留到上线前。
03
Excel 自动化把例外处理放到最后
只按正常数据开始实现，到了真实运行时很容易被列名变化、空栏、表记不一致或人工修正文件卡住。
容易发生
- 例外数据导致处理停止
- 哪些判断交给人不清楚
- 自动化后手动修正反而增加
避免方法
- 实现前先收集例外样例
- 拆分自动检查和人工判断
- 提前决定输出形式和错误提示
自动化 Excel 作业前应先看作业频率
自动化 Excel 或 CSV 作业前，先确认频率、例外、检查规则、输出形式，以及哪些判断仍需人工完成。
04
管理后台先设计画面，后考虑权限
如果画面完成后才考虑权限，可见范围、更新范围、操作历史和 CSV 输出通常都需要返工。
容易发生
- 查看者和编辑者差异不清楚
- CSV 和操作历史权限遗漏
- 审批或确认流程后补
避免方法
- 先准备角色权限矩阵
- 分别确认查看、更新、导出和历史
- 写明初期版暂不处理的权限
管理后台开发最先决定的权限、历史记录和 CSV
管理后台设计前，先决定权限、操作历史、CSV 导入导出、搜索条件和例外处理，会更容易维护。
05
既有项目部分委托时没有完了条件
只委托既有代码的一部分时，如果范围、评审方式、测试和交接预期不清楚，很容易卡在责任边界上。
容易发生
- 委托范围在中途扩大
- 评审关注点不一致
- 交付后缺少交接信息
避免方法
- 区分负责范围和不触碰范围
- 先定义完成条件和确认方式
- 决定交接说明里必须保留的内容
既有项目只外部委托一部分时怎么推进
既有项目部分外包时，应先明确边界、评审方法、分支、测试、交接条件和后续维护方式。
06
技术调查时没有明确要判断什么
即使发送大量资料或日志，如果没有说明最终要做出的判断，调查结果也很难直接转化为实现决策。
容易发生
- 调查范围过宽
- 缺少复现步骤或日志
- 讨论解决方案前还要先补事实确认
避免方法
- 先写明需要判断的事
- 整理环境、复现步骤和日志
- 确认可查看代码范围和 NDA 需求
委托技术调查时建议共享的信息
委托技术调查前，建议准备需要判断的问题、当前环境、复现步骤、日志、代码范围、NDA 和权限规则。
可以从最接近的失败模式整理咨询内容。
即使资料还比较粗，也可以先选择相近模式，整理第一封咨询邮件需要说明的前提。