为什么技术同事不愿意看需求文档呢？

还是在人人都是产品经理上看到的一个问题：

因网站需要改版，所以除了原型图外，撰写了需求文档，文档内删除了与开发无关的背景说明等内容，仅含有对原型图各处的开发需求，但发现技术和设计同事都不愿意看，说没时间，宁愿通过口头的沟通来一一确认，但是最初也是他们要求有需求文档的，所以文档的作用只是留存？那么每次沟通后与原有文档不一致的地方都需要记录下来，然后与各方确认？

人人都是产品经理

个人认为：

需求文档的作用不只是开发时的依据，还承担了测试以及后续迭代版本进行记录的作用。

不是有句话吗？好记性不如烂笔头。

但话是这么说，产品经理辛辛苦苦弄出来的产品文档技术不看，也是挺恼人的。

下面以自己的经历和体验，说说说为什么开发人员不喜欢看长篇大论的需求文档。

第一点情况：需求文档太长，看得累。

一般来说，在实际开发中，需求文档大多数都是给产品经理和测试人员看的。

当然有些大型的项目除外。

但一般的产品经理，能做几个大型项目呢？

因为产品经理需要记录最终的需求是什么，以便再次迭代时候，他有迹可循，或者说在做下次迭代的时候，能更准确地去了解上一次做了哪些功能和需求。

毕竟时间一长的话，谁都记不住；通过这种方式，后来人也可以继续更新迭代。

虽然产品经理有了更准确的记录，但也使得需求文档特别细也特别长，恨不得一些接口的实现逻辑他也想写里面去。

如此长的需求文档，别说技术没时间看。

就是有时间，也就只会扒拉几下，仍在了桌面上。

开发项目的时候，依然无视你的需求文档，反而当面问你。

第二种情况：需求变化太快，文档记录不及时。

我们在做一些敏捷开发项目时，往往前期都很规范。

比如需求文档，流程图，完全会按照一个预先设定的思路在做。

但是你计划赶不上变化，客户改起来需求，可不会等你更新完需求文档。

所以开发确认需求的最好方式不是查看需求文档，而是查看产品经理与业务确认的微信对话。

第三种情况：需求文档的需求有问题，得频繁和产品经理沟通

我们在写需求文档的时候，对于逻辑、功能、交互的描述，大多有时候会遇到语言上的困难；比如不知如何描写此处想达到的目标和交互。

所以苦思半天后的文档，技术在看了后，往往不知道你在说什么。

即浪费时间又浪费精力。

还不如直接和你沟通的得了。

所以：

对于测试人员，需求文档需要知道上一版本的情况是什么，他会细看。

对于开发人员来说，他需要知道你当前想实现什么，大多不会真的去看。

那有什么变通的方法呢？

我们的需求文档，有的是用word形式切的，有的用excel，但也有在原型旁边标注的，归根结底的作用是一样的。

但是一般像word这种长篇大论的需求文档，现在看的人确实非常少，原因就是懒。

但是你发现，在原型旁边标的需求说明，技术大多愿意去看的。

我们其实完全可以将需求记录是一个文档，对开发说明另外一个文档。

对开发的文档，完全可以在原型旁边去做一些备注，以这种的形式来是描写你的规则和你的交互；

另外一种文档则完全可以做测试和产品回归时候用。

自己说的终归浅，如果想解决这个问题，其实最主要的还是形成一个工作习惯。

比如在一开始开发项目的时候，大家就定好需求管理的规范。

END······