软件开发项目中要管理的事情非常多，这些事情大多都是依照软件生命周期阶段来划分的。比如，需求、开发、测试等等。从项目管理的角度来看，项目管理主要要管好3类事情：
1） 任务（activities)；依照计划在检查点、里程碑完成的计划；
2） 变更(defect and new feature) ；从内外反馈回来的关于软件的bug和新增建议；
3） 问题(issue)；项目中不能计划或不期望发生的问题和困难，这些问题如果不能及时解决，将影响项  
       目的进度。

下面是翻译的项目管理的问题管理的规程文档：

1. 前言
1.1. 文档目的    
提供在项目或部门中管理问题的方法。    
1.2. 适用范围
经过立项并在项目实施中产生的问题；部门中非立项但跨部门比较重要的问题。

1.3. 术语与缩略语
问题（ISSUE）：项目执行过程中产生的，无法计划或者无法预料的问题和困难。问题会不同程度地影响项目的规模、进度、成本、质量等目标，因此需要及时地在项目内或外部一起评审并跟踪这些问题，直至解决。

风险(RISK):不确定的变化，一种可能性。问题(ISSUE)不同于风险，问题是真实的事情，风险是未来可能发生的事件。

2. 问题管理办法
2.1. 综述
       定义问题管理办法的目标是保障项目团队来标识、评审、监控、解决项目问题。这将保障问题在没有严重影响项目目标前，能够有序和及时地解决。

我们使用jira（bug/issue trcking system）来实现问题管理流程。

2.2. 标识问题
          任务                                               负责人
1. jira中标识并记录问题                        项目成员
2. 向项目经理报告问题                          项目成员

2.3. 评审问题

任务                                                                                        负责人
1. 分析问题的优先级和紧急程度，
协调安排解决问题，记录问题的分析结果。                           项目经理

2.4. 控制问题
任务                                                       负责人
项目例会中评审问题，
推进问题的解决，发起子任务，
如有必要，发起变更请求      。                  项目经理

2.5. 关闭问题
任务                                                      负责人
确认问题是否解决，                              项目经理

关闭问题。
3. 模板

==========原文

Issue Management Process
1 Issue Management
1.1 Introduction
An Issue is a problem that can arise throughout the life of a project. If left unattended,
issues can put the deliverables of the project at significant risk.
It is critical to log issues as soon as they are raised so they can be assessed and managed
properly. Logging issues immediately also eliminates the risk of them being overlooked and
thus causing serious problems later in the project’s life cycle.
1.2 Objectives
The objective of this process is to ensure that all project issues are:
• Captured and logged using Project Environment Reporting Tool (PERT);
• Adequately documented and analysed to determine the impact on the project and
alternative actions to be considered.
1.3 Scope
This process covers all issues impacting the project. A project issue may be:
• A Question on any project topic (issue);
• A Statement of concern by a member of the project team (issue);
• A Statement of concern by a stakeholder or interested party external to the project
(issue);
• A record of some current or forecast failure to meet a requirement (Agreed
Exception).
1.4 Procedure Steps
1.4.1 Issue Identification
An issue is raised either within the team or through discussions with an external body (eg a
stakeholder or supplier).
1.4.1.1 Process for Team members without access to PERT
The team member shall complete the identification details of the issue on the Issue
Notification Template and then forward it (electronically) to the Project Office Manager for
logging in PERT.
1.4.1.2 Process for Team members with access to PERT
The team member who identifies or is first informed of an issue shall enter it into PERT. To
do so, undertake the following steps:
Open the Project Form, Open Risks, Issues and Change Requests Tab
Click on New in the Key Issues Section and complete details in the following fields:
• Key Issue Name and description
• Issue ID
• Originator’s Name
• Priority Level
• Status
• Approval Level Required (needs to be changed in PERT)
• Date Issue Raised
• History Log
• Shortcuts to any related documentation.
Notify Project Office Manager via e-mail to alert them to a new issue.
On receipt of the notification e-mail, the Project Office Manager will:
• Review the issue to confirm details entered by the originating officer;
• Assign an issue owner and due date in consultation with appropriate Team Leaders.
• Ensure that communication of the issue response conforms to the issue response and
1.4.1.3 Severity Level
1 Critical: Project has ceased; The Budget, Time or Quality impacts are such that the
Project Business Case is imperilled.
2 Significant: The project’s performance in terms of Budget, Time or Quality are likely
not to be within prescribed tolerances, but the Business Case is not imperilled.
3 Moderate: Cost and Time within Stage Tolerance and Quality within prescribed limits.
SAMIS Project Issue Management Process
29 November 2002 09009 Issue Management Process V1.0.doc Page 3
4 Low: Other than Impact Levels 1, 2 or 3.
1.4.2 Issue Analysis
Before making a decision on a course of action, each Project Issue should be assessed for its
impact, and alternative actions considered by its owner.
An initial examination of a Project Issue should be done as soon as it is logged.
The Analysis of each Issue is to be completed using the Issue Analysis Template. A shortcut
to the document (or the actual document) is to be attached to the Document section of the
Issue Form in PERT.
All Issue analyses will be saved in the SAMIS/Project Office/Issue Management Folder.
The naming conventions for the file will be I000X Issue Analysis (X being the number of the
issue ID in PERT).
1.4.3 Issue Review
All active project issues are to be reviewed on a regular basis. Decisions on a course of
action cannot take place until the Issue can be seen in the wider context of stage status,
product delivery and progress against plan.
The exception to this delay is where the Project Issue requires an urgent need for action,
where review will be done ad-hoc/as required.
The following steps are to be taken in preparing issues for review:
• Assemble all available information including the issues affect on:
􀂉 Budget
􀂉 Time scales and deadlines
􀂉 Benefit achievement and/or value
􀂉 Risks
􀂉 Resourcing
􀂉 Meeting the requirements of the project
􀂉 Meeting the stated quality standards
• Update of the Risk analysis if the issue relates to a previously identified risk or reveals a
new risk
• Recommend a course of action.
At review meetings the teams should not only review new issues but:
• Review the status of all unresolved issues;
• Review the progress of issue resolution;
• Reassign priorities;
• Escalate resolution if necessary.
An entry to the Issue History Log is to be completed by the Project Office Manager or
appropriate delegate at the conclusion of the meeting.
1.4.4 Action
An issue can require 4 different kinds of action.
• Change Request - This is when a change is required to the scope of the project to
alleviate the issue. This is usually identified early in the issue process and the change
management process shall then be followed.
SAMIS Project Issue Management Process
29 November 2002 09009 Issue Management Process V1.0.doc Page 4
• Risk Review - Determine actions required to immediately minimise the issue’s current
impact or likelihood of impact later. For example, required funding not being available
when required.
• Specific Activity - Action outside of the project. For example preparation for briefing to
a key stakeholder.
• Agreed Exception - To document any issue where a product is failing, or is forecast to
fail, to meet its specification. This might be a missing product or a product not meeting its
specification.
1.4.5 Issue History Log Updated
After any significant discussions or actions are taken regarding an issue, the issue owner
must update the issue history log with details of its current status.
1.4.6 Issue Resolved
Once the issue is resolved, the date of resolution is to be completed, the status changed to
resolved and the History Log updated with final details.