How We Found a Cool Way to Link Business and DevOps

    The DevOps philosophy, when development connects with 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 in DevOps'e engineering practices form the basis of the connection between development and support, so in the bizdevopse, 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 thanks to the initiative of employees and an indefatigable 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 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, is committed to creating 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 rests on low conversion, development teams issue fix by fix, and support is drowning in the stream of customer requests. Is that familiar?

    The root of evil here lies in a long and poor-quality feedback loop 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 fate 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 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 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, its rolling out 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 weed out hypotheses with a low effect. Or, for example, roll out 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 roll out 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 bottlenecks, 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 intricacies of services. Trying on 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 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. 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 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 could not 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 did not 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 could not just take what marketing has, we had to reconfigure everything and give marketing access to the new environment so that they were 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 step on a rake

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

    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 on the shore 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 dump 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, the choice of an instrument, and only then - analytics only where it will produce an effect.

    Material prepared jointly with Chebotar Olga ( olga_cebotari ).

    Also popular now: