Не все ИТ-проекты заканчиваются релизом и положительно влияют на метрики. Если ваш проект наткнулся на препятствия, а команда зашла в тупик, нужно искать оптимальный выход и перестраивать процессы.
Рассмотрим, что делать, если корпоративный проект не двигается с места и команда не понимает, что ее блокирует.
Как понять, что проект и его процессы нужно пересмотреть
Тупиковые ситуации в крупных компаниях и холдингах схожи, несмотря на различия в отраслях. У ИТ-команд производственных предприятий и ритейла могут быть разные проблемы, но общие цели, такие как упрощение документооборота, увеличение выручки и привлечение клиентов. Директор и руководитель ИТ-отдела должны рассмотреть цифровую трансформацию и изменения в следующих случаях.
1. Проектные процессы непонятны, плохо описаны
Улучшать и автоматизировать процессы легко, когда они описаны, формализованы и постоянно используются. Но бывает, что этапы работы и правила прозрачны только на бумаге. Если команда проекта не понимает, в чем суть процесса и как ему следовать, ничего улучшить и автоматизировать не получится.
Пример. Процессы в ИТ-команде основаны на Scrum. Все устроено идеально: регулярные встречи, планирование, ретроспективы, распределение ролей. Но команда не понимает, зачем ей встречи, поэтому дейлики превращаются в формальность, а ретро не помогают улучшить результаты разработчиков. Метрики ухудшаются, сроки горят, бюджета не хватает, а руководство считает, что Scrum не работает.
На самом деле проблема не в Scrum или команде. Она появилась из-за того, что пропущен подготовительный этап перед оптимизацией. Нужно не только разработать четкую методологию, но и объяснить команде, как появился регламент и зачем нужны указанные в нем процессы. От качества проработки этих двух аспектов зависят сроки, эффективность работы и результат.
Непонятными часто становятся требования в ТЗ. Например, когда запрос звучит так: «Сделайте мне большую зеленую кнопку, которая все решит». Но команда не знает, что именно должна делать кнопка, откуда брать данные, куда их отправлять. Цели формируются в процессе, это задерживает релизы.
Кроме того, результат может не совпасть с абстрактным желанием стейкхолдеров и не оправдать их ожидания. Здесь руководителю проекта тоже придется уделить время планированию и регламентированию.
2. У команды нет общего видения и взаимопонимания
Второе узкое место для проекта — отсутствие согласованности внутри команды. Если бы проект от начала до конца вел один человек: разрабатывал решение, отвечал за его реализацию, документировал процесс и получал оплату после удовлетворения всех сторон, управление было бы простым. Но такого почти никогда не бывает.
Пример. На реальных проектах команда из
Такой проект требует выстроенных процессов и понятных регламентов, чтобы результат был предсказуемым. Особенно это касается документирования того, что именно делается, почему принимаются те или иные решения и какие требования вызывают изменения.
Важно, чтобы в команде передавались знания. Поэтому руководителю нужно отслеживать, как команда взаимодействует, валидирует и фиксирует решения, согласовывает их с заказчиком. Отлаженная коммуникация поможет команде двигаться вместе, без расхождения на несогласованные траектории.
3. Команда не может настроить коммуникацию с менеджером на стороне клиента
Вовлеченность важна не только со стороны руководителя команды, но и со стороны клиента.
Пример. Бывают ситуации, когда инициативу проявляет один человек со стороны заказчика — функциональный заказчик или лицо, принимающее решения (ЛПР). Он заинтересован в реализации проекта, но остальная часть команды клиента либо не видит ценности в проекте, либо не считает его приоритетным.
На проектах нужно, чтобы вовлеченность была полной. Руководитель должен видеть не только формальное участие, но и выделение времени и ресурсов лидера со стороны клиента, который возьмет на себя ответственность за проект. Если этого нет, руководитель должен помочь команде настроить общение с ЛПР. Когда обе стороны заинтересованы в результате, ожидания чаще совпадают с реальностью.
4. Команда неправильно выбрала методологию проекта
Еще одно узкое место на проекте — неправильный выбор методологии. Выбирать методологию управления проектами также нужно отталкиваясь от того, как часто потребуется вовлечение заказчика и готов ли он погружаться и прилагать усилия.
Пример. Допустим, команда выбрала классический подход Waterfall, в начале проекта детально проработала техническое задание и определила задачи на все этапы проекта. На первый взгляд, это логично: все формализовано и зафиксировано. Однако на практике планирование может длиться месяцы, а реализация из-за обстоятельств занимать два-три года. За это время изменятся бизнес-задачи клиента, состав команд и ситуация на рынке.
В результате продукт, построенный по изначальным требованиям, к моменту завершения проекта уже не будет соответствовать нуждам заказчика. Из-за строгой водопадной модели команда часто не может подстроиться под изменения.
Чтобы избежать этого, руководителю важно заранее продумать методологию, исходя из специфики проекта. Например, выбрать гибкий Agile или Scrum. Они позволят регулярно получать результаты и показывать их заказчику на ранних этапах, чтобы он вносил коррективы по ходу работы.
Безусловно, гибкие модели подойдут не на всех проектах. В некоторых случаях классический подход остается предпочтительным, например, при моделировании крупных систем для государственных организаций. Тогда руководителю нужно учитывать риски, связанные с длительной реализацией проекта.
5. На проекте с неопытной командой нет вовлеченного руководителя
Если с новичками не работает ментор, а заказчик не погружается в ход проекта, это приводит к распылению ресурсов, размыванию конечной цели и неизбежным задержкам.
Пример. Пытаясь сократить расходы, подрядчик или заказчик иногда решают реализовать проект силами начинающих специалистов. Это работает, если цель — обучение новых сотрудников и вовлечение их в реальные задачи. Но работать это будет только под надзором сильного куратора и опытных экспертов. Без этого проект рискует превратиться в поле для экспериментов, поэтому увеличивается риск задержек и ошибок.
При этом бывает, что руководитель проекта теряет интерес и делегирует проект своим заместителям. Заместители начинают выдвигать свои требования, которые расходятся между собой. В итоге неопытная команда сталкивается с тем, что нужно удовлетворить 20+ разных запросов, не стыкующихся с целью проекта.
Чтобы предотвратить такие ситуации, новички должны работать под контролем опытного разработчика, лидер со стороны заказчика должен отвечать на запросы, а требования должны быть четкими.
Что делать, если проект зашел в тупик
Если на вашем проекте чего-то из этого не хватает и вы уже зашли в тупик, можете оттолкнуться от следующей инструкции.
Шаг 1. Провести анализ текущего состояния проекта
Первый шаг к решению проблемы — объективная оценка текущего состояния проекта. Нужно:
- понять, где находится проект — что реализовано и что работает;
- провести анализ соответствия первоначальных требований фактическому состоянию. Узнать, что выполнено, что в процессе, какие изменения вносились в ходе работы;
- проверить артефакты. Найти документацию по изменениям, новые требования и методы оценки работы.
Особое внимание стоит уделить самому результату: если заявлено, что проект готов на 95%, нужно выяснить, что проценты означают на практике. Бывает, что 95% — это написанный, но не протестированный код, а оставшиеся 5% превращаются в полгода доработок.
Для выявления проблемных зон можно провести анализ проекта с помощью инструментов для автоматизированного мониторинга и анализа производительности. Они помогут оценить работу отдельных компонентов системы, выявить проблемы в инфраструктуре и собрать другие данные.
После диагностики важно решить, что делать дальше. Определите:
- какие шаги потребуются, чтобы перейти от текущей «точки А» к желаемому результату в «точке Б»;
- какие части проекта нужно дорабатывать, какие оставить, а какие полностью заменить.
Иногда целесообразно отказаться от попыток завершить оставшиеся задачи. В отдельных случаях лучшим решением становится полное перепроектирование. Практика показывает, что отказ от старых решений в пользу новых чаще приводит к успеху, чем долгое «спасение» проекта.
Шаг 2. Автоматизировать процессы управления проектом
Второй шаг — настройка процессов. Автоматизация управления проектом упростит планирование, распределение задач и отслеживание прогресса. Для этого можно использовать специализированные системы управления проектами и описания бизнес процессов.
Если вы сами обращаетесь к профессионалам для реализации проекта, обратите внимание, чтобы у них были отлажены процессы.
Например, подход, который помогает подключаться к проекту на любом этапе: в начале, в середине и на финальном этапе. Еще одним преимуществом буду дополнительные расширения, которые позволяют не только внедрять ИС, но и добиваться максимальной эффективности для решения конкретных задач бизнеса.
Шаг 3. Постоянно совершенствовать процессы
На всех этапах проекта важно внедрять подходы к непрерывному улучшению. Для этого используются автоматизированные инструменты мониторинга и оптимизации рабочих процессов.
Настройка автоматизированных тестов позволяет экономить огромный объем ресурсов как у заказчика, так и у подрядчика.
Как это работает на практике
В качестве примера можно привести проект в одном международном холдинге, который сотрудничал с подрядчиком. Этот проект шел уже больше года, но получить работающую модель не получалось.
На этапе реализации в проектной команде возникли трудности: смена участников, привлечение недостаточно квалифицированных специалистов и слабый уровень управления процессами. Данные факторы привели к несогласованным решениям, что отразилось на функциональности и производительности системы. К концу сроков основные задачи не были выполнены: не было нужной функциональности, производительность не соответствовала требованиям. Возникли конфликты, сроки сдвинулись, а проблемы не решались.
Эксперты начали с анализа текущего состояния проекта. То есть, выявили критические проблемы и части проекта, которые требовали полной переработки. Стояли следующие задачи:
- переработать самые важные элементы системы, часть перестроить с нуля;
- реанимировать работоспособные части с минимальными доработками;
- регулярно показывать результаты работы и решенные задачи для прозрачности.
В ходе работы оказалось, что часть проекта находилась в состоянии
Требовалось провести детальный аудит проблемных мест, изучить документацию, системы регистрации изменений и показать заказчику, что локальные исправления не решат проблему. Даже после устранения текущих ошибок проект не мог быть устойчивым. Чтобы не маскировать проблемы, часть блоков пришлось перестраивать с нуля.
Каждый блок был проработан, протестирован и приведен к финальному виду.
Подводим итоги
Для выхода из проблемной ситуации на проекте нужно оценить его текущее состояние и выявить расхождения между требованиями и результатами. Затем внедрить и настроить под себя систему управления проектами. И после этого регулярно проверять, что все идет по плану, постепенно вводить лучшие практики и улучшать процессы.
Если вы задумываетесь об оптимизации и автоматизации, сначала объясните команде ее цели и важность каждого процесса. Затем, как руководитель, настройте передачу знаний внутри команды, особенно от экспертов к новичкам, и помогите с вовлечением представителей заказчика. Если проект зашел в тупик, посмотрите, что можно доработать, а что проще построить с нуля. Иногда реинжиниринг и подключение опытных подрядчиков — лучшее решение.
