导读
先从背景问题讲起，再来看Codes 创新解决思路，最后通过功能演示说明来体验感受。也就是抛问题，给思路，看落地实现。
背景
在项目或产品实施过程中，下面这两个需求管理的问题很普遍：
1、需求整合：重用难导致重复建设与资产浪费
需求重复开发：不同项目间存在30%-50% 的重复需求（如用户登录、权限管理），缺乏共享机制，导致重复造轮子，资源浪费严重。
能力复用不足：通用组件、模块、接口未沉淀为企业资产，各项目独立开发，技术债务累积
2、需求不好追踪：变更传导成 “灾难”：
同一业务领域相同或类似需求分散在产品的不同分支或不同项目中，难以掌握需求和产品或项目间的关系，特别是变更时不好评估受影响范围
3、虽然早就有需求池的概念，但是没有具像化的落地实现
从售前、客户等其他非产品人员渠道来源的需求，不可能立马定位到具体产品或项目上 ，如何管理这些需求
4、传统的产品型项目，项目型项目管理模式太繁琐
从交付的角度来看，不管是作产品还是项目，本质都是做项目。且把他们分区来管理时，人为带来了需求管理的复杂度，多了不必要的层级关系，增加了学习成本。
Codes的解决思路
Codes 产品团队以化繁为简的方式，不走寻常路，不死板的限定在理论中，也不固守陈规，拥抱零基思维。下面来先来看我们的解决思路，
首先具像化的需求池落地实现，用于对需求进行统筹管理，把3、4两个问题以简捷的方式解决了
需求池是一个大容器，需求一来就扔到池子里。需求池中的需求没有项目属性，通过他的分类来管理需求池中需求。需求分类可以从不同的维度来建，如业务线，功能线，然后下面再按区域分类，如华南售前等。
我们设计了需求池管理的两条主线，也就是两个需求池需求的查看视图。前面说的属于职能线，职能线用于各职能的人员查看和维护需求；另一条线我们叫产品线，主要方便产品人员从产品的维度来区分和维护需求。
产品线变成了需求池中需求的一个下拉选择的属性，从交付角度不存在产品型项目了，都是项目，把它以一个查看的视图来简化了但又没丢失从产品维度来管理需求。第4个问题解决了！
同时我们不再区分用户需求，研发需求，也不区分史诗、特性和用户故事，而是通过需求模板以及需求的拆分来解决 ，比如最上层的一个抽像的用户需求，然后拆分为研发可用的研发需求就行了，不需要明显的去人为把他们分出来，这增加了使用上的复杂度，所以我们这样来简化管理。
再围绕这个“池”并借用JAVA工程maven 管理Jar 包的思路，解决共享和复用的问题。
针对复用和共享我们用了“引用”这个概念来处理，具体来说就是：一个需求可以被多个项目引用，但是只能一个项目中实现，这就是复用型的共享模式，在实现项目中填进度，然后在需求池和其他引用该需求的项目中能同步查看进度信息。
对于只共享不复用，我们用“导入”这个概念来处理，具体来说就是：一个需求被多个项目导入，然后每个项目各自实现。举个不太恰当例子同一需求，在不同端都要实现，实现方式不一样。
引用和导入的区别：引用他就是只在一个项目中实现，其他引用项目中共用一分实现且能同步实现项目中的进度，除了实现项目外在其他单纯只是引用项目中只能看不能做其他动作；导入就是在不同项目中他们分别是不同的需求副本，各自有自己的实现，在某个项目中修改导入的需求时，需求池中的原始需求以及导入这个需求的其他项目不会同步这个修改。也就是说导入是维护某些需求的原始共同来源。
需求池中的某个需求，在一个项目中他要么被引用，要么被导入，不能又导入又引用。某一个需求池需求 ，也可以同时被不同的项目引用和导入。
需求池很好的解决需求溯源的问题
需求池，作为一个容纳任何需求的容器，从源头上作为需求的统一出处，然后通过引用和导入和项目产生联系，然后根据导入和引用的规则来实施需求的实现。少了需求池这一层，单纯的把需求导入到项目中，确实减少了重复录入。但是后续没法追踪。有了需求池之后，当变更时，能很清晰的知道影响的范围。需求池+引用+导入，建立了需求和项目间的依赖关系 ，随时可通过这些依赖关系来梳理需求在项目中的发散或裂变和共享。
需求池+引用+导入三板斧创新实现落地功能演示
界面说明
需求池主界面，左边是需求分类，缺省是职能线视图，可以换到到产品线视图，产品线视图左则目录显示产品的层级关系
需求分类的权限可按分类目录单独授权
创建需求池需求时，没有项目属性，可以用应需求模板
在需求池中能查看到需求在实现项目中的进度，只有被引用到项目中且指定了实现项目，才能在需求池及其他所有引用了该需求的非实现项目中，同步该需求的实现项目中的进度，被引用和导入后显示项目跟踪，
需求池需求引用或导入到项目
一次可以选多个需求然后引用或导入到多个项目中
引用
导入
在需求池中跟踪需求
项目跟踪，显示引用和导入关系，也就是该需注被哪些项目引用了，被哪需项目导入了。下图中需求池中需求，被两个项目引用，且在codes中实现，在demo软件这个项目中被引用，他们的进度在需求池中和项目中都有显示。
下图显示上图中的需求被哪个项目中导入了 ，导入时每个项目有各自的实现，所以各自都有各自的进度。
在项目中跟踪需求池需求
在项目中需求编号有G# 表示引用需求中的需求R#表示在当前项目中的需求编号
在引用关系时时只能在实现项目中能分解需求和建任务以及填写进度，且进度会同步到所有引用他的项目中；导入关系时每个项目中是一份独立的实现，所以都可以分解和建任务及填进度。
最后打个总结：
Codes 采用需求池+引用+导入，这三板斧，确实以创新简化的方式，解决需求跟踪和共享、重用的着问题。这三招也践行Codes 设计理念：”以便捷的方式给管理人员提供抓手，使管理抓得住，抓得好；以不增加负担的方式让执行人员聚焦业务，专注本职工作、高效协同“。需求池为轻IPD打了基础，下一次我们来聊聊 Codes 轻IPD的创新实现。匠心打磨，持续创新是 Codes 的产品基因。
