稍微持续长一点时间的项目，总免不了人员来来往往，需求无法详细处由开发自行补充，以及很多知识随着时间慢慢被遗忘；导致项目越来越难以被人完全掌握弄懂。
之前尝试过，通过需求文档的维护，来让项目的面貌能够让新人所知晓。
一、走的弯路：通过需求文档固化所有细节
当时的设计是这样的：
- 需求文档需要保持一个全量文档
- 在需求文档前面放上各个版本的修改记录和定位
- 在具体变动的地方，用黄色标出，下一次再去掉过往标注，标上新的
但是在执行过程中发现：
- 需求文档难以保持高质量的编写：产品经理写得过于精炼，开发测试会要求必须补充所有疑问的细节；而写得比较详细又欠缺好的阅读体验，往往一些很简单的功能为了满足开发测试所需，弄得非常冗长繁复。
- 产品经理多个人维护难以让文档保持结构整齐和没有重复性的描述。
- 产品在每次迭代时提新的功能都是面向变化的，面对一个老文档需要把这次的一个需求，拆分成好多处修改，极大地降低了产品地工作效率。
最后每次迭代花了很大精力维护得勉强合格的文档，却是一篇的对于想了解这个项目的人来说，该详细的地方不够深入，该概括的地方却又臭又长，行文逻辑不符合人的阅读认知的，诘屈聱牙，晦涩难懂，冗长得让人崩溃的文档。
面对这个文档，产品不愿再在上面添加新工作内容；而新人看到上百页的内容直接关闭，完全没有任何耐心去看上面的内容；就算硬着头皮看了两页也是一头雾水。
当时很苦恼：既想要维护住项目本身的需求面貌，让后续的新人能有一个能完全了解项目方方面面的细节的文档。又想在项目过程中，能让产品开发测试都能有一份，经过 battle 后大家都认可和参照执行的基准。
二、现在的路：需求归需求，知识归知识
需求
需求文档其实不需要一篇完全一以贯之整个生命的文档。只需要每次的需求能整理好即可。再
比如上一家公司，在 confluence 上，先将一个产品分成了很多的功能模块结构。每次迭代，在这些功能模块下面，增量地创建一个个的独立需求；再将这次迭代需要做的需求链接汇总到一个文档里。
那从时间维度就可以看到每个迭代的任务，而从功能模块中则可以看到这个功能的史诗。每次开发重点关注的是这次模块的需求是哪些。而需要回溯查验时，则去具体的功能模块中看当时需求是怎样描述的。
需求的作用其实到这里就够了。需求文档只是过程的指导，和偶尔回溯的参考。我们重点的着眼点还是项目本身的这个成果。
知识
有人会说了：新人加入或交接时，如果来看这临散的需求，那会是非常懵逼的。
没错。这个需求不是给新人看的。新人看什么呢？————知识。
我认为知识应该包括几个：
- 功能用例盘点：应从头到尾，按模块，逐个功能作简要描述。不需要描述细节和内容，只是让要了解这个项目的人，按照这个文档，一条一条地结合项目的界面来操作。需要注意的是，除了描述各种角色的用户之外，还需要从时间，上游系统，其余事件等几个发起点来进行梳理。
- 专项知识：有些内容其实就是 crud 的操作，这个并不需要额外进行描述。但是有些功能其实是涉及很多界面和流程的，这些内容，应该把他们单独抽离出来，用深入浅出地描写，将他记录和表达。这个过程应该是业产研测共同建设的。也可以通过知识地图、扩展阅读等形式让大家更全面地学习。还需要的是把存放在大家大脑中的，代码中的，口口相传的各种隐性知识沉淀为显性知识。
- 经验教训等级册
总结
需求文档是范围管理的范畴，范围管理就是要明确指引开发做且仅做需要做的事情。需求文档必须应该只聚焦这一个目的，不要承担知识管理的任务。 知识管理为了传播的效率，可以由浅入深地展开，不应该过分苛责某其全面性和准确性。同时应作为团队里大家乐意做的一个习惯，而不是令人厌烦的程序性工作。
