需求体系化-产品演进的产物

最近的两次交流与碰撞，关于需求体系化的思考比较多。今天想来试着聊一聊，在引入需求体系化之前，大家疑问最多的一个问题？

• 我们为什么要做需求体系化？

回到“需求体系化”这几个字，它最核心的关键字有两个:“需求”和“体系化”。需求，说明了去做这件事情的时机和角色。时机是在做需求分析和需求研讨的时候，“体系化”说明了它最终呈现出来的是一个“体系”，一个体系，可以把它认为是一棵树，或者一张网。

那如果没有这棵树，至少我们的需求分析和研讨出来的东西是什么样的？我暂且把它理解为是一片一片的叶子，或者小枝丫。这些叶子和小枝丫在需求分析过程中被制造出来，成为一个中间的过程产物，用完就完了。在这之前，我也有一个很大的疑惑，需求研讨中的东西，到底要不要去维护它的准确性？这其实就跟它们的作用息息相关。
很多资深的模块需求负责人，会说，我没有做需求体系化，我们的工作依然可以运作很顺畅，我为什么要做这件事情？
是的，对于一些对该模块知根知底的资深人士来说，确实问题并不大。因为这个体系已经在她的心里建立起来。所以每次新分析需求的时候，她回到心里的那棵树上去找东西。
对于团队的这个系统来说，那这个人就是他们的信息集中营，如果他离开了，换一个人，还能做到这样吗？
以上，一直在谈，需求体系化是如何帮助我们更好的对新的需求进行分析。

• 关于特性的使用说明？

以前，我们提供了很多的文档，随着版本的演变，文档开始变得过时。如果在需求体系化中，将这这部分用户使用说明纳入进来就能很好的做到内外同源。

• 最后一个问题，一个五年、十年的项目最后留下的是什么？

这个拿我们项目来讲，这个体会最为深刻。随着时间的推移，人员的更替，留给我的最核心的资产是:代码、需求列表和EC清单。
听起来，是不是感觉哪里没对。要不然为什么每次人员变动，模块交接的时候大家都很痛苦。
试想想，如果除了上面的部分，我们还能得到一个产品的全貌，包括所有特性的引入时间，特性说明，特性验收准则，特性实现方案，以及特性之间的依赖关系。问题是不是就相对来说要容易许多，因为人总是对未知的事情充满了恐惧。

需求体系化-产品演进的产物