问题所在
代价最大的错误，往往始于一个所有人都同意、却没人试过的假设。
"用户提交工作以供审批"在会议上听起来很清楚。可一旦有人真正使用，问题就来了：审批后内容又改了怎么办？审批人不在怎么办？两个人同时审批怎么办？这些问题应该在项目启动前弄清楚，而不是在第三次发布之后。
DEAD 如何运作
- Describe 描述。 记下您目前的认识，以及需要弄清的问题。假设始终标注为假设。
- Execute 运行。 用最低成本做出能让问题显现的版本。有时一个简单界面就够，有时需要一个可运行的小程序。只使用测试数据，绝不使用真实审批或访问凭证。
- Attack 攻击。 正常流程跑通只是开始。我们改变案例、角色和时机，提出令人不适的问题：到底谁有权做这个决定？
- Discover 发现。 记录哪些可行、哪些失败、哪些需要决策：形成案例、"必须/绝不"规则以及未决问题。
随后原型会被丢弃。留下的是学到的东西：书面记录、可追溯，并成为正式开发的基础。
您将得到
- 一个附带理由的决策： 停止、调整、集成或投入。
- 下一步的基础： 团队（或 AI）可以直接据此构建的案例、规则和验收标准，例如直接进入 ACD。
- 未决问题及其负责人： 哪些只能由您的专业人员或管理层决定。
有时会发现根本不需要新软件，只需要改变做法。这同样是成果，而且代价很低。
服务与结算方式
| 您得到什么 | 结算方式 | |
|---|---|---|
| 决策会议 | 一个想法、一项功能或一个久拖未决的问题，用 DEAD 现场推进[时长，例如半天，远程或到您现场 | 固定价格。没有决策，不收费。 |
| 成果方案中的 DEAD | 您的团队学会自己在几分钟内验证想法，作为每次较大投资前的固定流程 | 按成果分成或固定价格 |
依据
方法详见 Michael Küsters 的著作《Prototyping is DEAD》（Leanpub）。您可以自行应用这套方法。与我们合作，一次会议即可得出决策；没有决策，不收费。
常见问题
"决策"具体指什么？ 一份书面建议：停止、调整、集成或投入，并附上所依据的观察。停止也是完整的成果。
我们能拿到原型吗？ 您会得到从中学到的一切。原型是测量工具，并非为运行而建，因此不会进入生产环境。
如果会议上无法得出决策呢？ 那您无需付费。