当你找外包团队或开发公司聊一个新项目时，发出的第一份文档会影响之后的一切。需求写得含糊，拿到的方案也会含糊，报价区间大得离谱，还要花好几周来回确认细节。需求写得清楚，你就能拿到可以互相比较的方案、更切合实际的报价，项目也能更快启动。

好消息是，一份有用的需求简报不需要很长，也不需要很技术。它只需要讲清楚问题、用户，以及怎样才算成功。这篇指南会逐项说明该写什么。

1. 你想解决的问题

从问题出发，而不是从解决方案出发。描述现在哪里出了问题，以及为什么这件事重要。

  • 现在是什么情况？如果维持现状，代价是什么？
  • 谁受到影响？多久发生一次？
  • 大家现在是怎么绕开这个问题的？

「我们的客服团队每周要把同样的 30 个问题回答几百遍，今年回复时间翻了一倍」，比「我们想要一个 AI 聊天机器人」有用得多。

2. 为谁而做

描述会使用这个产品、或者受它影响的人：客户、员工还是合作伙伴。写清楚他们想达成什么目标、用什么设备、说什么语言，以及对技术的熟悉程度。

3. 怎样才算成功

说清楚你会怎么判断项目做成了。尽量让它可以衡量：

  • 回复时间缩短到几个小时以内
  • 一定比例的咨询不需要人工就能解决
  • 某个流程从几小时缩短到几分钟
  • 注册、销售或预约达到一定数量

清晰的成功标准，能帮团队提出合适的范围，也能帮你在项目结束后评估结果。

4. 范围：必须有的和可以有的

列出你认为需要的功能或能力，并分成两组：

  • 必须有： 少了这些，第一版就没法用
  • 可以有： 有价值，但可以以后再做

这一步对控制预算的作用，比其他任何事都大。它也让团队有机会提出一个更小的第一版，更快地验证你的想法。

5. 现有的基础

描述你们目前的情况：

  • 项目需要对接的系统和工具，比如 CRM、官网、数据库或客服系统
  • 项目会用到的现有内容或数据，以及它们目前的状态
  • 品牌规范、设计稿，或者之前的尝试，包括哪些没有成功

系统集成和数据往往是隐藏工作量最多的地方，你提供的信息越多，报价就越准确。

6. 限制条件

坦率地说明各种限制：

  • 预算： 给一个范围就可以，能为双方节省大量时间
  • 时间： 有没有固定的截止日期，比如发布会或销售旺季
  • 规则： 隐私、安全、行业监管或公司内部制度
  • 技术： 必须使用或必须避免的平台和托管方式

说出预算范围并不是示弱。它能让团队提出切实可行的方案，而不是靠猜。

7. 希望怎样合作

  • 你们这边由谁拍板？反馈速度大概多快？
  • 项目进行期间，你希望参与到什么程度？
  • 上线之后，你们团队里有没有人会接手维护？

不需要写的内容

  • 详细的技术规格，除非你有充分的理由。让团队来提出实现方案。
  • 没有优先级的长串功能清单。 这只会让报价不断膨胀。
  • 在签署协议之前的机密细节。 先用概括性的方式描述。

一个可以直接套用的模板

项目名称： [暂定名称]
问题： [哪里出了问题，为什么重要]
目标用户： [谁会使用，他们想达成什么]
成功标准： [两三个可以衡量的结果]
必须有： [核心功能]
可以有： [以后再做的部分]
现有系统和数据： [需要对接或使用的内容]
限制条件： [预算范围、时间、规则、技术]
决策人和联系人： [姓名和职位]

这样一份简报，一两页纸就能写完，花一个小时左右。等项目启动后，它省下的时间会远远不止一个小时。

如果你心里已经有一个项目，欢迎把需求简报发给我们，粗略的也没关系。我们会回复一些问题，并建议第一步怎么做。