Who needs nested tasks in the project management system?

What functionality should your dream task management system have? Very often, one of the necessary capabilities of such a system is called nesting 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 succeeded and will be discussed


I will not talk about technical difficulties that arise due to the support of embedded tasks, but will focus solely on the difficulties that our users encountered when working with embedded tasks.

Everyone has their own understanding of the structure of the project.

Everyone sees the project in their own way. And the parent-child relationship requires that the project team develop a single, usually for the majority, unnatural, project structure. What for? Honestly, only to support this very structure of the project. When adding a new task, you need to remember on which shelf it should be put so that interested parties can find it there. To achieve this is a non-trivial task.

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

As the project develops, our idea of ​​it changes, which means the desired hierarchy of tasks and the principles of construction, too. We have overhead for bringing the hierarchy of tasks to the proper form, training the project team in a new way of doing, etc. Does this bring any benefit to the project? Unlikely.

It’s hard to find 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. Nearby may be tasks from different levels, or similar tasks, but from different branches, which is very confusing. If you output tasks taking into account the tree, then there are two options - the tree is opened and then it can turn out to be very “branchy”, or it can be shown with hidden child nodes and then you need to open a bunch of nodes to get to the desired task.

The non-informative name of the 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, rally. This is because the parent task is a context and contains a lot of information that the user considers pointless to copy to the child. As a result, several tasks with exactly the same name may appear in the report. To distinguish them somehow, you need to show the entire branch of the parent tasks, which is very cluttered with reports.

Detailing reports.

Common questions: at what level of the hierarchy do you start and where do you stop? Do I need to include the indicators of the child task in the 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.

Choosing a hierarchy level.

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

To-do list

When creating a list of user tasks, is it worth showing 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 his documents and create a simple and understandable folder structure. But everyone whom, I know, finished this noble work on the fact that they created the Parse / New / Junk / Trash folder, where they dump all the files indiscriminately. If you can’t clean up your own computer, then why should the whole project team get it?

After writing this article, I ask habro-users whether they use the hierarchy of tasks and, if someone has successful experience, give examples of application scenarios.