In this article, I will share my experience in selecting ideas for the development of the functionality of our products and tell you how to keep the main development vectors.
We are developing an automated settlement system (ACS) - billing. Term
The life of our product is 14 years. During this time, the system has gone from the first versions of an industrial rater to a modular complex consisting of 18 products that complement each other. One of the most important aspects of longevity for programs is continuous development. And ideas are needed for development.
Ideas
Sources of
There are 5 sources:
- The main friend of the developer of corporate information systems is client. And the client is a collective image of decision makers, project sponsors, owners and executors of processes, in-house IT specialists, ordinary users and a large number of people who are interested in varying degrees. It is important for us that each of the client's representatives is potentially a supplier of ideas. In the worst case, we only get negative feedback about problems in the system. At best, there is a person on the client side 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 a lot and actively with industry representatives, receive first-hand requests for billing functionality from potential customers. Merchants and accounts have to be aware of all significant changes in their functionality and the latest software updates of competitors, be able to justify the pros and cons of different solutions. It is these employees of ours who are the first to feel if some billing features become a de facto standard, without which the software cannot be considered complete.
- Product Owner one of our top managers or a very experienced project manager. Keeps the strategic goals of the company in mind and adjusts product development plans in accordance with them.
- Architect, a person who understands the possibilities and limitations of the selected / used technological solutions and their impact on product development.
Development and testing teams. People who are directly involved in product development.
Classification of hits
We receive raw data from sources - letters, tickets, oral requests. All
appeals are classified:
- Consultations with the meaning "How to do it?", "How does it work?", "Why doesn't it work?", "I don't understand...". Calls of this type go to the Level 1 Support Line. It is possible to retrain the consultation into other types of appeals.
- Incidents with the meaning "Not working" and "Error". Handled by 2 and 3 support lines. If it is necessary to quickly fix and release a patch, it can be transferred from support directly to development. It is possible to reclassify it into a change request and send it to the backlog.
- Requests for changes and development. Get into the product backlog, bypassing the Support Lines. But for them there is a separate processing procedure.
There is such statistics on hits - immediately after the release, the number of hits grows by 10-15% for a short time. There are also bursts of calls when a new client with a large number of users comes to our cloud services. People are learning 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 single out a specific specialist. The cost of rent, of course, does not pay off these labor costs, but over time the situation levels off. The period of adaptation takes, as a rule, from 1 to 3 months, after which the need for counseling is significantly reduced.
Previously, we used self-written solutions to store calls. But gradually switched to Atlassian products. First, the development was transferred to make it easier to work on Agile, then the support. Now all critical processes live in Jira SD, plus they are provided with various plugins for Jira, plus Confluence. Self-written solutions remained only on non-critical processes for the company's activities. It turned out that our tasks are now end-to-end, they can be transferred between support and development without jumping from one system to another.
From this bundle, we can get data on all tasks, planned and actual labor costs, use various billing options for clients and generate documentation for internal needs and a report to clients.
Processing Change Requests
Typically, these requests come in the form of feature requirements. Our analyst studies the request, generates a specification and a top-level TOR. Transfers the specification and TOR 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 enters the request into the product backlog.
Product feature management
The backlog accumulates received requests for change and development. Once every six months, the technical council, consisting of the director, heads of maintenance, development, sales and the system architect, meets. In the discussion format, the council analyzes and prioritizes applications from the backlog and agrees on 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 is of little relevance remains in the backlog and does not reach development.
Classification of Change Requests and Finance
Development is expensive. Therefore, we will immediately tell you what options we may have if a change request came from a client, and not an employee.
Change requests are classified as follows: industry-specific needs or individual characteristics of the enterprise; a significant amount of new functionality or a small fix. Small fixes and individual requests are processed without any frills. Individual requests are calculated and implemented for a specific client as part of the project work with him.
If this is not a massive industry need and the amount of functionality is large, then a decision can be made to develop a new separate module that will be sold in addition to the main functionality. If such a request is received from the client, we can cover the costs of developing the module, provide the client with the module free of charge or with partial payment, and put the module in the public domain for sale. In such a situation, the client takes on part of the methodological burden and, in fact, conducts a pilot implementation of the module.
If this is a massive industry need, then a decision can be made to include new functionality in the base product. The costs in this case are borne entirely by 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 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. In the end, everyone wins: customers get the implementation of the functionality at a low cost, we enrich the product, after a while other market participants can also get the 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, behind the turnover, we never forget about the development of the product.
Each release goes through an appropriate set of testing and documentation. Further, this release is installed in the test environment of the corresponding customer, who, in turn, checks everything meticulously, and only after that the release is transferred to production.
In addition to the release system, there is a format of quick bug fixes so that customers do not live with errors for six months. This intermediate format will allow you to quickly respond to incidents of the first priorities and fulfill the stated 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 wide opportunities for customers to participate in product development. The lease format for SMB does not even suggest this. Instead of a change request in the form of clear requirements from a corporate party, there is only 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.
Source: habr.com