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