今天又被技术、UI狂虐了一天，究其原因，四个字：需求文档。
“哎，那谁，麻烦过来一下，你看需求是什么意思……”
“来一下，这个页面怎么变成这样了，之前文档里没写啊……”
第一个是前段、第二个是UI。
如果忽视了需求文档，你和技术、UI的对话可能永远以上面两句话开始，欲哭无泪。
先介绍一下背景。
公司做在线教育，算是赶个晚集，还好切入点不错，圈了几十所学校，主要服务学生家长。目前还只有公众号一个产品。
刚进入公司的时候，产品1.0版刚刚上线，为了赶进度，往往都是我收集好需求，整理成原型，直接交付UI设计成图，然后开发。需求文档、需求评审、测试一手包办。因为我个人不喜欢搞大版本，就这样一个需求一个需求叠加，原型-设计-研发-测试-上线，然后循环，看似进度很快，其实为我现在的处境挖了一个巨大的坑，关键还是自己给自己挖的。
由于每次更新需求点，都是直接在圆形上进行修改，顶多是在原型上添加备注，然后就交付UI，导致功能可用，但是跟原有的框架却不太相吻合，或多或少在原有框架上歪一点。功能少的时候还不甚明显。等到问题暴露出来，才发现，原本想造个变形金刚，结果搞成了四不像。
需求文档就是整个产品的脉络，每个功能解决的问题，实现的方式，达到的效果，测试检验标准，都体现在上面。如果需求杂乱，条理不清，就会导致UI设计图风格不统一、研发需求模糊、测试无法系统测试，往往都是一直在不停的修改BUG，最后的结果就会导致产品无法按时上线。
在编写需求文档的时候，要做好版本管理，哪怕只是改动了一个提示语，最好都要在文档中进行注明。
可以根据时间、功能、页面，等等纬度划分版本，将每次更新的内容作详细的拆解。
不要写模糊概念
不要写模糊概念
不要写模糊概念
重要的事情说一万遍都不亏
每一句话、每一个名词都要明确意思，如果解释不了，可以写800字作文。最好是上图，Axure原型的演示功能很强大要用好。不然，一个版本结束你会发现自己变成语文老师了。
一个概念，名词最好使用通用语，如果找不到，最好是拉上UI、研发、测试一起看，给每一个人看，一定要让其明白功能的含义是什么，最好是看到功能的名字就知道怎么操作。
不要一直加需求，要留时间梳理，不止梳理功能，还有逻辑。
功能越加越多，可能原有的为解决以前问题的需求，现在已经不适用了，这部分功能就要进行弱化，甚至废止。但是不能看一是一，一个功能往往牵扯到一个甚至更多的其他功能。这个功能废止了，肯定会影响其他功能的实现，是跳过，还是重新搭建其他功能，底层的逻辑受不受影响。
这些都需要完完整整的体现在需求文档中。口头交代可以有，但是不宜过多，而且要及时体现在文档中。
一是做记录，下次更新时不会遗忘需求；
二是防撕逼，其实主要是防撕逼。
写好需求文档，真的可以防撕逼，亲验，有效。
网友评论