How managers learn how to set tasks for developers
When it comes to development, managers and managers immediately recall the accumulated array of tasks that are waiting for their turn, unpredictable deadlines for their implementation, which have the property of constantly changing, strained relations with the IT department, which uses the “friend or foe” system, and many other problems hindering business development. To solve all these problems, you need to learn how to correctly set tasks and communicate with developers. Nikolay Khlebinsky, CEO and co-founder of the Retail Rocket platform, tells how managers should set tasks so that they are completed on time and in accordance with the task.
We constantly get ideas for improving and improving the product - how to increase the website conversion, speed up the work of the department, improve business processes, automate some functions, etc. There are even special positions and departments, whose duties include monitoring of new functionality, which appears in the leading market players. Another great source of ideas is feedback from customers. This entire array of data, opinions and suggestions is accumulated and requires constant sorting, evaluation and prioritization.
')
New ideas move the product forward and create a competitive advantage, but if each employee immediately went with emerging ideas to the developers, the latter simply would not have time to work. They would either have to wallow in a series of endless discussions on how best to implement one or another moment, and then the development would go extremely slowly. Or, on the contrary, trying to implement new functions and features as quickly as possible, we would have to code it with crutches, adding changes without looking at another functionality, which would create difficulties in the future.
In our Retail Rocket, any team member can generate an idea, and it is entered onto a specific board in Trello. In our work we use the ideology of Kanban and for each process in the company, for each department, we have our own board. Product ideas are recorded in a specific column, but in order to do this, the manager (or any employee) must formulate a brief description of it. That is, not just “limit the number of characters in reviews” or “add a quick order button”, but a clear description from which it will be clear why a new function is needed and how it will be useful.
That is, the person who has an idea does not immediately go to the development department, and does not even go to the product manager, but first of all tries to formulate the idea into words. This avoids many problems and issues in the further development and implementation of new functions.
After that, the product manager comes into play - this is a separate role that handles product management. The task of this role is to collect the requirements and prepare these requirements for the transfer to the development. That is, the idea maker does not communicate directly with the development.
The product manager should write a description by which the developers will decide how to implement this particular idea and estimate the deadlines for completing the task.
For example, in the case of the task of limiting the number of characters in a recall, what should be described is what happens if the recall is longer than the specified value, whether the symbol count should be, if the CSS styles change when the counter approaches zero or an error message is displayed, etc. All these questions should be answered so that developers do not have to specify details in the process.
This means that, firstly, the idea cannot go into development until the list of those who will be responsible for checking it is determined after it leaves the IT department. And secondly, until the performance criteria are clearly defined.
That is, an employee who orders a new feature should say: “These specific people will test, and testing will be considered successful if such an event occurs.”
The most important point that occurs at this stage is getting the estimate for the problem in money. This means that any task that is given to the development must be estimated in money by its director, i.e. The employee must calculate how much the business will earn on this. It seems to many that it is impossible to estimate how much money a task will bring, but this is not so. Yes, it can be difficult, but experience shows that for most tasks it is quite real. And if it is impossible - these are exactly the tasks that the business does not need. If you don’t know how much the task will bring, is it really necessary to spend time on it?
Let's give an example. There is a trigger script - a letter about the "abandoned basket", which the online store sends to users who have added the product to the basket, but did not place an order. One of the clients asked to send a second letter in case the price of one of the items in the basket decreased. To calculate the cost of this task, the product manager came up with a request to analysts and asked him to calculate how much the price of goods reduced by 5% or more per week. Analysts found that about 10% of the goods left in the basket in the fashion segment for a week reduce the price by 5% or more. This means that we can increase the number of sending letters about an abandoned basket by 10% and, accordingly, receive 10% more orders. Thus, over the week we received a task estimate in money.
And all these processes are happening so far without the participation of developers, i.e. we do not tear them away from current tasks.
After evaluating the task in money, you need to get an assessment of the task performance by time - at this stage the development department is connected.
According to the description made by the product manager, the developers discuss how to complete the task and how long it will take. For evaluation, we use Planning Poker .
After evaluating all the tasks in the backlog, you can prioritize them, i.e. understand which tasks can be completed as quickly as possible and which will bring the greatest financial return. For them you need to take in the first place.
Only now begins the work of the IT team on the task.
When it comes to development, it is important to make the first version of the feature as cheap and simple as possible in order to test the hypothesis as quickly as possible. That is, create an MVP (Minimal Viable Product). At this stage, it is important to verify the performance criteria that were determined when describing the task.
Using the example of a task with notification of a reduction in the price of goods in a basket, you do not need to immediately create an interface, marketing materials, etc. We simply write code that works almost manually, we offer several shops for testing, to test how this will affect sales and to confirm the calculations of analysts in practice. We conduct testing in manual mode and measure the results. And only after we received evidence that the hypothesis worked, depending on the results, we decide whether to develop a full feature (develop the interface, draw the design, make the layout, etc.).
No one except the product manager and, possibly, the CEO, should communicate with the developers. They should be in a separate room and no one should go to them. This will help at times to increase the efficiency of the IT department. Because in order to concentrate even on a simple task, a person needs to spend 15-20 minutes just to get started. And if after 15 minutes someone approaches him with a question (and this happens all the time, and the bigger the company, the more often), the person leaves the state of concentration. So, he again needs 15-20 minutes to dive. Those. at least 30-40 minutes is already wasted. And if 5-7 people a day approach the developer with a question, we can assume that he did nothing during the day.
We solved this task by allocating a separate room for IT, the entrance to which to all other employees is prohibited. There is a separate lock on the door, to which only the engineers themselves and several other people in the company have a key card.
Another important point: you need to build a "protective dome" around the IT department, i.e. guard against any problems, solve all issues, provide infrastructure so that they are not engaged in anything other than the production of a code. It is no coincidence that in corporations such as Yandex or Google, the offices are fully equipped so that a person can practically not go home. If an employee searches for tea, coffee, or a mouse battery, he will spend much less time on his immediate duties. Providing costly qualified professionals with everything they need is much cheaper than spending their time on non-targeted actions.
This is also important because there are really few good developers, and it’s useless to compete for them only in price, because there will always be someone who is willing to pay more. Therefore, the more comfortable conditions you can create, the more productive the development team can become and the more loyalty the employees will show.
Another simple, but very effective way to more effectively communicate with developers is to learn how to speak their language. Take courses on HTML, CSS (for example, codecademy.com), i.e. spend 10-20 hours of your time in order to better understand the IT team in the future.
How do you build interaction with the IT team? Share your approaches in the comments!
Generate the idea correctly.
We constantly get ideas for improving and improving the product - how to increase the website conversion, speed up the work of the department, improve business processes, automate some functions, etc. There are even special positions and departments, whose duties include monitoring of new functionality, which appears in the leading market players. Another great source of ideas is feedback from customers. This entire array of data, opinions and suggestions is accumulated and requires constant sorting, evaluation and prioritization.
')
New ideas move the product forward and create a competitive advantage, but if each employee immediately went with emerging ideas to the developers, the latter simply would not have time to work. They would either have to wallow in a series of endless discussions on how best to implement one or another moment, and then the development would go extremely slowly. Or, on the contrary, trying to implement new functions and features as quickly as possible, we would have to code it with crutches, adding changes without looking at another functionality, which would create difficulties in the future.
The first and most important problem that needs to be solved is the process of generating ideas.
In our Retail Rocket, any team member can generate an idea, and it is entered onto a specific board in Trello. In our work we use the ideology of Kanban and for each process in the company, for each department, we have our own board. Product ideas are recorded in a specific column, but in order to do this, the manager (or any employee) must formulate a brief description of it. That is, not just “limit the number of characters in reviews” or “add a quick order button”, but a clear description from which it will be clear why a new function is needed and how it will be useful.
That is, the person who has an idea does not immediately go to the development department, and does not even go to the product manager, but first of all tries to formulate the idea into words. This avoids many problems and issues in the further development and implementation of new functions.
Therefore, the first rule: A task can be included in ideas only if a person is ready to formulate a brief description of it.
Describe the task as detailed as possible.
After that, the product manager comes into play - this is a separate role that handles product management. The task of this role is to collect the requirements and prepare these requirements for the transfer to the development. That is, the idea maker does not communicate directly with the development.
The product manager should write a description by which the developers will decide how to implement this particular idea and estimate the deadlines for completing the task.
Hence the second rule: the initial function of the product manager is to set and describe the task so as to remove all the questions from the development.
For example, in the case of the task of limiting the number of characters in a recall, what should be described is what happens if the recall is longer than the specified value, whether the symbol count should be, if the CSS styles change when the counter approaches zero or an error message is displayed, etc. All these questions should be answered so that developers do not have to specify details in the process.
The third rule: the product manager must create a list of those who will test the feature and determine its effectiveness.
This means that, firstly, the idea cannot go into development until the list of those who will be responsible for checking it is determined after it leaves the IT department. And secondly, until the performance criteria are clearly defined.
That is, an employee who orders a new feature should say: “These specific people will test, and testing will be considered successful if such an event occurs.”
Evaluate each task
The most important point that occurs at this stage is getting the estimate for the problem in money. This means that any task that is given to the development must be estimated in money by its director, i.e. The employee must calculate how much the business will earn on this. It seems to many that it is impossible to estimate how much money a task will bring, but this is not so. Yes, it can be difficult, but experience shows that for most tasks it is quite real. And if it is impossible - these are exactly the tasks that the business does not need. If you don’t know how much the task will bring, is it really necessary to spend time on it?
The fourth rule: each task must be evaluated in money
Let's give an example. There is a trigger script - a letter about the "abandoned basket", which the online store sends to users who have added the product to the basket, but did not place an order. One of the clients asked to send a second letter in case the price of one of the items in the basket decreased. To calculate the cost of this task, the product manager came up with a request to analysts and asked him to calculate how much the price of goods reduced by 5% or more per week. Analysts found that about 10% of the goods left in the basket in the fashion segment for a week reduce the price by 5% or more. This means that we can increase the number of sending letters about an abandoned basket by 10% and, accordingly, receive 10% more orders. Thus, over the week we received a task estimate in money.
And all these processes are happening so far without the participation of developers, i.e. we do not tear them away from current tasks.
Prioritize tasks
After evaluating the task in money, you need to get an assessment of the task performance by time - at this stage the development department is connected.
According to the description made by the product manager, the developers discuss how to complete the task and how long it will take. For evaluation, we use Planning Poker .
After evaluating all the tasks in the backlog, you can prioritize them, i.e. understand which tasks can be completed as quickly as possible and which will bring the greatest financial return. For them you need to take in the first place.
Fifth rule: the first to work must go the tasks that will bring the greatest financial benefit and require minimal time.
Only now begins the work of the IT team on the task.
Create MVP first
When it comes to development, it is important to make the first version of the feature as cheap and simple as possible in order to test the hypothesis as quickly as possible. That is, create an MVP (Minimal Viable Product). At this stage, it is important to verify the performance criteria that were determined when describing the task.
Using the example of a task with notification of a reduction in the price of goods in a basket, you do not need to immediately create an interface, marketing materials, etc. We simply write code that works almost manually, we offer several shops for testing, to test how this will affect sales and to confirm the calculations of analysts in practice. We conduct testing in manual mode and measure the results. And only after we received evidence that the hypothesis worked, depending on the results, we decide whether to develop a full feature (develop the interface, draw the design, make the layout, etc.).
The sixth rule: develop a full version of the feature after confirming its effectiveness through MVP
Increase development team productivity
No one except the product manager and, possibly, the CEO, should communicate with the developers. They should be in a separate room and no one should go to them. This will help at times to increase the efficiency of the IT department. Because in order to concentrate even on a simple task, a person needs to spend 15-20 minutes just to get started. And if after 15 minutes someone approaches him with a question (and this happens all the time, and the bigger the company, the more often), the person leaves the state of concentration. So, he again needs 15-20 minutes to dive. Those. at least 30-40 minutes is already wasted. And if 5-7 people a day approach the developer with a question, we can assume that he did nothing during the day.
Seventh rule: Limit to the minimum the circle of those who communicate with the developers. Ideally, this should only be the product manager and in some cases the CEO.
We solved this task by allocating a separate room for IT, the entrance to which to all other employees is prohibited. There is a separate lock on the door, to which only the engineers themselves and several other people in the company have a key card.
Another important point: you need to build a "protective dome" around the IT department, i.e. guard against any problems, solve all issues, provide infrastructure so that they are not engaged in anything other than the production of a code. It is no coincidence that in corporations such as Yandex or Google, the offices are fully equipped so that a person can practically not go home. If an employee searches for tea, coffee, or a mouse battery, he will spend much less time on his immediate duties. Providing costly qualified professionals with everything they need is much cheaper than spending their time on non-targeted actions.
The eighth rule: organize the infrastructure and provide developers with all necessary
This is also important because there are really few good developers, and it’s useless to compete for them only in price, because there will always be someone who is willing to pay more. Therefore, the more comfortable conditions you can create, the more productive the development team can become and the more loyalty the employees will show.
Become your
Another simple, but very effective way to more effectively communicate with developers is to learn how to speak their language. Take courses on HTML, CSS (for example, codecademy.com), i.e. spend 10-20 hours of your time in order to better understand the IT team in the future.
How do you build interaction with the IT team? Share your approaches in the comments!
Source: https://habr.com/ru/post/336430/
All Articles