在管理需求、测试或者合规项目的时候，很多团队都会碰到怎么建结构、乱了怎么理的问题，因为系统是用项目树来放东西的，项目就是一个产品或软件的空间，里面用组件、集合、文件夹还有具体条目来放需求和测试，把这些层级弄明白，后面的追溯和变更才不会乱，如果一开始弄得太随便，不仅看过去很乱，还会影响到后面的权限、关系和交付。

　　一、怎么建立项目的结构

　　在建结构的时候，大家不要直接把Excel或者Word里的目录照搬进去，作者认为比较稳妥的做法，是团队要先把项目的交付逻辑想明白，然后再去安排组件、文件夹和条目的地方。

　　1、团队要先把项目的边界定清楚

　　项目的边界必须要先弄清楚，大家要搞明白这个项目到底是一个产品、一个平台，还是一个软件版本，如果边界不清楚，项目里面就会混进好几个产品线和很多版本，导致后面很麻烦。

　　一般情况下，管理人员要把【项目】当成最高层的位置，用【组件】来分系统模块或者业务，像做医疗设备项目的时候，大家可以分成用户需求、系统需求、软件需求这些模块，大家不要为了看起来多就全部塞进大目录里，不然找东西会很费劲。

　　2、团队要规划好集合和具体的条目类型

　　系统的树状图是靠组件、集合这些东西拼出来的，资源管理器也是这么显示层级的，在搭结构的时候，操作人员要把需求、测试用例和缺陷这些东西分开放，不能把所有内容都用同一种格式来存。

　　通常的做法是，大家把用户需求放在【Stakeholder Requirements】里，系统需求放在【System Requirements】里，软件需求放在【Software Requirements】里，测试用例放在【Test Cases】里，这样后面设置关系规则就容易多了，比如用户需求能连到系统需求，系统需求再连到软件需求上。

　　3、文件夹只能用来分小组，不能代替需求层级

　　文件夹用来给阶段或者功能分分组是可以的，但是大家不能把文件夹当成需求去用，在系统里放数据通常有“条目对子条目”和“文件夹对条目”这两种办法，前一个更适合表示父子关系，后一个适合用来分类和看东西。

　　二、项目结构层级太乱了要怎么理顺

　　层级变乱不单单是放错地方的问题，很多时候是大家导入、复制、很多人一起改，还有版本变了之后慢慢堆出来的，大家在整理的时候不要急着到处乱拖，要先看看到底哪里乱了，然后再一部分一部分地去改。

　　1、团队要先找出现在的结构问题

　　大家可以先把【Explorer Tree】全部点开，检查一下有没有这些毛病：一样Demand散在好几个地方、文件夹套得太深、类型用混了、测试用例堆在需求里、新旧版本分不清，还有临时用的东西没存好。

　　2、团队可以用鼠标拖拽和列表视图进行少量的修改

　　系统是支持在左边树状图和列表之间用鼠标拖着移动东西的，用来理结构挺省事的，但是在实际改的时候，操作人员不要一次性拖一整大片东西，特别是那些已经开始评审或者做过版本固定的内容。

　　比较稳的办法是大家先挑一个模块改改看，确认搬完之后字段、关系还有过滤器都正常，然后再去弄别的模块，针对重要的需求，大家可以先弄个临时视图，把名字、编号和上下游关系都列出来，搬完之后对照着看一下，免得表面上搬成功了，实际上底下的链接都断了。

　　3、导入文件引起的层级错乱要回源头去改

　　好多混乱都是因为从Word导入造成的，在导入的时候，Word里的标题样式会影响系统里的层级，系统会把标题变成新条目，里面的正文和图片就变成说明，要是源文件里的标题本来就很乱，导进去之后层级肯定是错的。

　　碰到这种情况，大家光在系统里拖来拖去是用处不大的，更好的办法是大家回到Word文件里，把一级标题、二级标题都改统一了，然后再重新看怎么对应，要是导进去的数据少，大家在系统里手动改改也行，要是数据太多，还是建议大家先备份，然后用标准模板重新导一遍，省得越改越乱。

　　三、怎么让项目结构一直保持明白

　　结构理顺了也只是解决当下的麻烦，如果没有后面的规矩，要不了多久系统还是会变乱，一个好用的结构，需要靠模板、名字、权限还有变更习惯一起管起来。

　　1、团队要定一个统一的名字规矩

　　结构能不能看懂不仅看层级，也看名字叫什么，组件、文件夹的名字要让人一看就明白，大家不要写“新建文件夹”、“需求1”或者“最终版2”这种名字。

　　2、关键的时候要及时把内容做个数据固定

　　项目结构在改动前后，大家最好在关键的时候做个数据固定，也就是建个基线，基线能把那个时间点的内容样子死死锁住，方便以后去对比和检查，系统的这个功能就是用来记下需求和测试在特定时候的状态的，适合在评审或者发布的时候用。

　　3、团队要把改结构这件事变成一个申请流程

　　项目开始用起来之后，管理人员不能让大家都随便去加组件、搬目录或者改类型，结构的层级就像是项目的骨头，改得太随便会影响所有人干活。

　　总结

　　其实建好系统结构的核心并不是把目录分得越细越好，而是要让项目的边界、组件的划分、文件夹的分组跟条目的关系对得上，在层级乱掉的时候，大家也不要急着全部重新排，应该先找毛病，然后再一小批一小批地搬过去验证，要是乱子是因为Word导入引起的，那就要回过头去改文件的标题样式，后面大家还要通过起名字的规矩、做数据固定和管好变更来保持结构的稳定，把这些事情都做到了，结构怎么建以及乱了怎么理这两个问题，才算是真正弄明白了。