Project Management - People Management
I work as a PM in a small - about 50 people - software development companies. This article is written solely for the purpose of sharing your thoughts about the processes of managing people in a team and, ideally, to hear the comments of professional managers and developers. Immediately make a reservation that I do not affect other aspects of management
Since I have been working for a very short time, about a year, and before that I was a programmer (I went through all the steps from the trainee to the architect), then the mistakes that my leaders made, after which, at best, it became dirty, were still fresh in my memory. Again, a disclaimer, all this is written solely for the purpose of discussion ... So, let's begin.
I think it is obvious that no project could normally complete (and begin) without a team that performs it. The main thing here is to understand what happens to be a “team”, and sometimes a “development team”. In the classics (Peopleware DeMarco and Lester) the process of “crystallization” of the team is described. Therefore, you should try to get the maximum control over the distribution of people in your team for projects and make all possible efforts (from loud indignation to the director to) to prevent their separation, so that they work together on all projects.
By the way, working on one project is not enough to create a team. We have to work on this. I met with the "team", which rather resembles a group of freelancers, who for some reason gathered in the same office and sit at the neighboring computers. In principle, I do not think that purposeful team-building (trips “on beer”, joint campaigns, etc.) can improve the situation. In my opinion, only worsen. It is much more unpleasant to dismiss or deprive of the premium of the person with whom I drank beer last week. I think that it is enough that each team member has a specific role in it and that there is continuous communication within the project (for which, as Brooks said, the main working time is spent). Formula 1 + 1 = 2.5 here works as well as possible more efficiently. And the most important thing in the team is mutual respect.
')
It is very important to ensure that each team member respects the others. And for this, first of all, every manager should be respected. Yes, indeed, Vasya is lazy, and Asya considers all others as idiots. Gosh considers himself much smarter than he really is, and Syoma writes a disgusting code. But at the same time, no one understands Linux-systems better than Vasya, Asya, despite everything, is a very good architect, Gosha seeks to write neat clean code, and Syoma is learning quite well. And this is the main point.
Make it clear (publicly) to Vasya that no one except for him could have written this automatic deployment script, praise Asin's class diagram and the Goshin code, again, publicly. Explain Syom that he does wrong and, for all, praise as soon as his code improves. This is a lot. The team will be respected only when you work on it. And, most importantly, never publicly insult your guys. It is shameful and unprofessional. Yes, and scold, preferably by setting aside and quietly (well, this is a well-known rule). In general, each person is unique, and this must be taken into account.
Usually, you have to work with each person. And this is one of the main responsibilities (and headaches) of the project manager. Unfortunately, PMs often forget about this, filled up with plans, deadlines, requirements and letters of an inadequate customer. It seems to me that any developer has a key that needs to be turned to make it work efficiently. A sort of "point G" that helps to achieve maximum impact. (I apologize for a too frivolous comparison, therefore we will call it better the “E point”, from the word effect). Moreover, this point requires continuous stimulation throughout the entire work time.
Let me give an example: we had a person who worked for us, say, Vasya, whom they wanted to fire as completely incompetent. And not just like that, but according to the results of several projects that "he has filled up." I asked to give me a month to understand why a specialist, whom I knew as a “serious computer scientist, almost a guru” since the university, shows such awesome results (losses were calculated, by the way, by tens of thousands of dollars a month). Everything turned out to be simple and trite. Vasya was an excellent programmer, but he didn’t know how to set tasks for himself. And, as soon as the requirements were a little unclear, he fell into a stupor bordering on a lethargic sleep. But it was worth spending fifteen minutes, to clearly formulate the task and the expected result, as everything turned out to be done, and quickly and efficiently. After we began to work in this mode, progress became so obvious that he was even promoted. Obviously, this requires a minimal understanding by the manager of the technology on which the development takes place.
It's great when a project manager has a detailed understanding of the technology that his team uses. But this is not the main thing (whatever Rainwater, a cat grazing specialist, says). It is enough for you to have such specialists whom you can entrust the technical part, focusing on management. I admit, I have only general ideas about the language in which my team writes. Sometimes I think it is even good, because otherwise I would definitely impose my own, rather narrow, views. Moreover, I consider it very important that the PCs in no case write the code themselves. Well, really, what will happen if programmers start negotiating with the customer about the deadlines, and sales specialists test the code? Like Chukovsky: “The pigs have begun to scowl, the cats have grunted ...” (the full text of this immortal work can be found here: www.stihi-rus.ru/1/chukovskiy/19.htm ).
Developers should be aware of the current situation of the project, as well as the current situation in the company and the prospects for its development. This is an ambiguous thesis. I am more than sure that many will list some things that are not necessary to bring to the developer (for example, how much the customer pays per hour of their work). But, really, the developer works much better if he feels that he is not hiding anything from him. Let him know that the customer pays ten, twenty, fifty bucks for the hour of his work, while he gets three, five, ten times less for the same hour. But he has a guaranteed income, a steady income and a guarantee that the salary will be paid on time. And the projects themselves do not need to search. On the other hand, one should not hide the facts (and the reasons) of the project’s exit for the budget, etc. If the developer is adequate, he will correctly understand why the project failed, and why he was not paid the premium.
By the way, about the failed projects. Unfortunately, project managers can sometimes hear statements like: “This project failed due to the fact that programmers are not sufficiently qualified, that they make a lot of mistakes. And Vasya is generally freelancing in the evenings ”). A great way to pass all the blame on the programmers (and, yes, the testers still did not find the error on time, and the analyst with the requirements was nakosyachil).
In fact, no one except the manager is to blame for the failure of the project. And this is very important! There are not enough qualifications among programmers - teach, look for an approach, this very “point E”. If a person is “completely wooden” - no one will worry if he is fired, has not yet become embedded in the team, and replaced by someone else.
If this is not done, the project will be a 90% failure. The remaining 10%, most likely, say that in this team the PM is not needed in principle.
Your team is your everything, so it’s very important that people are happy. It depends only on the project manager how comfortable conditions will be created for the team and each person individually. By and large, it is the PM that determines both the career and professional growth of their team. Therefore, if you think that your employee is worthy of a promotion, then you need to set this as your goal and achieve in all possible ways. I will make a reservation that, of course, only professional qualities are considered. The main thing is to ensure that personal affection or bias does not affect the adoption of such a decision (again, about the harm of drinking beer together). So, the well-being and comfort of people also need to work.
The conclusions are obvious. To perform effective projects, you need to work with the team. This is a necessary condition (but, of course, not sufficient). It can be stated as follows: it is impossible to achieve success in a project without having a well-coordinated and prepared project team. Long live captain Obvious!
Since I have been working for a very short time, about a year, and before that I was a programmer (I went through all the steps from the trainee to the architect), then the mistakes that my leaders made, after which, at best, it became dirty, were still fresh in my memory. Again, a disclaimer, all this is written solely for the purpose of discussion ... So, let's begin.
About the team
I think it is obvious that no project could normally complete (and begin) without a team that performs it. The main thing here is to understand what happens to be a “team”, and sometimes a “development team”. In the classics (Peopleware DeMarco and Lester) the process of “crystallization” of the team is described. Therefore, you should try to get the maximum control over the distribution of people in your team for projects and make all possible efforts (from loud indignation to the director to) to prevent their separation, so that they work together on all projects.
By the way, working on one project is not enough to create a team. We have to work on this. I met with the "team", which rather resembles a group of freelancers, who for some reason gathered in the same office and sit at the neighboring computers. In principle, I do not think that purposeful team-building (trips “on beer”, joint campaigns, etc.) can improve the situation. In my opinion, only worsen. It is much more unpleasant to dismiss or deprive of the premium of the person with whom I drank beer last week. I think that it is enough that each team member has a specific role in it and that there is continuous communication within the project (for which, as Brooks said, the main working time is spent). Formula 1 + 1 = 2.5 here works as well as possible more efficiently. And the most important thing in the team is mutual respect.
')
About respect
It is very important to ensure that each team member respects the others. And for this, first of all, every manager should be respected. Yes, indeed, Vasya is lazy, and Asya considers all others as idiots. Gosh considers himself much smarter than he really is, and Syoma writes a disgusting code. But at the same time, no one understands Linux-systems better than Vasya, Asya, despite everything, is a very good architect, Gosha seeks to write neat clean code, and Syoma is learning quite well. And this is the main point.
Make it clear (publicly) to Vasya that no one except for him could have written this automatic deployment script, praise Asin's class diagram and the Goshin code, again, publicly. Explain Syom that he does wrong and, for all, praise as soon as his code improves. This is a lot. The team will be respected only when you work on it. And, most importantly, never publicly insult your guys. It is shameful and unprofessional. Yes, and scold, preferably by setting aside and quietly (well, this is a well-known rule). In general, each person is unique, and this must be taken into account.
About individuality
Usually, you have to work with each person. And this is one of the main responsibilities (and headaches) of the project manager. Unfortunately, PMs often forget about this, filled up with plans, deadlines, requirements and letters of an inadequate customer. It seems to me that any developer has a key that needs to be turned to make it work efficiently. A sort of "point G" that helps to achieve maximum impact. (I apologize for a too frivolous comparison, therefore we will call it better the “E point”, from the word effect). Moreover, this point requires continuous stimulation throughout the entire work time.
Let me give an example: we had a person who worked for us, say, Vasya, whom they wanted to fire as completely incompetent. And not just like that, but according to the results of several projects that "he has filled up." I asked to give me a month to understand why a specialist, whom I knew as a “serious computer scientist, almost a guru” since the university, shows such awesome results (losses were calculated, by the way, by tens of thousands of dollars a month). Everything turned out to be simple and trite. Vasya was an excellent programmer, but he didn’t know how to set tasks for himself. And, as soon as the requirements were a little unclear, he fell into a stupor bordering on a lethargic sleep. But it was worth spending fifteen minutes, to clearly formulate the task and the expected result, as everything turned out to be done, and quickly and efficiently. After we began to work in this mode, progress became so obvious that he was even promoted. Obviously, this requires a minimal understanding by the manager of the technology on which the development takes place.
Pro technical skills
It's great when a project manager has a detailed understanding of the technology that his team uses. But this is not the main thing (whatever Rainwater, a cat grazing specialist, says). It is enough for you to have such specialists whom you can entrust the technical part, focusing on management. I admit, I have only general ideas about the language in which my team writes. Sometimes I think it is even good, because otherwise I would definitely impose my own, rather narrow, views. Moreover, I consider it very important that the PCs in no case write the code themselves. Well, really, what will happen if programmers start negotiating with the customer about the deadlines, and sales specialists test the code? Like Chukovsky: “The pigs have begun to scowl, the cats have grunted ...” (the full text of this immortal work can be found here: www.stihi-rus.ru/1/chukovskiy/19.htm ).
About the information
Developers should be aware of the current situation of the project, as well as the current situation in the company and the prospects for its development. This is an ambiguous thesis. I am more than sure that many will list some things that are not necessary to bring to the developer (for example, how much the customer pays per hour of their work). But, really, the developer works much better if he feels that he is not hiding anything from him. Let him know that the customer pays ten, twenty, fifty bucks for the hour of his work, while he gets three, five, ten times less for the same hour. But he has a guaranteed income, a steady income and a guarantee that the salary will be paid on time. And the projects themselves do not need to search. On the other hand, one should not hide the facts (and the reasons) of the project’s exit for the budget, etc. If the developer is adequate, he will correctly understand why the project failed, and why he was not paid the premium.
About the guilty
By the way, about the failed projects. Unfortunately, project managers can sometimes hear statements like: “This project failed due to the fact that programmers are not sufficiently qualified, that they make a lot of mistakes. And Vasya is generally freelancing in the evenings ”). A great way to pass all the blame on the programmers (and, yes, the testers still did not find the error on time, and the analyst with the requirements was nakosyachil).
In fact, no one except the manager is to blame for the failure of the project. And this is very important! There are not enough qualifications among programmers - teach, look for an approach, this very “point E”. If a person is “completely wooden” - no one will worry if he is fired, has not yet become embedded in the team, and replaced by someone else.
If this is not done, the project will be a 90% failure. The remaining 10%, most likely, say that in this team the PM is not needed in principle.
About caring
Your team is your everything, so it’s very important that people are happy. It depends only on the project manager how comfortable conditions will be created for the team and each person individually. By and large, it is the PM that determines both the career and professional growth of their team. Therefore, if you think that your employee is worthy of a promotion, then you need to set this as your goal and achieve in all possible ways. I will make a reservation that, of course, only professional qualities are considered. The main thing is to ensure that personal affection or bias does not affect the adoption of such a decision (again, about the harm of drinking beer together). So, the well-being and comfort of people also need to work.
About conclusions
The conclusions are obvious. To perform effective projects, you need to work with the team. This is a necessary condition (but, of course, not sufficient). It can be stated as follows: it is impossible to achieve success in a project without having a well-coordinated and prepared project team. Long live captain Obvious!
Source: https://habr.com/ru/post/83837/
All Articles