What developers need to know about business
Even in very large companies, developers are often treated like mushrooms: they are kept in the dark and fed with manure. Write code, family, and do not protrude. This approach may be convenient for many (including sometimes for the developers themselves in the case of not very adequate management), but from the point of view of business is not optimal. My position: developers should be able to find out everything that happens in the company and in the market, but without pressure. Wanted - he dug and figured out, did not want to - no need.
Rarely when a developer does not want to understand why and what he does. Few who do not want to see the impact of implemented features on the world around. Come on, let's be honest: we are all here either because of money, or because of the opportunity to do something meaningful. Money is everywhere. But interesting projects are less common.
I want to share the process of how we organize such information in the Tutu.ru team. Perhaps, it will seem to someone an educational program, but to someone it will be useful. Well, or you tell me how to do better.
')
It may seem that if a developer drops a task from above, then the maximum he is capable of with a complete picture of knowledge is to choose a slightly more correct architectural solution. It is believed that this reduces the rate of growth of technical debt, as the correctness of the architecture increases. Yes, this is true, but in practice it is about as difficult to organize and maintain the process of informing at dinner as it is to deal with technical debt.
But the second important thing appears. Namely - those who want to participate in brainstorming with the business. That is, if the business itself had previously planned, set objectives and priorities, and told himself what to do, now it is affected by development.
And here we had a very interesting phenomenon many times. The thinking of an engineer is different from the thinking of an ordinary person. Somewhere more structurally, somewhere unexpectedly good solutions, somewhere cognitive distortions. There is nezamilnost look. There is a denial of the practice "it happened", because for someone they are a given, and for an engineer - a gloomy legacy. And do not care how old he is.
At first, discussions slowed down. The developers obviously had great difficulties with financial analysis, and it was necessary to load them very often in order to justify the possibility or impossibility (more often) of a solution.
Then a couple of times we managed to find places where the business did not even think that it was possible to do something with almost one movement. For example, with the help of a mathematical model of a bus, we were able to tie stops to routes and restore the schedule in both directions. Here is the story .
The next important thing is that a unified system is expected to emerge on the market over the next 1-2 years. A year ago, this seemed like a fantasy, and every carrier, including small SPs with rusty buses of the 80s, had its own standards. Now all this is turned into a single information system. We have already built some of its functionality, but now you can remove this layer and immediately receive clean data. Of course, with this market change, we need the whole team to discuss. At a minimum, this removes the level of questions “why we don’t finish my cool cool feature code”, and at the maximum it gives us the opportunity to prepare for changes more effectively than anyone. Marketing is consulting with the technical team, asking how they would make the new system and what limitations it will have. We drew the architecture of how it will be implemented at the federal level, and realized that our system will become an add-on to manage the brand, marketing campaigns and other tools to promote and communicate with users. There will be not duplicating-competing, but integrated.
Or here's an example of what to do if we need to connect to the system a lot of small partners. Business knew everyone by sight and understood how they thought. The developer did not know anyone, was not aware of market restrictions, so he calculated the model and proposed a cold rational solution. In an attempt to justify why it is impossible, the business realized that in fact the restriction of the market is rather illusory. And here we have - another leap, just not in development. The team for working with partners shifted the focus to other partners, which gave us much more data to the system.
The following example. The developer speaks at a conference, talks about a technical solution. He told about his own system for booking flights - a personal account of the carrier. He is asked an absolutely user question from the audience at the level of “what will happen if I sit at the next stop”. In 98% of cases, the developer would respond in terms of integration and data exchange. Here he spoke about how the business works, what the relationship between the carrier and the station. And he argued every detail.
When the company had five owners of products, we once a week gathered and exchanged what was useful in the product and what could be useful for others. Then we were eight. Then - 13 people. And 13 people are harder to collect. They offered to share the results of analytics in the letters. They began to tell what they did to the product, and give recommendations on how to apply it in other products. Was once a month and a half, then - once a month.
This is how the tradition-rule with monthly reports was formed. According to the results of the team’s work, a hefty letter is sent in a month (the last time it was 27 pages A4 on buses). You can read only the top, but you can all or in pieces. It helps to get feedback, new ideas.
The report is duplicated by a meeting-performance: it is not necessary to come, but people often come from neighboring teams. At the meeting it is important - in short, you can ask questions on the fly. Then read the letter and understand the details if you want. At one of these meetings, an employee of the railways told how his user went to Sverdlovsk (Ukraine) instead of Yekaterinburg (Russia, the former Sverdlovsk in the Sverdlovsk region). There are such collisions on buses too. Together we have thought out a probabilistic analysis (where we most likely have to go) and a system of warnings about atypical routes. Changed the order of prompts by the first letters of cities, so that unlikely directions were to be sorted later than the most important ones.
I collected the digest by the grocery approach. That is, he first sent out what he thought was right from the values ​​of the end users (team developers, project owners, business people communicating with partners), and then began to collect feedback. Somewhere, someone started asking questions that were not there before. Somewhere asked for more details. Then I sent a poll to everyone, which is useful and what is not.
As a result, this structure appeared:
According to the results of the first digest, a study was started on the subject of whether the train tickets are cheaper or more expensive in comparison with the bus for the same segments. And they came to a lot of not quite obvious results. Perhaps I will write about it a little later.
Many of our studies are helpful to colleagues. And we take something. Following the example of another product - tours - they made CJM users. We used to think that the approach to buying a ticket is a linear funnel type. In fact, people wander between pages, open dozens of tabs, confidently click "back" in the browser in different forms and generally browse simultaneously from different devices (change from mobile phone to desktop when they need to buy). Keeping track of all these strange trajectories made it possible to decide that some steps are superfluous, somewhere people become isolated. A typical Russian problem: when choosing a bus, many could not defeat the interface of choice of a place. Let me remind you that we are talking about those people who live in villages and do not know the differences between the search query and the address of the site. These are exactly those who do not know how to use the scroll on the scales in the supermarket, if there is one. In general, the hypothesis was born: you must choose a place automatically, and then you must either agree or change it. And - lo and behold! - residents of distant Russian villages, labor migrants and a number of other categories of users are no longer confused in the interface.
At one of the meetings, the call center came to say that they were stupid with their stupid questions on the first line, and for a month now they were the same. A huge amount of questions were removed by signing hints to the fields, adding more details to the letter after purchasing the ticket, and so on. From the strangest thing: on the bus card, the link to the route was on a blue illuminated plate, but people didn’t go there, but called. That is, someone did not understand simply that this is a link.
Another interesting discovery - we listened to colleagues from the air at such a meeting and figured out how the pricing for flights works with carrier airlines. And then they offered our carriers to load the buses. When the flight leaves with a 40 percent fill or less, we drop the price in a short period of time so that there are fewer electric trains in the same direction. 1,300 ticket cost, 400 rubles became: it’s unprofitable to plant a carrier of 400 each, but taking 10 people of 400 and carrying them is better than not taking anyone at all.
Tasks and their progress. Examples:
Research and hypotheses, example:
Inhuman experiments (this is interesting to all teams), example:
At once I will say that we do not plan to replace the data in the issuance according to methods 3 and 4, but examine the real factors of choice. A / B tests relate to approximately 1% of the site’s audience and are fairly tightly limited in time. All experiments are ethical in the sense that they allow a person to solve a problem and do not hide important data from him, and the benefits of them should outweigh the possible inconveniences.
Feedback from the market, examples:
Next - unloading from Jira (in fact) simple language for those who love the details. Any additions and notes. Everything.
So I'm for telling everyone about what is happening inside the product. Separately, the question of commercial secrets arises: it is very easy to forward or fumble a report, but we trust our people. The data still flows between different players of the market, and if you really need to hide something completely, then the report refers to internal resources, where there is an additional layer of authentication.
Rarely when a developer does not want to understand why and what he does. Few who do not want to see the impact of implemented features on the world around. Come on, let's be honest: we are all here either because of money, or because of the opportunity to do something meaningful. Money is everywhere. But interesting projects are less common.
I want to share the process of how we organize such information in the Tutu.ru team. Perhaps, it will seem to someone an educational program, but to someone it will be useful. Well, or you tell me how to do better.
')
Overall position
- To the development team, as far as possible, to tell what is happening in the market, what relations with competitors, what and how is happening.
- It is important for the top management of the company to know what exactly was done in the project and how it leads to the strategic goal. Usually we are talking about the level of project groups, but if you want to - you can fall into the report to the specific work.
- Other teams are interested to see what their colleagues are doing. We use different types of transport (train, air, bus) to solve similar problems, and you can often reuse the code, look at the idea or see how different tools are used. And ask.
What does it affect?
It may seem that if a developer drops a task from above, then the maximum he is capable of with a complete picture of knowledge is to choose a slightly more correct architectural solution. It is believed that this reduces the rate of growth of technical debt, as the correctness of the architecture increases. Yes, this is true, but in practice it is about as difficult to organize and maintain the process of informing at dinner as it is to deal with technical debt.
But the second important thing appears. Namely - those who want to participate in brainstorming with the business. That is, if the business itself had previously planned, set objectives and priorities, and told himself what to do, now it is affected by development.
And here we had a very interesting phenomenon many times. The thinking of an engineer is different from the thinking of an ordinary person. Somewhere more structurally, somewhere unexpectedly good solutions, somewhere cognitive distortions. There is nezamilnost look. There is a denial of the practice "it happened", because for someone they are a given, and for an engineer - a gloomy legacy. And do not care how old he is.
At first, discussions slowed down. The developers obviously had great difficulties with financial analysis, and it was necessary to load them very often in order to justify the possibility or impossibility (more often) of a solution.
Then a couple of times we managed to find places where the business did not even think that it was possible to do something with almost one movement. For example, with the help of a mathematical model of a bus, we were able to tie stops to routes and restore the schedule in both directions. Here is the story .
The next important thing is that a unified system is expected to emerge on the market over the next 1-2 years. A year ago, this seemed like a fantasy, and every carrier, including small SPs with rusty buses of the 80s, had its own standards. Now all this is turned into a single information system. We have already built some of its functionality, but now you can remove this layer and immediately receive clean data. Of course, with this market change, we need the whole team to discuss. At a minimum, this removes the level of questions “why we don’t finish my cool cool feature code”, and at the maximum it gives us the opportunity to prepare for changes more effectively than anyone. Marketing is consulting with the technical team, asking how they would make the new system and what limitations it will have. We drew the architecture of how it will be implemented at the federal level, and realized that our system will become an add-on to manage the brand, marketing campaigns and other tools to promote and communicate with users. There will be not duplicating-competing, but integrated.
Or here's an example of what to do if we need to connect to the system a lot of small partners. Business knew everyone by sight and understood how they thought. The developer did not know anyone, was not aware of market restrictions, so he calculated the model and proposed a cold rational solution. In an attempt to justify why it is impossible, the business realized that in fact the restriction of the market is rather illusory. And here we have - another leap, just not in development. The team for working with partners shifted the focus to other partners, which gave us much more data to the system.
The following example. The developer speaks at a conference, talks about a technical solution. He told about his own system for booking flights - a personal account of the carrier. He is asked an absolutely user question from the audience at the level of “what will happen if I sit at the next stop”. In 98% of cases, the developer would respond in terms of integration and data exchange. Here he spoke about how the business works, what the relationship between the carrier and the station. And he argued every detail.
Okay, how to inform something?
When the company had five owners of products, we once a week gathered and exchanged what was useful in the product and what could be useful for others. Then we were eight. Then - 13 people. And 13 people are harder to collect. They offered to share the results of analytics in the letters. They began to tell what they did to the product, and give recommendations on how to apply it in other products. Was once a month and a half, then - once a month.
This is how the tradition-rule with monthly reports was formed. According to the results of the team’s work, a hefty letter is sent in a month (the last time it was 27 pages A4 on buses). You can read only the top, but you can all or in pieces. It helps to get feedback, new ideas.
The report is duplicated by a meeting-performance: it is not necessary to come, but people often come from neighboring teams. At the meeting it is important - in short, you can ask questions on the fly. Then read the letter and understand the details if you want. At one of these meetings, an employee of the railways told how his user went to Sverdlovsk (Ukraine) instead of Yekaterinburg (Russia, the former Sverdlovsk in the Sverdlovsk region). There are such collisions on buses too. Together we have thought out a probabilistic analysis (where we most likely have to go) and a system of warnings about atypical routes. Changed the order of prompts by the first letters of cities, so that unlikely directions were to be sorted later than the most important ones.
I collected the digest by the grocery approach. That is, he first sent out what he thought was right from the values ​​of the end users (team developers, project owners, business people communicating with partners), and then began to collect feedback. Somewhere, someone started asking questions that were not there before. Somewhere asked for more details. Then I sent a poll to everyone, which is useful and what is not.
As a result, this structure appeared:
- The main tasks that were in the product: why, why, why, how. It is very important to note here that each task somehow influences the market. Groups of features gather in strategy points like “place an order the fastest” or “have the most accurate schedule”,
- Then we carry out the results of analytical studies. For example, thanks to our research, we learned that very often a bus ride is only the first step in a journey, and then a person goes by train. Or it is transferred from the train to the bus (if it goes to remote places). And this is very important, because in the first approximation it affects marketing, and in the second, in general, on all interfaces. Because the task is no longer to buy a bus ticket, but to dock it with a train in order to get somewhere convenient. The following analyst - compared the route network of trains, trains, buses for duplication or expansion. So that on the page of the schedule of electric trains Moscow - Dmitrov and further buses throughout the Dmitrovsky district were in the widget. Now - in implementation.
- There may be news from the market. Everything is trivial: just so that everyone knows what to expect and what has already been done large.
- Polls - questions if you need to attract someone. Collected information inside, who as goes and what problems faced. Interviewed the team, as it would be more convenient to implement an electronic ticket. According to the range of buses - who went where, as there was, how rusty everything was. Sometimes we ask to photograph schedules at stops in certain directions.
According to the results of the first digest, a study was started on the subject of whether the train tickets are cheaper or more expensive in comparison with the bus for the same segments. And they came to a lot of not quite obvious results. Perhaps I will write about it a little later.
Many of our studies are helpful to colleagues. And we take something. Following the example of another product - tours - they made CJM users. We used to think that the approach to buying a ticket is a linear funnel type. In fact, people wander between pages, open dozens of tabs, confidently click "back" in the browser in different forms and generally browse simultaneously from different devices (change from mobile phone to desktop when they need to buy). Keeping track of all these strange trajectories made it possible to decide that some steps are superfluous, somewhere people become isolated. A typical Russian problem: when choosing a bus, many could not defeat the interface of choice of a place. Let me remind you that we are talking about those people who live in villages and do not know the differences between the search query and the address of the site. These are exactly those who do not know how to use the scroll on the scales in the supermarket, if there is one. In general, the hypothesis was born: you must choose a place automatically, and then you must either agree or change it. And - lo and behold! - residents of distant Russian villages, labor migrants and a number of other categories of users are no longer confused in the interface.
At one of the meetings, the call center came to say that they were stupid with their stupid questions on the first line, and for a month now they were the same. A huge amount of questions were removed by signing hints to the fields, adding more details to the letter after purchasing the ticket, and so on. From the strangest thing: on the bus card, the link to the route was on a blue illuminated plate, but people didn’t go there, but called. That is, someone did not understand simply that this is a link.
Another interesting discovery - we listened to colleagues from the air at such a meeting and figured out how the pricing for flights works with carrier airlines. And then they offered our carriers to load the buses. When the flight leaves with a 40 percent fill or less, we drop the price in a short period of time so that there are fewer electric trains in the same direction. 1,300 ticket cost, 400 rubles became: it’s unprofitable to plant a carrier of 400 each, but taking 10 people of 400 and carrying them is better than not taking anyone at all.
How is the report itself formed?
Tasks and their progress. Examples:
New decision rules for CC
- What did you decide? In some cases, the contact center specialists must make their own decisions in favor of the client, without waiting for the situation with a partner (bus station, carrier) to sort out the situation, which can take weeks, or support analysis. Therefore, they estimated where the price loss threshold is located, below which CC specialists can instantly make decisions.
- Result, and what do we do next? The price is determined, we will continue to work on other scenarios. In this case, all data is collected, and we will monitor this metric (ticket loss). KC specialists begin to independently decide part of the cases from clients.
- How can this be useful in other products? Sometimes it will be more effective and better to affect the brand, if you immediately help the client than to plunge into a deep trial. Rate, maybe here you also have something to work on.
On empty pockets, all KTISs were turned on (railway, air, train)
- What did you decide? When we were unable to offer buses to customers, they started to show all KTISs, returned to the railway. It was important to see how this affects behavior, whether the alternative is interesting, and whether it is worth further developing.
- Result, and what do we do next? In 36% of cases, the client was offered an alternative. It is assumed that customers are still looking for real buses (where they really go), so in fact there is a big tail of unsatisfied customers. This is the potential for both buses and PTT, where we expand the range. There is interest in this, they are looking, but we are not planning to actively develop on empty payouts, but we will think further about how to correctly integrate it into the current issue.
- How can this be useful in other products? For our big country, the bus can be somewhere indispensable part of the trip. Therefore, the combination of modes of transport (multimodality) can strategically make sense if you accustom clients to think in the category from A to B.
Research and hypotheses, example:
What makes people come back?
- What did you decide? Describe the users who returned to us, and how they differ in their behavior from those who did not return.
- Results, and what do we do next? Made a set of behavioral characteristics that describe the user and that can potentially affect his return. It is important that this is not a predictive model, but a descriptive one. We will continue to conduct experiments, impose characteristics and watch recurrence. Ultimately, we want to create a predictive model in order to understand how to involve users in a product, what to involve in, in order to increase the likelihood of a return. Obvious, but true: people who have already bought in other sections are likely to return for re-purchase on buses.
- How can this be useful in other products? If it is interesting to dig in this direction, then do a similar analytics and compare the intersection.
Then - answers to the question: “What is happening?”, An example of the agenda:
- Why buy less? Yes, everything is fine, just the season, which we did not know.
- Direct traffic Where does such a sharp increase come from? And you are correctly pledged? And you do not Pars? And more answers to several questions (spoiler: yes, we are parsed).
- Platform. We involve users. The first results of the real involvement of people in content management on the site. People actively help.
- Cross-platform purchases. An e-ticket stops people behind a PC without a printer. What's next? 83% of those who made the first purchase on a PC continue to buy on a PC.
- Cohort analysis. The graphics are not for the faint of heart.
- How is the upsail in the air. We understood a lot about the baggage ticket and not only ... (431 orders in buses by users who made an order for the air in the same period, of which 42% is a bus in addition to the aircraft (i.e., the bus to either the departure point or point of arrival), 12% - in the opposite direction.)
Inhuman experiments (this is interesting to all teams), example:
What does affect the demand for the flight?
- Carrier rating. The difference of one point in rating, in the opinion of our users (for example, 9.4 against 8.4), increases the likelihood of buying a flight by 23%. This can be a really significant argument for carriers in order to increase the level of service for passengers.
- The probability of buying a promotional flight (marked with badges "Offer Tutu.ru" with the crossed out price) increases by XX%.
- Adding the first promotional offer by XX% increases, all other things being equal, the likelihood of conversion from issue. And this means that it is necessary to expand the range of areas with stocks.
- If the A / B test on each issue of delivery reduces the number of empty seats by one, then the probability of conversion from issuing will increase on average by X%.
- If on the issuance, where there are more than 10 flights, to throw out (hide) one flight, then the probability of a purchase will increase by 0.6%.
At once I will say that we do not plan to replace the data in the issuance according to methods 3 and 4, but examine the real factors of choice. A / B tests relate to approximately 1% of the site’s audience and are fairly tightly limited in time. All experiments are ethical in the sense that they allow a person to solve a problem and do not hide important data from him, and the benefits of them should outweigh the possible inconveniences.
Feedback from the market, examples:
- Worked with the validation of the data entered schedule. Now the enemy will not pass (that is, the carrier will not be able to inadvertently enter the data of an unreal route).
- They gave carriers the opportunity to edit their schedule and flights. The guys are happy, and we have less work :)
Next - unloading from Jira (in fact) simple language for those who love the details. Any additions and notes. Everything.
Total
- Business began to understand the potential of the product, it allowed to very clearly substantiate the budgets for technical solutions.
- Developers began to give new ideas and see how the implementation of features ends and how it changes the world.
- A team nearby was able to convey to the developers the importance of some issues, and they were quickly resolved.
- Other teams get experience from us and share their experiences and code that we reuse.
- Users are happy (except for that 1% of traffic, which is related to inhuman experiments).
So I'm for telling everyone about what is happening inside the product. Separately, the question of commercial secrets arises: it is very easy to forward or fumble a report, but we trust our people. The data still flows between different players of the market, and if you really need to hide something completely, then the report refers to internal resources, where there is an additional layer of authentication.
Source: https://habr.com/ru/post/459564/
All Articles