How we choose ideas for the development of our products: the vendor must be able to hear ...
In this article, I will share my experience in selecting ideas for developing the functionality of our products and tell you how to keep the main development vectors.
We are developing an automated billing system (ASR) - billing. The
lifespan of our product is 14 years. During this time, the system has gone from the first versions of industrial tariffication 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 for development, ideas are needed.
Ideas
Sources
5 sources can be distinguished:
Classification of requests
From sources we receive raw data - letters, tickets, verbal requests. All
calls are classified:
There are such statistics on appeals - immediately after the release, the number of appeals grows by 10-15% for a short time. Also, bursts of calls happen when a new client with a large number of users comes to our cloud services. People learn to use the new features of software, they need advice. Even a small client at the beginning of 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 highlight a specific specialist. The cost of rent, of course, does not pay back these labor costs, but over 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 to store calls. But gradually switched to Atlassian products. First, we developed the development to make it easier to work on Agile, then support. Now all critical processes live in Jira SD, plus they are provided by various plugins for Jira, plus Confluence. Self-written solutions remained only on processes that were not critical to the company's activities. It turned out that our tasks are now cross-cutting, 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 various tariffing options for customers and generate documentation for internal needs and report to customers.
Change Request Processing
Typically, such requests come in the form of functional requirements. Our analyst studies the request, generates a specification and top-level ToR. It passes the specification and the statement of work to the person who submitted 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 understood each other correctly, the analyst writes the request to the product backlog.
Product Functionality Management
The backlog of requests for change and development are accumulated. Once every six months, a technical council is convened, consisting of a director, maintenance, development, sales, and system architect managers. In the discussion format, the board parses and prioritizes applications from the 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 little relevance remains in the backlog and does not reach development.
Classification of Change Requests and Finances
Development is expensive. Therefore, we’ll immediately tell you what options we can have if the request for change came from a client, not an employee.
Change requests are classified as follows: industry needs or individual characteristics of the enterprise; significant amount of new functionality or small fix. Small fixes and individual requests are processed without any frills. Individual requests are calculated and implemented for a particular client as part of the project work with him.
If this is not a massive industry need and the scope of functionality is large, then a decision may be made to develop a new separate module, which will be sold in addition to the main functionality. If such a request is received from the client, we can assume the costs of developing the module, provide the client with the module for free or with partial payment, and put the module on public sale. The client assumes part of the methodological burden in such a situation and essentially carries out the pilot implementation of the module.
If this is a massive industry need, then a decision may be made to include 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 that several customers have a similar need, but it does not attract 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 receive the implementation of the functionality at a low cost, we enrich the product, after a while the remaining market participants can also receive the functionality for their use.
DevOps
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, for the fluid, we never forget about the development of the product.
Each release passes an appropriate set of testing and documentation. Further, this release is installed in the test environment of the corresponding customer, who, in turn, meticulously checks everything and only after that the release is translated into production.
In addition to the release system, there is a format for quick bug fixes so that clients do not live with errors for six months. This interim format will allow you to quickly respond to incidents of first priority and fulfill the declared SLA.
All of the above is true primarily for the corporate sector and on-premise solutions. For cloud services focused on the SMB segment, there are no such broad opportunities for customers to participate in the development of the product. The lease 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 wishes for the service. We try to listen, but the product is massive and the desire of one client to bring something familiar from his old historical system may contradict the development strategy of the system as a whole.
We are developing an automated billing system (ASR) - billing. The
lifespan of our product is 14 years. During this time, the system has gone from the first versions of industrial tariffication 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 for development, ideas are needed.
Ideas
Sources
5 sources can be distinguished:
- 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, process owners and executives, IT specialists, ordinary users, and a large number of differently interested individuals. It is important for us that each of the representatives of the client is potentially a supplier of ideas. In the worst case, we get only negative feedback about problems in the system. At best, on the client’s side there is a person who is a constant source of ideas for improvement, providing structured information about the client’s needs.
- Our sellers and account managers are the second most important source of ideas for improvement. They communicate with industry representatives a lot and actively, 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 our employees who are the first to feel if some billing options become a de facto standard, without which the software cannot be considered complete.
- 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 plans for product development in accordance with them.
- An architect , a person who understands the possibilities and limitations of the selected / used technological solutions and their impact on product development.
Development, testing teams. People who are directly involved in product development.
Classification of requests
From sources we receive raw data - letters, tickets, verbal requests. All
calls are classified:
- Consultations with the meaning of “How to do it?”, “How does it work?”, “Why it doesn’t work?”, “I do not understand ...”. This type of call goes to the Level 1 Support Line. Possible re-qualification of the consultation in other types of applications.
- Incidents with the meaning of “Doesn't work” and “Error”. Handled by 2 and 3 Support Lines. If necessary, a quick fix and release of the patch can be transferred from support immediately to the development. It is possible to retrain into a request for change and send it to the backlog.
- Requests for change and development . Get into the product backlog 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. Also, bursts of calls happen when a new client with a large number of users comes to our cloud services. People learn to use the new features of software, they need advice. Even a small client at the beginning of 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 highlight a specific specialist. The cost of rent, of course, does not pay back these labor costs, but over 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 to store calls. But gradually switched to Atlassian products. First, we developed the development to make it easier to work on Agile, then support. Now all critical processes live in Jira SD, plus they are provided by various plugins for Jira, plus Confluence. Self-written solutions remained only on processes that were not critical to the company's activities. It turned out that our tasks are now cross-cutting, 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 various tariffing options for customers and generate documentation for internal needs and report to customers.
Change Request Processing
Typically, such requests come in the form of functional requirements. Our analyst studies the request, generates a specification and top-level ToR. It passes the specification and the statement of work to the person who submitted 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 understood each other correctly, the analyst writes the request to the product backlog.
Product Functionality Management
The backlog of requests for change and development are accumulated. Once every six months, a technical council is convened, consisting of a director, maintenance, development, sales, and system architect managers. In the discussion format, the board parses and prioritizes applications from the 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 little relevance remains in the backlog and does not reach development.
Classification of Change Requests and Finances
Development is expensive. Therefore, we’ll immediately tell you what options we can have if the request for change came from a client, not an employee.
Change requests are classified as follows: industry needs or individual characteristics of the enterprise; significant amount of new functionality or small fix. Small fixes and individual requests are processed without any frills. Individual requests are calculated and implemented for a particular client as part of the project work with him.
If this is not a massive industry need and the scope of functionality is large, then a decision may be made to develop a new separate module, which will be sold in addition to the main functionality. If such a request is received from the client, we can assume the costs of developing the module, provide the client with the module for free or with partial payment, and put the module on public sale. The client assumes part of the methodological burden in such a situation and essentially carries out the pilot implementation of the module.
If this is a massive industry need, then a decision may be made to include 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 that several customers have a similar need, but it does not attract 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 receive the implementation of the functionality at a low cost, we enrich the product, after a while the remaining market participants can also receive the functionality for their use.
DevOps
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, for the fluid, we never forget about the development of the product.
Each release passes an appropriate set of testing and documentation. Further, this release is installed in the test environment of the corresponding customer, who, in turn, meticulously checks everything and only after that the release is translated into production.
In addition to the release system, there is a format for quick bug fixes so that clients do not live with errors for six months. This interim format will allow you to quickly respond to incidents of first priority and fulfill the declared SLA.
All of the above is true primarily for the corporate sector and on-premise solutions. For cloud services focused on the SMB segment, there are no such broad opportunities for customers to participate in the development of the product. The lease 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 wishes for the service. We try to listen, but the product is massive and the desire of one client to bring something familiar from his old historical system may contradict the development strategy of the system as a whole.