В первой части статьи я описал теоретическую часть и прописал желательность использования информационной системы для ведения задач по проекту и учета времени (Service desk). Давайте перейдем к описанию жизненного цикла проекта и как на каждом этапе я в своей практике управляю проектами.
Старт проекта (Agile + Waterfall)
На самом первом этапе необходимо декомпозировать проект на этапы. Идея в течение одного-двух лет что-то проектировать, программировать обычно не работает, так как за год меняются процессы, как следовательно, общий результат оказывается не таким, какой нужен бизнесу. Если перед нами стоит задача запустить проект в срок, то необходимо на верхнем уровне использовать подход Agile и разбить проект на несколько «длинных спринтов» продолжительностью 2-4 месяца. Недельные или месячные спринты хороши при разработке порталов или внедрения стандартных платформ – но, если мы говорим об автоматизации производства или логистики, то законченные блоки, готовые для использования бизнесом, быстрее реализовать нереально.
При этом для определения сроков каждого этапа без классического подхода (waterfall) не обойтись. В своей практике я использую MS Project и на верхнем уровне разношу блоки проектирования, разработки, тестирования и стабилизации – тем самым формируя даты для дальнейшего контроля. Примерный начальный план может выглядеть следующим образом:
Красным выделен подход Agile, в рамках которого проект был декомпозирован на три этапа. Для первых двух этапах мы уже понимаем объем проектирования и можем назначить конкретные задачи на определенных исполнителей. Разработка/тестирование и стабилизация обозначены одной задачей. По мере готовности дизайнов блок разработки будет декомпозироваться, по мере завершения программирования – будут появляться задачи в блоке тестирования, и т.д. MS Porject, используя Waterfall подход, позволяет перераспределяя ресурсы смотреть влияние на сроки. Это удобно и позволяет, обозначив крайние сроки оперативно реагировать на выход за обещанные даты в процессе проекта.
Проектирование и базовая разработка (WaterFall)
В проектировании и базовой разработке на основании технических дизайнов я предпочитаю использовать WaterFall. Если мы говорим о большой ERP системе, то работа без архитектора и детальной проработки всех узлов системы с высокой степени вероятности приведет к тому, что функциональные блоки не будут стыковаться с друг другом, будут использовать разные справочники, а часть информации будет дублироваться. Нельзя забывать, что дизайн, должен быть понятен бизнесу – очевидный факт, добавить пропущенные требования или изменить спроектированные алгоритмы на несколько порядков проще и дешевле в Word, чем в готовой информационной системе.
При этом ставить одну задачу на проектирование всей функциональности на несколько сот часов очень рискованно. В этом случае нет контроля на возможное увеличение трудоемкости, о которой станет известно за пару дней до сдачи дизайна. Поэтому задачи по проектированию я стараюсь ограничить 40 часами, в крайних случаях – 80 часами. Важный момент: для меня количество дизайнов должно быть в пределах десятка. У меня были практики участия в проектах, в рамках которох разрабатывались сотни технических документов – на выходе постоянные перекрестные ссылки, противоречия между документами, путаница на стороне бизнеса.
При грамотной декомпозиции, кроме контроля выполнения и получения оперативной информации об увеличении трудоемкости или появлении новых требований, я вижу следующие преимущества:
- Гибкость – разные части дизайнов могут проектировать разные архитекторы. Понятно, что контроль последовательности работ полностью на стороне руководителя проекта и на первом этапе необходимо спроектировать ядро функциональности и основной бизнес процесс. После параллельно можно проектировать интеграцию с другими системами, загрузку начальных данных, отчетность, и даже начинать разработку согласованных блоков.
- Вовлеченный бизнес – каждый законченный блок дизайнов необходимо сразу согласовывать с бизнесом, и даже во время проектирования готовые функциональные блоки отправлять на ознакомление заказчикам. Участие бизнеса в процессе проектирования уменьшает объем документации, который необходимо читать, позволяет уточнять и добавлять требования в процессе работы. Как результат согласование документов идет более оперативно и бизнес, чувствуя себя полноценным участником процесса, настроен более доброжелательно.
- Одна голова хорошо, а несколько лучше – участие нескольких архитекторов в проектировании уменьшает количество ошибок в разы, из-за перекрестного анализа и совместных обсуждений.
В своей практике при разработке дизайнов, стараюсь придерживаться следующей практики: один раздел дизайна – одна задача в будущем на разработчика. Таким образом дизайн содержит описательный раздел, после чего описывает добавление или изменение объектов в системах. При применении описанного подхода, готовые и согласованные дизайны почти автоматически превращаются в задачи для разработки. Здесь более жесткие требования по объему задачи – максимум 16 часов, допустимо 32 часа, но это крайне редкое исключение – здесь предпочитаю выполнять дополнительную декомпозицию. Надо понимать, что риск изменения трудоемкости или появления проблемы на этапе программирования могут оказать серьезный негативный эффект на проект.
В своей практике я использую два уровня загрузки разработчиков на проекте: 80% и 50%. 80% используется для программистов, полностью задействованных на проекте. Почему не 100%? Страховой запас 20%, который защищает от рисков отклонения фактической трудоемкости от запланированной и закладывает страховую подушку на случай появления новых требований. Не говоря о том, что на команду положительно влияет факт того, что мы идем с опережением, а не отстаем. 50% используется, если разработчик участвует параллельно в устранении замечаний или в другой активности этого или другого проектов.
Внешне план работ по разработке согласованного дизайна может выглядеть приведенным ниже образом – несколько лесенок по числу разработчиков в команде:
Естественно весь массив задач как по проектированию, так и по разработке фиксируется в системе Service Desk. С самого начального этапа мы начинаем собирать и использовать статистика по проекту. При работе с MS Project – номера задач фиксируются в отдельном ссылочном поле, что позволяет в один клик посмотреть статус задачи в системе и отобразить его в MS Project. Благодаря системе Service Desk данный процесс выполняется менеджером проекта самостоятельно (без ручного сбора обратной связи от членов команды), и занимает не более 30 минут в день. При этом, при сдвиге задач, очень удобно выполнять перепланирование в Project, отражая изменение плановых дат и ответственных в системе Service Desk. Чтобы минимизировать объем ручного редактирования задач, в своей практике планирую задачи на конкретных исполнителей в системе Service Desk не более чем на две недели вперед.
Таким образом на выходе мы получаем «гибкий» Waterfall со следующими ключевыми преимуществами:
- Оперативное управление в реальном времени – за счет декомпозиции задач и управления ресурсами и временем.
- Понимание обоснованных сроков проекта – мы видим весь массив работ и видим сроки завершения с учетом загрузки команды.
Используя данных подход, мы приходим к этапу внутреннего тестирования, которое переходит в бизнес тестирование.
Поддержка тестирования, стабилизация (Agile)
Прекрасно работающий на предыдущем этапе подход Waterfall с самого начала тестирования начинает давать сбои. Основные изменения на данном этапе:
- Количество задач начинает измеряться десятками, а то и сотнями.
- Современные системы Service Desk поддерживают автоматизированное создание задач на каждое замечание обнаруженное во время автоматического или внутреннего тестирования.
- Сбором и консолидацией замечаний по внутреннему и бизнес тестированию в большинстве случаем занимаются выделенные члены команды, а не руководитель проекта.
Таким образом, если свести управление всем массивом замечаний на уровне руководителя проекта, с регистрацией каждой задачи в MS Project, с настройкой зависимостей, связыванием с системой Service Desk, то он станет узким местом и начнет тормозить процесс устранения ошибок. Используем гибкий подход, но видеть загрузку людей и количество замечаний не только в системе, но и визуально хочется. На выходе получается что-то наподобие доски ежедневного управления, но которую выносятся все поступающие замечания и доработки:
На листочках пишутся только номера задач и краткое направление проблемы (1-2 слова). Вся детальная информация, включая скриншоты, описания доступна в системе Service Desk. Цветами можно выделять разные этапы проекта или приоритеты задач.
Решенные задачи перевешиваются в правую часть доски, при этом, если ошибка повторилась или есть замечания от Code Review – ее достаточно просто вернуть в работу, перевесив листок обратно на левую половину доски. Понятно, что есть некоторое дублирование работы – кроме отражения задачи в системе Service Desk, ее еще надо оформить листочек и повесить его на доску, но преимущества более весомые:
- Вовлечение команды – возможность дружеских соревнований, тактильная работа с листочками, визуализация сделанного за неделю поднимает общее настроение и увлечение работой.
- Визуальное состояние проекта – одного взгляда на доску достаточно, чтобы понять как у нас идет тестирование/стабилизация проекта. Кто загружен замечаниями, кто успевает решать задачи, кто нет.
- Делегирование полномочий – регистрация задач и назначение листочков идет без непосредственного участия руководителя проекта. За ним остается только функция внешнего мониторинга и подключение в случае проблем. Что с одной стороны позволяет разгрузить руководителя проекта, с другой повышение мотивацию руководителей групп тестирования.
Таким образом у нас получается два разных подхода, используемых в рамках одного проекта на разных этапах. Вопрос заключается в их совмещении и интеграции, так как тестирование начинается во время базовой разработки и важно недопустить перегруза членов команды задачами из двух разных источников. Эта проблема решает благодаря системе Service Desk, в которой оба подхода объединяются в виде задач, и руководитель проекта в реальном времени может увидеть возникающие перегрузы и принять необходимые меры. Пример отчета, который показывает распределение нагрузки в часах по дням и по разработчикам приведен ниже, а логику его работы можно посмотреть по ссылке (текст на английском).
Основной вывод я формулирую следующим образом: в больших ИТ проектах, нацеленных на автоматизацию сложных производственных и логистических бизнес процессов необходимо быть гибким. Использование какого-либо одного подхода с высокой степенью вероятности приведет к срыву сроков или провалу проекта в целом. Необходима комбинация разных методологий, инструментов, способов работы в зависимости от масштаба проекта, текущего статуса и профессионализма команды. При этом система управления всем циклом разработки (включая управление временем) может стать той объединяющей силой, которая не позволит проекту превратиться в лоскутный и неуправляемый процесс.
Видео обзор моего опыта по управлению проектами доступен на моем канале YouTube: