- Hello!
- Hello!
- Tell me, what is it like to do technical support?
- Well, oh, imagine a bicycle ... and it burns ... and you burn ... and the road burns ... and in general, you are in hell ...

(c) author unknown

It doesn’t matter who you are, a beginner or an experienced manager, each of us has come up against a situation where there are many tasks, they come from different sources and there’s no end to this. Even as a “control shot,” someone asks to do everything yesterday. Did you recognize yourself in this paragraph? Then this article will help you.

I will tell you what major problems I encountered in my work, when I was just transferred to the management of technical support, where these problems have gone and how we live now, after 3 years. Speaking more simply, some of the techniques and principles of Kanban helped me personally and the team as a whole to significantly reduce the burden on specialists.

What were the problems?

The most common for project management in the field of IT (and not only):
')

• large task lists;
  
• customized managers;
  
• a huge number of sources of these tasks;
  
• deadlines;
  
• resentment at all.
  

Ha, what's so scary ?! You take the task and do it - that's all magic with a rabbit. So, yes, but it just seems that "we had defective hares."

New tasks arrived every day, and the lifetime of old ones increased exponentially. At each specialist, the number of tasks was measured in dozens and there was no end in sight.

Everyone who was involved in the chain suffered, from the programmer to the client, who, it seemed to us, was washing with our tears (in fact, I believe that he was even worse than us, and we sincerely did everything possible at that moment ).

What solutions have been taken

Naturally, it was clear to us that this could no longer continue and that something needs to be corrected. Found the strength and began to look for solutions.

Below I will briefly tell you about a couple of the “coolest” options and one good one.

Plan for 7-14 days with a deadline

Yes, there were fools, but the experience is useful.

What is the essence of the idea:

• for each task, they figured out how much time it would take in man-hours;
  
• a specific list of tasks was assigned to each date within the next 2 weeks;
  
• this list was formed on the basis of the total time that was supposed to be spent, and the available working time (we have this actual 7 man-hours);
  
• the tasks themselves are immediately assigned to specialists so that they can be completely hammered for 7 hours by work.
  

Cool! Now we have a clear plan and we know what task it will be when it is done! Here it is - salvation!

A day after these words came “managerial blood pressure”.

Some lyrics.
The specifics of technical support (at least for us) with many different projects is such that you never have a finite list of scheduled tasks (backlog) for the coming week. Even backlog for 3 days is something from the category of fiction. At any time a task can arrive that needs to be done right now (sometimes it is justified, sometimes it is not, but this is not the point).

And now, what exactly do I mean by "managerial hell."



The newly created “here and now” task completely broke the whole plan. Not only did you have to move tasks for the current day , you had to shift tasks for all 2 weeks . It is logical, because if this is not done, then the specialist would have a list that exceeds 7 people / hours per day, but for us in this case it was unacceptable.

A monstrous amount of time and effort, both mental and physical, was spent on these movements.

From this, any request from managers was perceived “in hostility”, and any new task became a disaster.

Perhaps this is the “coolest” solution we tried to work on.

Forming a task list for specialists based on categories

The universe explained relatively timely (it could have been earlier) that for constantly arriving tasks it is not an option to set specific execution times and build on the basis of this long-term plan. Accepted, understood, refused it.

But after all, in the general list of programmers you will not run, the poor fellows will be lost. Just to avoid this, we came up with a system of categories for tasks (small, medium, large and very large) and began to distribute everything into categories.

What is the essence of the idea:

• according to an approximate preliminary assessment, we assign a category to the task - small, medium, large and very large;
  
• each category has its own constant average lead time , something similar to Story Points (or maybe they were);
  
• each specialist is formed his own separate list of tasks based on a combination of categories. For example: 4 small + 2 medium; 3 small + 1 large; 6 small; 1 very large, etc.
  
• and so for the next 3 days (the plan is needed, at least the most crooked).
  

Hurray, finally! Guys, we have everything get-and-and ... Here somewhere Cosmos reloaded its gun and began to shoot at us. What was wrong with that decision?

1. Late began to maintain a database of standard tasks to simplify the assignment of categories.
   
2. We had to follow the queues at each individual specialist (although it took relatively less time than moving several times a day to the release date).
   
3. The problem with urgent tasks out of turn did not go anywhere - they still forced them to reshape the lists.
   

It seems to be a good solution. Slightly better than the first option, but still not flexible in terms of emerging urgent and important tasks.

Technique based on the pull system (Kanban)

Quite by chance, I got to one free hour webinar dedicated to Agile and some methods based on it (of course, it was advertising courses). And now, only after the main part, someone mentioned Kanban as a well-established technique for technical support and not only.

Inspired by the new information, the days of reading about this miracle of management began. We got the information, now we are ready for the experiment with the (current) method adapted for us.

What is the essence of the idea:

• specialists do not have their own line;
  
• all tasks that are ready for work are moved to a common queue ;
  
• the current Plan is formed from this Queue . The plan is a list of tasks that does not have an end date and is relevant at the moment, at this second;
  
• Tasks fall into the current Plan on the basis of their own priorities. manager (the life of the task, urgency, etc.);
  
• the Plan has a limit on the number of tasks in it;
  
• all unit specialists see the same current plan ;
  
• after the completion of the current task, the specialist pulls out the next highest one and so on.
  

Good! They invented, they told everyone how to do it, we look. Guys, ah, seriously ?!

What were the results after 1.5 calendar weeks:

1. We have reduced the number of current tasks on Development alone from 75 to 25 !!! And this provided that the incoming task flow remained the same.
   
2. Reduced the amount of negative about the timing
   
3. In the process of flexibility
   

And this is just what was immediately visible.

And how did it happen that everything more or less earned? My thoughts on this are:

• Programmers have ceased to choose the most understandable task in their work. Now the manager managed to queue and put in the Plan only the most necessary tasks at the moment (this is the key moment).
  
• Such a pull directly affected the reduction of negativity on the part of managers and clients. Why? Yes, because there are no equally urgent tasks on the same project and the negative is most likely provoked the most valuable at the moment.
  
• Flexibility and grace like a cat, and sometimes potato dexterity - the pull system allowed us to respond to important and urgent tasks without losing or wasting time on changing the queue. We translate the necessary task into the Plan and remove from it a more recent one (remember about the restriction in the Plan?).
  

Results

If you encounter a large flow of tasks, even from a single source, and do not feel that the bike is burning more than we would like, then turn your eyes to Kanban. Based on the principles of this technique, it can be quite painlessly implemented in current business processes.

At the moment we have adapted the stretching system to fit our needs, normalized the delivery of releases. Of course, “zapary” also happens, but after some time the system comes to a relative norm based on current capabilities.

It is also worth understanding that Kanban is not only a “dry” method, but also a system of values ​​and principles that are aimed at continuous improvement and adaptation of current processes. There is no limit to perfection, so just go ahead!