写「产品需求文档」时，别像我这样犯低级错误

文章开头：本文是韩旭博老师发表在产品壹佰的文章（http://www.chanpin100.com/article/105456）转载文章仅供大家习，不作任何商业用途。

产品新人总要经历一些锥心之痛，才能写好一份PRD么？

今天又被技术、UI狂虐了一天。究其原因：产品需求文档。

“哎，那谁，麻烦过来一下，你看需求是什么意思…”

“来一下，这个页面怎么变成这样了，之前文档里没写啊…”

第一个是前端、第二个是UI。

如果忽视了产品需求文档，你和技术、UI的对话可能永远以上面两句话开始（欲哭无泪）。

先介绍一下背景。

公司做在线教育，算是赶个晚集，还好切入点不错，现在服务几十所学校，主要面向学生家长。目前还只有公众号一个产品。

刚进入公司的时候，产品1.0版刚刚上线，为了赶进度，往往都是我收集好需求，整理成原型，直接交付UI设计成图，然后开发。产品需求文档、需求评审、测试一手包办。

因为我个人不喜欢搞大版本，就这样一个需求一个需求叠加，原型-设计-研发-测试-上线，然后循环。看似进度很快，其实为我现在的处境挖了一个巨大的坑，关键还是自己给自己挖的。

由于每次更新需求点，都是直接在原型上进行修改，顶多是在原型上添加备注，然后就交付UI。导致功能可用，但跟原有的框架却不太相吻合，或多或少在原有框架上歪一点。功能少的时候还不甚明显，等到问题暴露出来，才发现，原本想造个变形金刚，结果搞成了四不像。

产品需求文档就是整个产品的脉络，每个功能解决的问题、实现的方式、达到的效果、测试检验标准，都体现在上面。如果需求杂乱，条理不清，就会导致UI设计图风格不统一、研发需求模糊、测试无法系统测试，往往都是一直在不停的修改BUG，最后就会导致产品无法按时上线。

所以，在编写产品需求文档的时候，要做好版本管理。哪怕只是改动了一个提示语，最好都要在文档中进行注明。可以根据时间、功能、页面等等纬度划分版本，将每次更新的内容作详细的拆解。

不要写模糊概念

不要写模糊概念

不要写模糊概念

重要的事情说一万遍都不亏。每一句话、每一个名词都要明确意思（如果解释不了，可以写800字作文）。最好是上图，Axure原型的演示功能很强大要用好。不然，一个版本结束你会发现自己变成语文老师了。

一个概念，名词最好使用通用语，如果找不到，最好是拉上UI、研发、测试一起看。给每一个人看，一定要让其明白功能的含义是什么，最好是看到功能的名字就知道怎么操作。

不要一直加需求，要留时间梳理，不止梳理功能，还有逻辑。

功能越加越多，可能原有的为解决以前问题的需求，现在已经不适用了，这部分功能就要进行弱化，甚至废止。但是不能看一是一，一个功能往往牵扯到一个甚至更多的其他功能。这个功能废止了，肯定会影响其他功能的实现。

那么，是跳过？还是重新搭建其他功能？底层的逻辑受不受影响？这些都需要完完整整的体现在产品需求文档中。口头交代可以有，但是不宜过多，而且要及时体现在文档中。

一是做记录，下次更新时不会遗忘需求；

二是防撕逼，其实主要是防撕逼。

写好产品需求文档，真的可以防撕逼，亲验，有效。

文章结尾：再次申明所有转载文章仅供学习，感谢韩旭博老师的分享，如果喜欢我们的文章点关注❤️吧！比心呦！