建议增加可拷贝产品模块及需求的功能

这问题我提过一次类似的，希望做一个需求池，不过wcs似乎认为没必要这样作。

现在我用的办法是，永远不关闭被分解出来的细化需求，将它们归入到共有需求中备查——并不将它们和特定产品关联。
各产品中描述自身的框架性的需求，给出来关键字，分解任务的时候将这些需求分解为多个任务，根据关键字在需求池中查找。

暂时只能这样用，要看wcs啥时候有心情会觉得这个有必要了。

分支产品的管理，我觉得应该还是归到一个产品中。而不是分开若干的产品。我觉得这样对于产品管理是一件很麻烦的事情。比如可以考虑将不同的分支作为产品的 一个模块，跟分支产品相关的需求放到分支模块下面，然后公共的需求放到通用的模块下面。

不能作为一个产品管理的...

较为复杂的项目，可能会有一些子项目是交叉项目，没办法纳入到一个产品中，尤其是硬件项目，可能功能是相似甚至是采用同样一个方案的改版，但是接口却彻底的不同。

简单的例子，在agp和pcie显卡还在共存的年代，与主板的接口可能因为有agp和pcie的区别，这个对于不同的显卡来说是不同的需求，但是实际实现的功能都是显示，主体硬件方案也是一个，对于硬件厂商来说，不可能把这两种显卡作为同一个产品来发布的。
它们的驱动可能可以共享，软件上可以同等对待，但是硬件上的不同导致需求需要“有重叠”。

关键在于，即便当前做成公共需求，放到通用模块下，由于当前zentao管理需求是允许关闭的，agp显卡实现了的需求关闭了以后，pcie的需求怎么办？所以现在我只能不允许关闭任何需求……

我也提过这样的需求：/thread-view-79251.html
真的很迫切，如果做为一个产品来管理，真的不现实，
我们只做一种产品，但是有很多的型号，
这么多型号下的模块要手动一个一个建，
而且这些模块都是大同小异的，有些是完全相同的。

我觉得最好不是“拷贝”、“复制”，因为“拷贝动作”本身是将需求分成了2个，但是测试用例管理之类都是针对一个需求建立的，拷贝出去的需求成了独立需求，测试用例估计也需要独立建立了。

最合适的应该还是我当时提出来的做需求池，引用...这样测试用例也是一个，不过wcs认为这样太复杂...

如果完善的话，就变成多分支产品管理，这个貌似很复杂

这个问题的关键不在于我有没有心情，而是本身这件事情的合理性。
我做事情的一个判断原则，就是如果这个事情太复杂，肯定有它的原因，我们不能因为复杂的问题而引入复杂的应用。这样下去，禅道系统会越来越难用。关键是要找到解决问题的根本。

比如公司里面的这么多的产品管理，是否存在问题呢？这已经上升到企业战略管理的问题了。我们直观的认为，这样的产品管理是存在问题的，应该有更好的管理方式。

也许你们可以考虑自己动手修改代码。或者找我们开发插件。通用的发行版本中，我们要保证功能的通用性和合理性。

话说，隔行如隔山，做软件的和做硬件的毕竟不一样……

一个中等规模的公司里有很多面向不同客户的类似属性产品的存在是绝对不可避免的。
不同客户的需求不完全一样，或许你可以说“引导”客户接受，但是不是所有的需求都是可以引导的。

前面提到的那个，类似系统存在同需求的情况，我想请问wcs一下，A系统中实现了的需求X，在B系统中也存在的情况下，该需求到底是应该关闭呢还是怎么样？
如果按照你说的做成“公共需求”，这个需求就不可能关闭，也就是我现在的应用状态。

但是不关闭需求对A系统来说是“不公平”的，因为我这个系统已经做完了啊，凭啥不让我结束……