Summary of problem handling process specifications on the problem tracking platform

In the process of daily project development and implementation, there will be a series of problems and tasks around the system, such as requirements, defects, suggestions, and tasks. In the context of systematic development of work information, generally, a unified problem tracking platform is used to record, track, and manage various problems, such as Jira and ITSM. The appendix summarizes and standardizes the problems I encountered during the early promotion and use of the problem tracking platform (Jira), with the aim of using the problem tracking platform tool, it focuses on how to better "use this tool", including organizing the comprehensive work collaboration process, standardizing the use and collaboration between teams, and clarifying the responsibilities of each role.

1. Summary

This document regulates the handling process of the problem tracking platform. Applicable personnel: All personnel using the problem tracking platform, including the problem initiator, problem handler, and project owner.

The problem handler is collectively referred to as the "handler", and the problem initiator is collectively referred to as the "initiator". The project owner in this article is the project owner on the problem tracking platform.

1.1 prerequisites

Before reading this document, you must first read the Topic Tracking platform using the manual. Doc document.

The following is an explanation of the terms that are closely related to understanding this article:

Problem: The problems mentioned in this article include bugs and requirements.

Receive questions: All questions raised by the customer should be received, but after receiving the questions, they may not be resolved, some problems may be rejected, and some problems may be accepted.

Accept questions: After receiving the problem, you can analyze and determine whether to accept the problem. If you accept the problem, the result will certainly be resolved.

Related terms on the issue tracking platform:

Proposed: Author of the original question

Speaker: Persons who submit the problem to the problem tracking platform

Expiration Date: This issue requires the handler to complete the resolution by the latest date. Note: This date cannot be used as the resolution date for feedback to the customer, because the problem was resolved only on that date and was not tested and released.

Solved version: Version number to be resolved.

Release Date of the version to be resolved: Release Date of the version to be resolved. This date can be used as the benchmark date for feedback to the customer to solve the problem, but generally the actual problem solving date is the benchmark date + N days, N can be customized, used for on-site testing after version release.

1.2 personnel responsibility overview 1.2.1 Initiator

The initiator is a bridge between the customer and the handling person. It is a window for the company to directly face the customer and an important factor that determines the customer satisfaction. The initiator plays an important role in problem collection, locating, and customer coordination. Its main responsibilities are as follows:

L is responsible for collecting customer or their own problems and submitting them to the problem tracking platform. The problem description must be detailed and easy to understand.

L if the handler requires coordination of the problem, it must actively cooperate with the handler for coordination.

L tracking problem handling throughout the process, timely communicating with the customer and providing feedback until the problem is closed.

L after receiving the problem, the required time (GENERAL: non-emergency issues cannot exceed 2 working days, and urgent issues cannot exceed 1 working day) Report to the customer: whether the problem is accepted, inform the customer of the handling completion time of the accepted problem, explain the reason to the customer for the unacceptable problem, and try to reach an agreement with the customer.Problems can be received, but they cannot be accepted without authorization and promised to the customer, except for bugs that are clearly identified.

L after the release of the version to solve the problem, determine whether to upgrade (you can negotiate with the customer and the on-site project manager ).

L perform the upgrade.

L notify the customer of the resolved problems after the upgrade

L close the problem.

1.2.2 handled

L handles the problem and writes the result to the remarks of the problem tracking platform in detail.

L if the problem to be handled has a great impact on the development plan or the relevant resources cannot be coordinated, the project owner must report the issue to the Project Administrator in a timely manner.

L tracks the problem until the problem is closed.

L ensure that the problem is handled within the deadline specified by the project owner.

1.2.3 project owner

L determine the version release cycle, determine the time, content, and version number of the latest version release, formulate a detailed release plan, and release the pre-announcement after confirmation.

L problem assignment: analyze the problem and determine whether to accept the problem. Distribute the accepted problems to the handling personnel, determine the problem resolution date, the version release date, and the version number to be resolved. Explain the rejection. At the specified time (GENERAL: non-emergency issues cannot exceed 2 working days, and urgent issues cannot exceed 1 working day.

Arrange or coordinate other related resources according to the problem report reported by the handler.

L decide whether to release patches instantly.

L the release plan should be adjusted in a timely manner when the problem needs to be solved. If the problem needs to be postponed to the next version or later, the release must be approved by the initiator or customer.

L daily work monitoring.

2. Overall process

Shows the overall process:

 

3 initiator 3.1 Collection

1. The initiator is responsible for accurately collecting and classifying the customer's problems:

L It is a bug issue and must be ensured that the bug can be reproduced. For bugs that cannot be reproduced for the time being, it should be actively tracked;

L it is a requirement issue and requires a detailed investigation with the person who asks the request. It is not allowed to make a "promise to fulfill this requirement" or other commitments to the person who asks the request on the spot without authorization. After the investigation is clear about the requirements and is approved by the on-site project manager, submit the information to the problem tracking platform, communicate effectively with the handling personnel, and coordinate with the customer based on the communication results.

2. determine the degree of urgency of the problem and solicit the opinions of the customer and the on-site project manager.

3. Issues collected by the initiator must be submitted to the issue tracking platform. If the problem cannot be submitted in time, other personnel must be coordinated to submit the issue.

4. The description of the problem must be easy to understand. It is best to attach an image to describe the problem. Especially for interface improvement requirements, you must provide instructions on how to improve or provide corresponding interface references that reflect customer preferences.

5. When submitting a question to the problem tracking platform, you must fill in the "author", that is, the original author of the question. If the initiator proposes it, the "creator" is the same as the "Speaker.

3.2 coordination

If the project owner or the handling person asks a question and requires the initiator to coordinate the problem, the initiator must take the initiative to participate in the coordination and specify the coordination reply time in the remarks.

3.3 tracking

The initiator pays attention to the issues submitted by himself every day. If the problem is urgent, he/she must confirm with the project owner by phone.

If the release time of the version to solve the problem is too long, the initiator must explain the problem to the customer (if necessary, the initiator may ask the on-site project manager for assistance). If the problem is not approved by the customer, the initiator can contact the project owner to handle the problem.

3.4 Feedback

1.Problem accepted feedback: The initiator shall be within the specified time after submitting the problem (generally, the non-urgent issue shall not exceed 2 working days, and the urgent issue shall not exceed 1 working day) provide feedback to the original author and related personnel. The feedback includes: accept or not; the version number and launch time of the solution if it is accepted; the reason for rejection if it is not accepted; or the reason for deferred resolution and reasons. Feedback can be sent via email and phone. The initiator shall reach an agreement with the customer in an appropriate manner and method, especially for unacceptable issues or issues that need to be extended.

Note: The "release time of version to Solve the Problem" reported to the customer is based on the "Release Date of version to be resolved" + N days on the problem tracking platform (N can be provided by various project managers, initiators and Development Projects) the owner shall negotiate and determine based on the actual situation, for example, the Jiangxi project requires n = 3, which is used for testing before the on-site upgrade ).

2.Feedback on problem solving: After the on-site version is upgraded, the original author of the problem and the relevant personnel should be informed of the problem.

3.Feedback on problem adjustment and Solution: When the problem to be resolved needs to be adjusted and postponed, negotiate with the original creator of the problem in a timely manner to reach an agreement and report the negotiation result to the project owner.

3.5 Verification

After the problem is resolved, the initiator must verify the problem in time and close the problem after confirming that the problem has been resolved. If the problem persists or is not fully implemented, open the problem again and notify the handling personnel to proceed.

3.6 upgrade

After the product is released, the initiator needs to obtain the opinions of the customer and the on-site project manager to determine whether to upgrade the product. If you need to upgrade, you need to prepare the work arrangement immediately and coordinate the project owner in advance to upgrade the work arrangement.

4. Project Owner

LDevelop and maintain release plans

Determine the version release cycle, determine the time, content, and version number of the latest version, and formulate a detailed release plan. Maintain and update the release plan based on implementation and problem tracking platform issues.

LRelease pre-announcement

After determining the release plan, release the pre-announcement in a timely manner. You can send an email to all related personnel: the initiator and the Project Manager of the project team where the initiator is located.

LIssue assignment

Analyze the problem and determine whether to accept the problem. For accepted problems: distribute the problem to the handling person to determine the problem resolution date, the version release date to be resolved, and the version number to be resolved. For rejection: provide detailed explanations of the cause, communicate with the initiator, and help the initiator to explain the cause to the customer.

Issue assignment should be completed within the specified time (generally: non-urgent issues cannot exceed 2 working days, and urgent issues cannot exceed 1 working day.

LCoordination:Arrange or coordinate other related resources according to the problem reported by the handler.

LDecide whether to release patches instantly.

L the release plan should be adjusted in a timely manner when the problem needs to be solved. If the problem needs to be postponed to the next version or later, the release must be approved by the initiator or customer.

LRelease announcement of version or patch

After a version or patch is released, the initiator and related personnel must be notified in a timely manner. You can send an email. All problems corrected in this release must be described.

LDaily Work monitoring.

5. Handling person 5.1 rejection

1. repaired

If the problem has been solved in daily development, change the problem to the current date after expiration, then add remarks to indicate which version of the problem has been fixed or has not been released (indicating the release time );

2. No repair required

First, contact the initiator and explain the reasons for no repair. If the initiator confirms that no repair is required, the initiator can reject the repair and does not use the repair operation, and indicate the confirmation process and the reason for not using the repair.

3. Repeated

Associate the duplicate question first, and then add detailed remarks to fully describe where the problem is repeated.

4. Incomplete

If the problem submitted by the initiator cannot be fully described, you must communicate with the initiator. If the initiator still cannot clearly describe the problem through coordination and agrees to close the problem, the handler will first write the process coordinated by the initiator into the problem remarks to reject incomplete operations. Otherwise, the handler can ask the initiator to re-collect and modify the Problem description.

5. cannot reproduce

First, the handler contacts the initiator to confirm whether the scenario cannot be reproduced. If the initiator confirms that the problem cannot be reproduced, the attacker can reject the problem and fail to reproduce it, the confirmation process and the cause of failure to reproduce are provided in troubleshooting.

6. Deferred Processing

First, the handler notifies the project owner of the problem. The project owner contacts the sponsor to confirm whether the problem can be extended. If the initiator finally confirms that the issue can be extended, the project owner assigns the issue to himself, adjusts the development plan and specifies the expiration date, and finally rejects and delays the issue, the confirmation process and the time points for deferred handling are provided in troubleshooting.

5.2 acceptance questions

In terms of the denial of Operation processing method, I have already stated several conditions that can be used to reject the operation. If none of these conditions are met, all the processes that are accepted will be executed, there are two processes to confirm acceptance:

1. the project owner confirms acceptance

After the project owner accepts the problem, the project owner will formulate a development plan and give the overdue time. Then, it is assigned to the corresponding handler;

2. the handler confirms acceptance

If the handler can give the problem deadline and accept the problem without affecting the development plan, and if the workload is large and it affects the subsequent Plan, the handler should contact the project owner, after the project owner adjusts the development plan according to the actual situation, the project owner will give the handling person an overdue time. the handling person will fill in the overdue time of the problem and accept the problem.

If you confirm that the problem is acceptable, you must ensure that the final state of the problem is fixed. In special cases, you need to adjust the plan during handling. Therefore, you can change the status of the problem to extended. In addition to the two statuses, no other processing statuses can appear.

Finally, it should be emphasized that if the problem is accepted by the handler,If the handler starts to process the problem, the problem handling status must be changed to processing.In this way, the person who follows the problem will know that the problem has started.

5.3 handling person coordination and tracking

Sometimes, when accepting a question, it involves people who need to coordinate. In order to prevent problems from being tracked in a timely manner during the coordination process, an effective handling mechanism should be made for the coordination time. The specific process is as follows:

1. confirm the need for coordination

The handler should coordinate the problem discovery, and specify the coordination solution in the remarks. First, reply by email,Confirm and coordinate with the initiator via oral or telephone.

2. Monitoring and Coordination

The handling personnel should promptly report issues to the project owner, and the project owner must monitor and coordinate issues.

3. Coordinated Time Control

The handler requires the initiator to give a reply time. The initiator must write the reply time to the remarks of the question, and the handler will follow up based on the time. If the initiator cannot explicitly provide a reply time or a reply time delay or a long reply time may lead to a delay in fixing the problem, the handler should report the problem to the project owner in a timely manner, the project owner notifies the relevant personnel (including the initiator and on-site project manager) and requests a reasonable response time.

If the project owner is required to coordinate resources during the coordination process, report to the project owner in a timely manner.