Stages of solving the problem

I decided to write an article after reading this . It seems that there was a lot in it, but on the other hand, you understand that it is impossible to react emotionally to bugs and deadlines. So what's the problem?

All the stages below are invented by me based solely on my work experience. For illustration with examples, we will use three situations:

1. A new problem appeared in the bug tracker.
2. The developer received a complaint from the customer
3. The product does not have time to go on time

Stage one, is there a problem?

Behavior of participants : rational.
The first thing we do when we hear about the problem - we are trying to make sure that it exists - to reproduce, check the project performance schedule. This is not a denial of the problem, just a test. After all, if there is no problem, then there is nothing to solve.

Examples:

1. A new problem has appeared in the bug tracker. We are trying to reproduce
2. The developer received a complaint from the customer. It would be necessary to check if there was a letter with a modified header “from whom”, but most likely there is a problem.
3. The product does not have time to go on time. It all depends on where you get this information from - if these are thoughts of an accountant offended at IT, this is one thing. But if a timlid came to confess - we definitely have a problem

')

Stage Two, What is the problem?

Behavior of participants : rational.
It is necessary to determine exactly what the problem is - the server is incorrectly configured by the toli, or the user has not dropped the cache, or the customer has personal accounts with the developer. This stage should smoothly flow into the fourth, but, unfortunately, usually go to the third.

Examples:

1. A new problem appeared in the bug tracker. If the tester added a bug, then he had to describe the conditions of occurrence. If the user added it, we determine when the bug appears.
2. The developer received a complaint from the customer. We find out what events preceded this, read the text of the letter.
3. The product does not have time to go on time. You need to understand what part of the product is lagging behind or what org. issues are not resolved

Stage Three Who is to blame?

Behavior of participants : emotionally.
The eternal Slavic question :). It is at this stage that the nerves begin and everything else described here . My personal opinion is to avoid it with all your efforts, because no productive decisions are made at this stage, but a huge amount of energy is spent. And in general - you want to embroil the team - look for the guilty. But the most unbelievable act that I saw was to calm down at this stage - and that, the guilty ones were found, you can safely live on, why should you solve the problem?

Examples:

1. In the bug tracker, a new problem appeared Aaa, again Vasya has a double block!
2. The developer received a complaint from the customer. But what am I to blame for, that these assholes called at one o'clock at night?
3. The product does not have time to go in time Yeah, we all know how our IT department works!

Stage Four, what to do?

Behavior of participants : rational. But if you start right after the third stage, it can be emotional.
If you still could not resist, and found guilty, be sure to cool off before this stage, otherwise you will make problems.
If we can think logically, then we understand in more detail the causes of the problems, and if they can be eliminated, we choose a solution path. If it is impossible, we are trying to change something so that these problems do not exist - we cut off the functionality, revise the list of partners, etc.

Examples:

1. A new problem appeared in the bug tracker. So, it seems like an error in this section of the code, but you should check with Vasya.
2. The developer received a complaint from the customer Vasya, it seems you just misunderstood ...
3. The product does not have time to go on time. Critical for us is * functional *, it seems to be ready. Let's remove the rest, first release, all the same

Stage Five, Problem Solving

Behavior of participants : rational
Just doing the planned earlier. If the stage is delayed, then rescheduling may be required.

Examples:

1. A new issue has appeared in the bug tracker
2. The developer received a complaint from the customer. We apologize to the customer, conduct a conversation with Vasya.
3. The product does not have time to reach the deadline. We agree with the product managers change, redistribute efforts.

Stage Six, Whip and Gingerbread, or "Whose Fault" -2

Behavior of participants : rational

We have already talked about finding the guilty, and came to the conclusion that this is an empty idea. However, it is often necessary to respond to the constant mistakes of an employee, or vice versa, to reward them for good work. The main thing is not to take everything to the court of the collective, not to arrange a witch hunt. In addition, at this stage, it often turns out that the problem is not as significant as it seemed to us in the first stages, and there is simply no point in punishing the guilty one (who, perhaps, did everything himself).

Examples:

1. In the bug tracker, a new problem appeared. Vasya was busy on another project, but Peter stayed after work and fixed everything. Give him a bonus
2. We received a complaint from the customer’s developer. We’re scribbling Vasya for being rude and promising that next time there will be a fine.
3. The product does not have time to go out in time. The case is the most serious, so maybe you will have to dismiss someone

What is the result? It is very simple - most of the stages are quite logical and rational. They pass without stress. But there is one stage, which unfortunately is very fond of us - it is to look for the guilty, instead of solving the problem. If you can get away from it - work will become much more comfortable.