How we choose ideas for the development of our products: the vendor must be able to hear ...
In this article I will share the experience of selecting ideas for the development of the functionality of our products and tell you how to keep the main vectors of development.
We are developing an automated billing system (ASR) - billing. Term
The life of our product is 14 years. During this time, the system has gone from the first versions of industrial tariffing to a modular complex consisting of 18 products that complement each other. One of the most important aspects of long life for programs is continuous development. And development needs ideas.
Ideas
Sources
There are 5 sources:
Classification of cases
From the sources we get raw data - letters, tickets, verbal requests. Everything
references are classified:
')
There are such statistics on appeals - immediately after the release, the number of appeals grows by 10-15% for a short time. There are also splashes of calls when a new client with a large number of users comes to our cloud services. People learn to use new software features, they need advice. Even a small client when starting work in the system easily burns more than 100 hours of consultations per month. Therefore, when connecting a new client, we always reserve time for initial consultations. Often, we even select a specific specialist. The cost of rent, of course, does not pay for these efforts, but with time the situation is leveled. The adaptation period takes, as a rule, from 1 to 3 months, then the need for counseling is significantly reduced.
Previously, we used self-written solutions for storing requests. But gradually switched to Atlassian products. First, we transferred the development to make it easier to work on Agile, then support. Now all critical processes live in Jira SD, plus are provided with various plug-ins to Jira, plus Confluence. Writing solutions remained only on non-critical processes for the company. It turned out that the tasks we now have are end-to-end, can be transferred between support and development without jumping from one system to another.
From this bundle, we can obtain data on all tasks, planned and actual labor costs, use different pricing options for clients and generate documentation for internal needs and a report to clients.
Processing change requests
Usually such requests come in the form of functional requirements. Our analyst studies the query, forms the specification and TZ of the top level. Transmits the specification and TK to the person who made this request for approval - we must be sure that we speak the same language with the customer.
Having received confirmation from the customer that we understand each other correctly, the analyst makes a request to the backlog of the product.
Product Function Management
Backlog accumulates incoming requests for change and development. Every six months, a technical council is convened, consisting of a director, managers of maintenance, development, sales, and a system architect. In the discussion format, the council reviews and prioritizes applications from backlog and coordinates 5 development tasks for implementation in the next release.
In fact, the technical council responds to the requirements of the industry and the market, considering the needs recorded in the applications. Everything that has low relevance remains in the backlog and does not reach development.
Classification of change requests and finances
Development is expensive. Therefore, we will immediately tell you what options we may have if the change request came from a client, not an employee.
Requests for change are classified as follows: industry need or individual feature of the enterprise; A significant amount of new functionality or small fix. Minor fixes and individual requests are processed without any frills. Individual requests are calculated and implemented for a specific client in the framework of the project work with him.
If this is not a massive industry need and the amount of functionality is large, then a decision may be made to develop a new separate module that will be sold in addition to the basic functionality. In the event of such a request from the client, we can assume the costs of developing the module, provide the client with a module for free or with partial payment, and put the module on public sale. In such a situation, the client takes on a part of the methodological burden and, in fact, carries out a pilot implementation of the module.
If this is a massive industry need, then a decision can be made to include the new functionality in the base product. The costs in this case fall entirely on us, and the new functionality appears in the current version of the programs.
Old customers are provided with an update.
It may also be the case that several customers have a similar need, but it does not pull on a mass product. In this case, we can send the specification to these customers and offer to share the development costs between them. As a result, everyone wins: customers get the implementation of functionality for low cost, we enrich the product, after a while the other market participants can also get functionality for their use.
Devops
The development prepares two major releases per year. In each release, time is reserved for the implementation of 5 tasks received from the technical council. Thus, we never forget about the development of the product.
Each release passes the corresponding complex of testing and documentation. Further, this release is installed in the test environment of the corresponding customer, who in turn checks everything thoroughly, and only after that the release is translated into production.
In addition to the release system, there is a format of fast bug fixes so that clients do not live with errors for half a year. This intermediate format will allow you to quickly respond to incidents of the first priorities and implement the declared SLA.
All of the above is true primarily for the corporate sector and on-premise solutions. For cloud services oriented on the SMB segment, there are no such opportunities for customers to participate in the product development. The rental format for SMB does not even suggest this. Instead of a change request in the form of clear requirements from the corporate party, here is just the usual feedback and suggestions for the service. We try to listen, but the product is massive and the desire of one client to bring something familiar from its old historical system may contradict the development strategy of the system as a whole.
We are developing an automated billing system (ASR) - billing. Term
The life of our product is 14 years. During this time, the system has gone from the first versions of industrial tariffing to a modular complex consisting of 18 products that complement each other. One of the most important aspects of long life for programs is continuous development. And development needs ideas.
Ideas
Sources
There are 5 sources:
- The main friend of the developer of corporate information systems is the client . And the client is a collective image of decision makers, project sponsors, owners and performers of processes, in-house IT specialists, ordinary users and a large number of interested individuals in varying degrees. It is important for us that each of the customer representatives is potentially a supplier of ideas. In the worst case, we get only negative feedback about problems in the system. At its best, there is a person on the client’s side who is a constant source of ideas for improvement, providing structured information about the client’s needs.
- Our salespeople and account managers are the second most important source of ideas for improvement. They actively communicate with representatives of the industry a lot, receive first-hand requests for billing functionality from potential customers. Sellers and accounts have to be aware of all the significant changes in their functionality and the latest software updates of competitors, to be able to justify the pros and cons of different solutions. It is these employees of ours who are the first to feel if any billing opportunities become the de facto standard, without which the software cannot be considered full-fledged.
- The product owner is one of our top managers or a very experienced project manager. He keeps in mind the strategic goals of the company and adjusts the product development plans in accordance with them.
- An architect , a person who understands the possibilities and limitations of selected / used technological solutions and their influence on the development of a product.
Development teams, testing. People who are directly involved in product development.
Classification of cases
From the sources we get raw data - letters, tickets, verbal requests. Everything
references are classified:
')
- Consultations with the meaning of “How to do it?”, “How does it work?”, “Why is it impossible?”, “I did not understand ...”. Appeals of this type go to the Level 1 Support Line. It is possible to retrain the consultation in other types of appeals.
- Incidents with the meaning “Not working” and “Error”. Processed 2 and 3 lines of support. If necessary, prompt corrections and release of the patch can be transferred from the support immediately to the development. Possible retraining in a request for change and sending to backlog.
- Requests for change and development . Fall into the backlog of the product, bypassing the Support Lines. But for them there is a separate processing procedure.
There are such statistics on appeals - immediately after the release, the number of appeals grows by 10-15% for a short time. There are also splashes of calls when a new client with a large number of users comes to our cloud services. People learn to use new software features, they need advice. Even a small client when starting work in the system easily burns more than 100 hours of consultations per month. Therefore, when connecting a new client, we always reserve time for initial consultations. Often, we even select a specific specialist. The cost of rent, of course, does not pay for these efforts, but with time the situation is leveled. The adaptation period takes, as a rule, from 1 to 3 months, then the need for counseling is significantly reduced.
Previously, we used self-written solutions for storing requests. But gradually switched to Atlassian products. First, we transferred the development to make it easier to work on Agile, then support. Now all critical processes live in Jira SD, plus are provided with various plug-ins to Jira, plus Confluence. Writing solutions remained only on non-critical processes for the company. It turned out that the tasks we now have are end-to-end, can be transferred between support and development without jumping from one system to another.
From this bundle, we can obtain data on all tasks, planned and actual labor costs, use different pricing options for clients and generate documentation for internal needs and a report to clients.
Processing change requests
Usually such requests come in the form of functional requirements. Our analyst studies the query, forms the specification and TZ of the top level. Transmits the specification and TK to the person who made this request for approval - we must be sure that we speak the same language with the customer.
Having received confirmation from the customer that we understand each other correctly, the analyst makes a request to the backlog of the product.
Product Function Management
Backlog accumulates incoming requests for change and development. Every six months, a technical council is convened, consisting of a director, managers of maintenance, development, sales, and a system architect. In the discussion format, the council reviews and prioritizes applications from backlog and coordinates 5 development tasks for implementation in the next release.
In fact, the technical council responds to the requirements of the industry and the market, considering the needs recorded in the applications. Everything that has low relevance remains in the backlog and does not reach development.
Classification of change requests and finances
Development is expensive. Therefore, we will immediately tell you what options we may have if the change request came from a client, not an employee.
Requests for change are classified as follows: industry need or individual feature of the enterprise; A significant amount of new functionality or small fix. Minor fixes and individual requests are processed without any frills. Individual requests are calculated and implemented for a specific client in the framework of the project work with him.
If this is not a massive industry need and the amount of functionality is large, then a decision may be made to develop a new separate module that will be sold in addition to the basic functionality. In the event of such a request from the client, we can assume the costs of developing the module, provide the client with a module for free or with partial payment, and put the module on public sale. In such a situation, the client takes on a part of the methodological burden and, in fact, carries out a pilot implementation of the module.
If this is a massive industry need, then a decision can be made to include the new functionality in the base product. The costs in this case fall entirely on us, and the new functionality appears in the current version of the programs.
Old customers are provided with an update.
It may also be the case that several customers have a similar need, but it does not pull on a mass product. In this case, we can send the specification to these customers and offer to share the development costs between them. As a result, everyone wins: customers get the implementation of functionality for low cost, we enrich the product, after a while the other market participants can also get functionality for their use.
Devops
The development prepares two major releases per year. In each release, time is reserved for the implementation of 5 tasks received from the technical council. Thus, we never forget about the development of the product.
Each release passes the corresponding complex of testing and documentation. Further, this release is installed in the test environment of the corresponding customer, who in turn checks everything thoroughly, and only after that the release is translated into production.
In addition to the release system, there is a format of fast bug fixes so that clients do not live with errors for half a year. This intermediate format will allow you to quickly respond to incidents of the first priorities and implement the declared SLA.
All of the above is true primarily for the corporate sector and on-premise solutions. For cloud services oriented on the SMB segment, there are no such opportunities for customers to participate in the product development. The rental format for SMB does not even suggest this. Instead of a change request in the form of clear requirements from the corporate party, here is just the usual feedback and suggestions for the service. We try to listen, but the product is massive and the desire of one client to bring something familiar from its old historical system may contradict the development strategy of the system as a whole.
Source: https://habr.com/ru/post/457202/
All Articles