Оценка эффективности ИТ-проекта: Новые подходы в условиях импортозамещения

Дмитрий
Левшин

Наиболее часто непосредственное получение прибыли и есть главная цель внедрения того или иного ИТ-решения

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

Объективная и субъективная оценка

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

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

Со стороны заказчика под эффективностью того или иного ИТ-проекта стоит понимать, в первую очередь, возврат инвестиций по нему и выход на окупаемость. Исполнитель для объективной оценки выполненных работ может использовать наработанные стандарты в области управления проектами. Для менеджера проекта это, например, проектный треугольник – модель, описывающая проект с точки зрения трех его главных компонентов: сроков, бюджета и содержания. Соответственно, успешным можно назвать проект, при реализации которого менеджер проекта уложился в запланированный объем ресурсов, стоимость, сроки, выполнил все определенные в документации работы – причем не только по формальным показателям, но и с точки зрения удовлетворенности заказчика. Второй пункт – это очень важный нюанс, который можно легко упустить из виду. В индустрии разработки ИТ-проектов встречаются ситуации, когда формально всё выполнено по контракту, но заказчик получает систему не совсем с той функциональностью, которую ожидал.TrafficSoft ADC: балансировщик нагрузки с высокой скоростью работы и минимальными аппаратными требованиями

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

Факторы успешности проекта

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

По нашему опыту, нужно очень внимательно подбирать конкретных людей на конкретный проект. Привлекать наиболее компетентные команды как в части технической экспертизы, так и в части внутреннего взаимодействия специалистов. Учет soft skills, работа с мотивационными профилями здесь не менее важны, чем hard skills. Бывают ситуации, когда разработчик технически подготовлен к тому, чтобы выполнять те или иные задачи, но он, например, привык работать в одиночку или только с конкретными коллегами. На крупных проектах, в командах по 10-40 человек, он может проявить себя менее эффективно, конфликтовать и вредить эмоциональной стабильности коллектива, что, как следствие, негативно повлияет на качество и сроки проекта.

Проектный менеджер, кроме того, должен владеть современными методологиями управления разработкой (Kanban, Scrum, Agile) и инструментарием (системы управления проектами, таск-менеджеры, планировщики). Одна из его задач на этапе планирования – выбрать ту или иную методологию и в процессе модифицировать ее под конкретные реалии проекта.

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

Импортозамещение требует экспериментов

Ситуация, которая сложилась в России в 2022 году, кардинально изменила взгляд компаний на ИТ-инфраструктуру. Сегодня новые ИТ-проекты всё чаще связаны с импортозамещением, а оно всегда сопровождается оценкой рисков, сложившихся из-за ухода с рынка зарубежных вендоров. Поэтому с точки зрения риск-менеджмента импортозамещение – очень эффективный инструмент для компаний, которые не хотят, чтобы их работоспособность зависела от неуправляемых внутренним законодательством ИТ-решений.

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

Например, в 2022 году мы проработали возможность перевода корпоративного хранилища данных «Почты России» с Vertica на продукты отечественного вендора Arenadata^[1]. В отличие от типовых проектов, целью данной инициативы был не определенный конечный результат в виде полнофункциональной системы, а именно исследование самой возможности бесшовной перегрузки данных из одной системы в другую: какие для этого требуются доработки, какая будет производительность на новой системе, насколько это в целом реализуемо, нужно ли рассматривать другие варианты?

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

Данный пилот завершился успешно: мы провели анализ, передали результаты заказчику, после чего он принял окончательное решение проводить миграцию СУБД на ArenaData DB. В том числе, сейчас он привлекает специалистов IT_One к реализации данной задачи.

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

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

Важность сбалансированного подхода

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

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

Примечания