The DevOps philosophy, about development and software maintenance, will not surprise anyone. A new trend is gaining strength – DevOps 2.0 or BizDevOps. In it, three components merge into a single whole: business, development and support. And as DevOps engineering practices come form the basis of the connection between development and support, so in the BizDevOps, the analyst assumes the role of a “glue” that combines development with business.

I want to admit right away: that we got a real BizDevOps, we learned only now by reading smart books. It somehow developed itself because of the initiative of employees and an indefatigable passion for improvement. Now analytics is part of the production development process, significantly reducing bad feedback and regularly supplying 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, from its side, is committed to create very good, high-quality code. Support, however, hopes for complete automation of the processes, for the ease and convenience of maintaining a new product.

The reality most often develops in such a way that clients get a rather complicated process, business low conversion, development teams fix issue by issue, and support is drowning in the stream of customer requests. Is that familiar for you too?

The main idea here lies in a long and poor-quality feedback embedded in the process. When collecting requirements and receiving feedback during sprints, business and developers communicate with a limited number of customers, which greatly affect the development process of the product. Often, what is important for one is not at all characteristic of the entire target audience.

Understanding whether the product is developing in the right direction comes with financial reports and marketing research results few months after launch. And they, because of the limited sampling, do not provide the possibility of testing hypotheses on a large volume of clients. In general, it turns out long, inaccurate and inefficient.

Trophy instrument

We found a good way to get away from this. A tool that used to only help marketers, we give 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 and its delivery to a large volume of customers.

If you plan some kind of product improvement, you can immediately see what metrics it is associated with, and how these metrics affect sales and business characteristics. So you can immediately leave hypotheses with a low effect. Or, for example, release a new feature to a statistically significant number of users and follow the metrics in real time, to understand whether everything works as intended. Do not wait for feedback in the form of appeals or reports, but immediately monitor and quickly correct the process of creating the product yourself. We can make a new feature, in three days already collect statistically correct data, make changes in three more days – and now in a week an excellent new product is ready.

You can track the entire funnel, all customers who came in contact with a new product, find the points at which the funnel has narrowed sharply, and figure out the reasons. Both developers and business are now watching this, this is part of the daily work. They see the same client path and together they can generate ideas and hypotheses for improvement.

Such integration of business and development together with analytics makes it possible to create products continuously, constantly optimize, look for and see weaknesses in the whole process.

It’s all about complexity

When we create a new product, we do not start from scratch, but embed it in the already existing amount of services. While trying a new product, the client most often contacts several departments. He can communicate with the employees of the contact center, with managers in the office, can contact support in online chats. Using metrics, we can see, for example, what is the load on the contact center, how is best to handle incoming requests. We can understand how many people get to the office and suggest how to further advise the client.

With information systems, everything is exactly the same. Some bank has existed for more than 20 years, during this time a large layer of systems has been created and is still functioning. The interaction between back-end systems is sometimes unpredictable. For example, in some old system for a certain field there are restrictions on the number of characters and sometimes this crashes a new service. Tracking a bug by standard methods is quite difficult, but using web analytics is elementary.

We got to the point where we began to take and analyze the texts of errors that are shown to the client from all the systems involved. It turned out that many of them were outdated, and we couldn’t even imagine that they were somehow involved in our process.

Work with analytics

We have web analytics and SCRUM development teams in the same room. They constantly interact with each other. When necessary, experts help you set up metrics or upload data, but basically the team members themselves work with the analytics service, there’s nothing complicated.

Help is needed if, for example, you need some dependencies, additional filters for a limited type of clients or sources. But in current architecture, we rarely encounter this.

Interestingly, the introduction of analytics didn’t require the installation of a new IT system. We use the same software that marketers 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 and give marketing access to the new environment to make them be with us in the same information field.

In the future, we plan to buy an improved version of web analytics software that will cope with the increasing volumes 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 source, type of client, product. 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: don’t repeat our mistakes

And finally, I want to share tips that will help you to avoid problems in the process of building a business DevOps.

  1. If 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.
  2. You must have a team or person who understands the future analytics architecture well. It is also necessary to decide from the beginning how you will scale the analytics, integrate it into other systems, reuse the data.
  3. Do not generate extra data. Web statistics is, in addition to useful information, also a huge garbage bag  with low-quality and redundant data. And this garbage will interfere with decision making and evaluation, if there are no clear goals.
  4. Do not do analytics for analytics. At first, goals, choice of an instrument, and only then – analytics where it will produce an effect.