项目的需求及知识管理-六虎

稍微继续长一点时刻的项目，总免不了人员来来往往，需求无法详细处由开发自行补充，以及许多常识随着时刻慢慢被遗忘；导致项目越来越难以被人彻底掌握弄懂。

之前尝试过，通过需求文档的保护，来让项目的相貌能够让新人所知晓。

通过需求文档固化所有细节

其时的设计是这样的：

但是在执行过程中发现：

需求文档难以坚持高质量的编写：产品司理写得过于精炼，开发测验会要求必须补充所有疑问的细节；而写得比较详细又欠缺好的阅读体会，往往一些很简单的功用为了满意开发测验所需，弄得十分冗长繁复。
产品司理多个人保护难以让文档坚持结构规整和没有重复性的描绘。
产品在每次迭代时提新的功用都是面向变化的，面临一个老文档需求把这次的一个需求，拆分红好多处修改，极大地降低了产品地工作效率。

最后每次迭代花了很大精力保护得牵强合格的文档，却是一篇的对于想了解这个项目的人来说，该详细的当地不够深入，该归纳的当地却又臭又长，行文逻辑不符合人的阅读认知的，诘屈聱牙，不流畅难懂，冗长得让人溃散的文档。

面临这个文档，产品不愿再在上面增加新工作内容；而新人看到上百页的内容直接关闭，然后打开项目的界面，直接找熟悉的人给他讲。

其时很苦恼：既想要保护住项目自身的需求相貌，让后续的新人能有一个能彻底了解项目方方面面的细节的文档。又想在项目过程中，能让产品开发测验都能有一份，通过 battle 后我们都认可和参照执行的基准。

需求文档其实不需求一篇彻底一以贯之整个生命的文档。只需求每次的需求能整理好即可。再

比如上一家公司，在 confluence 上，先将一个产品分红了许多的功用模块结构。每次迭代，在这些功用模块下面，增量地创立一个个的独立需求；再将这次迭代需求做的需求链接汇总到一个文档里。

那从时刻维度就能够看到每个迭代的使命，而从功用模块中则能够看到这个功用的史诗。每次开发重点重视的是这次模块的需求是哪些。而需求回溯查验时，则去详细的功用模块中看其时需求是怎样描绘的。

需求的效果其实到这儿就够了。需求文档仅仅过程的辅导，和偶尔回溯的参阅。咱们重点的着眼点仍是项目自身的这个效果。

有人会说了：新人加入或交接时，假如来看这临散的需求，那会是十分懵逼的。

没错。这个不是给新人看的。新人看什么呢？————常识。

我以为常识应该包括几个：

功用用例盘点：应从头到尾，按模块，逐个功用作简要描绘。不需求描绘细节和内容，仅仅让要了解这个项目的人，依照这个文档，一条一条地结合项目的界面来操作。需求留意的是，除了描绘各种人物的用户之外，还需求从时刻，上游体系，其他事情等几个发起点来进行整理。
专项常识：有些内容其实便是 crud 的操作，这个并不需求额定进行描绘。但是有些功用其实是触及许多界面和流程的，这些内容，应该把他们单独抽离出来，用深入浅出地描绘，将他记载和表达。这个过程应该是业产研测共同建设的。也能够通过常识地图、扩展阅读等方式让我们更全面地学习。还需求的是把存放在我们大脑中的，代码中的，口口相传的各种隐性常识沉积为显性常识。
经验教训等级册