The philosophy of DevOps, where development connects with software maintenance, is no longer surprising anyone. A new trend is gaining momentum — DevOps 2.0 or BizDevOps. In this approach, three components merge into a single whole: business, development, and support. Just as engineering practices form the foundation of the connection between development and support in DevOps, in BizDevOps, analytics plays the role of 'glue' that unites development with business.
I want to admit right away: we only recently realized that we have truly created a BizDevOps, having read insightful books. It somehow came together thanks to the initiatives of the employees and an unquenchable passion for improvements. Now, analytics is a part of the production process of development, significantly reducing feedback loops and consistently providing insights. Let me tell you in detail how everything is organized here.
Drawbacks of Classic DevOps
When developing new client products, the business creates an ideal model of customer behavior and expects good conversion, based on which it builds its business goals and outcomes. The development team, for its part, aims to produce very good, quality code. Meanwhile, support hopes for full process automation, ease, and convenience in maintaining the new product.
In reality, clients often end up facing a rather complex process, the business struggles with low conversion rates, development teams release fix after fix, and support gets overwhelmed with a flood of customer inquiries. Sound familiar?
The root of the issue lies in the long and poor-quality feedback loop embedded in the process. Business and developers, when gathering requirements and obtaining feedback during sprints, communicate with a limited number of clients who significantly influence the product's fate. Often, what is important for one is not characteristic of the entire target audience.
Understanding whether the product is developing in the right direction comes along with financial reports and marketing research results months after the launch. And even these don't allow for hypothesis testing on a large client base due to sampling limitations. Overall, it turns out to be lengthy, inaccurate, and ineffective.
Trophy Tool
We've found a great way to move away from this. A tool that used to assist only marketers is now in the hands of businesses and developers. We began actively using web analytics to observe the process in real-time, understanding what's happening at the moment. Based on this, we can plan the product itself and its rollout to a large number of clients.
If any product improvement is planned, we can immediately see which metrics it relates to and how these metrics impact sales and other important business characteristics. This way, we can quickly filter out hypotheses with low effects. For example, we can roll out a new feature to a statistically significant number of users and monitor the metrics in real-time, ensuring everything works as intended. We don't have to wait for feedback in the form of inquiries or reports; we track and adjust the product creation process ourselves promptly. We can roll out a new feature and collect statistically valid data within three days; make adjustments in another three days—and within a week, we have an excellent new product.
We can trace the entire funnel, all customers who came into contact with the new product, identify the points where the funnel narrowed sharply, and understand the reasons why. Both developers and the business now monitor this as part of their daily work. They see the same customer journey and can collaboratively generate ideas and hypotheses for improvements.
This integration of business and development, along with analytics, enables continuous product creation, constant optimization, identifying and seeing bottlenecks in the entire process.
It's all about complexity.
When we create a new product, we don't start with a blank slate, but rather weave it into an already existing web of services. As clients engage with the new product, they often interact with multiple departments. They may communicate with contact center staff, office managers, or reach out for support in online chats. With the help of metrics, we can see, for example, what load is on the contact center and how to better handle incoming requests. We can understand how many people arrive at the office and advise on how to further consult the client.
The same goes for information systems. Our bank has been operating for over 20 years, during which a large number of diverse systems have been created and continue to function. The interaction between backend systems can sometimes be unpredictable. For example, in some ancient system, there are restrictions on the number of characters for a certain field, which can sometimes crash the new service. Tracking bugs using standard methods is quite challenging, but with web analytics, it becomes elementary.
We have reached a point where we started collecting and analyzing error messages from all the involved systems that are shown to clients. It turned out that many of them were outdated, and we never even imagined they played a role in our process.
Working with analytics
Our web analysts and SCRUM development teams work in the same space. They constantly interact with each other. When needed, specialists help set up metrics or export data, but for the most part, team members work with the analytics service themselves, which is not complicated.
Help is required if, for example, some dependencies or additional filters are needed for a limited type of clients or sources. However, in our current architecture, we rarely encounter this.
Interestingly, implementing analytics did not require installing a new IT system. We use the same software that was previously used by marketers. We only needed to approve its use and integrate it into business and development. Of course, we couldn't just take what marketing had; we had to reconfigure everything from scratch and then give access to marketing in the new environment so they could be in the same informational field with us.
In the future, we plan to purchase an improved version of the web analytics software that will handle the increasing volume of processed sessions.
We are also actively integrating web analytics with internal databases from CRM and accounting systems. By combining the data, we gain a complete understanding of the client across all necessary dimensions: by sources, types of clients, and products. BI services that help visualize data will soon be available to all departments.
What did we end up with? Essentially, we made analytics and decision-making a part of the production process, which had a visible impact.
Analytics: Don't step on rakes
Lastly, I want to share some tips that will help you avoid bumps along the way while building BizDevOps.
- If analytics can't be completed quickly, it means you're not doing the right analytics. You need to take the simple route from one product and then scale up.
- You must have a team or a person who understands the future architecture of analytics well. You need to decide in advance how you will scale analytics, integrate it into other systems, and reuse data.
- Do not generate unnecessary data. Web statistics, aside from useful information, are also a huge dump of poor-quality and excess data. This junk will hinder decision-making and assessments if there are no clear goals.
- Don't do analytics for the sake of analytics. Start with the goals, choose the tool, and only then implement analytics where it will have an impact.
This material was prepared in collaboration with Olga Cebotari ().
Source: habr.com
