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

Привычные в проектном управлении диаграммы Гантта работают в таком случае плохо. Типичный пример — разработка расширений для КИС.

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

1. Планирование работ

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

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

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

Как быть? Как обеспечить контроль хода работ? Как понять — успеваем или нет; где узкие места; достаточно ли ресурсов; кто работает хорошо, а кто не очень? Как, в конце концов, представить отчет руководству?

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

2. Использование системы управления работами

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

В своей практике я использовал разные инструменты и опубликовал обзорную статью на эту тему (см. статью на Хабре: Инструменты руководителя проекта). Здесь же я более подробно опишу опыт использования JIRA, которую мы настроили на управления разработками, пользуясь стандартной функциональностью, с минимальным использование дополнительных плагинов.

JIRA — это система управления задачами (запросами) от компании Atlassian. Стоимость лицензии, в зависимости от количества пользователей, начинается от 10 долл. за 10 пользователей. Есть варианты установки у себя, или использования приложения в облаке. Цены на все варианты можно посмотреть здесь.

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

Нам доработка не понадобилась, мы настраивали и постоянно совершенствовали workflow (рабочий процесс — набор и порядок статусов по задаче и переходы между ними), а также доступы участников и дашборды для контроля работ.

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

3. Рабочий процесс управления задачей

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

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



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

4. Трудоемкость задачи

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

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

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

Сложность задачи определяется в зависимости от объекта и объема работы с ним. Например, для разработки формы в Oracle eBS критерии сложности описаны так:

• Очень простая — одноблочная форма с 8 и менее колонками. Не требует специальной функциональной логики.
• Простая — одно и многоблочная (2-3 блока) форма с 20 и менее колонками. Требуется простая функциональная логика (простое редактирование, кросс-редактирование (cross edits), простые расчеты, итоги и подитоги).
• и т.д.

Тип задачи отражает содержание задачи, специфику технологии, приложения или его части.

Например:

— Новые или изменяемые формы.
— Новые или изменяемые отчеты.
— Новые или изменяемые программы базы данных.
— Скрипты SQL*Loader'a.
— Сигналы (alerts).
— Персонализации.
— и т.д.



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

5. Контроль исполнения задачи

Итак, имея статусы задачи и ее трудоемкость, как нам оценить ход работ?

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

Можно попробовать запланировать завершение отдельных этапов задачи. В вышеприведенном примере мы использовали 21 этап, каждый распланировать невозможно. Выберем основные — завершение проектирования, завершение кодирования, завершение всей задачи. Запланируем дату для каждой задачи, будем контролировать отклонения. Это кажется посильным. Однако при одновременной работе над большим количеством задач увидеть что-то в нескольких сотнях отклонений и сделать правильные выводы довольно сложно. По каждому отклонению будет объяснение, объективная причина. Что-то будет сделано с опозданием, что-то быстрее.

На одном из проектов мы пытались использовали метод контроля по датам. Плановую дату ставили исполнители. Факт автоматически записывался в системе при переходе из в соответствующий статус.



На рисунке — гистограмма отклонений по дате готовности функционального дизайна (ФД). Положительные значения показываю опережение, отрицательные — отставание графика. Видно, что самое большое количество ФД исполнители сдают с отставанием от 3.8 до 1.7 дней. При этом крайние значения от 43 дней опоздания до 67 дней опережения.

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

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

Если вы хотите что-то контролировать, подумайте, что вы будете делать с результатами контроля, какие решения вы можете принять на основании собранных данных?

6. Метод освоенного объема

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

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

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

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



После того, как такая таблица составлена, для каждой задаче можно определить, сколько человек-дней из плановых уже освоено и таким образом измерять ход исполнения по каждой задаче.
Например, задача имеет плановую трудоемкость 10 чд на дизайн и 20 чд на разработку. Тогда на стадии тестирования мы считаем, что она выполнена на 80% в части работы аналитика (осталось еще 20% трудозатрат на завершение тестирования) и 50% — в части работы разработчика. Мы готовы признать, что по дизайну отработано 8 чд, а по разработке — 10 чд. Итого, из 30 человеко-дней 18 уже завершено.

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

7. Отчетность по проекту

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

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

Общая картинка по проекту становится удобной для представления на уровне руководства:

Сводная таблица на основе выгрузки из JIRA



контроль план-факта по всему проекту





Данный метод не всегда находит понимание. Мифические человеко-дни менее понятны, чем штуки разработок. И он не отменяет детального планирования на уровне группы и отдельных исполнителей. Вместе с тем это наиболее объективный метод оценки текущей ситуации и прогнозирования завершения работ.