The only intuitive interface is women's breasts, everything else needs to be learned. This popular wisdom came to me this morning, when I told my third colleague in details and colors, how the resolved differs from closed and how to do log work so that the management would not be painfully painful afterwards. In this article I will try using the example of several sketches to describe possible options for using a task management system using the example of the popular Jira for daily work. The techniques, of course, are not the only possible ones - but they are simple enough, universal and applicable not only to Jira, but also to most popular task management systems — Redmine, Trac, Bugzilla, and others.

Task insides

The foundational brick that underlies task management is, in fact, tasks. Apart from the actual name of the task and the optional description, any task has three basic properties around which everything revolves and which determine its fate:

• The customer , also known as Reporter, is the one who initiated the task. It is understood that this is a person for whom for one reason or another it is important to complete this task. Pay attention to the vagueness of the terminology - “reporter” is translated from English as “reported”, “the one who informed”. Historically, this property was used for bug reports, and the reporter was quite obviously the one who found the bug and was not too lazy to tell about it. But the evolution of task management systems led to the fact that they were used not only to log fixes for bugs, but also to work with tasks in general - “add new functionality”, “write an article for Habr”, “hold a standup meeting (daily)”. The scope has changed, but the term remains the same - few task management systems are shared by “who said this” and “who said to do the work”. In general, a reporter is the person for whom the work must be done, who will verify that it is done.
• The performer , he is Assignee - the one who will perform the task.
• Status , it is Status (for some reason, the term state is used in few places) - what is happening with this task at the moment.

Task evolution

When the one who needs the work done is aware of this sad fact, he creates a task. The action is quite natural, consistent with common sense and approved by the Captain Obvious. What characterizes a newborn task? Assignee - who needs to do the job and Status - the current status, designed to reflect her newborn. In most systems, the newly created task will have the status " Open ". This state seems to be telling us - “this task is hanging over someone with a Damocles sword, and work on it is either already underway or will be carried out soon.” It is implied that the performer, having seen the task “open” “on himself”, will start working after a while, depending on the current tasks and their priority.
Suppose the performer reached his hands to complete the task. Here the most interesting begins - depending on the task, options are possible:

1. Artist everything is clear. He starts to work, a certain amount of time (hours, days, months or years) is working, after which he considers that the task has been completed. In order for the customer to know about this joyful event, the performer changes the state of the task, setting it to “Resolved” . In this simple action, a lot of funny nuances are hidden, for many years bringing happiness and joy to both the developers and their managers. The fact that the employee considers the task completed - does not mean that the task is actually completed. It can only be considered completed by the customer - the one who set the task and is competent to verify what is done is really what needs to be done. Therefore, the state of the problem “resolved” is primarily a volleyball, thrown from the contractor to the customer. "For my part I did - check." Accordingly, after seeing the task in the “resolved” state, the customer must check that the work has actually been completed and perform one of two actions:
   
   1. If the work is really done, the status of the task changes to " Closed ". By this we sort of “send the task to the archive” - everything is done, there is nothing more to track.
      
   2. But it is often different - looking at what has been done, the customer grabs his head, runs around in circles, shouts the letter “A” and in other ways expresses his surprise. In this case, the contractor needs to explain that what he did is not entirely consistent with what the customer expects - for this, the task again sets the state " Open ". In some systems for the same purpose there is a special state " Reopened " - but, as practice shows, its presence changes little - rarely really you need to distinguish between the first attempt or the tenth one - anyway it is displayed in the task status log.
      
   
   
2. If there is a case when the performer understands everything, then there must be the opposite - when the performer doesn’t understand anything. Unclear bug reports, poorly worded requirements, lengthy descriptions - all this rarely adds optimism to the performer and leads to a logical desire to clarify. Here the most interesting begins - if the contractor has not completed the task, but wants the customer to clarify what needs to be done - this is still the " Resolved " state! A rather counterintuitive thing that many stumble over. As I wrote above, “resolved” is not the fulfillment of a task. This is a sign that the performer has done something . For example, I looked at the task and decided that it would be nice for the customer to clarify it :). Resolved is a pass of a volleyball ball to the customer, passing it priority. This task status indicates that “the next step is for the customer”. He can read what is incomprehensible to the performer, and decide that the task does not need to be performed at all - then the state changes to " Closed ". Or he can clarify what was not clear and change the state to “ Open ” (“Reopened”) again.
   The attentive reader © will always take an interest - and how will the customer determine what exactly the performer did? Did you complete the task or do you want it clarified to him? The devil, as always, is safely hidden in the details - the state of the problem “Resolved” has a property - “Resolution”. And it is in this property that the performer indicates what exactly he did or did not do with the task. Popular options: “Fixed” (task accomplished, heavy legacy of bug trackers), “Incomplete” (it’s not clear what to do, what I described here), “Can't reproduce” (see below), “Won't Fix” ( see below), “Duplicate” (see below). Correct use of the property “Resolution” is the cornerstone of using task management systems that everyone does not know about.
   
3. There are also less common reactions of the performer to the obtained task, determined by the value of the “Resolution” property. If “Fixed” (“Complete”, “Done”) and “Incomplete” (“Need more info”) exist in almost all popular task management systems, the other properties differ. I will give the most popular:
   
   1. Can't reproduce - The performer did not find something that is specified in the problem. It is most often used in work with errors, when the error repeating by the developer does not reveal an error. But this property is also found in the routine - for example, if the task states “dig before lunch, a shovel in the toilet” - and there are no shovels in the toilet O_O.
      
   2. Won't Fix - The contractor does not want to do the work. The name of the property, as you probably already guessed, is a heavy legacy of bug trackers. Accordingly, when correcting bugs, it is used if the executor is sure that this is not a bug at all. In the bug trackers of popular programs, the chains “Open” -> “Won't Fix” -> “Reopened” -> “Won't Fix” -> “Closed” -> “Reopened” -> ... can last for years and reach a fair length.
      
   3. Duplicate - The contractor believes that this task duplicates another task that he has already completed or is only doing. Accordingly, the customer may agree with this - or may not agree.
      
   4. Wait - The contractor has done something and now it is necessary to wait for the onset of an external event - for example, the completion of a freelance job or the return of an accountant from vacation. As a rule, the customer does not need to somehow react to the task with such a state — the performer himself must track the onset of the expected event and take further action. But control over such tasks will not hurt - what if the performer forgets that he is waiting for something? :)
      
   
   

The concept of work with the task, safely buried in the depths of the Jira documentation. Pay attention to the state “In Progress” - it is often used, if the contractor has many tasks and the management is important to know which of them he performs right now. In practice, in most situations, this state can not be used.

Filters are our everything

If you look at the task management system of a large and serious project, it will look something like this:

Note the total number of tasks in this linear list. Of course, now Jira shows everything, but even if you set the filter “only open” - changing thirty thousand to six does not fundamentally change anything. Many developers, using the task management system for the first time and looking at such task lists, begin to be interested in “how is it with a tree view”? At first glance, the idea of ​​copying a tree-like architecture from a file system seems successful - there are parental tasks, there are subtasks ... Some systems even implement such a hierarchy, stating "unlimited depth of subtasks" as one of the main competitive advantages. But popular systems such as jira, redmine, trac - as a rule, there is only a “task-subtask” relationship, and that is rarely used? Why and how do users work with kilometer task lists?
The answer to this question lies in one word - Filter . Filters implemented in most task management systems allow you to do one simple thing - to group tasks for a specific query. For example, if you make the filter “tasks that have a reporter I, and the state resolved”, then we will immediately see the tasks for which we, as the customer, have reported the performers and need to take some action. A big plus of filters is that each user of the task management system can configure their own set of filters, showing tasks in a convenient way. For example, a filter fragment in the Jira Client, showing the work of the staff of my department:

Useful tips

• Does your system lack the necessary properties for the “Resolved” task state? It does not matter, most systems allow you to add your own properties. For example, Jira has added the “Wait” property without any problems.
  
• To control the execution of tasks, it is convenient to do “log work” at the end of the day — indicating how many hours were spent on a particular task. Most task management systems allow you to generate reports on these logs, so that the “monthly report what we did,” which many fear, is made up in two clicks.
  
• “Log work” can and should be done even if you are neither a customer nor a task performer. Many systems do not support the appointment of more than one executor - but this is not a problem, as any person who actually worked on the task can do “log work”.
  
• When the state of the task changes, it is not recommended to change either the customer or the contractor. Many users mistakenly install Assignee on the same person as Reporter when setting the task state to Resolve. This destroys the logic of work described above and in every way impedes "single-click" work with tasks.
  
• I hope, as a result of the discussion here to add something :)
  

')
For this round. If anyone has something to say on this important and not very simple topic - I will be happy to hear it in the comments and will try to discuss as much as possible.