Mobile Product Support: Tasks, Processes, Tools

A long production cycle (time to market) is evil, especially in the field of mobile technology, where operating systems are updated every year, and new devices appear every two to three months. Therefore, do not be afraid to go out with a simple product with a minimum of functionality. Work on applications should go in a continuous improvement format with short iterations (no more than a month for updates) and with well-established feedback. In other words, the heaped up application should become gradually.

Alexander Alekhin, director of the Redmadrobot mobile application support and development department (@alekhinsasha), shares the experience of organizing processes.

Need support

The main specialization of our company is service applications for self-service clients of financial, insurance and telecommunication companies. And there is some specificity. On the one hand, these companies have their own customer service departments, which take on the first wave of user questions and complaints. On the other hand, the support of such applications requires an increased level of service provision, which is tied to the level of service of the client company.

The main tasks solved after the publication of the application are:

• health monitoring;
• receiving feedback from end users of the product and assisting in solving their problems;
• improving the stability of work and adding new functionality;
• adaptation of the application for new devices and OS versions;
• tracking the degree of satisfaction of the business needs of the client company;
• adjustment of the product development plan.

And here is how we solve these problems in Redmadrobot.
')

Work flow and support and development processes

We conduct all activities related to the support and development of products in accordance with the ITIL methodology in the framework of six main processes:

1. Incident and Problem Management
2. Change management
3. Release Management
4. Service Management
5. Audience management
6. Business Value Management

Release Management

Formally, the result of our work is the release of a new release, so the release management process can be considered central to the overall scheme. It consists of the following successive stages:

• release planning
• release build
• release release

The composition of the future release is formed from:

• defects identified during operation
• A new functionality that is not included in previous updates or appeared in the process of formulating new requirements

Thus, the "fuel" for working on releases, as shown in the diagram, provides the incident and problem management process and the change management process.

Work on building the release is in accordance with the methodology of Agile, and its composition is packaged in one or more sprints. Jira is used as a task tracker, in which we set up a separate Workflow and a set of Agile boards.

On the topic of working with the Agile Board in Jira, I recommend a detailed article from the guys from Yandex.Kartinok: “Agile Board. How we plan in Yandex. Pictures and how we came to this. ”

The quality of the release is evaluated by user feedback, as well as by the deviation of the number of crash reports from the background level.

 : — Jira   : —   —    (Request for Change  RFC)   : —  (Release Candidate) —    : , ,   —    :         —  QA-       : — - —     —  

Incident and Problem Management

The purpose of this process is to timely solve the problems found during the operation of the application.

According to the definition:
An incident is any event that is not part of the standard (standard) use case, which resulted in partial or complete inability to use the application.
A problem is an unknown cause of one or more incidents.

The work in this process is built according to the classical three-level scheme:

First level
Operational service - a single point of entry appeals. Carries out the registration and classification of applications, the determination of their priority and responsible for the execution, is responsible for solving typical incidents.
As I mentioned at the beginning, this level of support is given to the customer service department on the customer side. We only supply operational personnel with the necessary documents and instructions and help build the process of interaction with the second level.

Second level
Support engineers - conduct technical expertise and solve atypical incidents, are responsible for updating the application knowledge base, detect defects and transfer them to the third level of support. At the same level, the middleware is administered, if it is used.
Problem solving is transferred to the third level if the cause is related to the product architecture or software implementation.

Third level
Developers and testers - analyze complex incidents that are not resolved at the second level, correct defects, test the solutions provided.

We receive information on incidents and problems through three channels:

• our Helpdesk-system - Zendesk, in which the registration, classification and control of the execution of applications
• application stores, the daily monitoring of reviews in which allows you to identify critical defects, especially in the first days after the publication of the update
• application health monitoring systems that collect crash statistics and automatically initiate tasks in the bug tracker

  : — Zendesk — Crashlytics  Google Analytics — Jira   : —      —       : —           : —   —  —     — - 

Change management

The purpose of the process is to estimate the cost of making changes, as well as their impact on the product.
As part of the process, RFCs are accepted, requirements are detailed, the degree of impact of changes, costs and risks associated with their implementation is assessed.

All requests fall into the tracker, where after analyzing the implementation, depending on the degree of criticality for the business, they either get into the backlog of the product, or immediately into the sprint of the next release.

  : — Jira   : — RFC   : —     (Road Map) —         : —      —   — - 

Audience management

As part of this process, we directly interact with the end users of the application:

• we monitor user feedback in order to detect missing defects as well as adjust the product development plan
• answer questions about the functionality of the product (unfortunately, this opportunity is only on Google Play)
• inform about plans for release
• we filter inadequate comments and plus those that are in the case

In short, we are conducting a dialogue with users, making it clear that their opinion about the product is important to us.

Obviously, it’s almost impossible to work with negative reviews in app stores. They are emotional, uninformative, besides there is no feedback. Therefore, we motivate users to report problems to the support service via the feedback form. It can be found on the “About application” screen standard for our projects or opened at the time of evaluation in case the user wants to stick a two or one.

In addition to maintaining the rating, the feedback form allows you to collect the necessary information for analysis: device type, OS version, account information and context.

Choosing the right moment to show the assessment dialogue, as well as the trick with redirecting negative emotions is well described in the article “Prompting for App Reviews” ( translated from Macilove).

  : — Google Play Developer Console — iTunes Connect — Windows Phone Dev Center — AppAnnie —      : —     — ,        : —          —        : —   

Business Value Management

The most important process in terms of product development. Its goal is to plan product changes to achieve key business indicators defined by the business.

I think more than half of all mobile business applications do not track any metrics at all. At best, monitor the number of users in Google Analytics. Decisions to change the design and functionality of the product in such situations are taken on a whim and not reasoned. Meanwhile, in order to continually improve the quality of the product, it is vital to count and analyze key metrics that are synchronized with business goals.

The process is based on the collection and analysis of metrics at each stage of the conversion funnel. As part of the process, we conduct the following activities:

• tuning tracking and analytics systems
• designing funnels inside the application to assess the achievement of specific business goals
• visualization of changes in metrics
• consulting in the field of analytics (what is good and what is bad for business from the point of view of metrics, and not divination)
• metrics improvement activities
• providing analytics by direct competitors

  : — AppsFlyer — Flurry — Google Analytics — AppAnnie — AppInTop   : —          : —  Road Map  : — - —      

Service Management

The purpose of this process is to monitor compliance with the signed SLA and improve the quality of support services.

A Service Level Agreement or SLA (Service Level Agreement) is a document describing the services provided as part of the support, the procedure for providing these services, as well as measurable quality indicators, such as:

• response time
• the time to solve incidents and defects depending on the degree of their criticality and impact on business processes

Read more about SLA in the article “SLA for beginners”.

Now we offer a choice of two options for agreement: basic and advanced, differing in response time to applications and problem solving, as well as the number of channels that we monitor to assess the performance of the application.

At the output, the process generates reports that give an idea of ​​the quality of support and the general state of the product to all interested parties. During the experiments with reporting, we stopped at the following formats:

A daily report informing the release manager of critical issues that have arisen, or of overdue tasks beyond the scope of the SLA, is a kind of siren that turns on when something seriously goes wrong. Daily reports also take into account bursts of negative reviews in app stores, which is especially important in the first days after the update.

The weekly report is a monitor of feedback received on all the channels we track. The report consists of three parts:

1. Ticket statistics in Zendesk for each type of ticket:
   
   • change requests
   • incidents
   • defects
2. Statistics on crashes in Crashlytics, which gives an idea of ​​the stability of the release. At each failure, an error message is generated, which, if a certain level of severity is exceeded, automatically gets into our bug tracker.
3. Statistics on reviews in the app stores, taking into account the rating change for the week, the total number of reviews and the number of established defects. In addition to quantitative indicators, the free-form support engineer provides a qualitative description of reviews, focusing on obvious problems and frequent requests from users.

The monthly report contains information on the number of hours spent by each of the specialists for budgeting and accounting for support costs, as well as the percentage of compliance with the SLA, which allows you to identify systematic violations and make management decisions. The report is intended for managers of the project office and the department of support and development.

  : — Zendesk — Jira   : —         —    (,   )     : — ,       : —   

findings

1. By all means convince the customer of the correctness of work with short iterations. Give him the book Getting Real and Rework. Take as an example successful products based on a continuous improvement model. Prove that only this approach will ensure the maximum possible satisfaction of the business needs and the needs of their customers.
2. Build a support system for your products. Without it, you will not be able to work with a more or less large customer. If you do not have an SLA, most likely, you will not even be admitted to the tender.