需求文档怎么写:一份甲方版

很多甲方写不出需求文档，不是因为不会写，是因为不知道该写到什么程度。

写太少，团队做出来的不是你要的。写太多，自己也被绑住了。

下面给一份甲方视角的需求文档结构，6 个部分，照着填就能用。

第一部分：一句话说清这个项目是什么

不要写"做一个钱包"。

要写："给谁用，在什么情况下，解决什么问题。"

举个例子："给已经在用海外钱包的用户，提供一个中文界面、支持本地支付的入口，解决他们看不懂英文界面的问题。"

这一句话是整个项目的锚点。后面所有的争议，都可以回到这句话来裁决。

第二部分：列出用户会做的 5 个动作

不要列功能，列动作。

动作是"用户做了什么"，功能是"系统提供了什么"。

比如：

打开应用，看到自己的资产

选一个地址，发起转账

输入金额，确认

查看这笔操作的状态

出问题了，找到人工客服

列到 5 个动作就够。 超过 10 个，说明你还没想清楚核心是什么。

第三部分：写出你最在意的 3 个标准

每个项目都有"哪些地方绝对不能出问题"。

挑出 3 个写清楚。比如：

不能出现资产数额显示错误

不能连续两次操作失败

不能让用户在 3 步之内找不到客服

这 3 条是验收时的判断依据。 也是团队要把资源倾斜的地方。

第四部分：画出你不要的东西

这一条几乎所有甲方都会漏。

明确写出"这一版不做"：不做会员体系、不做邀请裂变、不做多语言、不做客服系统。

写清楚"不做"，比写清楚"做"更能保护项目。 因为"做"的边界是无限扩张的，"不做"的边界是明确的。

第五部分：给出你的时间和预算区间

不用给精确数字，给区间。

比如"希望 3 个月内上线，预算在 20 到 40 万之间"。

给区间不是示弱，是让团队知道怎么给你配资源。 完全不给预算区间的甲方，团队只能按最贵的方式做方案，这是双方的浪费。

第六部分：写清楚验收方式

谁验收

按什么标准验

什么时候验

不通过怎么办

这部分写清楚，后期 90% 的扯皮都不会发生。

最后

这份文档不需要写得很长，A4 纸 2-3 页就够。

关键是把上面 6 个部分都填了。

很多项目出问题，不是因为文档不够详细，是因为该写的没写，不该写的写了一大堆。