在前面《25 - 项目需求如何有效梳理》文章中，已经说明过项目需求应如何依据实际情况进行梳理。不过，那是针对单个项目的情况。
倘若项目负责人负责多个项目，且这些项目之间存在一定关联，例如同属某个具体行业，此时，项目需求梳理就会面临问题。
该项目负责人所在团队有 10 人，负责项目 A、B 两个项目，这就需要两份需求文档、两个项目计划以及两个版本发布时间。
- 项目 A 的需求文档和项目计划
- 项目 B 的需求文档和项目计划
按理来说，这种安排并没有什么问题。然而，由于这两个项目均由这 10 个人负责，存在人员复用的情况，项目 A 的需求和计划一旦发生变化，就会对项目 B 的需求和计划制定产生影响。
对于项目负责人而言，项目管理的难度显著增加。一方面，需要在不同的项目文档里整理需求；另一方面，还需在不同项目中修改计划。
此外，还有两个版本发布时间，原本 10 个人负责的工作，却出现两个目标时间节点，无论是目标导向还是上下级沟通，都变得很复杂。
如何解决这一问题呢？
一方面要简化项目负责人对多个项目的管理工作，另一方面要让这 10 个项目成员更具目标感和凝聚力，设定唯一目标，即 10 个人要在规定的时间节点前完成安排的任务。
鉴于项目 A 和项目 B 同属一个行业，可以把它们转为子项目，重新创建一个总项目，下设子项目 A 和子项目 B，如此一来，就只需一份需求文档、一个项目计划和一个版本发布时间。
但这里存在一个问题，总项目的版本号只是用来做需求规划的，项目 A、项目 B 都有各自独立的版本号，并没有办法沿用总项目的版本号。那么，如何将它们与需求文档关联起来，以便追溯呢？
例如，项目 A 线上出现了 Bug，需要查看这个版本更新了哪些内容，才能判断 Bug 的影响范围。
假设总项目需求文档是 V1.0，而项目 A 当前版本是 V2.1，怎么在需求文档中查看项目 A 的 V2.1 迭代了哪些功能呢？
我能想到的是，只需要在总项目每个版本的需求文档里，在项目 A 旁标记当前版本号，并评估这些迭代功能是否需要升版本号即可。
如果要在该文档系统中列出项目 A 某个版本的全部需求（比如 V2.1 ），可以在搜索框使用【项目 A `2.1`】进行搜索，这样相关内容就能全部罗列出来。
