过滤器的浏览权限
首次创建完后，默认的权限都是自己可见。如果想把过滤器的结果呈现在个性首页上，就必须把过滤器的浏览权限开放给你要共享的人，可以在“Issue”→“管理过滤器”选定你要共享的过滤器，进入“编辑当前过滤器”对话框进行操作。共享范围可以是所有人、指定的用户组或特定的项目。
过滤器涉及项目的浏览权限
共享过滤器时，一定要确保这些被分享到的人或指定用户组，具备过滤器筛选条件中所涉及的项目浏览权限。否则即便是他收藏了你分享的个性首页，页面上也无法显示和他相关的内容，并会提示一堆“选择的过滤器filter-10005有错误：ID为‘10202’的值在字段‘project’中不存在”的报错，报错提示中的filter和ID后面的数字，会随着你过滤器的不同而变化。
个性工作流让潜规则浮上台面
应用需求场景
A公司不同业务分类下的项目，存在不同的执行流程。同一个业务分类下的不同项目中的不同类型事情，也会有不同的执行流程。虽然项目干系人都知道执行流程，也能在项目执行中及时发现流程上的问题并积极改进，最后落实到文档层面。但这些流程在执行过程中，总觉得缺少一种承载物，导致在执行中或多或少地都带有“人情”因素，会执行不力。想通过把制度流程与工具相结合，让不同项目中的不同类型事务，都能按照既定的流程执行并跟踪，把潜在台面下的流程规则浮上台面。通过把项目状态和流程的具体事务操作相结合，实现一些状态数据的统计分析、共享、流程权限控制等，促进项目执行自动化水平。
JIRA解决方案
总结项目执行中的关键状态和节点，在JIRA中定义其状态，通过JIRA工作流把这些状态与具体事务操作联系起来。A公司互联网产品技术类项目执行过程的关键状态节点可以划分为：方案设计中、UE设计中、UI设计中、页面制作中、开发中、测试中、待上线、已上线等状态。落实到JIRA工作流中，可增加一个初态Open（开启）和终态Closed（关闭）。以Story类型提案为例，具体的状态操作跳转流程如图5所示。
图5Story、新增功能或改进优化类型提案的状态操作跳转流程
图5中，当创建Story类型的项目提案后，默认的初始状态是开启，然后进行产品方案设计，进入方案设计阶段。
如果该项目提案依赖于页面展示，那么就会依次经历UE设计、UI设计和页面制作等阶段，然后进入开发、测试和上线等阶段。
如果该项目提案不依赖于页面展示，那么就不再需要经历UE设计、UI设计和页面制作等阶段，直接进入开发、测试和上线阶段。
无论Story类型的项目提案是否依赖于页面，最后终结的状态都是关闭。
从终态关闭，也可通过“恢复开启提案”的事务操作回到初态开启。
关键实现步骤
JIRA提供了两种工作流的设计方法：Text文本方法和Diagram图形方法。个人感觉采用Text文本方法相对易用些，而采用Diagram图形方法时容易出乱走样。以下简要介绍采用Text文本方法进行工作流的设计与实现。在jira-administrators管理员权限下，以Story类型工作流的实现为例。
①“Issue”→“状态”→“添加新状态”，将图5中提到的状态，都添加完成。里面除了开启和关闭是系统提供的状态外，其他都是自定义的。
②“Issue”→“工作流”，复制JIRA默认的工作流，重新命名，如：WeiboStoryIssueTypeWorkflow。
③梳理图5中涉及状态和事务操作的对应关系，可以思考以下问题。
从项目上游的A状态到下游的B状态，要进行什么样的事务操作？
从下游的B状态退回到上游的A状态，要进行什么样的事务操作？
从A状态进行什么样的事务操作可以不经过B状态直接到达C状态？
每种状态操作有哪些权限控制？什么权限的角色可以操作？什么权限的角色不可以操作？
这些可以梳理成表2的形式。表2中，项目管理人员在每个状态都具有操作权限，这里为了强调让团队的每个成员都参与进来使流程运转，所以在“适合操作角色”的内容上，将各个状态对应了各角色的成员。
表2Story类型项目提案状态和事务操作的对应关系
④“Issue”→“工作流”，选定你要设计的工作流，如WeiboStoryIssueTypeWorkflow，在“添加新步骤”中完成“步骤名称”和“链接的状态”的添加。
⑤在Text文本工作流的设计页面中，选定需要操作的状态，点击“添加工作流动作”链接进入“添加工作流动作”页面，填写工作流名称、描述、链接目标状态和工作流动作页面。其中工作流动作页面不是必须要有的，可根据你的业务需要来取舍，如果业务层面需要有工作流动作页面作为跳转页面，那么该页面就会在执行这个工作流动作时出现。
⑥在步骤⑤中提到的工作流动作页面，可以在“Issue”→“界面”和“界面方案”中，完成你所需要过渡页面的制作，并在“添加工作流动作”的页面中与链接目标状态进行关联。
⑦“Issue”→“工作流方案”页面中，创建工作流方案并命名，如XXXWorkflowSchemes，并给XXX工作流方案的不同提案类型指派不同的工作流模型，譬如：给Bug类型的提案，指派JIRA默认的工作流；给Story类型的提案，指派前文中提到的WeiboStoryIssueTypeWorkflow工作流等。
⑧最后，把工作流方案XXXWorkflowSchemes与具体的Project项目库关联，生效后方可使用。
工作流的设计完成后，项目提案中的状态与事务操作对应关系，工作流的JIRA效果展示，如图6所示。
图6Story类型提案的状态与事务操作对应关系，工作流的JIRA效果展示
图6中是把Story类型项目提案的每个状态下所对应的具体事务操作，先局部截图后，再以拼图的形式做效果展示。每个局部截图中的数字标号表示效果展示的顺序。红色分割线表示每种状态与事务操作对应关系区分。
需要注意的点
①设计工作流时，建议首先复制JIRA默认的工作流，在JIRA默认工作流的基础上再重命名，设计符合你需求的工作流。不要刚上来就直接定义新工作流来设计，否则你会发现很多时候工作流的状态和事务操作在执行时，都没法按你的规则去实现。
②如果需要对某个事务操作（如“关闭提案”）在工作流中进行权限控制，可以在该事务操作的权限控制页面中，通过“触发条件”下的Addcondition进行权限操作。
项目报表让各项目情况一目了然
应用需求场景
A公司的产品设计开发节奏快、周期短，平时并行的项目较多，除了个别非常重要紧急的项目以外，很少能做到专人专项。UED、开发、测试等职能部门的人力资源多数都是当项目立项后，再被临时指派到各个项目上。项目执行中的状态、时间点等信息也比较散落。想让每个项目的上线时间、资源分配（占用）情况、各环节的交付时间点、以及项目执行中遇到的问题风险等，能一目了然地呈现；能在一个动态的项目报表中看出整个业务分类下的现行项目情况。
JIRA解决方案
把A公司互联网产品技术类项目的人员角色划分，包括产品经理、UE设计师、UI设计师、页面制作、前端工程师、后端工程师、测试工程师、运维工程师、项目管理等，在jira-administrators权限下的“字段”→“自定义字段”里，定义成“选择用户”（多选）的字段。
把项目执行中涉及的各环节时间点，包括起始时间、方案交付时间、UE交付时间、UI交付时间、页面交付时间、前端交付时间、后端交付时间、测试交付时间、上线时间等，在jira-administrators管理权限下的“字段”→“自定义字段”里，定义成“日期选择器”类型的字段。
涉及的自定义人员和时间字段，都可以在某些类型提案里做成多标签页面的形式。以Story类型为例，在jira-administrators权限下的“界面”→“配置界面”→“字段标签页”→“增加字段”中，可以实现项目时间计划、参与人员、上线发布等主题的多标签页面。
再用JIRA过滤器筛选出指定业务分类下的项目，同时，把事前定义好的各角色参与人员、各环节时间点和问题风险等字段，通过JIRA过滤器Columns自定义列元素的方式，做成一个项目报表。最后将其通过“导出”→“打印预览”的形式，得到一个绝对的链接地址，作为常用链接放到JIRA导航栏上，实现效果如图7所示。
图7项目报表实现效果示意图
由于项目报表的横向宽度较宽，所以分两张图分开展示。图7的示例中，前半部分列分出了项目提案名称、优先级、状态、上线时间、典型问题风险及后续计划等项目关键要素，后半部分列出了项目资源分配（占用）情况，以及各环节的交付时间点，各职能部门负责人可以由此粗略估算出某个已被占用资源，下次被释放的大致时间。
小结
本文通过三个较为典型的JIRA实践案例，简要介绍了A公司在互联网项目执行的高效能协作过程中，JIRA所起到的重要承载作用，以及针对不同应用需求场景提供的解决方案、关键实现方法等。当然在其他具体实践方面，JIRA能处理的应用需求场景远远不止于此。希望这三个JIRA实践案例中涉及的解决方案、关键实现方法等，能抛砖引玉，为你在平时工作遇到的类似应用场景，带来高效解决方案层面的一些启迪和思考。
