无论是互联网产物照旧产物项目，所有这一切的初步都始于需求阐明，一份好的需求文档往往是项目乐成的先决条件，对一个产物司理或项目司理来说就显得尤为重要。可是，同样是写需求，差异的人写出来结果却截然差异。对比产物菜鸟，好手毕竟在哪些方面表示得更为突出呢？

同样是写需求，为什么有的人能一次过，而有的人改了又改，甚至还要推倒重来？

同样是写需求，为什么有的人思量全面，而有的人丢三落四，直到评审的时候被怼得遍体鳞伤？

同样是写需求，为什么有的人简朴易懂，而有的人长篇大论，各人却看不懂？

这种环境在我们事情中常常会看到，优秀的需求文档和拙劣的需求文档，就像产物司理的脸面。

那么，怎么才气写出一份大度的需求文档，团结这几年的事情总结，和各人聊一聊

一、精确领略需求，才气有的放矢

写需求的大忌之一，就是自嗨。

许多自嗨型选手，自傲型的，会以为本身的领略才是最完美的，用户提的需求可能场景，都是欠思量的。

他们不屑去找用户求证，也不会利用简朴的方案先验证需求，而是完美主义的妄想一步到位，他们信奉乔帮主的一句话：用户并不知道本身需要的是什么，直到我们拿出本身的产物，他们就发明这是我想要的。

自卑型的，他们不肯意找用户，畏惧找用户求证。因为担忧本身没有领略用户的需求，会被其他人看不起，猜疑本身的本领。

所以纵然不领略，也不肯意找用户求证，可是又要交差，最后就只能凭据本身的领略硬着头皮上。

不能精确领略业务场景，就敢写需求的，最后城市成为义士。领略了需求是1，后头所有的文档，开拓和测试都成立在这个1上，没有1，后头再多的0也白费。

精确领略需求，其实就是要领略需求背后的利用场景，可以利用常用的5W1H框架。

what：用户的问题和需求是什么？

when：用户什么时候会碰着这样的问题?

why：用户为什么会碰着这样的问题？

where：用户一般在什么处所碰着这样的问题:

who：碰着这个问题的用户是谁？用户群体有什么特征？

how：用户当前是怎么办理这个问题的？

好比我最近认真的产物，有一个预警的需求，主要是针对平台的异常数据举办预警。

预警一般就分为三步：预警的数据从哪来？预警的法则如何配置？发生预警后以奈何的形式发送给谁？

前两步我跟用户（公司的业务方）都对的较量清楚。而在第三步通知上，我就犯了理所虽然的错误，陷入了本身的想象中。

我的想法是，发生预警的动静通知因为需要按照模板来设置的，这就有点雷同于微信动静通知，都有牢靠的模板。

所以我想虽然的认为，我们也只能通过配置几个牢靠的模板，然后按照发生预警的内容往模板内里填充信息。

但实际用户的需求并不是这样，牢靠的模板不能满意用户的需求，用户不只需要预警动静，还需要自界说通知哪些信息给哪些用户。

所以最终的效果就是定好的开拓打算需要从头拟定，需求需要从头评审。亏得还没有进入开拓，只是延长了2天的时间。假如是在验收的时候发明这个问题，那的确就是劫难了。

磨刀不误砍柴工，前期需求确认越精确，需求的不确定就越小，后期修改和返工的概率就越小。

二、学会制造和利用东西

确认好需求今后，就可以着手开始写文档了。

需求文档本质上是将我们脑筋里对需求成果的构思，精确的转达给设计师、开拓和测试同事。

那么，有哪些要领能提高信息的转达率呢？总结起来，或许有三种要领：

之一，换位思考，站在开拓的角度思考问题

既然我们主要是写给开拓同学看的，那么就应该用他们熟悉的思考 *** 来撰写需求文档。

什么是开拓的思维 *** 呢？谜底是函数思维。所有的函数都由三部门构成：输入—要领—输出。针对某一成果，用户的输入是什么？颠末什么样的要领或流程？最终输出是什么？

譬喻，登录成果，用户输入账号和暗码，点击登录按钮，这进程颠末尾哪些？

输入：用户的账号、暗码；

要领或流程：请求靠山用户账号表，校验用户账号和暗码；

输出：返回登录功效，登录乐成跳转到首页，登录失败则返回失败的原因。

因此，成果的具体需求描写，应该包罗：

要写清楚成果的输入是什么？输入的参数有哪些？是否是必填，参数的字段范例是奈何的？

挪用什么样的要领或流程

输出是什么

异常环境有哪些，如那里理惩罚？