The philosophy of DevOps, when development is combined with software maintenance, is no surprise to anyone. A new trend is gaining momentum - DevOps 2.0 or BizDevOps. It already merges three components into a single whole: business, development and support. And just as in DevOps, engineering practices form the basis of the connection between development and support, so in business devops, analytics takes on the role of the “glue” that unites development with business.
I want to admit right away: that we got a real bizdevops, we learned only now, after reading smart books. It somehow developed itself thanks to the initiative of employees and an irrepressible passion for improvement. Today, analytics is part of the production process of development, greatly reducing feedback loops and regularly providing insights. I'll tell you in detail how everything is arranged with us.
Disadvantages of classic DevOps
When new client products are conceived, a business creates an ideal model of customer behavior and expects a good conversion, on the basis of which it builds its business goals and results. The development team, for its part, strives to make very good, high-quality code. Support, on the other hand, hopes for full automation of processes, for the ease and convenience of maintaining a new product.
The reality most often develops in such a way that clients receive a rather complicated process, business rests on low conversion, development teams release fix after fix, and support drowns in a stream of requests from customers. Familiar?
The root of the evil here lies in the long and poor quality feedback loop embedded in the process. Businesses and developers, while collecting requirements and receiving feedback during sprints, communicate with a limited number of customers, which greatly influence the fate of the product. Often what is important to one person is not at all characteristic of the entire target audience.
Understanding whether the development of the product is in the right direction comes with financial reports and market research results months after the launch. And they, due to the limited sample size, do not provide an opportunity to test hypotheses on a large volume of clients. In general, it turns out long, inaccurate and inefficient.
trophy tool
We found a good way to get away from this. A tool that used to help only marketers, we got into the hands of business and developers. We began to actively use web analytics in order to look at the process in real time, to understand what is happening here and now. Based on this, plan the product itself, its rolling out to a large number of customers.
If some kind of product improvement is planned, you can immediately see what metrics it is associated with, and how these metrics affect sales, characteristics that are important for business. So you can immediately weed out hypotheses with a low effect. Or, for example, roll out a new feature to a statistically significant number of users and monitor the metrics in real time, to understand whether everything is working as intended. Do not wait for feedback in the form of requests or reports, but immediately monitor and promptly correct the process of creating a product. We can roll out a new feature, collect statistically correct data in three days, make changes in another three days - and now a great new product is ready in a week.
You can track the entire funnel, all the customers who came into contact with the new product, find the points where the funnel narrowed sharply, and understand the reasons. Both developers and business are now watching this, it's part of the daily work. They see the same customer journey, and together they can generate ideas and hypotheses for improvement.
This integration of business and development, together with analytics, makes it possible to create products continuously, constantly optimize, look for and see bottlenecks, the whole process.
It's all about complexity
When we create a new product, we do not start from scratch, but we build it into an already existing intricacies of services. Trying on a new product, the client most often comes into contact with several departments. He can communicate with employees of the contact center, with managers in the office, he can contact support, use online chats. With the help of metrics, we can see, for example, what is the load on the contact center, how best to process incoming requests. We can understand how many people come to the office and suggest how to further advise the client.
It's the same with information systems. Our bank has existed for more than 20 years, during this time a large layer of heterogeneous systems has been created and is still functioning. The interaction between backend systems is sometimes unpredictable. For example, in some ancient system, there are restrictions on the number of characters for a certain field, and sometimes this crashes the new service. Tracking a bug using standard methods is quite difficult, but using web analytics is elementary.
We have reached the point where we began to take and analyze error texts from all involved systems that are shown to the client. It turned out that many of them were outdated, and we could not even imagine that they were somehow involved in our process.
Working with analytics
We have web analytics and SCRUM development teams in the same room. They constantly interact with each other. When necessary, specialists help set up metrics or upload data, but basically the team members themselves work with the analytics service, there is nothing complicated.
Help is required if, for example, some dependencies are needed, additional filters for a limited type of client or source. But in the current architecture, we rarely encounter this.
Interestingly, the introduction of analytics did not require the installation of a new IT system. We use the same software that marketers have previously worked with. It was only necessary to coordinate its use and implement it in business and development. Of course, we couldn’t just take what marketing has, we had to reconfigure everything anew and give marketing access to a new environment so that they are with us in the same information field.
In the future, we plan to buy an improved version of the web analytics software that will be able to cope with the increasing volume of processed sessions.
We are also actively integrating web analytics and internal databases from CRM and accounting systems. By combining the data, we get a complete picture of the client in all the necessary sections: by sources, types of clients, products. BI services that help visualize data will soon be available to all departments.
What did we end up with? In fact, we made analytics and decision-making on it a part of the production process, which gave a visible effect.
Analytics: do not step on the rake
And finally, I want to share tips that will help you avoid bumps in the process of building a bizdevops.
- If the analytics cannot be done quickly, then you are doing the wrong analytics. You need to follow a simple path from one product, and then scale.
- You must have a team or person who understands the future analytics architecture well. You still need to decide on the shore how you will scale analytics, integrate it into other systems, and reuse data.
- Don't generate extra data. Web statistics is, in addition to useful information, also a huge garbage dump with low-quality and redundant data. And this garbage will interfere with decision-making and evaluation if there are no clear goals.
- Don't do analytics for the sake of analytics. First, the goals, the choice of a tool, and only then - analytics only where it will give an effect.
The material was prepared jointly with Olga Chebotar ().
Source: habr.com