How we found a cool way to connect business and DevOps
DevOps philosophy, when the development is connected with the maintenance of software, no one is surprised. New trend is gaining momentum - DevOps 2.0 or BizDevOps. In it already three components merge into a single whole: business, development and support. And as in DevOps, engineering practices form the basis of the connection between development and support, so in the bi-social networking industry the analyst assumes the role of a “glue” that unites development with business.
I want to immediately admit: that we have turned out a real bizdevops, we learned only now, after reading smart books. It somehow developed itself thanks to the initiative of the employees and an irrepressible passion for improvement. Now analytics is part of the production development process, significantly reducing feedback loops and regularly supplying insights. I'll tell you in detail how everything is arranged here.
When thinking about new client products, a business creates an ideal model of customer behavior and expects a good conversion, on the basis of which builds its business goals and results. The development team for its part seeks to make a very good, high-quality code. Support also hopes for full automation of processes, for ease and convenience of tracking a new product.
')
The reality most often develops in such a way that clients get a rather complicated process, business rests on low conversion, development teams release fix-by-fix, and support sinks in the flow of calls from clients. Familiar?
The root of evil here lies in a long and low-quality feedback loop embedded in the process. Business and developers in the collection of requirements and receiving feedback during the sprints communicate with a limited number of customers who strongly influence the fate of the product. Often, what is important for one person is not at all typical of the entire target audience.
Understanding whether product development is going in the right direction comes along with financial reports and marketing research results months after launch. Yes, and they, because of the limited sample, do not allow testing hypotheses on a large volume of clients. In general, it turns out long, inaccurate and inefficient.
We found a good way to get away from this. The tool, which previously only helped marketers, fell into the hands of business and developers. We began to actively use web-analytics in order to look at the process in real time, here and now to understand what is happening. Based on this, plan the product itself, roll it out to a large volume of customers.
If you are planning some kind of product improvement, you can immediately see with which metrics it is connected, and how these metrics affect sales, the characteristics important to the business. So you can immediately weed out hypotheses with low effect. Or, for example, roll out a new feature to a statistically significant number of users and follow the metrics in real time, see if everything works as intended. Do not wait for feedback in the form of requests or reports, but immediately monitor and promptly correct the product creation process. We can roll out a new feature, after three days already collect statistically correct data, make changes in three more days - and here in a week a great new product is ready.
You can track the entire funnel, all customers who have come into contact with the new product, discover the points at which the funnel has narrowed sharply, and sort out the reasons. Both the developers and the business are now monitoring this, this is part of the daily work. They see the same client path, 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, search and see bottlenecks, the entire process as a whole.
When we create a new product, we start not with a clean slate, but embed it in an already existing tangle of services. Trying on a new product, the client most often contacts with several departments. He can communicate with contact center employees, with managers in the office, can contact support, in online chats. With the help of metrics, we can see, for example, what is the load on the contact center, how best to handle incoming requests. We can understand how many people reach the office, and suggest how to further advise the client.
With information systems all the same. Our bank has existed for more than 20 years, during which time a large reservoir 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 limitations on the number of characters for a certain field, and sometimes it crashes a new service. Tracking a bug in standard ways is quite difficult, and using web analytics is elementary.
We have come to the point that from all the systems involved we have begun to take away and analyze the texts of errors 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.
We have web-analytics and SCRUM-development teams are in the same room. They constantly interact with each other. When needed, experts help to set up metrics or upload data, but mostly the team members themselves work with the analytics service, there is nothing complicated.
Assistance is required if, for example, you need some kind of dependency, additional filters on a limited type of customer or source. But in the current architecture, we rarely come across this.
Interestingly, the introduction of analytics did not require the installation of a new IT system. We use the same software that marketers previously worked with. It was necessary only to coordinate its use and implement it in business and development. Of course, we could not just take what marketing had, we had to reconfigure everything anew and give marketing to access to a new environment so that they were with us in the same information field.
In the future, we are planning to buy an improved version of web analytics software that will enable us to cope with the increasing volume of processed sessions.
We are also actively involved in the process of 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 have we got in the end? In fact, we made analytics and decision making on it a part of the production process, which gave a visible effect.
And finally, I want to share tips that will help you avoid cones cramming in the process of building a bizdevops.
The material was prepared jointly with Olga Chebotar ( olga_cebotari ).
I want to immediately admit: that we have turned out a real bizdevops, we learned only now, after reading smart books. It somehow developed itself thanks to the initiative of the employees and an irrepressible passion for improvement. Now analytics is part of the production development process, significantly reducing feedback loops and regularly supplying insights. I'll tell you in detail how everything is arranged here.
Disadvantages of classic DevOps
When thinking about new client products, a business creates an ideal model of customer behavior and expects a good conversion, on the basis of which builds its business goals and results. The development team for its part seeks to make a very good, high-quality code. Support also hopes for full automation of processes, for ease and convenience of tracking a new product.
')
The reality most often develops in such a way that clients get a rather complicated process, business rests on low conversion, development teams release fix-by-fix, and support sinks in the flow of calls from clients. Familiar?
The root of evil here lies in a long and low-quality feedback loop embedded in the process. Business and developers in the collection of requirements and receiving feedback during the sprints communicate with a limited number of customers who strongly influence the fate of the product. Often, what is important for one person is not at all typical of the entire target audience.
Understanding whether product development is going in the right direction comes along with financial reports and marketing research results months after launch. Yes, and they, because of the limited sample, do not allow testing 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. The tool, which previously only helped marketers, fell into the hands of business and developers. We began to actively use web-analytics in order to look at the process in real time, here and now to understand what is happening. Based on this, plan the product itself, roll it out to a large volume of customers.
If you are planning some kind of product improvement, you can immediately see with which metrics it is connected, and how these metrics affect sales, the characteristics important to the business. So you can immediately weed out hypotheses with low effect. Or, for example, roll out a new feature to a statistically significant number of users and follow the metrics in real time, see if everything works as intended. Do not wait for feedback in the form of requests or reports, but immediately monitor and promptly correct the product creation process. We can roll out a new feature, after three days already collect statistically correct data, make changes in three more days - and here in a week a great new product is ready.
You can track the entire funnel, all customers who have come into contact with the new product, discover the points at which the funnel has narrowed sharply, and sort out the reasons. Both the developers and the business are now monitoring this, this is part of the daily work. They see the same client path, 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, search and see bottlenecks, the entire process as a whole.
It's all about complexity
When we create a new product, we start not with a clean slate, but embed it in an already existing tangle of services. Trying on a new product, the client most often contacts with several departments. He can communicate with contact center employees, with managers in the office, can contact support, in online chats. With the help of metrics, we can see, for example, what is the load on the contact center, how best to handle incoming requests. We can understand how many people reach the office, and suggest how to further advise the client.
With information systems all the same. Our bank has existed for more than 20 years, during which time a large reservoir 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 limitations on the number of characters for a certain field, and sometimes it crashes a new service. Tracking a bug in standard ways is quite difficult, and using web analytics is elementary.
We have come to the point that from all the systems involved we have begun to take away and analyze the texts of errors 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.
Work with analytics
We have web-analytics and SCRUM-development teams are in the same room. They constantly interact with each other. When needed, experts help to set up metrics or upload data, but mostly the team members themselves work with the analytics service, there is nothing complicated.
Assistance is required if, for example, you need some kind of dependency, additional filters on a limited type of customer or source. But in the current architecture, we rarely come across this.
Interestingly, the introduction of analytics did not require the installation of a new IT system. We use the same software that marketers previously worked with. It was necessary only to coordinate its use and implement it in business and development. Of course, we could not just take what marketing had, we had to reconfigure everything anew and give marketing to access to a new environment so that they were with us in the same information field.
In the future, we are planning to buy an improved version of web analytics software that will enable us to cope with the increasing volume of processed sessions.
We are also actively involved in the process of 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 have we got in the end? 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 a rake
And finally, I want to share tips that will help you avoid cones cramming in the process of building a bizdevops.
- If analytics fails to be done quickly, then you are doing the wrong analytics. You need to go on a simple path from a single product, and then scale it up.
- You must have a team or a person who understands the future architecture of analytics well. We still need to decide on the bank how you will scale the analytics, integrate it into other systems, reuse data.
- Do not generate extra data. In addition to useful information, web-statistics is also a huge dump with poor-quality and superfluous data. And this garbage will interfere with decision-making and evaluation, if there are no clear goals.
- Do not do analytics for the sake of analytics. First, the goal, the choice of the tool, and only then - the analyst only where it will have an effect.
The material was prepared jointly with Olga Chebotar ( olga_cebotari ).
Source: https://habr.com/ru/post/455932/
All Articles