How to increase the effectiveness of the development method of Kuklachev
How did Yuri Kuklachev manage to create a team that has consistently, over the years, been showing inconceivable results for other similar teams?
UPD: Fasting is not about food deprivation.
The secret of Yuri Kuklachev is simple:
')
1. Proper selection of specialists (super important)
2. Correct alignment of processes
These two principles can be used to build effective teams in the development of software products.
There is no sense in breaking and re-crafting a person; it is better to immediately try to attract only those people who comply with your principles. It is important for us that the new person has the following qualities:
Before the interview, we always give candidates a test task (more on this below). The completed test task is much better than a piece of code once written, it shows that the candidate is a creator and is quite interested. The code will show the competence performed by the test - the level of interest (see the interest-competence matrix) and the approach to work.
At the interview, you can distinguish the creator, if you go into great detail in the way he solved this or that problem in the previous work. If the candidate has some experience, you can ask what will be his first steps in solving a specific task.
We are looking for candidates in the desire to do what they are curious and interesting, a tendency to get involved in their work. A person who is passionate about consumption is hardly strong in creation.
You can learn about this by asking open-ended questions about what the candidate wants in life, what he liked / didn’t like at previous places of work. To many developers, such questions may seem strange and stupid, therefore, you should at least try not to ask stereotyped questions “by whom you see yourself in 5 years”, but to come up with something original, something to which a person will answer sincerely.
We strive to ensure that the team was cross-functional. The market and technology are changing very quickly. All this requires that people be able to flexibly adapt and quickly learn new things.
Ideally, your test task itself will be something new for the candidate. For example, if he never used GitHub, and the test task assumes its use, it will perfectly show whether a person can quickly orient himself.
At the interview again open questions will help. Avoid questions that imply an obvious socially desirable answer, for example, “are you ready to learn new technologies?”. It will be much more productive to ask what is new in his or related fields he has learned over the past couple of months.
If someone is satisfied with holivary for any reason or he has a weak tolerance for the mistakes of others, it will ruin the atmosphere in the team.
If during the interview there are doubts about this, the candidate says that he was dissatisfied with his colleagues, conflicted with them, then it is necessary to go deep, ask him to tell him more about it.
It all starts with the right job text. You can not mindlessly copy the text of other vacancies. Write a job from the heart, put yourself in the place of the candidate.
This business is very similar to marketing - look at the vacancies of other companies, track the conversion of those who looked at your old vacancies, highlight the most successful, analyze why they are successful. There are statistics on Freelansim and Huntim, it is possible to evaluate which headlines and snapshots of vacancies attract applicants.
Do not narrow your search range too much. If you write that you need a developer who has already worked with some technology, then you have a chance to miss the excellent candidates who did not work, but will be able to study this technology in 3-4 weeks and get involved in the work.
For example, we develop on yii, but we emphasize that experience with this framework is not so critical.
I have already written above that for each candidate, we first of all issue a test task. Interesting test problems work best.
No one wants to do the same thing for the 33rd time. But too creative a task will fit poorly - it will be better if the test is similar to the tasks that the selected candidate will face in the work.
I can not help but brag about how candidates react to our test:
If we are looking for not a developer, but a system administrator / manager / designer / any other specialist, then we should try to invent an analogue of the test task for him. For example, for a manager, this could be a plan for entering a position, something that he would do first.
After there are 5-10 candidates who sent the test, we conduct interviews. We discuss the results of the test, compare the values ​​with respect to your criteria and choose the one who suits us best.
Anyone who sent a test task must answer, it is better in more detail, they spent their time on your task.
To store the code, we use a private repository on GitHub, we also use it for tracking tasks and maintaining documentation.
Some tips that may be useful to you:
1. Prioritization. Use shortcuts in the GitHub tasker
Shortcuts allow you to highlight among a large number of tasks priorities, push tasks with low importance.
2. Eat the elephant bite by bite
It is better to try to avoid epic tasks, and beat them to small ones. But small ones of the same type - group in one issue list with checkboxes. Use markup for this:
- [] Task is not ready yet
- [x] Task is ready
3. Registration tasks. The use of GitHub Flavored Markdown improves life, I advise you to read about it in detail
4. Transparency of goals and objectives. On Monday, we make a list of tasks for the week and combine them into milestone. At retrospectives, we analyze the results of Milestone, which can be improved during the development process. We praise each other for success, good ideas, this has a positive effect on the atmosphere in the team.
As a result, both the current tasks and the long-term goals should be clear for the whole team, where we are going and what we want to achieve. Such a process is relevant for our small team, but perhaps for large teams you need to use your own format, since in large teams the discussions can drag out and take a significant amount of time.
5. Personal responsibility. For each task there should be only one responsible, no collective responsibility for tasks.
6. Stand-up rally. In the mornings we hold a quick stand-up rally, with traditional questions who did what, what problems there are and who is going to do today.
The emphasis is on the tasks that are made and will be made. Stand-up helps everyone to be aware of who does what, to quickly solve problems.
7. Maximum availability of information. Documentation is maintained in the wiki repository. We widely use group chats in Skype, including when communicating with specialists who are not in a team so that everyone on the team can be aware of the situation and can read.
8. Cross code review. At the end of each week we do a cross code review for mutual learning and improving the quality of the code.
9. User support. All one way or another interact with users, in contact with their support. This allows everyone to better understand the product and user needs.
10. Deploy and tests. We use an intermediate deployment to the dev server with an automatic test run, and then deploy to the production server, and we will tell you more about the deployment process in a separate topic.
UPD: Fasting is not about food deprivation.
The secret of Yuri Kuklachev is simple:
')
1. Proper selection of specialists (super important)
2. Correct alignment of processes
These two principles can be used to build effective teams in the development of software products.
Team selection
There is no sense in breaking and re-crafting a person; it is better to immediately try to attract only those people who comply with your principles. It is important for us that the new person has the following qualities:
1. Creator
Before the interview, we always give candidates a test task (more on this below). The completed test task is much better than a piece of code once written, it shows that the candidate is a creator and is quite interested. The code will show the competence performed by the test - the level of interest (see the interest-competence matrix) and the approach to work.
At the interview, you can distinguish the creator, if you go into great detail in the way he solved this or that problem in the previous work. If the candidate has some experience, you can ask what will be his first steps in solving a specific task.
2. Motivated not by money
We are looking for candidates in the desire to do what they are curious and interesting, a tendency to get involved in their work. A person who is passionate about consumption is hardly strong in creation.
You can learn about this by asking open-ended questions about what the candidate wants in life, what he liked / didn’t like at previous places of work. To many developers, such questions may seem strange and stupid, therefore, you should at least try not to ask stereotyped questions “by whom you see yourself in 5 years”, but to come up with something original, something to which a person will answer sincerely.
3. Likes to learn new technologies and approaches.
We strive to ensure that the team was cross-functional. The market and technology are changing very quickly. All this requires that people be able to flexibly adapt and quickly learn new things.
Ideally, your test task itself will be something new for the candidate. For example, if he never used GitHub, and the test task assumes its use, it will perfectly show whether a person can quickly orient himself.
At the interview again open questions will help. Avoid questions that imply an obvious socially desirable answer, for example, “are you ready to learn new technologies?”. It will be much more productive to ask what is new in his or related fields he has learned over the past couple of months.
4. Adequately communicates
If someone is satisfied with holivary for any reason or he has a weak tolerance for the mistakes of others, it will ruin the atmosphere in the team.
If during the interview there are doubts about this, the candidate says that he was dissatisfied with his colleagues, conflicted with them, then it is necessary to go deep, ask him to tell him more about it.
Dream Team Tips
1. Vacancy
It all starts with the right job text. You can not mindlessly copy the text of other vacancies. Write a job from the heart, put yourself in the place of the candidate.
This business is very similar to marketing - look at the vacancies of other companies, track the conversion of those who looked at your old vacancies, highlight the most successful, analyze why they are successful. There are statistics on Freelansim and Huntim, it is possible to evaluate which headlines and snapshots of vacancies attract applicants.
Do not narrow your search range too much. If you write that you need a developer who has already worked with some technology, then you have a chance to miss the excellent candidates who did not work, but will be able to study this technology in 3-4 weeks and get involved in the work.
For example, we develop on yii, but we emphasize that experience with this framework is not so critical.
2. Test task
I have already written above that for each candidate, we first of all issue a test task. Interesting test problems work best.
No one wants to do the same thing for the 33rd time. But too creative a task will fit poorly - it will be better if the test is similar to the tasks that the selected candidate will face in the work.
I can not help but brag about how candidates react to our test:
If we are looking for not a developer, but a system administrator / manager / designer / any other specialist, then we should try to invent an analogue of the test task for him. For example, for a manager, this could be a plan for entering a position, something that he would do first.
3. Interview and selection
After there are 5-10 candidates who sent the test, we conduct interviews. We discuss the results of the test, compare the values ​​with respect to your criteria and choose the one who suits us best.
Anyone who sent a test task must answer, it is better in more detail, they spent their time on your task.
Alignment of development processes
To store the code, we use a private repository on GitHub, we also use it for tracking tasks and maintaining documentation.
Some tips that may be useful to you:
1. Prioritization. Use shortcuts in the GitHub tasker
Shortcuts allow you to highlight among a large number of tasks priorities, push tasks with low importance.
2. Eat the elephant bite by bite
It is better to try to avoid epic tasks, and beat them to small ones. But small ones of the same type - group in one issue list with checkboxes. Use markup for this:
- [] Task is not ready yet
- [x] Task is ready
3. Registration tasks. The use of GitHub Flavored Markdown improves life, I advise you to read about it in detail
4. Transparency of goals and objectives. On Monday, we make a list of tasks for the week and combine them into milestone. At retrospectives, we analyze the results of Milestone, which can be improved during the development process. We praise each other for success, good ideas, this has a positive effect on the atmosphere in the team.
As a result, both the current tasks and the long-term goals should be clear for the whole team, where we are going and what we want to achieve. Such a process is relevant for our small team, but perhaps for large teams you need to use your own format, since in large teams the discussions can drag out and take a significant amount of time.
5. Personal responsibility. For each task there should be only one responsible, no collective responsibility for tasks.
6. Stand-up rally. In the mornings we hold a quick stand-up rally, with traditional questions who did what, what problems there are and who is going to do today.
The emphasis is on the tasks that are made and will be made. Stand-up helps everyone to be aware of who does what, to quickly solve problems.
7. Maximum availability of information. Documentation is maintained in the wiki repository. We widely use group chats in Skype, including when communicating with specialists who are not in a team so that everyone on the team can be aware of the situation and can read.
8. Cross code review. At the end of each week we do a cross code review for mutual learning and improving the quality of the code.
9. User support. All one way or another interact with users, in contact with their support. This allows everyone to better understand the product and user needs.
10. Deploy and tests. We use an intermediate deployment to the dev server with an automatic test run, and then deploy to the production server, and we will tell you more about the deployment process in a separate topic.
Source: https://habr.com/ru/post/209664/
All Articles