问题跟踪平台问题处理流程规范总结

日常项目开发实施过程中，都会存在需求、缺陷、建议和任务等一系列围绕系统产生的问题任务出来，在工作信息系统化的发展背景下，通常大家都会使用统一的问题跟踪平台来记录、跟踪和管理各类问题，如JIRA，ITSM。附件是我基于问题跟踪平台问题（JIRA）在早期推广使用过程中出现的问题，进行了总结和规范，目的在于基于问题跟踪平台这个工具之上，重点补充如何去更好"用这个工具"，主要包括梳理全面工作协同流程，规范团队之间使用与协作方式，明确各个角色之间的责任。

1概要说明

本文档对问题跟踪平台的处理流程做了一个规范，适用人员：使用问题跟踪平台的所有人员，主要包括问题的发起人、问题的处理人、项目负责人。

以下问题的处理人统称“处理人”，问题的发起人统称“发起人”，本文中的项目负责人为问题跟踪平台上的项目负责人。

1.1预备知识

阅读本文档前，需首先阅读《问题跟踪平台使用手册.doc》文档。

下面对与理解本文关系密切的术语先进行一个解释：

问题：本文中所指的问题包括bug、需求等。

接收问题：对客户提出的所有问题都应该接收，但接收后的问题，并不是都会得到解决，有些问题可能会被拒绝，有些问题会被接受。

接受问题：接收问题后，可进行分析判断是否接受该问题，如果接受了该问题，其结果肯定会被解决。

问题跟踪平台上的相关术语：

提出人：原始问题的提出人

报告人：该问题提交到问题跟踪平台上的人员

逾期日期：该问题要求处理人最迟完成解决的日期。注意：此日期不能作为反馈给客户的解决问题的日期，因为问题只是在该日期被解决了，并没有进行测试和发布。

解决的版本：该问题被解决的版本号。

解决的版本发布日期：该问题被解决的版本的发布日期。此日期才可以作为反馈给客户的解决问题的日期的基准日期，但一般实际反馈给客户的解决问题的日期为基准日期+N天，N可自行定义，用于版本发布后现场测试。

1.2人员职责概述

1.2.1 发起人

发起人是客户与处理人之间的桥梁，是公司直接面对客户的窗口，是决定客户满意度的重要因素。发起人在问题的收集、定位、客户协调中起了重要的作用，其主要职责如下：

l负责收集客户或自己的问题并提交到问题跟踪平台上，必须将问题描述详细并通俗易懂。

l如果处理人要求问题进行协调处理，必须主动配合处理人进行协调工作。

l全程跟踪问题的处理，及时与客户做好沟通和反馈工作，直至问题被关闭。

l接收到问题后，需在规定时间（一般：非紧急问题不超过2个工作日，紧急问题不超过1个工作日）内给客户反馈：问题是否接受，对接受的问题告知处理完成时间，对不接受的问题与客户解释原因，并尽力与客户达成一致意见。可以接收问题，但不得擅自接受问题并给客户承诺，但明确属于bug的除外。

l解决问题的版本发布后，决定是否需要升级（可与客户、现场项目经理协商决定）。

l执行升级。

l升级后，及时告知客户被解决的问题

l关闭问题。

1.2.2 处理人

l负责执行问题的处理，并将结果详细写入到问题跟踪平台的备注里。

l如果处理的问题对开发计划影响很大或无法协调相关资源，必须及时向项目负责人汇报。

l负责问题的跟踪，直至问题被关闭。

l保证问题在项目负责人规定的逾期日期内完成处理。

1.2.3 项目负责人

l确定版本发布周期，确定最近一个版本发布的时间、发布内容、版本号，制定详细的发布计划，并在确定后进行版本发布预公告。

l问题分派：分析问题，确定是否接受问题。对接受的问题分发给处理人，确定问题解决日期、解决的版本发布日期、解决的版本号。对拒绝的问题给出解释。需在规定时间（一般：非紧急问题不超过2个工作日，紧急问题不超过1个工作日）内完成问题分派。

l根据处理人汇报的问题调整计划安排或协调其他相关资源。

l决定是否即时发布补丁。

l问题需要调期解决时，及时调整发布计划，当需要延期到下一版本或之后发布的，必须征得发起人或客户的同意。

l日常工作监控。

2 总体流程

处理总体流程如下图所示：

3 发起人

3.1 收集

1. 发起人有责任对客户的问题进行准确收集，并对问题进行分类：

l属于bug类的问题，需确保该bug可重现；对于暂时无法重现的bug，应积极持续跟踪；

l属于需求类的问题，需与需求的提出人进行详细调研，不允许擅自当场对需求提出人做出“答应实现该需求”之类的承诺。在调研清楚需求并得到现场项目经理同意后，提交到问题跟踪平台，并跟处理人进行有效沟通，根据沟通结果再跟客户进行协调。

2. 对问题的紧急程度进行判断，并征求客户及现场项目经理的意见。

3. 发起人收集的问题必须提交到问题跟踪平台上，如果未能及时提交问题，必须协调其他人员进行提交。

4. 问题的描述必须通俗易懂，最好附有图片加以说明。尤其对于界面改进类的需求，必须提供如何改进的说明或提供能反映客户喜好的相应界面参考。

5. 提交问题到问题跟踪平台时，需填写“提出人”，即该问题的原始提出人。如发起人自己提出的，则“提出人”与“报告人”相同。

3.2 协调

如果项目负责人或处理人提出问题需要发起人进行相关协调，发起人需要主动参与协调工作，并在问题备注中写明协调答复时间点。

3.3 跟踪

发起人每天关注自己提交的问题，如果问题紧急，必须通过电话方式与项目负责人进行确认。

如果解决问题的版本发布时间过长，发起人需要和客户进行解释说明（有必要时，发起人可要求现场项目经理的协助），如果未能得到客户认可，发起人可以联系项目负责人，对问题进行特殊处理。

3.4 反馈

1.问题是否接受反馈：发起人在提交问题后的规定时间内（一般：非紧急问题不超过2个工作日，紧急问题不超过1个工作日）给该问题的原始提出人及相关人员反馈。反馈内容包括：是否接受；如果接受的话，解决问题的版本号及上线时间；如果不接受的话，不接受的原因解释；或延期解决及原因。反馈方式可以通过邮件加电话方式进行。发起人应采用适当的方式和方法与客户达成一致意见，尤其对不接受的问题或需要延期处理的问题。

特别说明：反馈给客户的“解决问题的版本上线时间”根据问题跟踪平台上的“解决的版本发布日期”+N天（N可由各项目经理、发起人与开发项目负责人根据实际情况共同协商确定，如：江西项目规定N=3，这N天用于现场的升级前的测试工作）。

2.问题得到解决的反馈：现场版本进行升级后，应及时告知该问题的原始提出人及相关人员已被解决的问题。

3.问题调期解决的反馈：当计划解决的问题需要被调整延期解决时，及时与该问题的原始提出人进行协商，尽力达成一致，并把协商结果反馈给项目负责人。

3.5 验证

发起人得知问题解决后，必须及时验证问题，确认问题得到解决后，关闭问题。如果发现还有问题或未能完全实现，需要重新打开问题并及时通知处理人继续进行处理。

3.6 升级

确认产品发布后，发起人需要征得客户及现场项目经理的意见来决定是否升级。如果需要升级，需要立即准备工作安排，并提前协调项目负责人进行升级工作安排。

4项目负责人

l 制定并维护发布计划

确定版本发布周期，确定最近一个版本发布的时间、发布内容、版本号，制定详细的发布计划。并根据执行情况以及问题跟踪平台的问题情况维护更新发布计划。

l 版本发布预公告

确定发布计划后，及时进行版本发布预公告。可通过邮件的形式，发送给所有相关人员：发起人、发起人所在项目组的项目经理等。

l 问题分派

分析问题，确定是否接受问题。对于接受的问题：分发给处理人，确定问题解决日期、解决的版本发布日期、解决的版本号。对于拒绝的问题：给出详细的原因解释，并与发起人进行沟通，协助发起人给出可以与客户解释的原因。

需在规定时间（一般：非紧急问题不超过2个工作日，紧急问题不超过1个工作日）内完成问题分派。

l 协调：根据处理人汇报的问题调整计划安排或协调其他相关资源。

l 决定是否即时发布补丁。

l 问题需要调期解决时，及时调整发布计划，当需要延期到下一版本或之后发布的，必须征得发起人或客户的同意。

l 版本或补丁发布公告

版本或补丁发布后，需及时告知发起人及相关人员，可通过邮件的形式。必须说明本次发布修正的所有问题。

l 日常工作监控。

5处理人

5.1拒绝问题

1、已修复

如果问题已经在日常的开发中解决，先将问题逾期改成当前日期，然后添加备注充分说明此问题在哪个版本已经修复或未发布的版本已经修复（注明发布时间）；

2、不用修复

先与发起人联系并说明不用修复的原因。如果发起人确认可以不用修复，才可以做拒绝并不用修复的操作，并注明确认过程和不用修复的原因。

3、重复

先将重复的问题进行关联，然后添加详细备注，充分说明该问题与之前问题重复的地方。

4、不完整

如果发起人提交的问题不能完整描述问题，必须跟发起人进行沟通。如果发起人通过协调后仍然不能将问题描述清楚，并且同意关闭问题，处理人先将于发起人协调的过程写入到问题备注中，这样才能执行拒绝并不完整操作。否则，处理人可以要求发起人重新收集并修改问题描述。

5、不能重现

首先处理人与发起人联系，确认是否场景真的无法重现，如果发起人确认无法重现问题，则可以做拒绝并未能重现操作，问题处理里写明确认过程和无法重现原因。

6、延期处理

首先处理人将问题通知给项目负责人，项目负责人联系发起人确认是否可以延期。如果发起人最后确认可以延期，项目负责人将该问题主动分派给自己，然后调整开发计划和注明逾期日期，最后对问题做拒绝并延期操作，问题处理里写明确认过程和延期处理的时间点。

5.2接受问题

在拒绝操作处理方式上我已经说明了能使用拒绝操作的几个条件，如果在这些都不成立的时候，全部执行接受的流程中，确认接受的流程分为两种：

1、项目负责人确认接受

项目负责人接受问题后，会制定开发计划，并给出逾期时间。然后分派给相关处理人；

2、处理人确认接受

处理人如果在不影响自己开发计划时，可以自己给出逾期时间并接受问题，如果工作量比较大，对后面计划有所影响的话，处理人与项目负责人联系，项目负责人根据实际情况调整开发计划后，给处理人一个逾期时间，处理人将逾期时间填入到该问题的逾期时间，并接受问题。

确认问题是可以被接受的话，就必须保证问题处理最终状态是已修，特殊情况会出现处理中需要调整计划，所以这个时候可以将问题的状态改成延期。除了这两个状态以外，不能再有其他的处理状态出现。

最后需要强调的是，如果问题一旦被处理人接受，处理人如果开始进行对问题的处理，就必须将问题处理状态改成处理中，这样关注此问题的人就知道问题已经开始进行了。

5.3 处理人协调跟踪方式

有些时候在接受问题时，会涉及到需要协调的人。为了避免问题在协调的过程中出现跟踪不及时的现象，需要对协调时间作出有效的处理机制。具体流程如下：

1、确认需要协调处理

处理人发现问题需要协调，在备注中写明协调处理办法，首先以邮件方式进行答复，并口头或电话方式与发起人进行确认协调处理方法。

2、监控协调

处理人及时汇报需要协调的问题给项目负责人，项目负责人必须监控协调问题。

3、协调时间控制

处理人要求发起人给出一个答复时间，发起人必须要将答复时间写入到问题的备注中，处理人根据此时间来进行跟踪。如果发起人不能明确给出答复时间或答复时间延迟或给出的答复时间很长导致该问题修复的时间延迟的话，处理人需及时向项目负责人汇报，由项目负责人通知到相关人员（包括发起人、现场项目经理）并要求给出合理的答复时间。

协调过程中如果处理人需要项目负责人协调需要资源，要及时向项目负责人进行汇报。