Каким функционалом должна обладать система управления задачами Вашей мечты? Очень часто одной из необходимых возможностей такой системы называется вложенность задач. Например, 1, 2, 3, 4. Такого же мнения придерживались и мы, когда принимали решение о включении данной фичи в состав нашего продукта. О том, что у нас из этого получилось и пойдет речь
Я не буду говорить о технических трудностях, которые возникают из-за поддержки вложенных задач, а сосредоточусь исключительно на сложностях, с которыми столкнулись наши пользователи при работе со вложенными задачами.
У каждого свое понимание структуры проекта.
Каждый видит проект по–своему. А отношение родитель-потомок требует, чтобы проектная команда выработала единую, как правило, для большинства неестественную, структуру проекта. Зачем? Честно говоря, только для того, чтобы эту самую структуру проекта и поддерживать. При добавлении новой задачи надо помнить на какую полочку ее надо положить, чтобы заинтересованные лица ее там могли обнаружить. Добиться этого нетривиальная задача.
Виденье и структура проекта могут меняться со временем.
По мере развития проекта наше представление о нем меняется, а значит желаемая иерархия задач и принципы построения тоже. У нас возникают накладные расходы на приведение иерархии задач к надлежащему виду, обучении проектной команды нового способу ведения и т.д. Дает ли это какой-то пользы проекту? Вряд ли.
Трудно искать задачу.
Как реализовать поиск и фильтрацию задач? Если выводить искомые задачи одним списком, то непонятно их место в иерархии. Рядом могут оказаться задачи с разных уровней, либо аналогичные задачи, но с разных веток, что сильно сбивает с толку. Если же выводить задачи с учетом дерева, то есть два варианта – дерево раскрыто и тогда оно может оказаться очень “ветвистым”, либо оно показывается со скрытыми дочерними узлами и тогда нужно раскрывать кучу узлов, чтобы добраться до нужной задачи.
Неинформативное название листовой задачи
Чем больше глубина вложенности, тем короче название задачи. Типичные названия на нижнем уровне: Отчет, кнопка Добавить, модерация, совещание, митинг. Так происходит потому, что родительская задача является контекстом и содержит много информации, которую пользователь считает бессмысленным копировать в дочернюю. Как следствие в отчет может рядом оказаться несколько задач с абсолютно одинаковым именем. Чтобы их как-то различать, нужно показывать всю ветку родительских задач, что сильно загромождает отчеты.
Детализация отчетов.
Обычные вопросы: с какого уровня иерархии начинать и где остановиться? Нужно ли показатели дочерней задачи включать в показатели родительской? Например, отработанное время. Либо нужно строить очень гибкую и сложную систему настроек, либо выбирать один из возможных вариантов.
Выбор уровня иерархии.
Поскольку задачи на разных уровнях иерархии описывают одно и тоже, но с различной степенью детализации, то пользователи путают, куда отнести тот или иной объем работы – к родительской или дочерней задаче.
To-do список
При формировании списка задач пользователя стоит ли показывать родительскую задачу, если в списке есть дочерняя?
Конечно, мы отдаем себе отчет, что описанные выше проблемы – это, возможно, лишь проблемы нашей реализации, а не иерархии задач в принципе. С другой стороны, думаю, что каждый пользователь компьютера пытался навести порядок в своих документах и создать простую и понятную для себя структуру папок. Но все кого, я знаю, закончили это благородное дело на том, что создали папку Разобрать/Новое/Хлам/Помойка, куда сбрасывают все файлы без разбора. Если не получается навести порядок на собственном компьютере, то почему должно получится у целой проектной команды?
Написав эту статью, я спросить у хабропользователей пользуются ли они иерархией задач и, если кто-то имеет успешный опыт привести примеры сценария применения.
Автор: etyumentcev
