Who needs nested tasks in a project management system?

What functionality should your task management system have? Very often one of the necessary capabilities of such a system is nesting of tasks. For example, 1 , 2 , 3 , 4 . We were of the same opinion when we decided to include this feature in our product. The fact that we have turned out of this and will be discussed


I will not talk about the technical difficulties that arise from supporting nested tasks, but will focus exclusively on the difficulties that our users have encountered when working with nested tasks.

Everyone has their own understanding of the project structure.

Everyone sees the project in their own way. A parent-child relationship requires that the project team develop a unified, as a rule, for the most unnatural, project structure. What for? To be honest, just to keep this very project structure and support. When adding a new task, you need to remember on which shelf it should be put, so that those interested can find it there. To achieve this is not a trivial task.
')

The vision and structure of the project may change over time.

As the project develops, our understanding of it changes, which means that the desired hierarchy of tasks and principles of construction also. We have an overhead of bringing the hierarchy of tasks to the proper form, teaching the project team a new way of doing it, etc. Does it give any benefit to the project? Hardly.

It is difficult to search for a task.

How to implement search and filter tasks? If you display the desired tasks in one list, then their place in the hierarchy is not clear. There may be tasks from different levels, or similar tasks, but from different branches, which is very confusing. If, on the other hand, output tasks with respect to the tree, then there are two options - the tree is opened and then it can turn out to be very “branchy”, or it is shown with hidden child nodes and then you need to open a bunch of nodes to get to the desired task.

Uninformative name of a sheet task

The greater the depth of nesting, the shorter the name of the task. Typical names at the lower level: Report, Add button, moderation, meeting, meeting. This happens because the parent task is the context and contains a lot of information that the user considers meaningless to copy to the child. As a result, there may be several tasks with exactly the same name in the report. To somehow distinguish between them, you need to show the entire branch of parental tasks, which is very clutter with reports.

Detailing reports.

Common questions: from which level of hierarchy to start and where to stop? Should indicators of a child task be included in indicators of the parent? For example, time worked. Either you need to build a very flexible and complex system of settings, or choose one of the possible options.

Select hierarchy level.

Since tasks at different levels of the hierarchy describe the same thing, but with varying degrees of detail, users are confused where to take one or another amount of work to the parent or child task.

To-do list

When forming the user's task list, is it worth it to show the parent task if there is a child in the list?

Of course, we are aware that the problems described above are, perhaps, only the problems of our implementation, and not the hierarchy of tasks in principle. On the other hand, I think that every computer user tried to clean up their documents and create a simple and understandable folder structure. But all of whom, I know, finished this noble cause by creating the folder Disassemble / New / Junk / Dump, where all files are dumped. If it fails to bring order to your own computer, then why should the whole project team succeed?

Having written this article, I ask the habros users whether they use the hierarchy of tasks and, if someone has successful experience, provide examples of the application scenario.