Due date as a component of responsibility in the development process

In product development, the issue of efficiency is constantly and quite urgent. How to build a process so that it is optimal in terms of business, employee growth, variability, transparency, and many other factors? Where is that “silver bullet” that will allow you to solve all problems at once and save you as a leader from a headache?

The title of this “silver bullet” in turn is claimed by fashionable ( and not so ) development methodologies: Scrum, Kanban, XP, RAD, FDD, etc. New ways and approaches, frameworks and tools regularly appear. Business consultants come to the company and share their know-how for a lot of money, telling how it is right. And at the same time it would be good also cheap, wouldn’t it?

And it's great if people can articulate the needs that they want to satisfy through this or that process. But it often happens that without thinking, a fashionable approach is simply being introduced, which ultimately leads to dissatisfaction of participants or to inefficiency for business - in the modern world with its high rates, start-ups and high competition, the result of such indiscretions can be deplorable.

Let's think about what is required from the process, what problems need to be solved and what approaches are used for this. And at the same time I will talk about how we do in Badoo. This is my third post in a row in our blog on Habré. But just in case, I introduce myself again: I am Ilya Ageev, I lead QA in Badoo.

Participants of the process

Speaking about the process, they mostly talk about the participants. There are more conditions, results, resources, goals, etc. But the organization of teamwork in such a way that it is comfortable and efficient in most cases implies a process in a feature development .

All employees of a company making a product for users come to the office every day with different goals. It is good if these goals are able to balance and jointly achieve good business performance. But it is obvious that business and ordinary employees have different goals and values ​​from the outset. Someone saves on housing, new car, vacation. Someone interested in live communication and personal development. A business earns money and perceives employees as resources, allowing to achieve goals.

You must admit that few companies exist simply to pay employees, because they are good people (if there are such people at all). Other goals, although not always shared by employees.

And it seems to me that in this complex symbiosis, the company's goals are more important than the goals of individual employees. A good company appreciates and loves its resources, but from a business point of view, people (like many other resources) can always be replaced (albeit sometimes very difficult). But changing global goals is impossible. And it would be strange to expect this from business. “Let us now, instead of baking bread, let us give musical performances at children's matinees!” For what? If for the sake of greater profit and if this is easy to do, give. But to change the direction of business only because the baker Volodya loves and wants to sing (otherwise he can quit), naturally, no one will.

Consequently, the first and most important participant in the production process is the business itself. He, figuratively speaking, pays and therefore orders music. What does a business want? The goals are very different. Starting from charity and ending with the employment of a relative (it happens sometimes). But still, in most cases, the main goal is to improve the welfare of the owners. And preferably with the lowest cost . “Spend as little as possible and earn as much as possible” is the alphabet of the market.

In our manufacturing process for developing features, the business manager is the product manager. It is intended to understand the goals of the business, formulate, convey to the developers, if necessary, “chew”, find a compromise and plan everything competently. And then - to control the process, check the result and put it into operation.

What are his goals ? This is obvious: in as little time as possible to get as much work done as possible. In order to conduct experiments, test ideas for viability, and have time to correct possible shortcomings, and start earning money on the produced product as soon as possible (I do not deliberately talk about quality, but I mean it: no one will buy low-quality goods).

Therefore, the product manager constantly requires time data, an overview of the current situation, puts pressure on the rest of the process and seems to want everything at once. He just wants to understand how to do it as efficiently as possible, and ideally, how to do more and more quickly the next time. This is normal from a business point of view as well.

Therefore, we need the importance of the goals of the product manager to convey to all participants in the process, explain - and, perhaps, then the product manager will not have to run after the developer every half hour, asking: “Well, when will it be ready ?!”, making it difficult for him and distracting from working on a task.

In Badoo, scheduling is a very important part of the development process. The delivery time for a new feature appears as soon as possible and is called Due date . It represents the date when the feature should be on production. Due date depends on many factors - it affects almost everything in the process of product development, ranging from the degree of detail in the description of the required changes and ending with the method of delivering the code to the end user. Task decomposition , interface design complexity, testing and automation, the amount of external interaction, and the architecture of the code can all dramatically affect Due date. And given that people work at every stage of production, the human factor’s impact on the delivery time is enormous.

It would be ideal if all the team members understood the importance of the process, were well motivated and careful and always had time for everything. Is it possible? Not always. Especially when it comes to explaining and sharing common values. But I am sure that a compromise can always be found if the subsequent participants in the process themselves try to meet the deadline, focusing on some simple indicator and guided by simple rules.

In our company, this indicator is Due date. How do we ensure that the developers themselves strive to achieve their business goals, I will tell you further.

Who is the next participant in the process? Baker Volodya. In our case, the programmer. What goals can an ordinary person have, even if we consider that the average IQ in our industry is high? Earn money and go to Bali, buy an apartment, save for old age, pay a loan, buy a Gibson guitar, leave early for work, go to the movies in the evening and get to know a pretty neighbor. So be it, since we’re talking about IT people, let’s throw it over again: parse the backlog at work, reproduce the annoying bug and get rid of the boss’s quibbles, learn Erlang, “feel” the new Python framework, learn English, assemble the drone on the Raspberry Pi and listen to the podcast about the benefits Kotlin.

Of course, there are excellent guys who “support the project” and “understand the business,” because we work together on a common cause. But try not to pay them several times (I’m not trying to offend - I specifically play on contrasts so that the essence is clear). What happens in the end? They will go to Yandex, Facebook, Google and any other company where the salaries are rather big, they are fed with lunches, sheared and given massage and manicure. And rightly so! Work is a place where a business buys the work (and brains) of programmers for money, therefore commodity-money relations rule here. And if the business goal is to get as much work as possible for the least money, then the goal is the opposite for employees: to make as little as possible and get as much as possible for it.

Of course, there are other participants in the process: designers, copywriters, translators, analysts, testers, release engineers, system administrators. But first, their goals are not very different from those of Volodya’s baker. And secondly, they often act not on the leading roles, but rather cover up the fighters-developers while they “go on the attack”. By the way, there are no such employees in the company at all: their roles are often combined with other roles. In product development, all such roles act as resources for products and programmers, helping them to do their job better, eliminating routine, etc.

So, the main participant in the process after the product manager representing the business is the programmer. Baker Volodya can do a lot if he is interested; he can not sleep at night, not eat, not go out. But the business has different tasks, and there are many uninteresting and routine ones among them. So, if Volodya fulfilled ten interesting for him, but irrelevant for business tasks and one uninteresting, but very important for business - this is equivalent to the fact that he completed only one task. It is important for business that the goods produced are liquid and competitive, and which technologies are used in this, how successfully Volodya applied the algorithms and breadmaking patterns is a minor issue.

Of course, Volodya does not want to know about any deadlines, I do not want to communicate with the product manager, designers, accountants - he wants to sit down and immerse himself in his interesting task (and so that no one interferes). And in these conditions, the timing, plans, customers, competitors - this is a harsh reality, with which Volodya is forced to put up, but not part of the strategic goal, as is the case with the product manager.

A responsibility

How to make the company's goals, which are so far from the goals of Volodya’s baker, still be taken into account in the development process? So that at all stages with a multitude of pitfalls, problems and surprises, such decisions are made that are useful primarily to the company? So that Volodya needs to keep a deadline and ideally avoid problems with architecture planning, over-engineering and others that can lead him away from business needs?

In Badoo, we call this process “developer responsibility” and in every way encourage and encourage this very responsibility. As I have already said , in our processes, the developer acts as a microproject manager for the projects he is working on. What does this mean, how do we stimulate it? It's very simple: the developer is responsible for keeping the deadline (that Due Date).

This means that the developer himself must establish the time limit. Of course, he should do this, having carefully studied the task and trying to take into account as many factors as possible when planning. And of course, he must strive to meet this deadline. But at the same time you need to be prepared for the fact that the developer can disrupt the deadline. The bottom line is how we proceed: we consider every nuance that prevents us from meeting the deadline, and we are preparing an answer to it (how to ensure that the next time this problem does not recur).

The answer must be demanded from the developer, because he knows the project best. He called the term this time, and he will call it in the future. Perhaps he will again make a mistake - it is not scary. It is important that such an approach improves the engineering culture and stimulates the growth of the developer and the company as a whole. And it is obvious that the decision on how to avoid such problems in the future should be reliable. Do not “try next time,” but make sure that this does not happen again, eliminating the human factor to the maximum.

It would be good if the technical manager, having received the deadline for implementation (Due date) and confirming it, did not stop paying attention to the project before the deadline - this is risky and postpones the solution of many problems to the last stage (problems that are easier, faster and cheaper to solve ). Here it is necessary to go back to each task and clarify the situation, adjust the deadlines with a certain, predetermined periodicity (so that it does not distract the developer from work). You may have to make compromise decisions that allow you to meet the deadline, but leave to the prospect of "polishing" and refinement of the functional.

Well, it would not be superfluous to mention that simply throwing n days in time is not the best solution. How to control it? Very simple: tasks performed ahead of time should also be considered incorrectly planned. At the same time, “improperly planned” does not mean that everything is bad and the developer must be punished - this means that the manager’s attention should be paid to this aspect and the problems that affected the time frame should be discussed (for example, “creative ecstasy” and unexpected findings in development process).

Of course, do not forget about Parkinson's Law , which says that the work takes all the time allotted to it. But first, the most effective way to counteract this is to shorten the time to complete the task by doing something useful before its completion, which fits nicely into the feature development, because we are doing several projects in parallel. Secondly, we view any deviation from the deadline as an excuse for retrospecting and stimulating the development of a reliable decision on how to make a more accurate forecast in the future. And thirdly, even if we met the deadlines, it is necessary to ask the question: how next time to do it faster?

It is very important to grasp the point - we do not simply strive to make everyone respect due date. In feature development (as opposed to baking) there are too many uncertainties. Very few tasks resemble one another - they are not “universal” loaves of bread. If a baker "went wrong" with the terms, it means either there was a force majeure (the electricity was cut off, the flour was not delivered in time, etc.), or he was just lazy. In the development, on the contrary, it is rarely possible to meet the deadline, even if you try very hard. And if the developer didn’t meet the deadline, it doesn’t mean that he faked somewhere. The point here is different - we look at why deadlines are not met and evaluate the reasons (which affected the deadline: the situation, resources, the laziness of the performers, or the lack of understanding of business goals). The developer can be very efficient, but without focusing on the result, he is constantly distracted by insignificant trifles that may seem important to him (or, alternatively, helping the loader Vasya, because they have friendly relations). As a result, the developer has a lot of reasons that he sincerely considers important, but there is no result. It requires constant support and adjustment of the manager.

So let's summarize.

1. The developer sets the date of the task in the form of Due date. This is the time when the task will be in production.
2. Technical manager must confirm the date Due date. It would be good if he did this, having previously studied the project on his own, and immediately pointed out factors that could affect the deadlines in the future. Coaching must begin at this stage.
3. With a certain periodicity, agreed in advance, the manager must check the status with the developer: consider problems that could already arise, and processes that can already be accelerated. Example: “Why did the review of three lines of code take three days?”
4. After the completion of the project, in any case, you need to do a retrospective and put the question: how next time to do faster?

Due date is an optimistic forecast. In our company, everyone understands this and knows that the developer needs support from the manager at all stages of the project. And even if we assume that the developer has a small amount of time, which helps him to feel calmer and more confident, there is nothing wrong with that. Our goal is to make it efficient and pragmatic, and not to “drive horses to death,” because we still have to work together and do many cool projects.

Examples

The following situations can be considered as examples describing good and not so solutions. Obviously, the decisions are not the only correct ones, but they allow you to capture the essence (I hope).

1. The task had too many re-discoveries, because testers found many bugs, which led to unnecessary time costs at all related stages: context switching, waiting for tasks in queues, etc. Bad decision: yell at testers, fire them, hire new ones. A good solution: to cover the code with unit tests, so that the next time the feedback about the quality of the code is obtained faster; work on methodologies and practices to improve product quality.
2. The designer made a too complex design of the new feature, the buttons literally had to be drawn from scratch, it took longer. Bad decision: ask the designer not to do this again. A good solution: create guidelines for your application and have standard components, give them to designers and work in accordance with guidelines.
3. The developer decided to make a new feature on a new fashionable framework, this pulled changes in other places, I had to rewrite almost everything. Bad decision: tell everyone that the framework is bad and never use it again. A good solution: in the problem of the code should be at a minimum - only to solve this particular problem; new approaches, frameworks, etc. should go separate tasks in the framework of technical debt with investigateom, smooth deployment , etc.
4. In the process of working on fixing the bug, the developer found another old bug, began to fix it, dug into the old code and refactor half of the project. Bad decision: prohibit fix bugs and refactoring. A good solution: in the problem of the code should be at a minimum - only that relates to fix the bug. Despite the fact that XP involves the development through refactoring, you need to think about the situation several times before embarking on reworking everything. It often happens that refactoring at this stage is better postponed. In the foreground should be pragmatism, not the beauty of the code and the correctness of the architecture. You think that you need to refactor - discuss it with the manager and only after that start “shoveling” the code.
5. They did everything on time, but two days after the layout they found that a very important component of the system was broken by new code, users could not use the product, the feature had to be rolled back and fixed. Bad decision: to fine developer and testers. A good solution: start monitoring this and other important components of the system, cover them with auto-tests, provide new features with at least minimal statistics on health and key business indicators.

There can be a great many situations - it is impossible to foresee everything. But when dealing with problems, every time we try to immediately solve a number of similar problems in the future. This approach not only improves the whole project, but also significantly increases the level of the developer - after all, he encourages him to look at problems more broadly. The developer in this case receives an architectural, managerial expertise and feels an important part of a unified, evolving and constantly improving engineering team.

And it is good to remember that the person in charge must be alone. Even if several developers are working on a project, one of them must be responsible for coordination and deadlines, often the most experienced specialist. So we are trying to avoid a situation of collective responsibility: after all, if everyone is responsible for something, it means that no one is de facto responsible.

We at Badoo also practice an approach where the most responsible are not the most experienced, but the youngest and “hot” - to stimulate growth. In this case, experienced developers monitor all phases of the project and in every way help him, advise, point out errors. And even if at the same time features will be made a little slower (although this is not at all necessary) and there will be more risks, this approach is strategically correct, as it ensures the growth of people in a team.

Conclusion

Creating the process, I try to make the system optimize itself. In the theory of solving inventive problems, there is an approach called the “ideal end result” ( IFR ). He proposes, when solving a problem, to imagine an ideal image of a solution when the necessary action is performed without any costs, complications and undesirable effects.

In feature development, it often happens that we demand something from the developer, try to control it, surround ourselves with more and more indicators in order to gain confidence that everything is going according to plan. But the more people, the more tasks, the more indicators, the more difficult and more difficult to manage. As a result, you can come to a situation where there is no time for anything other than tables with indicators and conversations, but things are not going very well anyway.

In addition, there are many factors affecting the developer's motivation, stimulating his understanding and acceptance of business goals: business prospects, understanding the importance of a project for a company, striving for smooth implementation and operation, subjective customer satisfaction, etc. But a lot of this is difficult formalize and measure. And even more difficult at times to convey the value to a specific artist. Often, even a very good developer does not catch the change in the direction of the "grocery wind", and he needs some kind of clear and simple mechanism that indicates the right direction.

Accordingly, I consider Due Date as one of the main tools for encouraging the developer's RBI at all stages. He goes through the whole process and makes invent solutions that allow to avoid a lot of problems in the future. It allows us to delegate responsibility without resorting to numerous KPIs. It is understandable and accessible to almost everyone. And it leads us all to the main goal of the business: to make it as fast as possible. And whether it will also be cheap depends on the decisions that we will use, and therefore on all of us.

How do you do in your company?