Итерационное проектирование на проектах внедрения

Сибгатуллин Айрат, руководитель проектов DIRECTUM

В последнее время на проектах внедрения возникает всё больше специфичных задач, решение которых вызывает определенные сложности: отсутствуют «лучшие практики», нет четких требований к результату, до конца не ясна целесообразность автоматизации. Уверен, у каждого найдутся подобные примеры. Их объединяет одно: речь идет об уникальных процессах организаций со сложной методологией или процессах, которые существуют только «на бумаге» или «в головах». Данная статья посвящена нашему опыту реализации подобных проектов.

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

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

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

Быть гибким

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

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

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

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

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

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

●   Большая нагрузка на специалистов заказчика в течение всего проекта. Оценка получаемых результатов, принятие решений и корректировка требований требует значительного времени не только ИТ-специалистов, но и всех участников, задействованных во внедрении (ключевых пользователей и руководителей).

Ищем бизнес-ценности

В результате первоначального исследования должно сформироваться четкое понимание того, чего предстоит достичь. Можно долго и мучительно описывать процессы в формате «как есть» и «как будет», но в будущем они будут мало полезны, т.к. усилия будут сконцентрированы не на проектных документах, а на работающей системе. Поэтому более правильным будет фиксация требований сразу в журнал пожеланий в формате «как должно быть» и «почему». Это будет основной документ (и возможно единственный), с которым предстоит далее работать. Во многом он будет напоминать классический бэклог по Scrum.

Расставляем приоритеты

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

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

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

Размер итерации

Существует много взглядов на длительность одной итерации. Мы пробовали продолжительность от одной недели до месяца. В первом случае, этого оказалось слишком мало и за этот срок не удавалось получить более-менее готовый результат для демонстрации заказчику. Во втором случае, команда начинала увлекаться, делая функциональность, от которой после демонстрации пришлось отказываться. Оптимальной оказалась длительность в 2 недели. Важно, что ни под каким предлогом мы не уменьшаем и не увеличиваем этот размер на протяжении всего проектирования. С одной стороны, это постоянно держит команду в тонусе, с другой – дает возможность планировать работы с горизонтом до 2-3 месяцев.

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

Бывает достаточно сложно спрогнозировать, сколько итераций займет тот или иной блок. В первом приближении достаточно взять количество пожеланий из бэклога функционального блока и распределить их между двухнедельными итерациями. Опытным путем мы пришли к тому, что наиболее сложные блоки («красные») занимают не менее трех итераций, «желтые» - не более двух, «зеленые» возможно выполнить за одну. Обеспечивая равномерную загрузку команды, можно составить первоначальный план-график выполнения работ. При этом всегда помним о том, что работы по любому блоку могут затянуться на большее количество итераций. Поэтому план-график следует пересматривать каждый раз перед началом новой итерации.

Оценка ресурсов

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

●   Обычно заранее известно, сколько специалистов привлекается на проект. Допустим два аналитика, два разработчика и один руководитель проекта;

●   Итерационное проектирование требует полного погружения аналитиков и разработчиков на весь период. Исходим из того, что 90% своего времени они будут погружены в проект, а руководитель проекта на 50%;

●   В неделе 40 рабочих часов;

●   По первоначальной оценке потребуется 6 двухнедельных итераций;

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

Состав итерации

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

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

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

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

Исход итераций

Любая итерация завершается демонстрацией системы. На первой итерации демонстрируется реализация ключевых пожеланий самого сложного блока. В этот момент от заказчика поступает множество замечаний о том, что «все не так» и «все должно быть иначе». И это нормально! Именно для этого мы затеяли итерации, чтобы корректировать свою работу с заказчиком с первых дней проекта. Скорее всего, придется выкинуть все, что было сделано за две недели и на следующей итерации сделать по-другому. В этот момент важно помнить о том, что в следующую итерацию необходимо взять еще один функциональных блок. Стоит дать слабину и сдвинуть его на следующую итерацию, как у вас «поплывет» весь первоначальный план. Даже при острой нехватке ресурсов, работы по блоку начать необходимо, по крайней мере взяв меньше пожеланий из бэклога. В результате на второй демонстрации заказчик получит дополнительный результат и увидит прогресс.

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

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

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

Результаты

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

Итерационный подход мы начали применять на проектах с труднопредсказуемым положительным результатом с целью уложиться в установленный бюджет. Не скажу, что мы вышли «в ноль», но удалось удержать превышение в рамках 5-10%, что вполне приемлемо и компенсируется на этапе внедрения за счет меньшего количества пожеланий. В действительности оказалось, что ничего не мешает применять итерационный подход и на типовых проектах. Сокращение трудоемкости при этом достигает 40% при одновременном повышении качества продукта.

Выученные уроки

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

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

●   Отказываясь от проектных решений, остаются размытыми рамки проекта. Бывает сложно определить, входит ли новое замечание заказчика в первоначальные договоренности или нет.

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

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

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

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

Источник: GlobalCIO