稍微继续长一点时刻的项目，总免不了人员来来往往，需求无法详细处由开发自行补充，以及许多常识随着时刻慢慢被遗忘；导致项目越来越难以被人彻底掌握弄懂。
之前尝试过，通过需求文档的保护，来让项目的相貌能够让新人所知晓。
通过需求文档固化所有细节
其时的设计是这样的：
- 需求文档需求坚持一个全量文档
- 在需求文档前面放上各个版别的修改记载和定位
- 在详细变动的当地，用黄色标出，下一次再去掉过往标示，标上新的
但是在执行过程中发现：
- 需求文档难以坚持高质量的编写：产品司理写得过于精炼，开发测验会要求必须补充所有疑问的细节；而写得比较详细又欠缺好的阅读体会，往往一些很简单的功用为了满意开发测验所需，弄得十分冗长繁复。
- 产品司理多个人保护难以让文档坚持结构规整和没有重复性的描绘。
- 产品在每次迭代时提新的功用都是面向变化的，面临一个老文档需求把这次的一个需求，拆分红好多处修改，极大地降低了产品地工作效率。
最后每次迭代花了很大精力保护得牵强合格的文档，却是一篇的对于想了解这个项目的人来说，该详细的当地不够深入，该归纳的当地却又臭又长，行文逻辑不符合人的阅读认知的，诘屈聱牙，不流畅难懂，冗长得让人溃散的文档。
面临这个文档，产品不愿再在上面增加新工作内容；而新人看到上百页的内容直接关闭，然后打开项目的界面，直接找熟悉的人给他讲。
其时很苦恼：既想要保护住项目自身的需求相貌，让后续的新人能有一个能彻底了解项目方方面面的细节的文档。又想在项目过程中，能让产品开发测验都能有一份，通过 battle 后我们都认可和参照执行的基准。
新的思考
需求
需求文档其实不需求一篇彻底一以贯之整个生命的文档。只需求每次的需求能整理好即可。再
比如上一家公司，在 confluence 上，先将一个产品分红了许多的功用模块结构。每次迭代，在这些功用模块下面，增量地创立一个个的独立需求；再将这次迭代需求做的需求链接汇总到一个文档里。
那从时刻维度就能够看到每个迭代的使命，而从功用模块中则能够看到这个功用的史诗。每次开发重点重视的是这次模块的需求是哪些。而需求回溯查验时，则去详细的功用模块中看其时需求是怎样描绘的。
需求的效果其实到这儿就够了。需求文档仅仅过程的辅导，和偶尔回溯的参阅。咱们重点的着眼点仍是项目自身的这个效果。
常识
有人会说了：新人加入或交接时，假如来看这临散的需求，那会是十分懵逼的。
没错。这个不是给新人看的。新人看什么呢？————常识。
我以为常识应该包括几个：
- 功用用例盘点：应从头到尾，按模块，逐个功用作简要描绘。不需求描绘细节和内容，仅仅让要了解这个项目的人，依照这个文档，一条一条地结合项目的界面来操作。需求留意的是，除了描绘各种人物的用户之外，还需求从时刻，上游体系，其他事情等几个发起点来进行整理。
- 专项常识：有些内容其实便是 crud 的操作，这个并不需求额定进行描绘。但是有些功用其实是触及许多界面和流程的，这些内容，应该把他们单独抽离出来，用深入浅出地描绘，将他记载和表达。这个过程应该是业产研测共同建设的。也能够通过常识地图、扩展阅读等方式让我们更全面地学习。还需求的是把存放在我们大脑中的，代码中的，口口相传的各种隐性常识沉积为显性常识。
- 经验教训等级册
