Problem solving: 10 manager rules
Consider the following situation: you are a project manager, and your project has a problem. About how to gradually get to the source of the problem and eliminate it, I will describe in detail in today's article.
Everything works!
')
There is a popular belief that the problems are solved by the performers, and the managers only walk and interfere . However, what happens if there is no manager on the project? Imagine a situation: an angry letter comes to the support: “I pressed the button, and there is the 500th mistake!”. And the letter comes not one, that is, the problem is massive.
To give the bug? Suppose the support service assumes that the problem has occurred on the client side, and gives the bug to a JavaScript programmer. The JavaScript programmer looks at the description and says: “Most likely, the problem is on the server. I have nothing to do with this". The support officer nods and goes to the server programmer. The server programmer, in turn, declares that there are no problems on the server, the code is reliable, everything should work. Support goes to the admin. Admin looks at the CPU, disk, free space, logs, but also does not find anything criminal.
From this point on, the problem that has arisen on the project is, as it were, “on no one’s side”: no one considers himself responsible and does not consider it necessary to take up its solution. And everyone can be understood: everyone has his own task, a plan for development, and besides, it is much more interesting to cut new features than to deal with the mysterious five hundredths, which, well, certainly not through your fault. As a result, all the good people and busy business - only the user is still bad.
Of course, this is not the only possible course of development of the scenario. There are teams in which there is no person with the post of project manager, but problems, however, are solved. However, this is due to the fact that one of the team members actually performs the functions of a manager.
So, how will the situation described above change, if we assume that there is still a PM on the project?
Rule # 1: Any problem becomes yours.
First of all, we found the owner of the problem: this is, in fact, PM. All techies can be sure that the problem is not with them, but the project manager is obliged to consider any problem of users as his personal problem.
Rule # 2: Users Never Lie
This is important to remember: no matter how insanely the report looks, especially if it is not the only one of its kind, truth is most likely written in it.
Rule # 3: You Can't Believe Anyone ... Except User
This thesis in the style of Dr. Hacus is very well explained in the situation in question: if you believe everyone who has bypassed the support, trying to achieve the truth, it turns out that no one has a problem. But we remember that users do not lie!
Rule # 4: Solve the problem from above
After we found out that there is a problem and it is ours, it would be nice to start solving it. It is always necessary to start from above, that is, from the place where the symptom appears. In our case, the symptom is that the user presses the button, and as a result receives the 500th error.
Of course, if we put a stub that hides the five hundredth answer from the Ajax-end from the user, this will not solve the problem (not to mention the fact that the user will sooner or later find out about it and, of course, complain). From this follows the fifth rule PMA.
Rule # 5: eliminate the symptom, not the symptom
In this situation, in order to get to the bottom of the cause, the manager goes to the maker-up and finds out in which cases he brings the five hundredth error to the UI. What will the maker-up respond to? "When I received the wrong answer from the server." - “Ok, and what answer did you get from the server?” - interested in PM. "Status 500", - responsible maker-up. Here we finally have some information: the user sees a five hundredth error when the server returns a response with code 500. If this is true (and we remember that no one can be trusted), you need to find out what happens to the server when it starts to behave that way.
Rule # 6: The Most Lazy Principle
Since the project manager must act on the basis of the principle of the most lazy, at this point you need to trust the client-side programmer and go further.
Rule # 7: The problem is the responsibility of the PM
How can conditional inexperienced PM act at this stage? Try to send a typesetter to the server programmer in the hope that "they will somehow agree there between themselves."
What happens if the developers provide themselves? The maker-up comes to the server programmer, reports the 500th error and receives the answer: "Oh, well, this is all the base." The maker-up agrees: "Well, yes, it is in the database." After that, both of them continue to program further - after all, the base is to blame for everything (and not the fact that this is true, but even if it is so, the user is no better off). After that, a day, two, a week passes ... All this time, the manager is piously convinced that the problem has been fixed. I'm sure until I receive another angry letter from tech support, in which the user complains about the same problem. At this moment our conditional PM thinks: “How so? But we figured it out! ” So he comes to the seventh rule of the project manager: I solve problems, other people are not obliged to solve them. Well, if you decide, but not obliged.
Therefore, a good project manager should go to the programmer himself in this situation.
Rule # 8: log each step
A programmer will naturally tell him that there is a mass reason for a five-hundredth error, but he does not have access to the logs from production, so he cannot figure out what is wrong. Here, a small lyrical digression is necessary: ​​the presence of logs greatly simplifies the life of both the developers and the manager. Lack of access to the logs from the programmer’s production is a solvable problem. The delivery of logs from production to the development network can be configured, and you need to motivate developers through admins using all available methods. They can be cleaned from cookies, user data and everything else superfluous, but the logs must come.
Consider the most hardcoding option: the manager at the project recently, no one has configured import of logs, and there is data from the production only at the production. Only one way out: go to admins and ask for logs. Suppose we are not so bad, and still have logs; however, in them it is succinctly written: “500” - and not another word.
Rule # 9: Do not forget the main thing.
The next mistake a manager can make is to tell the programmer: “Ok. Make logging ", and forget about the problem. Where it leads? First, the developer will not cover all the cases with logging, of course, and secondly, of course, he will forget about the initial problem during the development of the logging process.
The correct plan for behavior in this situation is this: get the developer to tell him what other services, databases and backends he goes, where an error may occur. After that, all possible cases should be carefully logged. If this problem is live, then you need to log quickly, and immediately roll out the hot fixes.
So, the logs are recorded, and from them it becomes clear that the service could not go to some database or to another service. At this point, there are two options: show the logs to the developer so that he can figure it out himself, or dive into the architecture and figure out everything yourself.
Once with the help of logs, admins and other improvised means the source of the problem is found, it is necessary to proceed directly to solving the problem. In our case, it can be either optimizing SQL queries or using an API, or something that is offensively simple: it’s possible that the error results from the fact that the developer goes to the authorization service and sends the wrong client IP to it.
Rule # 10: Make sure the symptoms disappear.
After the probable cause of the error is identified, the manager entrusts its decision to the person responsible for this section of the system. Now the most important thing is to make sure the symptoms are gone. You can verify this in only one way - ask the reporter for the bug if everything is OK. Only after this problem can be considered solved.
Ideal Manager in Vacuum
In my presentation, the project manager turned out to be a kind of superhero from IT, who does everything himself: he looks at the logs, he knows the architecture, and he can solve the problem if something happens. Such cases are, but, of course, it is not necessary. Mostly managers are surrounded by sane professionals who can themselves see and fix something. But, nevertheless, it is important to remember what we started with: developers tend to think that the problem is not on their side, but the project manager considers any user problem to be his pain. And acts accordingly.
Not technicians uniform
Another important conclusion from my story: the project manager does not have to be a techie. In order to say “I am responsible for any problem”, “users never lie” and “you can’t trust anyone”, you don’t need to have special technical skills. There is, of course, a benefit from the technical background - it builds the right direction in the brain and helps to understand when it is impossible to trust anyone - but this is not critical for the manager. In addition, often in the process of solving a problem, the task is so chewed up for developers that they themselves already understand how to solve it, and no management decisions are required.
In the following series
In this article, I shared my thoughts on how to solve problems on a project from the point of view of a project manager. PMA has many other interesting tasks: how to manage deadlines and risks, how to quickly and efficiently make new features. I will try to tell about it in the following articles.
Denis Anikin,
Technical Director Mail Mail.Ru
Everything works!
')
There is a popular belief that the problems are solved by the performers, and the managers only walk and interfere . However, what happens if there is no manager on the project? Imagine a situation: an angry letter comes to the support: “I pressed the button, and there is the 500th mistake!”. And the letter comes not one, that is, the problem is massive.
To give the bug? Suppose the support service assumes that the problem has occurred on the client side, and gives the bug to a JavaScript programmer. The JavaScript programmer looks at the description and says: “Most likely, the problem is on the server. I have nothing to do with this". The support officer nods and goes to the server programmer. The server programmer, in turn, declares that there are no problems on the server, the code is reliable, everything should work. Support goes to the admin. Admin looks at the CPU, disk, free space, logs, but also does not find anything criminal.
From this point on, the problem that has arisen on the project is, as it were, “on no one’s side”: no one considers himself responsible and does not consider it necessary to take up its solution. And everyone can be understood: everyone has his own task, a plan for development, and besides, it is much more interesting to cut new features than to deal with the mysterious five hundredths, which, well, certainly not through your fault. As a result, all the good people and busy business - only the user is still bad.
Of course, this is not the only possible course of development of the scenario. There are teams in which there is no person with the post of project manager, but problems, however, are solved. However, this is due to the fact that one of the team members actually performs the functions of a manager.
So, how will the situation described above change, if we assume that there is still a PM on the project?
Rule # 1: Any problem becomes yours.
First of all, we found the owner of the problem: this is, in fact, PM. All techies can be sure that the problem is not with them, but the project manager is obliged to consider any problem of users as his personal problem.
Rule # 2: Users Never Lie
This is important to remember: no matter how insanely the report looks, especially if it is not the only one of its kind, truth is most likely written in it.
Rule # 3: You Can't Believe Anyone ... Except User
This thesis in the style of Dr. Hacus is very well explained in the situation in question: if you believe everyone who has bypassed the support, trying to achieve the truth, it turns out that no one has a problem. But we remember that users do not lie!
Rule # 4: Solve the problem from above
After we found out that there is a problem and it is ours, it would be nice to start solving it. It is always necessary to start from above, that is, from the place where the symptom appears. In our case, the symptom is that the user presses the button, and as a result receives the 500th error.
Of course, if we put a stub that hides the five hundredth answer from the Ajax-end from the user, this will not solve the problem (not to mention the fact that the user will sooner or later find out about it and, of course, complain). From this follows the fifth rule PMA.
Rule # 5: eliminate the symptom, not the symptom
In this situation, in order to get to the bottom of the cause, the manager goes to the maker-up and finds out in which cases he brings the five hundredth error to the UI. What will the maker-up respond to? "When I received the wrong answer from the server." - “Ok, and what answer did you get from the server?” - interested in PM. "Status 500", - responsible maker-up. Here we finally have some information: the user sees a five hundredth error when the server returns a response with code 500. If this is true (and we remember that no one can be trusted), you need to find out what happens to the server when it starts to behave that way.
Rule # 6: The Most Lazy Principle
Since the project manager must act on the basis of the principle of the most lazy, at this point you need to trust the client-side programmer and go further.
Rule # 7: The problem is the responsibility of the PM
How can conditional inexperienced PM act at this stage? Try to send a typesetter to the server programmer in the hope that "they will somehow agree there between themselves."
What happens if the developers provide themselves? The maker-up comes to the server programmer, reports the 500th error and receives the answer: "Oh, well, this is all the base." The maker-up agrees: "Well, yes, it is in the database." After that, both of them continue to program further - after all, the base is to blame for everything (and not the fact that this is true, but even if it is so, the user is no better off). After that, a day, two, a week passes ... All this time, the manager is piously convinced that the problem has been fixed. I'm sure until I receive another angry letter from tech support, in which the user complains about the same problem. At this moment our conditional PM thinks: “How so? But we figured it out! ” So he comes to the seventh rule of the project manager: I solve problems, other people are not obliged to solve them. Well, if you decide, but not obliged.
Therefore, a good project manager should go to the programmer himself in this situation.
Rule # 8: log each step
A programmer will naturally tell him that there is a mass reason for a five-hundredth error, but he does not have access to the logs from production, so he cannot figure out what is wrong. Here, a small lyrical digression is necessary: ​​the presence of logs greatly simplifies the life of both the developers and the manager. Lack of access to the logs from the programmer’s production is a solvable problem. The delivery of logs from production to the development network can be configured, and you need to motivate developers through admins using all available methods. They can be cleaned from cookies, user data and everything else superfluous, but the logs must come.
Consider the most hardcoding option: the manager at the project recently, no one has configured import of logs, and there is data from the production only at the production. Only one way out: go to admins and ask for logs. Suppose we are not so bad, and still have logs; however, in them it is succinctly written: “500” - and not another word.
Rule # 9: Do not forget the main thing.
The next mistake a manager can make is to tell the programmer: “Ok. Make logging ", and forget about the problem. Where it leads? First, the developer will not cover all the cases with logging, of course, and secondly, of course, he will forget about the initial problem during the development of the logging process.
The correct plan for behavior in this situation is this: get the developer to tell him what other services, databases and backends he goes, where an error may occur. After that, all possible cases should be carefully logged. If this problem is live, then you need to log quickly, and immediately roll out the hot fixes.
So, the logs are recorded, and from them it becomes clear that the service could not go to some database or to another service. At this point, there are two options: show the logs to the developer so that he can figure it out himself, or dive into the architecture and figure out everything yourself.
Once with the help of logs, admins and other improvised means the source of the problem is found, it is necessary to proceed directly to solving the problem. In our case, it can be either optimizing SQL queries or using an API, or something that is offensively simple: it’s possible that the error results from the fact that the developer goes to the authorization service and sends the wrong client IP to it.
Rule # 10: Make sure the symptoms disappear.
After the probable cause of the error is identified, the manager entrusts its decision to the person responsible for this section of the system. Now the most important thing is to make sure the symptoms are gone. You can verify this in only one way - ask the reporter for the bug if everything is OK. Only after this problem can be considered solved.
Ideal Manager in Vacuum
In my presentation, the project manager turned out to be a kind of superhero from IT, who does everything himself: he looks at the logs, he knows the architecture, and he can solve the problem if something happens. Such cases are, but, of course, it is not necessary. Mostly managers are surrounded by sane professionals who can themselves see and fix something. But, nevertheless, it is important to remember what we started with: developers tend to think that the problem is not on their side, but the project manager considers any user problem to be his pain. And acts accordingly.
Not technicians uniform
Another important conclusion from my story: the project manager does not have to be a techie. In order to say “I am responsible for any problem”, “users never lie” and “you can’t trust anyone”, you don’t need to have special technical skills. There is, of course, a benefit from the technical background - it builds the right direction in the brain and helps to understand when it is impossible to trust anyone - but this is not critical for the manager. In addition, often in the process of solving a problem, the task is so chewed up for developers that they themselves already understand how to solve it, and no management decisions are required.
In the following series
In this article, I shared my thoughts on how to solve problems on a project from the point of view of a project manager. PMA has many other interesting tasks: how to manage deadlines and risks, how to quickly and efficiently make new features. I will try to tell about it in the following articles.
Denis Anikin,
Technical Director Mail Mail.Ru
Source: https://habr.com/ru/post/198702/
All Articles