Task life cycle

About task management, everyone knows everything for a long time. Unfortunately, or fortunately, there is nothing special to know. On any advice, methodology, practice, there will be hundreds, if not thousands of comments, tips and links, where the same information will be told in more detail, more interesting, more colorful and "based on a scientific approach."

But, despite the volume of knowledge, there are no fewer problems in practice. You talk, for example, with the project manager - like he should know everything about task management. Well, yes, like everyone knows. You look at the system in which he works - and awkwardly shut up. Why are you, dude, such, with such a volume of knowledge, again, once again, already a million times, you turn people's activities into uncontrollable kissel?

Hang tasks for more than a year. Why hang? Starts to go, read. And, it was done long ago, it is necessary to close it. Oh, and this is no longer necessary, the customer has long been dismissed. Uh, and this is a cool task, it is strange that we looked at it. Why doesn't this one move? The developer asked questions, and the customer did not answer? Does he know what to answer? Damn, you need to check the alert system.

In the management of tasks, not knowledge is important, but practice, the embodiment of knowledge in routine, daily work. The key difference between tasks, as entities, or natural phenomena, is endless. I mean, never run out. It is the subconscious desire to “do all this and forget all as soon as possible”, when it does not come true (= always), pushes people away from task management, forcing them to switch to the “everything will somehow work itself out” mode.

I myself sometimes fall into the same condition, although I know how harmful it is. Then I am convinced, on figures, that because of the Non-management of tasks, I, or the team, or the whole company slipped twice, and even three times. This is the price of not following the elementary rules in handling tasks. This is the incentive to follow the rules, the fulfillment of which increases the number (and / or weight) of solved tasks 2-4 times.

The rules are simple, clear to everyone, they just need to follow.

Life cycle

The essence of all the rules is the same - the task has a life cycle, which it must live through. All problems arise due to the fact that the task hangs at some stage of this cycle, does not move further and, as a result, does not end. Similarly, psychology recommends dealing with stress - to complete its cycle in one way or another, otherwise it also “hangs” and spoils life. For example, go through a stressful situation, experience fear, etc.

The life cycle of a task in a simplified form looks like this: setting - execution - closing. If we confine ourselves to these three states, then we are faced with problems, because it is not clear how the task moves between states.

For example, we work with a customer on tasks using private repositories in a githaba. Customer representatives write issues (issues), i.e. carry out the production - the first stage of the life cycle. It seems everything is simple - take it and do it.

But just take and do not work. First, there are a lot of tasks - tens, hundreds at the same time. We need the rules of choice - what to do first. Secondly, the statement is not always clear, you need to ask clarifying questions. Thirdly, we do not always agree that the task should be done (it can be a duplicate or already solved earlier).

There are many difficulties, the result is one - the task is in an incomprehensible state. It seems to be recorded, but the performance does not go. We ask a question about the task, the customer does not respond. The task now in what condition? We wrote that there was already a solution, gave a link. The customer does not respond, the task does not close. What state is it in? Unclear.

This “incomprehensible” causes a lot of problems. The developer, entering the list of such tasks, sometimes just does not understand what to do. At first, the task can not choose. When he nevertheless chooses, he cannot understand whether it should be done or not - maybe the discussion has not ended yet. When done, wrote a comment in the task, the customer does not check. Again it is not clear.

It is clear that only two states of the task are set (appeared in the open list) and closed (turned into closed).

How exactly to control and manage the life cycle of the task, everyone already knows - through the status system. There are at least two options for implementing statuses in a githaba — via labels (labels) and via milestones (milestones). Probably, status management is in any system, so the rules can be considered universal.

Task statuses

There should be exactly as many statuses as you need for a specific situation. There is no "correct" or "universal" set of statuses. The main condition is that everyone should know exactly who, what and when to do with a task of a certain status.

It sounds a bit strange, but with the task, at different times, you need to do different actions to different people. At one point you need an encoder writing code. At another point, you need a tester that checks the result. In the third point, you need a customer testing on their data. At the fourth moment, a manager is needed who constantly reminds the customer of the need to close the task.

Depending on the status, the approaches to working with tasks also differ. Elementary, when the task is for execution, one person works with it. Or vice versa - one person works with one task. I chose from the list, or the system of priorities I chose, sat down and done.

In a status like “not yet taken to work” the approach is different - one person works with several tasks. In each comes, reads, and makes a decision. One task should be sent for revision, asking questions to the customer. Another task must be taken for execution, write a comment for the artist and change the status.

In the status of "completed, waiting for verification by the customer," nothing particularly needs to be done, just to follow the deadlines. If done yesterday, you can do nothing. If 3 days have passed, you need to write a comment to remind the customer of the need for verification. If a month has passed, then it’s time to write to the customer’s manager, in order to get ordinary professionals to work.

It seems everything is clear, thanks cap. But differences in approaches, depending on the status, should give rise to differences in processes, in the choice of algorithm, mode, and even the time of day for such work.

For example, with tasks in statuses requiring batch processing, it makes no sense to work several times a day. It is much easier and more efficient to deal with them in the morning, spending half an hour, or even less. If you do not follow this rule, you will have to be distracted several times during the day - for example, to a new task that has arrived. The cost of distraction turns out to be unreasonably high (it stopped performing the current one — read a new one — penetrated — answered something — changed status — returned to the current — but no, we had to smoke — and now drink coffee — but what about coffee afterwards?).

No matter how silly it sounds, but for tasks in different status different energy is needed. I am not an expert in energy, I define it intuitively, but I feel the difference keenly. Popin customers to check the work performed - one thing. Programming is completely different.

Let's go through a short status.

The status of "task set"

This status is automatically assigned to any incoming task. Usually where I worked, there are two sources of tasks: customers (internal or external) and a team (developers, manager).

The main problem here is probably that not all tasks fall into this status. Simply put, not all tasks are recorded.

Despite the widespread use of automated task management systems, the problem of unrecorded tasks is still very relevant.

Someone asked to do something at a meeting, or Skype conference. Someone came up in the smoking room. Someone looked into the office and started telling what he needed to do there.

Especially often the tasks remain unwritten in factories where there are many people who do not want to work with computers. There can also be attributed to "cool managers" who believe that with one word addressed to the programmer they have already honored him. Accordingly, he should listen carefully and “write down the task to his shitty system”.

A separate stream of lost tasks is all kinds of electronic communications outside the system, mainly mail and instant messengers. Yes, there are bots, there are in many systems autoload mail. But they will not solve the problem 100%.

Tasks need to be recorded. Customers of all kinds need to force tasks to write. Not immediately, gradually, but to accustom to the thought: if the task is not written down properly, it will not be solved. No offense.

A separate line would like to mention the developers who do not write down the tasks, but are taken to do them. This is an incredible thing, because there is a second, uncontrollable work flow. Customers get used to the fact that, despite the announced rules, there is always a fallback - “get out, Kolyan, a normal guy, without any crap, he takes and does.” And if the manager, or team leader, tries to manage efficiency on the basis of the recorded tasks, then the presence of the second stream will bring his efforts to naught.

The task from the “Delivered” status should move to another - “sent for revision” or “accepted for work”. In bureaucratic systems, coordination is still added — for example, the head of the IT department, or the head of the customer’s unit, or related departments, if their processes are affected.

Status "Sent for revision"

If the customer is cotton (and there are most of them), then such status is vital. He throws a stone in the customer's garden - makes him responsible for the plot of the fate of the task. Of course, sending for revision should be accompanied by a normal commentary or a question, so that it is clear what the reason is and what needs to be done.

Without this status, the performers, the entire department, become, in the eyes of the others, such terpils who can “throw tasks”, according to the principle “sent and forgotten”. If the task is automatically considered accepted, the quality of the performance will begin to decline rapidly, as will the performance of the performers.

The customer must understand his responsibility in solving the problem. Having the status of "sent for revision" helps to raise this responsibility.

There are two ways out of the “sent for revision” status: either back to “Delivered” or “floppy” - the customer can make such a decision if the performers' comments have convinced him that the task should not be solved (for example, if he asks for duplicate functionality) .

Of course, you should not get involved in sending in the revision without a reason.

Status "Accepted in work"

It's all clear. Accepted to work - we will do. How, when, in what order is another topic, not related, in fact, to the life cycle of the task.

The task adopted in the work has two paths: “Done” and again “Sent for revision”. It is clear that in the process of execution it may turn out that the task should not be done anyway. Or it is impossible to do (although it seemed possible at the acceptance). Or too expensive. Or in the course of execution it turned out that a similar functionality appeared in one of the used modules of external suppliers.

But the main way, of course, is “Done.”

Status "Completed"

When the task is marked as completed, the responsibility again passes to the customer - he must check the result on his data. At this point, there are many variations with intermediate statuses, such as internal testing by the developer, the work of an individual tester, documentation, etc., but for simplicity, I will skip these steps.

In the status of "completed" hangs a lot of tasks. The reason is simple - the customer has already received the result (if he is in production), and it is banal to be lazy to perform any additional actions. It works the same, what else is needed.

But for performers, and especially - for their manager - the transfer to the status “accepted by the customer” is extremely important. Often depends on his income. Yes, and trite - the task must leave the list, otherwise it will quickly swell, as well as the cost of its administration. It’s one thing to move 10 tasks, quite another to 100.

The task of the “Completed” status has two ways - either it will be accepted by the customer, and its life cycle will end, or it will be returned to the performer if the result was unsatisfactory.

Lifecycle Management

Manage the life cycle i. change the status of the task, you can in different ways. You probably have a wealth of experience of such work. I will add my own to the piggy bank. The main thing here, I repeat, is not to know, but to do.

Setting goals

The first thing to practice is recording all the tasks. Here the rule is simple: the task is not recorded - the task is not solved. Depending on customers, their behavior and character, you can do in two ways. The first is forcing them to write down tasks with their own hands.

The second is sometimes to write down the tasks yourself, according to the customer. Personally, it seems to me that the second way to get involved is not worth it - get used to it quickly, and then it is difficult to wean, perceived as a personal insult. Although it’s most likely that the role of secretary cannot be completely avoided - any manager has a superior manager who has a formal and moral right to dictate tasks orally.

Filtering lists

The second thing that is important for any statuses is the ability to quickly and easily see the task lists for each stage of the life cycle. In most systems, this is done elementary, but there are exceptions when, instead of simple statuses, beautiful business processes are generated with non-grouped stages. In this case, to understand the status of the task, you need to go into it and read from top to bottom.

Well, even with the presence of beautiful filtering by status, there is always the problem of lazy performers and managers who do not change this status. We read a new task, asked a question to the customer, but didn’t set the status “sent for revision”. The customer, of course, received a notification in the mail that he needed to answer the question, but it happened late in the evening, and the next morning he simply forgot. I went, as I was taught, into my list of tasks, filtered by statuses "sent for revision" or "completed", I saw the emptiness, with full satisfaction went to go about my business. And the task is frozen.

Ideally, lists should be pre-configured, especially for the customer. He, in fact, suffices two - "sent for revision" and "completed", with filtering by director. The presence of tasks in these lists means that he needs to take some action, i.e. he has a task to "process tasks". If the lists are empty, all is well, nothing is required of it. If he wants to help him, he will go on the “in work” list and look (although, what will he see there?).

Similarly, there should be a pre-defined list for the executive manager - assigned tasks. If there is something in it, then you need to work - either to accept for execution, or send for revision. He came in the morning, worked, devastated the list - went on to go about his business.

Terms of status change

I had this practice - designation of terms for statuses. For example, to make a decision on a new task is one working day, after which the task begins to “blush”.

Similarly, we need deadlines for customers, only they are usually softer. For the tasks sent for revision, you can safely set the month, because from the point of view of the performers, such a task does not seem to exist. And if it does not exist, there is no point in worrying about it.

For completed tasks that are pending verification by the customer, a normal period of 3-5 working days will be. There is no sense to put too short a time, it will never be fulfilled. We, the performers, do nothing but work with tasks. The customer, with a high probability, is busy with completely different things, with some of his activities, and with our tasks can work, at best, once a day.

Storing the date of status

I will single out a separate item, although it seems obvious. But not all task management systems contain such information, alas.

When the status changes, in the task (or somewhere nearby, it does not matter) the date and time of this change should be saved. Some people think that it is enough to have such information in the versioning system, and not in the data itself. I don’t know, it’s possible that in some systems it’s as easy to handle versions as data, I don’t come across such in practice. Versions are not reliable, they can be cleaned by an admin or a routine, such as compressing a database. Well, there are a lot of versions, and to find the one in which the status has changed, you will have to tinker. In the same githabe, the date of the status change can be calculated only through the API, or you can use the comments and search for where, when and who “added” labels.

It is much easier to add several properties of a primitive type (date and time) to the task object, and store changes in them. Then it is very easy to calculate the "red" and the time elapsed since the status change. Information about the status change time is incredibly useful in managing, because the life cycle of a task becomes measurable. We know for sure how long the backside is sticking in the unaccepted, or untested, and we can make a decision about its future fate.

Sanctions

Usually, in traditional models of task management, sanctions of any kind are imposed only on executors - for untimely execution of the task. But, as we now know, the life cycle of a task depends not only on execution.

Therefore, I prefer to apply sanctions to all stages of the life cycle, especially to the part where the responsibility lies with the customer. It is clear that the essence of the sanctions will depend on what legal relationship with the customer you are.

The most effective sanctions are, if the customer is internal. In my practice, there were sanctions up to fines, i.e. depremirovaniya, for non-performance of obligations to work with tasks, but this, of course, bust.

I prefer “natural” sanctions. For example, if the customer has set 10 tasks, of which 5 were sent to him for revision, and he hasn’t done anything with them for a long time, then he would not have access to the formulation of new tasks. While his new tasks do not appear, the situation maintains the status quo. When a new task has appeared, and there is no opportunity to put it, 5 hung tasks begin to move in a magical way. Of course, some supporters simply asked their colleagues to set the task, but such cases are rare.

Another example of a milder sanction is to automatically close a task that the customer has not checked within 5 business days. This is not even a sanction, but a service, which is very convenient for lazy customers.

The situation is more complicated when the customer is external. We have to balance and apply only very soft sanctions. For example, spam is stupid every day, or at other reasonable intervals, to remind of the need to check the implementation, or to clarify the formulation of the problem. It is easier with staging - it is objectively clear there, incl. to the customer - if the statement is not clarified, the task will not move from its place.

With verification of the result, you can use cunning - in new tasks, refer to the unchecked and assert that there is a strict internal relationship of data or algorithms, and until the previous one is verified, a new one cannot be made.

Some statistics

Task management I, like many of you, have been doing for many years. And still, every time, I wonder how much more efficient this process can become if you manage the life cycle of tasks.

Every time, getting into a new company, or a new team, or working with a new customer, I first tell myself - no, there is no such trivial thing here. Here are intelligent people who know everything themselves and do the right thing. Well, it can not be that everywhere were the same problems.

A few weeks, or months, I, as they say, "do not climb into my own business." I work as set in the team. And every time I see the same thing - stability. The same development, the same number of tasks in the period, the same list of stuck, no dynamics.

Patience breaks, and we begin to manage the life cycle of tasks. And again, effectiveness and efficiency grow, and almost always doubled. Efficiency grows in the same way as efficiency, because costs are constant.

Here is an example from the last project. We started from October, reached a stable figure, stuck on it until March, from April began to manage the life cycle of tasks - and immediately jumped twice. May is already at the monthly average level, although less than half a month has passed, and even fewer working days at the beginning of May.

Explanation of the picture: the red line is the main developer, the yellow line is auxiliary, the blue line is the overall performance. Efficiency is considered as the sum of marks in points for solved problems, checked by the customer. Score in points - poker planning system.