Continuing the journey
The Maintain section of support is intended to provide customers with ongoing support and maintenance for their applications. Engagement with Support needs to be consistent so that you have someone with a good understanding of the project available to quickly resolve application and infrastructure issues. Infrastructure support (via a Managed Service Provider) includes ensuring your application is up and running, as well as maintaining the server, database and other services used by the application. Application support is generally focused on problems discovered by users that are hindering them from engaging with the application as they expect. In software products these types of defects and infrastructure issues can arise often and should as a result be prioritised based on their impact to the user.
Underpinning the support phase are three levels that define how a submitted ticket will be handled, and by whom.
Level 1: Basic help desk support
Level 1 support is the first support tier within any operation. It is usually provided by lower-level IT support personnel but can change depending on the context and requirements. Typically, tasks required here are collecting customer requirements, handling calls and basic troubleshooting to mitigate the impact of user centric problems.
Level 2: In-depth technical support
Level 2 support is handled by a trained support developer able to triage, estimate and resolve issues with an application. Pre-requisites for handling these requests is having knowledge of the system, understanding its expected behaviour and having access to relevant information or people. It’s important that any resolutions are handled using standard development, testing and quality practices.
Level 3: Expert product and service support
An issue is typically deferred to level 3 once all layers of support development have been exhausted and the original, or a more senior software developer needs to address the request. These developers will have the most appropriate level of knowledge and information available to them to resolve the issue. To save time and effort, it’s important that all information currently gathered through the first 2 levels is transferred to level 3.
External vendor and supplier support
Outside of the levels defined, sometimes application problems come from outside the organisation that developed the application. In these cases, level 2 and 3 support need a mechanism to identify vendor or supplier issues that need to be deferred to the support mechanism of the relevant parties. If you source anything from external vendors or suppliers, it’s important to have a channel available to gain support in these instances. A good example here is integrating with a payment gateway, where that gateway’s API requires its own fix to work on other applications.
Even though a build has entered support, this does not mean that a customer needs to stop work with a Delivery Team. Once a version of the application has been released to production, the support team will be able to handle the active maintenance and improvement of that build. Meanwhile, this allows the other teams to begin focusing on the next problem statement, scope and subsequent iteration of the product. Once that subsequent development cycle is ready for production, a similar flow can begin, to handover the next version of the application for support.
Product Owners, or in some cases their users, can submit tickets to support. Tickets tend to come in the form of defects, general questions or improvements. Submitted tickets require time to triage, replicate, diagnose and attempt to resolve the issue. Tickets that are improvements will be deferred to a separate Enhance process for proper elaboration prior to development. To manage the priority of requests, product owners are asked to assign one of the severity levels defined below.
Blocker: Produces an emergency in which the software is inoperable, produces incorrect results, or fails completely.
Critical: Produces a detrimental situation in which performance of the software degrades substantially under responsible loads, such that there is a severe impact on use.
Major: Produces an inconvenient situation in which the software is usable but does not provide a function in the most convenient or expeditious manner.
Minor: Produces a noticeable situation in which the software use is affected in some way but can be corrected by a documented change or by a future release.