在Jama Connect中，Pick List为字段提供固定的下拉选项。修改后如果仍看到旧内容，先分清是哪一处没有变化：编辑页面的下拉菜单、已有工作项的字段值，还是过滤器与计算结果。它们需要分别检查。

Jama Connect可以通过Relationship Rule Set规定不同Item Type之间允许建立怎样的上下游关系，并把指定关系纳入Coverage检查。需求、系统需求、验证项和测试用例都已经录入项目，但Trace View里仍然出现断点、缺少下游验证或Relationship Status Indicator变红时，要分别检查规则集有没有应用到当前项目、关系方向和类型是否对应，以及现有Item之间是否真的建立了关系。

当我们在建立新需求管理项目、测试管理项目或者合规项目的时候，总是会被“Jama Connect项目模板怎么配置，Jama Connect项目模板字段不符合团队要求怎么办”这些事情卡住，其实模板项目的用途不只是去复制一个空的项目出来，它是把项目的结构、工作项的类型、关系的规则、权限的习惯、流程的节点还有示例的内容，都提前固定下来，在Jama Connect里面，我们可以通过模板项目把新项目的配置时间减少，这样就能让不一样的项目都跟着用一样的方法论，还有追溯模型也能保持一致。

在做需求验证和测试管理时，经常会遇到“Jama Connect测试计划怎么创建，Jama Connect测试计划执行范围怎么确认”这类问题。Jama Connect里的测试计划不是一个普通文件夹，它用于描述产品或系统如何验证、验证哪些需求、采用什么测试策略。测试计划下面还会继续组织测试用例、测试组、测试周期和测试运行记录，所以创建测试计划时，不能只建一个名称，还要想清楚执行范围和测试组织方式。

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

当完成测试用例的整理工作后，还需要把它们安排进具体的测试计划和测试周期里，才能真正开始执行。在Jama Connect里，测试计划这一项是用来讲清楚验证范围、测试目标以及执行时间安排的；测试周期则是专门组织某一轮实际测试活动的；而测试运行，就负责把每条用例跑出来的结果记录下来。这三样东西各管各的，不要把它们当成一回事来用。另外需要注意的一点是，测试用例自身状态的变化，并不是手工直接去改的，而是由它所关联的那些测试运行结果，通过系统自动计算汇总出来的。

当需求、测试用例和变更项进入确认阶段以后，如果还是靠着几张表格和来回的邮件去传递信息，版本混成一团的事情就很容易冒出来。想要搞清楚在Jama Connect里面怎样去新建一轮评审，以及评审的提醒又该怎么发出去，就得把评审到底要覆盖哪些内容、参与者担任什么角色、截止时间卡在哪里，还有通知的整个传递路径，一并都设好才行。Jama Connect允许对项目里面的单条条目，或者凑成一组条目去提起评审，而发起评审的那个人，会被默认当作主持人，也就是Moderator。

Jama Connect导入Excel怎么做，先别急着把表格拖进去。官方帮助里把这件事拆得很清楚，Excel导入分单向导入和round-trip两种，前者适合把新条目导进Jama Connect，后者更适合把Jama里导出的表格改完后再回写更新；同时一张工作表只能导一种item type，层级也要提前在表里用缩进或颜色准备好。也就是说，导入前先把表格结构理顺，比后面反复重导更省事。

很多团队在Jama Connect里做完评审后，最容易漏掉的不是意见处理，而是后面怎么把记录导出来、怎么把证据留成一套可审计材料。按Jama Connect官方帮助的口径，评审导出和评审归档本来就是两件事：导出解决的是把评审活动、签名状态、评论和评审内容带出系统，归档解决的是让已完成评审从日常列表中收口，同时保留后续可查可恢复的历史记录。

很多团队在用Jama Connect时，前期最容易出的问题，不是谁不会点权限，而是把许可证、角色、项目访问和对象层级这几件事混成了一套。按官方帮助中心的口径，Jama Connect里有两条线要先分清，一条是role，也就是谁能做管理动作，另一条是permission，也就是谁能在项目里看和改哪些内容；再往下还有license type，会直接影响用户能不能创建、编辑、执行测试或只读查看。只有先把这三层拆开，后面的项目权限才不会越配越乱。