Недостатки планировщиков

В этом документе я попытался описать наиболее раздражающие меня недостатки настольных инструментов планирования проектов. Таких, как MS-Project Standard (не путать с сервером), OpenWorkbench или OpenProj.

Очень интересно, услышать Ваше мнение по этому поводу.

WBS versus календарный график

В жизни существует две независимых «топологии» над набором задач проекта:

• Иерархическая структура задач (в которой деление на подзадачи происходит естественным образом)
• Распределение задач по вехам, или по версиям системы. Здесь две подзадачи одной задачи вполне могут попасть в разные вехи. Например, если одна подзадача крайне важна, а вторая — незначительная «фича»

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

Такое положение дел иногда приводит к тому, что планировщики начинают использовать некорректно, заменяя WBS структурой вроде следующей:

Первая версия

  Разработка

    Разработка фичи 1

  Тестирование

    Тестирование фичи 1

Вторая версия

  Разработка

    Разработка фичи 2

  Тестирование

    Тестирование фичи 2

Здесь появляются версии, но ломается логическая структура работ. Теряется информация о том что какие то задачи являются частями одной бОльшей задачи.

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

Разработка

  Разработка фичи 1

  Разрапотка фичи 2

Тестирование

  Тестирование фичи 1

  Тестирование фичи2

Веха — версия 1, зависит от (Разработка фичи 1, Тестирование фичи 1)

Веха — версия 2, зависит от (Разработка фичи 2, Тестирование фичи 2)

Здесь все правильно с точки зрения логики. Но к сожалению, абсолютно не наглядно. При сколько нибудь приличном объеме проекта, в котором есть много задач и много связей между ними, оказывается крайне сложным сказать какие задачи попадают в какую из вех. (Поскольку большая часть зависимостей транзитивна). Тем более сложно осмысленно перемещать задачи между версиями. При этом совершенно не видно к каким последствиям это перемещение приведет — что потянется за перемещаемой задачей. Опять таки причина этого явления в том, что в древние времена не возникало такой проблемы как перенос задачи между версиями. Версии сами являлись независимыми проектами и были статичны.

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

Ну и напоследок — нет простого способа найти задачи, не попадающие ни в одну веху (опять проблема транзитивных задач)

О них, кстати, подробнее:

Транзитивные зависимости между задачами

Ни в одном планировщике нет способа увидеть все задачи, зависимые от данной или все — зависящие от данной. То есть есть возможность увидеть только список непосредственно зависимых (или зависящих). А вот зависимых от зависимых (и тд) — нельзя никак. Часто это оказывается неудобным.

Наиболее яркий пример неудобства — это выставление этих самых зависимостей при планировании проекта из 100 и более задач. Практически нет удобного способа убедиться что все зависимости выставлены правильно. Вполне может оказаться что задача 32 зависит от задачи 44, но мы эту зависимость не указали, потому что решили, что она и так есть — транзитивная. Может быть она даже была, но в какой то момент пропала. Отследить это, не видя транзитивных зависимостей, крайне сложно.

Можно возразить, что надо-де вставлять все зависимости напрямую и не полагаться на транзитивные. Но вот пример — задача «Подготовительные активности» в которой 30 подзадач. И задача «Разработка» в которой еще 50 подзадач. Станете вы вставлять полторы тысячи прямых зависимостей для каждой из 50ти задач по разработке от каждой из 30ти подготовительных задач? А проходить по списку подготовительных задач, искать зависимые для каждой из них и переносить каждую из этих зависимостей в каждую из 50 ти задач разработки? А поддерживать целостность такого плана?

На самом деле это практически не возможно да и вообще нелогично. Поэтому транзитивные зависимости , действительно, важны и очень странно, что современные планировщики уделяют им столь мало внимания.

Личные планы

Другим забавным неудобством планировщиков является трудность в просмотре личного плана — плана работы для одного человека. Нечто подобное реализовано только в OpenWorkbench в виде фильтра по ресурсам (людям), скрывающим все задачи, в которых данный человек не участвует.

Это уже кое-что. Но. Было бы очень неплохо видеть на этом графике входящие и исходящие зависимости задач этого человека от других задач. Чтобы при планировании было видно где график работы Васи Пупкина может «поплыть» не по его вине, а из-за задержки другого члена команды. С другой стороны, чтобы этот самый Вася видел, на какие задачи ему стоит обратить внимание, чтобы не «удружить» своему товарищу.

А еще мне не хватало возможности выбрать ни одного, а несколько человек в этом фильтре. Скажем двоих — чтобы посмотреть зависимости между их задачами.

Молчаливый и настойчивый Искусственный интеллект

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

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

12:21.22 — Попытка сдвинуть задачу такую-то ранее 12го августа пресечена, поскольку 12е августа — дата старта нашего проекта.

12:21.45 — Пользователь Вася изменил длительность задачи такой то, поэтому теперь работа пользователя Пети, который будет эту задачу делать увеличилась и составила 24 часа вместо ранее запланированных 16ти.

Это бы сэкономило время и нервы, а заодно бы послужило хорошим заменителем длинных мануалов.

При этом, особо важные сообщения можно показывать сразу же — в виде всплывающих подсказок, клик по которым открывал бы всё тот же лог.

Информационная атака

Очень симпатично смотрятся примеры работы с планировщиками, взятые из разных tutorial-ов. Типа проект «постройка дома» мило делится на 15 задачек, вроде «заказ гвоздей» иди «заливка фундамента».

В реальности, нормальный средний проект редко содержит менее тысячи задач.

Наблюдать такой план, который к тому же снабжен тучей зависимостей — чистый мазохизм.

А если план меняется (как это всегда бывает в жизни), да к тому же менять его надо именно вам?

Вобщем слабое место в существующих планировщиках — полное пренебрежение принципом «разделяй и властвуй». Они практически не пытаются показывать различные осмысленные «срезы» проекта, объем которых не превосходит того, с которым может реально работать человек, и при этом они не утрачивают смысла.

Например, есть такая задача менеджера как осмысление взаимных зависимостей различных частей проекта. В реальности, далеко не все подзадачи вообще имеют какие-либо зависимости. Так почему же менеджер должен видеть всю тысячу задач, чтобы осмыслить скажем 30 зависимостей? В данной ситуации было бы очень полезно уметь скрыть ненужные задачи.

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

• Определяем список задач, которые приходится решать менеджеру
• Описываем, что в идеале ему нужно для решения этих задач
• Создаем «проекцию» нашего дерева задач, наиболее приближенную к этому идеалу.

Кстати, пункт «Личные планы» тоже из этой оперы. Это срез информации необходимый для оценки плана работ каждого участника проекта.

Статичность

Почти все перечисленные выше проблемы (кроме проблемы Искусственного интеллекта) имеют один общий корень. Я бы назвал его статичностью планирования. Проблема эта сложилась исторически:

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

Статичность является больше чем недостатком планировщиков. Она является причиной, по которой многие начали отказываться от планирования вообще, потому что оно в таком виде не работает. Появились agile методы, в которых сознательно отказываются от долгосрочного планирования,  оставляя лишь создание краткосрочного плана на текущую версию. Интересно, что одним из основных недостатков agile методов их критики называют «размывание контекста задачи» или «размывание бизнес целей проекта». ..