太上，不知有之；其次，亲而誉之；其次，畏之；其次，侮之。信不足焉，有不信焉。悠兮，其贵言。功成事遂，百姓皆谓“我自然”。 --《道德经》
研发管理或者系统工具的指导思想我觉得就是依照上面这句话做到“不知有之”和“我自然”。如果管理方法是合理和高效的，它一定是符合（或者能够引导符合）大多数人的使用习惯，如果不止一个人提出觉得流程复杂或者难以理解，或者实际实施的过程中时常会出现错误，那我们应该从管理上找原因，是不是不够自然，别扭。因为在实际工作中很多人没有特别固执的管理方法或者系统工具的要求，就像不同公司的企业文化，大家容易偏于适应，所以当有人提出问题，管理团队的问题可能性更大。但是人是有惰性的，管理需求的复杂与人员使用的简单之间，如何很好的去做平衡，我的思路是“大部分人做简单的事情，小部分人做复杂的事情”。
Jira系统，或者说研发管理系统的服务对象有两个：
-
迭代（一个标准的Scrum迭代）
-
团队（全角色研发团队）
迭代
迭代是在一个时间范围内组织所有角色配合最终产出交付物的活动过程。角色不单单是内部的产品研发测试运维，还包括技术支持、客户服务、销售等等。迭代难点在于规划和过程管控，所以核心指导思想我认为是：规范、可控。我给出了实际生产使用的迭代节点说明：
有如下几个场景：
- 敏捷看板（待办事项/进行中的sprint）
涉及需求边界确认的都可能有影响，团队内部使用敏捷看板来提交待办需求，划定最终需求边界。 - 筛选器（filter）问题清单
常用于整体需求确认的时候编辑需求属性，分配到对应研发人员。
也可以整理出最终的发布的需求清单用于制作改版说明和明确升级内容。
筛选器的问题清单页面有列表和详情两种模式，还可以自定义展示字段。 - 甘特图（插件/二次开发）
针对所有人员的子任务的甘特图，用于确认排期，过程跟进等。
团队
Jira的核心指导思想需要覆盖到所有目标人群，对人群的工作内容能够起到完善辅助、提高效率、全面覆盖的作用。
一个团队中主要包含三类常规角色：基层员工、中层管理、决策高层和外部单位。一类非常规角色：研发管理。
研发管理
研发管理一般来说是整个研发中心的规范制度建设和推动者，有些公司是有研发高层直接推动，有些公司会独立出单独部门来进行管理，根据不同公司的不同业务形态和团队构成而定。但是这个部门的职责会制定研发规范，推动系统使用和规范检查，还有绩效考核等管理工作。
本文中以单独部门的形态给大家介绍，这样区分会更加清晰。由于研发管理是规则的制定者，是最合适的管理者，能够达到知行合一。所以复杂的事情会堆积到这里来。有如下几个场景：
- 规范管理（仪表盘）
通过仪表盘筛选出违反规范的信息，整理汇总报告给管理跟进。 - 工时管理（插件/第三方BI）
研发管理规范要求每天的工时完整上报，所以需要跟进填报情况，记录异常。 - 绩效考核（筛选器+导出excel+第三方BI）
绩效要能够做到尽量量化，有数有据可查。由于Jira本身无法进行绩效的复杂规则制定和计算，所以需要导出excel来处理，后期规则固定则可以直接接入rest接口或者数据库连接进行计算。 - 系统改进
工作流、字段配置、脚本编写等等，如果你有编码的能力是一个极大的优势。
基层员工
无论是刚刚入职的新员工，还是创始团队的老员工，基层员工往往是被动的，需要安排工作。不同人员素质/经历不同，复杂的研发内部流程可能也会影响效率。对于基层员工而已，我们的核心指导思想就是：简单、直接。
有如下几个场景：
- 工作入口（仪表盘）
员工的工作场景，每天打开Jira，可以在一个页面上就获取我今天的所有工作，包括：按照时间/重要程序排序的待办工作，按照时间/重要程序排序的缺陷修复，管理规范异常任务（比如任务排期已经在今日之前还未完成），通知/公告类信息（如迭代排期、重要插入任务、修正发布任务清单等等）。员工培训很简单，在这个入口页面，你可以按照研发预定的规则来完成任务，修复缺陷，了解重要通知信息。 - 任务/缺陷工作流
我可能是一个产品/UI/后端/前端/测试，一个Story需要多个角色协作。现在有两种实现方式:
第一种： 主任务在不同角色之间流转，每个角色维护好主任务在自身当前环节的状态，并且在工作完成后流转至下一环节。
第二种：不同角色在主任务下建立子任务，每个角色维护好自身子任务状态，父任务工作流通过外部环节触发流转（自动/手动）。
第一种需要每个角色了解父任务的复杂流程，并且维护和触发流转工作流。第二种子任务工作流仅包含“待办-进行-结束”三种，任务可以并行无需关心前后流程。后一种与前一种相比对于员工的要求更低，出错的几率也更小，但是对于系统有更高的要求（自动流转），外部管理协调的要求也提高了。但是员工的工作流达到最简单。 - 工作汇报
很多公司都可能有日报、周报、月报等汇报类型，可能是邮件、excel等形式。缺点难以积累用于统计分析和改进，更贴近形式要求。汇报的部分可以考虑使用任务工时代替，将单日花费工时记录在任务上，能够在完成自身任务时候直接填报，自然的就完成了日报的工时填报，累计而成周报，月报。数据还能用于个人分析。
中层管理
中层管理一般身上会负担一定程度的技术工作/技术指导，同时也会负责小团队的管理跟进。技术的部分可以参考基层员工，针对他们的管理职能，我们希望能够给定一个规范成熟的管理模型引导他们直接套用，降低门槛和工作量，但是还能够达到比较好的最终管理效果。所以核心指导思想是：简单管理。
有如下几个场景：
- 评估/排期管理（仪表盘）
研发人员对任务的评估和排期的变更可能会造成整个排期波动，一些重要交付项最终延期而过程中无法了解到。所以我们将任务的评估和排期修改权限提到了管理层，研发管理部会每日去跟进所有研发人员的任务状态是否正确维护，并且通知主管跟进具体的任务异常。主管根据具体人员的实际情况来调整任务或者上报风险。
主管也可以（非必须）通过仪表盘了解本部门下属人员的异常状态。 - 折算工时（筛选器）
由于不同人员级别不同，所以完成同样任务花费时间不同，我们需要确认以同一标准评估所有人的任务工时，从而计算出一个折算工时来进行横向对比。
研发管理部生成好筛选器，提交给各个主管，评估一段时间内的部门人员的折算工时，最终用于生成绩效考核数据。
决策高层/外部单位
一方面，高层和外部单位其实都是在研发迭代循环的体系之外的，另一方面，外部单位和研发的可能是配合支持，高层则是更关心产出、团队情况和发展方向。
所以针对决策高层/外部单位，我思考的核心指导思想是：信息隔离，可视全面
- 信息隔离（项目分隔）
不同中心事务处理的流程不同，权限也有差异，所以最好将不同的流程体系拆分到不同项目进行隔离，如果有联动的状态要求，可以使用关联进行操作，自动触发流程流转。 - 汇报面板（第三方BI）
管理层在意的是整体层面的产出和损耗，要能够尽快的发现问题并修正，可视化是很好方式。可惜在Jira上并没有找到很好的可视化BI报表，所以这块需要依赖第三方数据报表。
总结
对第一节的内容进行一个总结，指导思想中最核心的其实就是两个字“简单”，但是这个简单是需要以研发管理人员的“复杂”为代价的。管理者无论在设计规范、流程或者制度时，都要考虑操作方的代价，要以少量人员的复杂换取大多数人的简单，而且要在能够满足管理需求的基础之上。
从Jira的模块来看，最重要的几个功能模块包括：仪表盘、筛选器（JQL语法）、自动化工作流，分别对应统一入口、多维度清单、简单操作推动复杂主流程。