October 23, 2013 at 14:21Problem Solving: 10 Manager Rules
Consider the following situation: you are a project manager, and a problem has arisen on your project. About how to gradually reach the source of the problem and eliminate it, I will describe in detail in today's article.
Everything works!
There is a common belief that executors solve problems, and managers only walk and get in the way . However, what happens if there is no manager on the project? Imagine a situation: an angry letter arrives in support: “I pressed the button, and there’s the 500th error!” Moreover, the letter comes not one, that is, the problem is massive.
Who should I give the bug to? Suppose support assumes that the problem occurred on the client side and gives the bug to the JavaScript programmer. The JavaScript programmer looks at the description and says: “Most likely, the problem is on the server. It's not my fault". The technical support nods and goes to the server programmer. The server programmer, in turn, states that there are no problems on the server, the code is reliable, everything should work. Support goes to the administrator. The admin looks at the processor, disk usage, free space, logs, but also does not find anything criminal.
From this moment on, the problem that arose on the project was, as it were, “on neither side”: no one considers himself responsible and does not consider it necessary to take on its solution. And everyone can understand: everyone has their own missions, a development plan, besides sawing new features is much more interesting than sorting out the mysterious five hundredth, which certainly doesn’t appear through your fault. As a result, all well done and busy - that's just the user is still bad.
Of course, this is not the only possible scenario development course. There are teams in which there is no person with the post of project manager, but problems, nevertheless, 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 are still PMs 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 user problem as his personal problem.
Rule # 2: users never lie
This is important to remember: no matter how crazy the report looks, especially if it is not the only one of its kind, the truth is most likely written in it.
Rule # 3: Do not trust anyone ... except the user
This thesis in the style of Dr. House is very well explained in the situation under consideration: if you believe everyone who 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: we 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. You must always 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 find out about it sooner or later and, of course, complain). From this follows the fifth rule of PMa.
Rule # 5: eliminate the symptom and the cause
In the situation under consideration, in order to get to the bottom of the reason, the manager goes to the layout designer and finds out in which cases he displays the five hundredth error on the UI. What will the layout designer answer? "When I got the wrong answer from the server." - “Well, what kind of response did you get from the server?” - PM is interested. “Status 500,” the layout designer replies. Here we finally get some information: the user sees the 500th error when the server returns a response with the 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 begins to behave like that.
Rule # 6: The principle of greatest laziness
Since the project manager should act on the basis of the principle of greatest laziness, at this point you need to trust the client-side programmer and go further.
Rule # 7: the problem is the area of responsibility of the PM
How can a conditional inexperienced PM act at this stage? Try to send a layout designer to the server programmer in the hope that "they will somehow agree among themselves there."
What happens if developers are left to their own devices? The typesetter comes to the server programmer, reports the 500th error and receives the answer: “Ah, well, that's all the base.” The typesetter agrees: “Well, yes, the point is in the database.” After that, both diverge further to program - because the base is to blame for everything (and not the fact that this is true, but even if so - the user is not easier on this). After that, a day, two, a week passes ... All this time the manager is firmly convinced that the problem has been fixed. I am 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 found 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 they decide, but not required.
Therefore, a good project manager should go to the programmer in this situation.
Rule # 8: we log every step.
The programmer will naturally tell him that there are a lot of reasons for the five hundred error, and he has no access to the logs from production, so he is not able to find out what is the matter. A slight digression is needed here: the presence of logs greatly simplifies the life of both developers and the manager. The lack of access to the logs from production by the programmer is a solvable problem. Log delivery from production to the development network can be configured, and you need to motivate developers through the admins to organize it using admins. They can be cleaned from cookies, user data and everything else superfluous, but the logs must come.
Consider the most hardcode option: a project manager recently, nobody configured log import, and there is data from production only on production. There is only one solution: go to the admins and ask for the logs. Suppose we are not all so bad, and there are still logs; however, they are succinctly written: "500" - and not a word more.
Rule # 9: do not forget about the main
thing. The next mistake that a manager can make is to tell the programmer: “Ok. Make logging, ”and forget about the problem. Where it leads? Firstly, the developer will not cover all cases with logging, of course, and secondly, in the process of developing logging, he, of course, will forget about the initial problem.
The correct plan of behavior in this situation is as follows: get the developer to tell him what other services, databases and backends he goes to, where an error may occur. After that, all possible cases must be carefully pledged. If this problem is alive, then you need to log quickly, and immediately roll out hot fixes.
So, the logs are recorded, and from them it becomes clear that the service could not go to some database or other service. At this moment, there are two options: show the logs to the developer so that he can figure it out himself, or immerse yourself in the architecture and find 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 go directly to solving the problem. In our case, it can be either optimization of SQL queries or using the API, or something offensively simple: perhaps the error appears as a result of the developer going to the authorization service and sending the wrong client IP there.
Rule # 10: make sure that the symptoms have disappeared
After the probable cause of the error has been identified, the manager will delegate its decision to the person responsible for this part 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 bug reporter if everything is OK. Only after this can the problem be considered resolved.
The perfect manager in a 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 do occur, but, of course, this is not necessary. Mostly managers are surrounded by sane professionals who themselves can see and fix something. But, nevertheless, it is important to remember where we started: developers are inclined to believe that the problem is not on their side, and the project manager considers any user problem as his pain. And it acts accordingly.
Not techies single
Another important conclusion from my story: the project manager does not have to be a techie. In order to say to myself “I am responsible for any problem”, “users never lie” and “no one should be trusted”, one does not need to have special technical skills. Of course, there is a benefit from the technical background - it builds the brains in the right direction and helps to understand when exactly one cannot be trusted - but this is not critical for the manager. In addition, often in the process of solving the problem, the task is so chewed up for the developers that they themselves already understand how to solve it, and no management decisions are required.
In the next series
In this article, I shared my thoughts on resolving problems on a project from the perspective 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 this in the following articles.
Denis Anikin,
Technical Director of Mail.Ru Mail
Everything works!
There is a common belief that executors solve problems, and managers only walk and get in the way . However, what happens if there is no manager on the project? Imagine a situation: an angry letter arrives in support: “I pressed the button, and there’s the 500th error!” Moreover, the letter comes not one, that is, the problem is massive.
Who should I give the bug to? Suppose support assumes that the problem occurred on the client side and gives the bug to the JavaScript programmer. The JavaScript programmer looks at the description and says: “Most likely, the problem is on the server. It's not my fault". The technical support nods and goes to the server programmer. The server programmer, in turn, states that there are no problems on the server, the code is reliable, everything should work. Support goes to the administrator. The admin looks at the processor, disk usage, free space, logs, but also does not find anything criminal.
From this moment on, the problem that arose on the project was, as it were, “on neither side”: no one considers himself responsible and does not consider it necessary to take on its solution. And everyone can understand: everyone has their own missions, a development plan, besides sawing new features is much more interesting than sorting out the mysterious five hundredth, which certainly doesn’t appear through your fault. As a result, all well done and busy - that's just the user is still bad.
Of course, this is not the only possible scenario development course. There are teams in which there is no person with the post of project manager, but problems, nevertheless, 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 are still PMs 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 user problem as his personal problem.
Rule # 2: users never lie
This is important to remember: no matter how crazy the report looks, especially if it is not the only one of its kind, the truth is most likely written in it.
Rule # 3: Do not trust anyone ... except the user
This thesis in the style of Dr. House is very well explained in the situation under consideration: if you believe everyone who 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: we 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. You must always 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 find out about it sooner or later and, of course, complain). From this follows the fifth rule of PMa.
Rule # 5: eliminate the symptom and the cause
In the situation under consideration, in order to get to the bottom of the reason, the manager goes to the layout designer and finds out in which cases he displays the five hundredth error on the UI. What will the layout designer answer? "When I got the wrong answer from the server." - “Well, what kind of response did you get from the server?” - PM is interested. “Status 500,” the layout designer replies. Here we finally get some information: the user sees the 500th error when the server returns a response with the 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 begins to behave like that.
Rule # 6: The principle of greatest laziness
Since the project manager should act on the basis of the principle of greatest laziness, at this point you need to trust the client-side programmer and go further.
Rule # 7: the problem is the area of responsibility of the PM
How can a conditional inexperienced PM act at this stage? Try to send a layout designer to the server programmer in the hope that "they will somehow agree among themselves there."
What happens if developers are left to their own devices? The typesetter comes to the server programmer, reports the 500th error and receives the answer: “Ah, well, that's all the base.” The typesetter agrees: “Well, yes, the point is in the database.” After that, both diverge further to program - because the base is to blame for everything (and not the fact that this is true, but even if so - the user is not easier on this). After that, a day, two, a week passes ... All this time the manager is firmly convinced that the problem has been fixed. I am 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 found 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 they decide, but not required.
Therefore, a good project manager should go to the programmer in this situation.
Rule # 8: we log every step.
The programmer will naturally tell him that there are a lot of reasons for the five hundred error, and he has no access to the logs from production, so he is not able to find out what is the matter. A slight digression is needed here: the presence of logs greatly simplifies the life of both developers and the manager. The lack of access to the logs from production by the programmer is a solvable problem. Log delivery from production to the development network can be configured, and you need to motivate developers through the admins to organize it using admins. They can be cleaned from cookies, user data and everything else superfluous, but the logs must come.
Consider the most hardcode option: a project manager recently, nobody configured log import, and there is data from production only on production. There is only one solution: go to the admins and ask for the logs. Suppose we are not all so bad, and there are still logs; however, they are succinctly written: "500" - and not a word more.
Rule # 9: do not forget about the main
thing. The next mistake that a manager can make is to tell the programmer: “Ok. Make logging, ”and forget about the problem. Where it leads? Firstly, the developer will not cover all cases with logging, of course, and secondly, in the process of developing logging, he, of course, will forget about the initial problem.
The correct plan of behavior in this situation is as follows: get the developer to tell him what other services, databases and backends he goes to, where an error may occur. After that, all possible cases must be carefully pledged. If this problem is alive, then you need to log quickly, and immediately roll out hot fixes.
So, the logs are recorded, and from them it becomes clear that the service could not go to some database or other service. At this moment, there are two options: show the logs to the developer so that he can figure it out himself, or immerse yourself in the architecture and find 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 go directly to solving the problem. In our case, it can be either optimization of SQL queries or using the API, or something offensively simple: perhaps the error appears as a result of the developer going to the authorization service and sending the wrong client IP there.
Rule # 10: make sure that the symptoms have disappeared
After the probable cause of the error has been identified, the manager will delegate its decision to the person responsible for this part 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 bug reporter if everything is OK. Only after this can the problem be considered resolved.
The perfect manager in a 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 do occur, but, of course, this is not necessary. Mostly managers are surrounded by sane professionals who themselves can see and fix something. But, nevertheless, it is important to remember where we started: developers are inclined to believe that the problem is not on their side, and the project manager considers any user problem as his pain. And it acts accordingly.
Not techies single
Another important conclusion from my story: the project manager does not have to be a techie. In order to say to myself “I am responsible for any problem”, “users never lie” and “no one should be trusted”, one does not need to have special technical skills. Of course, there is a benefit from the technical background - it builds the brains in the right direction and helps to understand when exactly one cannot be trusted - but this is not critical for the manager. In addition, often in the process of solving the problem, the task is so chewed up for the developers that they themselves already understand how to solve it, and no management decisions are required.
In the next series
In this article, I shared my thoughts on resolving problems on a project from the perspective 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 this in the following articles.
Denis Anikin,
Technical Director of Mail.Ru Mail