Особенности контроля ИТ-проектов: как не утонуть в дедлайнах и бюджете, создавая сложный технологический продукт
Хороший план — еще не гарантия успеха. Многие руководители искренне верят: если в начале проекта всё детально расписать, дальше система сработает сама. Практика показывает обратное. Каждый второй ИТ-проект требует изменений в процессе внедрения. Бизнес теряет деньги, команды выгорают, а заказчики остаются недовольны. Где именно система управления дает сбой? Разберем основные причины и способы их устранения.
Главная ловушка: статичный план в динамичном мире
План, утвержденный в начале проекта и больше не меняющийся, — это иллюзия контроля. План должен быть гибким инструментом, который корректируется по ходу работы, а не застывшим документом. Когда проект выбивается из сроков, причина всегда одна: что-то не учли на этапе планирования. Технические сложности, зависимости от сторонних систем или человеческий фактор — все это проявляется позже, а исправлять последствия приходится уже в процессе.
Можно ли предсказать проблемы заранее? Да. Самый очевидный маркер — размытое понимание результата. Если заказчик формулирует задачу абстрактно, а исполнитель понимает её по-своему, конфликт интерпретаций неизбежен. И чем позже он вскроется, тем дороже обойдется исправление.
Цифры: В 35% случаев готовый продукт не соответствует бизнес-требованиям именно из-за неверно сформулированных целей на старте.
Кто отвечает за результат
Когда проект становится убыточным, ищут виноватых исполнители часто винят неподъемные требования заказчика, заказчик работ квалификацию исполнителей. Но если разобраться профессионально:
- Заказчик в большинстве случаев не виноват. Его дело — формулировать потребности. Задача исполнителей — правильно их интерпретировать, согласовать с заказчиком и реализовать.
- Исполнитель без четкой постановки и регулярного контроля неизбежно ошибется.
- Ответственный от исполнителя. Именно руководитель проекта и тимлид выступает переводчиком между заказчиком и исполнителем. Они должны «разжевать» задачу до состояния кристальной ясности и проследить за исполнением.
Взаимодействие с командой можно сравнить с отношением к детям: если вы не объяснили, не проконтролировали и не проверили, результат будет непредсказуем. Как сделать это? Ваша задача оцифровать бизнес процессы, с помощью которых ошибки и недопонимания будут выявляться на раннем этапе. Начнем с подходов к управлению проектами в ИТ.
Три основных подхода к управлению ИТ-проектами
Идеальной методологии нет. Есть однако условное деление на разные подходы (методологии) в разработке. Важно понимать: чистые методологии встречаются редко. Сегодня большинство команд выбирают гибридные модели. По данным исследований, 55% проектов используют смешанные подходы. На практике это выглядит так: Такой гибрид позволяет сохранить предсказуемость и гибкость одновременно. Но помните: нет правильного или неправильного подхода. Есть подход, который подходит именно вашему проекту. Выбор методологии решает только часть вопросов, далее нужно выстроить систему управления процессами и начинать надо с распределения ответственности. Четкое распределение зон ответственности. Создайте документ (RACI или матрицу ответственности), где черным по белому написано, кто за что отвечает. Это исключает ситуацию «Миша думал на Костю, а Костя — на Мишу» или «Миша делал за Костю поэтому не успевает выполнять свои задачи». Также нужно вести детальное планирование и оцифровку задач. Есть пять моделей: Задача считается поставленной только тогда, когда принята исполнителем и одобрена компетентным лицом, задачи должны выполняться в конкретные временные сроки желательно не более 8 часов, т.е. должны быть разбиты так, чтобы легко видеть динамику исполнения в разрезе в рабочего дня, что позволяет оцифровать процессы. Если вы не можете выразить результат в цифрах (показателях эффективности), вы не можете им управлять. Показатели должны быть динамичными и иметь возможность пересматриваться по ходу исполнения. Но, как же без «но», бывают разные ситуации, допустим все же произошел форс мажор и изменение планов, что нужно делать. И как вывод можно привести три следующих основных правила при исполнении проектов: Создание ИТ-продукта — это всегда балансирование между желаниями заказчика, возможностями команды и суровой реальностью. Утонуть в дедлайнах и выйти за рамки бюджета проще простого, если полагаться на авось и абстрактные договоренности. Удачных проектов!