找开发团队之前，你应该先准备好哪些东西

大多数出问题的项目，问题都不是发生在开发期间。它们出问题，是在撰写需求的那一周，只是两个月后才有人发现。

想要好的开始，你不需要一份技术规格书。你需要的是几个问题的清楚答案，而这些问题没有任何开发者能替你回答。

实际上到底是谁在用

不是「我们的客户」。是哪些客户、在做什么、用什么设备、在什么情境下。

一套由办公室人员坐在桌前使用的预约系统，和一套由司机在雨中用手机操作的预约系统，是两个不同的产品——即使两份需求上写的都是「预约系统」。

说出主要的用户是谁。如果有两种差异很大的用户，要尽早讲——这会改变整个开发的样貌，而在一开始就知道，成本低得多。

做好之后，哪个问题会消失

具体描述痛点，而不是功能。

「我们想要一个仪表板」是一个解决方案。「要花两天才能查出哪些案子还没收款」是一个问题——而它可能用比仪表板简单得多的方式就能解决。

描述问题的团队，会比描述解决方案的团队得到更好的成果，因为开发者能提出更省钱的方法达到同样的结果。带着功能清单来的团队，就会刚好得到那份功能清单，不论它有没有真正解决任何事。

现在是怎么运作的，包括混乱的部分

把目前流程实际运作的样子写下来——包含例外状况、手动调整，以及那些「直接打电话问同事」的情况。

这些例外正是软件项目超支的地方。开发途中才发现的每一个例外，都是一次变更需求；一开始就知道的每一个例外，只是一个设计决定。

如果你的流程只存在某一个人的脑袋里，就请那个人来参加第一次会议。

谁可以说好

每个项目都会遇到必须在两个合理选项中做出选择的时刻。如果那个人没空，工作就会停下来，或是有人只能用猜的。

项目开始前就决定谁有最终决定权，并确保他有时间处理。一个有三位兼职决策者、却没有人能拍板的项目，前进速度会被最难乔的那个行程拖住。

第一版的「完成」是什么意思

你能带来最有用的东西，是一份简短的清单，写出第一版必须做到的事——以及一份更长的清单，写出它刻意不做的事。

第二份清单更重要。它能阻止一个三个月的项目变成九个月，而且在一开始写，比在半途中协商容易得多。

「现在不做」清单上的任何项目，之后仍然可以做。只是要等真实用户告诉你，它到底是不是真的需要。

你真的不需要准备的东西

你不需要知道该用什么技术、数据库要怎么设计，或画面应该长什么样子。那正是你聘请团队来做的工作。

你也不需要完成的设计稿。画在纸上的草图就很好，而且往往更好——草图会让人想修改，而精美的模型只会让人想点头同意。

一份合理的起始数据报

带着这些来，任何称职的团队都能准确报价：

• 一段话说明要消除的问题
• 主要用户是谁，以及他们使用时身在何处
• 目前的流程，包含例外状况
• 第一版的必备清单，以及一份明确的「现在不做」清单
• 谁负责核准决策，以及他们能呼出的时间
• 任何硬性限制——无法延后的期限、必须串接的系统、必须遵守的法规

这通常只有一到两页。它能省下的时间，比一份五十页的规格书还多，因为其中每一行，都是只有你才能提供的信息。