5 cool things in the processes of the American company
I want to share interesting and useful techniques in organizing company processes in the United States. I worked for 9 years in one grocery company, since I graduated from the institute, there was a lot of good things there, but from a certain moment I wondered “how about the others?”. About 8 months ago HR knocked me and called for a job interview at a project company for a DBA position to work for a company from the USA. At that moment I worked as a deputy technical director. Such a proposal was quite unexpected, I did not take it seriously - I wanted to see what others had, but not with such a sharp decline in my career. But, I agreed to come for an interview - the process was interesting.
There were 3 stages of the interview:
During the interview, it turned out that the company is very large, the development is carried out using the same tools as in the first company. Everything is very close. Many database tasks. I liked how detailed the questions were about technologies, it was clear that the level of specialists is high and the project is interesting.
I decided to accept the offer and come to the company - to work on an interesting task and see how the processes in the American company are organized. It is necessary to make a reservation here that I had pink glasses. I thought that if the company is in America, then all the processes within it are established, the leaders work according to the principles of Stephen Covey and Yitzhak Adizes. To my surprise, this was not the case. Rose-colored glasses were removed, but many useful and new things were found in the work of the company.
')
The methodology itself, with its pluses and minuses, deserves a separate article. So far I will only say that the development is divided into "sprints". Each sprint 2 weeks. It is assumed that all tasks will be closed during this period. If suddenly, someone will more quickly cope with the tasks on sprint, then he will be connected and will help those who are not in time. The assessment of the complexity of the task, in my opinion, is a very useful thing, is carried out collectively. There is a call once a week, during which the team discusses unvalued tasks and assigns complexity - in a closed ballot. Then, when everyone voted, it is already clear who put it and how much, if there are big differences in the assessment - the people who rated the task, speak out and discuss. As a result, the group comes to a common assessment of the problem. A thing is long (rarely takes less than 2 hours), but, in my opinion, useful. Firstly, everyone is aware of the main tasks. Secondly, this method allows us to more objectively assess the complexity and scope of the task.
I do not know how often the problem occurs when the company’s management does not understand what programmers are doing. In my first company, this was a sore point. We tried all kinds of reports that the management did not read as a result, the question finally hung, but there was still a lack of understanding. And there was such a simple solution. The presentation is once in 2 weeks (here at the end of each sprint) with a brief overview of what has been made clear to business people by the language. This gives the management an understanding of what people are doing and the opportunity to understand whether the project is going there.
This is a demo for employees from management. With a description of the main priorities of the company's development, achievements, and directions for further development. In my opinion, a wonderful thing. It gives, first of all, an understanding to people of what tasks the leadership solves and on which it works. Secondly, it gives the opportunity to correlate their priorities and development principles with the priorities and principles of the company’s development - this way you can check all the time, but can you follow the way?
At such a “call”, the whole company is usually present. And everyone has the opportunity to ask a question on the air. Lasts about 1 hour. It is held once a month or a quarter, depending on the company.
This is more technical part, but also very useful. The organization of the application of changes in the first company was as follows: the developer made changes, tested, gave to the tester, then the mandatory part followed with a detailed code review by the manager. Further, the manager has already applied the changes to the working system. We could not think of how to get rid of the part with viewing the code. And the solution is very simple - code review should be done by the developers themselves. Only not the one who wrote the code, but 2-3 other people. All their comments and comments should be carefully studied and applied, or the author-developer must convince his colleagues that his decision is better. One moment - developers should be motivated to do code review. Sometimes waiting for feedback from others takes as much time as the task itself, and then returning to the already written code and editing it is inconvenient.
If some unforeseen situation happens, for example, the CPU load on the production server increases to 90% and the problem cannot be solved within 5 minutes, the Bridge call of the company's specialists is organized. Present DBA and leading developers.
At first I was quite skeptical of such “phoned”. It seemed to me that this should rather hinder the solution of the problem. However, I see the effectiveness of this method - the solution is usually found and the problem is solved. Such teamwork allows you to find the cause, due to the fact that several people put forward suggestions and are engaged in finding a problem and its solutions.
I hope my experience will be useful to you.
There were 3 stages of the interview:
- With the lead developer of the project in the company-employer
- With a leading developer from a customer company (already in English)
- With the architect in the company-customer
During the interview, it turned out that the company is very large, the development is carried out using the same tools as in the first company. Everything is very close. Many database tasks. I liked how detailed the questions were about technologies, it was clear that the level of specialists is high and the project is interesting.
I decided to accept the offer and come to the company - to work on an interesting task and see how the processes in the American company are organized. It is necessary to make a reservation here that I had pink glasses. I thought that if the company is in America, then all the processes within it are established, the leaders work according to the principles of Stephen Covey and Yitzhak Adizes. To my surprise, this was not the case. Rose-colored glasses were removed, but many useful and new things were found in the work of the company.
')
1. Scrum
The methodology itself, with its pluses and minuses, deserves a separate article. So far I will only say that the development is divided into "sprints". Each sprint 2 weeks. It is assumed that all tasks will be closed during this period. If suddenly, someone will more quickly cope with the tasks on sprint, then he will be connected and will help those who are not in time. The assessment of the complexity of the task, in my opinion, is a very useful thing, is carried out collectively. There is a call once a week, during which the team discusses unvalued tasks and assigns complexity - in a closed ballot. Then, when everyone voted, it is already clear who put it and how much, if there are big differences in the assessment - the people who rated the task, speak out and discuss. As a result, the group comes to a common assessment of the problem. A thing is long (rarely takes less than 2 hours), but, in my opinion, useful. Firstly, everyone is aware of the main tasks. Secondly, this method allows us to more objectively assess the complexity and scope of the task.
2. Demo to guide each sprint
I do not know how often the problem occurs when the company’s management does not understand what programmers are doing. In my first company, this was a sore point. We tried all kinds of reports that the management did not read as a result, the question finally hung, but there was still a lack of understanding. And there was such a simple solution. The presentation is once in 2 weeks (here at the end of each sprint) with a brief overview of what has been made clear to business people by the language. This gives the management an understanding of what people are doing and the opportunity to understand whether the project is going there.
3. All hands meeting
This is a demo for employees from management. With a description of the main priorities of the company's development, achievements, and directions for further development. In my opinion, a wonderful thing. It gives, first of all, an understanding to people of what tasks the leadership solves and on which it works. Secondly, it gives the opportunity to correlate their priorities and development principles with the priorities and principles of the company’s development - this way you can check all the time, but can you follow the way?
At such a “call”, the whole company is usually present. And everyone has the opportunity to ask a question on the air. Lasts about 1 hour. It is held once a month or a quarter, depending on the company.
4. Code review
This is more technical part, but also very useful. The organization of the application of changes in the first company was as follows: the developer made changes, tested, gave to the tester, then the mandatory part followed with a detailed code review by the manager. Further, the manager has already applied the changes to the working system. We could not think of how to get rid of the part with viewing the code. And the solution is very simple - code review should be done by the developers themselves. Only not the one who wrote the code, but 2-3 other people. All their comments and comments should be carefully studied and applied, or the author-developer must convince his colleagues that his decision is better. One moment - developers should be motivated to do code review. Sometimes waiting for feedback from others takes as much time as the task itself, and then returning to the already written code and editing it is inconvenient.
5. Bridge call during problem
If some unforeseen situation happens, for example, the CPU load on the production server increases to 90% and the problem cannot be solved within 5 minutes, the Bridge call of the company's specialists is organized. Present DBA and leading developers.
At first I was quite skeptical of such “phoned”. It seemed to me that this should rather hinder the solution of the problem. However, I see the effectiveness of this method - the solution is usually found and the problem is solved. Such teamwork allows you to find the cause, due to the fact that several people put forward suggestions and are engaged in finding a problem and its solutions.
I hope my experience will be useful to you.
Source: https://habr.com/ru/post/306238/
All Articles