Кому нужны вложенные задачи в системе управления проектами?

    Каким функционалом должна обладать система управления задачами Вашей мечты? Очень часто одной из необходимых возможностей такой системы называется вложенность задач. Например, 1, 2, 3, 4. Такого же мнения придерживались и мы, когда принимали решение о включении данной фичи в состав нашего продукта. О том, что у нас из этого получилось и пойдет речь


    Я не буду говорить о технических трудностях, которые возникают из-за поддержки вложенных задач, а сосредоточусь исключительно на сложностях, с которыми столкнулись наши пользователи при работе со вложенными задачами.

    У каждого свое понимание структуры проекта.

    Каждый видит проект по–своему. А отношение родитель-потомок требует, чтобы проектная команда выработала единую, как правило, для большинства неестественную, структуру проекта. Зачем? Честно говоря, только для того, чтобы эту самую структуру проекта и поддерживать. При добавлении новой задачи надо помнить на какую полочку ее надо положить, чтобы заинтересованные лица ее там могли обнаружить. Добиться этого нетривиальная задача.

    Виденье и структура проекта могут меняться со временем.

    По мере развития проекта наше представление о нем меняется, а значит желаемая иерархия задач и принципы построения тоже. У нас возникают накладные расходы на приведение иерархии задач к надлежащему виду, обучении проектной команды нового способу ведения и т.д. Дает ли это какой-то пользы проекту? Вряд ли.

    Трудно искать задачу.

    Как реализовать поиск и фильтрацию задач? Если выводить искомые задачи одним списком, то непонятно их место в иерархии. Рядом могут оказаться задачи с разных уровней, либо аналогичные задачи, но с разных веток, что сильно сбивает с толку. Если же выводить задачи с учетом дерева, то есть два варианта – дерево раскрыто и тогда оно может оказаться очень “ветвистым”, либо оно показывается со скрытыми дочерними узлами и тогда нужно раскрывать кучу узлов, чтобы добраться до нужной задачи.

    Неинформативное название листовой задачи

    Чем больше глубина вложенности, тем короче название задачи. Типичные названия на нижнем уровне: Отчет, кнопка Добавить, модерация, совещание, митинг. Так происходит потому, что родительская задача является контекстом и содержит много информации, которую пользователь считает бессмысленным копировать в дочернюю. Как следствие в отчет может рядом оказаться несколько задач с абсолютно одинаковым именем. Чтобы их как-то различать, нужно показывать всю ветку родительских задач, что сильно загромождает отчеты.

    Детализация отчетов.

    Обычные вопросы: с какого уровня иерархии начинать и где остановиться? Нужно ли показатели дочерней задачи включать в показатели родительской? Например, отработанное время. Либо нужно строить очень гибкую и сложную систему настроек, либо выбирать один из возможных вариантов.

    Выбор уровня иерархии.

    Поскольку задачи на разных уровнях иерархии описывают одно и тоже, но с различной степенью детализации, то пользователи путают, куда отнести тот или иной объем работы – к родительской или дочерней задаче.

    To-do список

    При формировании списка задач пользователя стоит ли показывать родительскую задачу, если в списке есть дочерняя?

    Конечно, мы отдаем себе отчет, что описанные выше проблемы – это, возможно, лишь проблемы нашей реализации, а не иерархии задач в принципе. С другой стороны, думаю, что каждый пользователь компьютера пытался навести порядок в своих документах и создать простую и понятную для себя структуру папок. Но все кого, я знаю, закончили это благородное дело на том, что создали папку Разобрать/Новое/Хлам/Помойка, куда сбрасывают все файлы без разбора. Если не получается навести порядок на собственном компьютере, то почему должно получится у целой проектной команды?

    Написав эту статью, я спросить у хабропользователей пользуются ли они иерархией задач и, если кто-то имеет успешный опыт привести примеры сценария применения.

    Only registered users can participate in poll. Log in, please.

    пользуетесь ли Вы вложенными задачами?

    LLC Tik-Tok Coach
    28.11
    Компания
    Share post

    Comments 23

      +2
      Мы обычно пользуемся не вложенными задачами, а связанными. Например, для решения задачи A требуется сначала решить задачу B, но задачу B нельзя считать вложенной в A, т.к. это самостоятельная задача (нужна сама по себе, независимо от того, существует ли задача A), просто пока она не решена, A решить невозможно. При таком подходе получаются не «папки», а просто связи между задачами. Для каждой задачи можно посмотреть, от каких она зависит, и какие, в свою очередь, зависят от нее.
        0
        Мы пользуемся, и постоянно. В списках задач отражаются все задачи (если есть родительская задача, это помечается), в трудозатраты родительской задачи включаются затраты дочерних задач.
        Поиск, по-моему, при этом наоборот облегчается: если ищешь какой-нибудь «отчет» по какому-то конкретному функционалу, то не надо перебирать тонну задач с заголовком «отчет», а достаточно перейти по ссылке из родительской задачи, у которой уже будет уникальное название.
        Связанные задачи тоже используем, но тогда трудозатраты не суммируются, а это порой удобно.
        И даже бывает так что выкладывать задачи не в совокупности смысла нет — и тогда кроме как иерархию для отображения этого факта ничего и не придумаешь, наверное.
          +1
          А не могли бы Вы немного рассказать о своей структуре задач? Как разбиваете, какова глубина вложенности, как согласуете между собой?
            +1
            Глубина вложенности — обычно 2-3 уровня
            На верхнем т.н. «эпики», т.е. какие-то крупные нововведения, эпики бьются на задачи, задачи — на подзадачи. Найденные при тестировании задач баги отправляются на уровень подзадач, там же находятся задачи на code review и тесты.

            Стандартный процесс: от заказчика сваливается нечто с формулировкой «ДОРАБОТКИ», открыв описание, я вижу, что доработки там разноплановые и что их можно распараллелить, делю задачу на соответствующее числу доработок количество подзадач, распределяю по людям, в итоге получаю оценку родительской задачи и могу следить за ее выполнением, тестированием, правкой багов и код ревью.

            Либо приходит что-то, что можно определить как эпик вследствие объема, тогда делю ее на задачи, каждая из которых может быть реализована и протестирована отдельно. Соответвенно, в задачах уже будут подзадачи с багами, тестами, ревью. Если задачу можно разделить на этапы, также выношу это в подзадачи.
          0
          Любую задачу можно разбить на несколько более мелких задач. Этот процесс называется декомпозиция. До разумных пределов конечно. Что автор увидел в этом неестественного?
            +1
            Я нигде и не пытался сказать, что декомпозиция плохо. Я лишь отметил, что большинство наших пользователей испытывают трудности при проведении этой самой декомпозиции. Причем трудности настолько большие, что им проще отказаться от разбиения задачи на более мелкие и перейти к плоскому списку задач. Причем, я привел пример, что это не только с системами управления задач такое происходит, но и, например, при работе с файловой системой.

            При этом вижу по результатам опроса, что большинство все же пользуется иерархией задач. Пока, что приходит в голову, что, возможно, нужна не иерархия в общем виде, а какие-то ее частные случаи: например, ограничение глубины, чек-листы, что-нибудь еще.
              0
              Возможно, вы пытаетесь изобрести велосипед. Ничего лучше иерархии нет. Это абстракция понятная каждому. А трудности, которые испытывают пользователи — это проблема плохого дизайна ПО.

              Хороший пример с файловой системой. Папки и подпапки — это чрезвычайно удобно. Доказано временем. Хотя это не единственный способ для организации данных.

              Просто дайте людям возможность создавать подзадачи. Если они хотят плоский список, пусть не создают подзадач. Какая проблема? Я и правда видел на своём веку людей, которые все свои файлы хранили в одной единственной папке: музыку, документы, картинки и т.д. Но все люди разные, и всё сильно зависит в команде от того, как работает менеджер. Вы его работать по-своему не заставите. Просто дайте инструмент. И сделайте его простым, понятным и очевидным.

              Не надо за людей решать: вам не нужны подзадачи (потому что мы не знаем как сделать работу с ними удобной).
                +1
                Не могли бы Вы рассказать какой иерархией задач на проектах, одном проекте пользовались?
                  +1
                  Программный комлекс, состоит из 3-х систем.

                  Проект
                  — Система 1
                  … — Модуль 11
                  … — Модуль 12
                  …… — Решение задачи XXX
                  …… — Интерфейс
                  ……… — Реализация
                  ……… — Логгирования
                  …… — Решение задачи YYY
                  ……… — Подготовка данных для исследования
                  ……… — Разработка структуры

                  и т.д. и т.п.

                  Если в одном трекере будет это всё валяться сплошняком, будет ад. Теги, связи — конечно хороши, но они не дают надёжную чёткую структуру что из чего состоит, потому что иерархия задач подразумевает: какая работа частью какой работы является. Она может зависеть от других задач, быть с ними связана, укладываться на диаграму, быть триггером для старта/завершении цикла, но она всегда является частью чего-то большего.

                  В любом случае иерархия есть, как минимум в разрезе Проект — Задачи. По сути проект это и есть одна большая задача. Хотя мне не нравится, когда некоторые разработчики выбирают подход «Всё есть задача». Тоже фейл но в обратном направлении.
                    +2
                    Структура понятная, но рано или поздно попадается задача, которая может быть отнесена как к модулю 11, так и к модулю 12. Кроме того, при такой структуре не так уж и просто понять где и какие задачи уже сделаны, а какие еще нет.
                      0
                      Во-первых, при такой структуре можно посмотреть готовность работы на любом уровне иерархии. Что называется, не вдаваясь в детали. Это очень удобно для менеджеров, которым может нет дела как идут дела с реализацией отдельных функций отдельных программистов, а текущее состояние задач по-крупней. Во-вторых, подзадача не может быть отнесена к двум задачам. Потому что иерархия проекта и иерархия задач — разные вещи совершенно. Хоть и на начальном этапе возможно сходство. Поймите, наконец, что иерархия в задачах — это декомпозиция. Большие задачи разбиваются на мелкие, но это в совокупности одна и та же задача. Это не просто папка для подзадач. Так вы своих пользователей запутаете.
            0
            Наш багтрекер не поддерживает вложенные задачи. Однако, руководство не умеет разбивать задачи на этапе формулировки (например, сваливает совершенно несвязанные проблемы из нескольких жалоб пользователей в одну задачу и обзывает ее «проблемы, найденные пользователями» и ставит milestone на следующий релиз). Тактика «закрывать абсолютно любую задачу, содержащую список, как невалидную по формальной причине необходимости разбить» только привела к конфликтам. Не знаю, помогли бы в такой ситуации подзадачи или нет, но, думаю, не попробовав, не узнаю.
              +2
              Ну, руководителя тоже можно понять. Ему неважно, на какие задачи разбиваются эти «проблемы, найденные пользователями» — ему главное к следующему релизу быть уверенным, что все эти проблемы решены. И контролировать это ему удобнее в одной задаче (сразу видно, решена она или еще в работе), а не выискивать кусочки задачи по всему багтрекеру.
                0
                В принципе, эту ситуацию даже удобнее будет описать не вложенными задачами, а через связи между задачами.
                  0
                  Конкретно в этом случае — руководитель с самого начала занес в тикет нумерованный список.

                  1. Раз проблема

                  2. Два проблема

                  3. Три проблема

                  И тикет был в итоге разбит ровно по пунктам 1, 2, 3.
                +1
                А что за продукт то?
                  0
                  Написал личное сообщение, так как, если ответить здесь, то могут счесть за рекламу.
                    0
                    Напишите и мне, пожалуйста. Интересно.
                  0
                  Вложенные задачи нужны однозначно, это гораздо сложнее для разработчика в реализации, но для пользователя это однозначное благо, т.к. если нет необходимости — этой вложенностью можно и не пользоваться.
                  То, что у каждого свое видение структуры – есть такое, но это неизбежно, т.к. классическая древовидность предполагает одного родителя у узла дерева.
                  Вот про поиск и выдачу задач – действительно, не совсем понятно как удобнее выводить пользователю. Но это сложности разработчика. Навскидку – просто выводить рядом путь в дереве. Для большинства случаев хватит за глаза.

                  Мы тоже работаем над системой управления задачами, в ней постарались реализовать древовидность без каких-либо ограничений. Могу дополнить копилку сложностей всего лишь одним аспектом – разруливание возможных противоречий между родительской задачей и дочерними, если их допускать нельзя. Т.е., к примеру, если в родительской задаче установлены какие-то параметры, то и дочерние должны им соответствовать (если это важно). К примеру, сроки, бюджет, время и т.п. – должны ли сроки подзадач укладываться в сроки родительской и т.п. Аналогичная ситуация, к примеру, с метками задач или их аналогами – должны ли подзадачи их наследовать или нет. У каждого пользователя свои предпочтения.
                  Ну и по мелочи — у пользователей разное видение того, что должно произойти с подзадачами при выполнении родительской задачи. Кто-то считает, что должны быть автоматически помеченые как выполненные все подзадачи (как в Google Tasks), но это далеко не всем подходит. Аналогичная ситуация с родительскими задачами – что должно произойти при выполнении всех подзадач – должна ли родительская задача стать выполненной?
                  • UFO just landed and posted this here
                      0
                      Выделили вам как менеджеру большую задачу, а вы уже колупайте её как хотите и раздавайте своим подчиненным. Если у подчиненных есть свои подчиненные, они могут поступать аналогично. Или разбивать задачу на подзадачи чисто для себя и для правильной организации и оценки времени. Не ищите проблем там, где их нет :)
                      +1
                      Когда пользователям даешь новую фичу с богатым функционалом и простором для воображения, всегда есть период, когда фича используется как попало. По-идее, со временем народ вырабатывает какой-то свой подход ее использования.

                      Но! Есть опасность, что ее начнут использовать совсем уж не по назначению. Как например было с отличным проектом Google Wave — народ стал пользоваться вложенностью и возможностю сворачивания комментариев в Wave и плодить километровые волны. А разработчики все-таки рассчитывали, что волны будут примерно похожи на почтовую переписку. В итоге проект провалился, хотя ему прочили заменить все виды письменного общения (почта, чаты, вики).

                      Т.о. первый вывод: нужно давать пользователям понять, для каких именно случаев разработчики все-таки ввели эту фичу. Может быть не давать общие названия, типа «подзадача». А конкретные: задачи первого уровня — проекты, второго — системы, третьего — подсистемы и т.д. Например, чтобы эти названия можно было настраивать админу достаточно гибко, но система уже заставляла народ использовать заданную структуру. Кажется такое есть в TrackStudio — они очень гордятся иерархичностью своей системы.

                      Вторая опасность: если каждый человек/компания выработает свой подход к использованию фичи, то дальнейшие фиче-реквесты по ее доработке будут очень разнообразными — т.к. каждый человек захочет ее «допиливать» в разные стороны — под то, под что он ее пытается приспособить.
                        0
                        Я полагаю иерархия зада становится естественной, если она повторяет другую существующую в проекте иерархию. Скажем у вас есть дерево целей, которое переносится в трекер в виде задач приближенных к корню, а на более глубоких уровнях уже располагается декомпозиция.

                        Кстати, в youtrack очень простая и удобная иерархия на мой взгляд.

                        Only users with full accounts can post comments. Log in, please.