Привет, Хабр! Я Константин Сошнев, бизнес-аналитик портфеля продуктов «Цифровой вагон» в ПГК-Диджитал. Мы занимаемся созданием цифрового двойника грузового вагона, повышаем точность информации о текущем состоянии вагона, помогаем своими инструментами снижать совокупные расходы на ремонт и увеличивать производительность вагона.
Очень часто IT-проекты фокусируются на разработке, настройке и внедрению информационной системы, упуская из вида вопросы трансформации существующих бизнес-процессов и обеспечения приживаемости продукта в рамках этих самых процессов. Это может привести к тому, что затраченные на разработку информационной системы ресурсы не окупятся и не принесут ожидаемого эффекта владельцу бизнеса. Сегодня в условиях значительного влияния различных факторов российским компаниям стоит переосмысливать расстановку границ IT-проектов и фокусироваться на приживаемости систем не меньше, чем на самой разработке.
Такой подход, в классическом понимании, можно отнести к IT-продуктам, ориентированным на результат. Основная цель – максимально полно определить функциональный набор, который должен выполнять продукт для удовлетворения изначально выявленных требований заказчика, и определить те из них, которые можно реализовать в текущем проекте.
Project scope, или границы проекта, путем декомпозиции глобальной задачи, показывают нам, какая часть конечного продукта будет реализована в текущем проекте. Проще говоря, определяем черту между тем, что реализовываем сейчас и тем, что отложим на потом или от чего вовсе откажемся. Границы проекта помогают нам не только качественно спланировать объем работ, но и пригодятся для удержания непомерных желаний заказчика. Самое главное, что при определении границ проекта нужно использовать функции, а не сущности предметной области, которые могут привести к ряду негативных последствий.
Помимо проектов, ориентированных на продукт, не стоит забывать и о проектах, ориентированных на результат. Результат может быть оценен как с финансовой точки зрения, так и со стороны имиджа компании (социально-экономической точки зрения). Почти всегда заказчик проекта оценивает его эффективность по возврату вложенных инвестиций и срокам выхода на полную окупаемость. При этом исполнитель (IT-блок) для объективной оценки выполненных работ должен использовать существующие стандарты в области управления проектами. Если посмотреть со стороны менеджера IT-проекта, он должен ответить на три вопроса:
уложился ли проект в запланированный объем ресурсов;
уложился ли проект в запланированные сроки;
уложился ли проект в запланированный бюджет.
Если везде «да», формально проект можно считать успешным. В любом случае правильное планирование, декомпозиция задач, сбор и анализ требований бизнеса уже являются половиной успеха проекта. Но не стоить забывать, что успех проекта, не тождественен успеху продукта и не гарантирует возврат инвестиций и прибыли в полном объеме.
Здесь нам не обойтись без правильно сформированных метрик приживаемости и четкого понимания, какой реинжиниринг бизнес-процессов необходимо (если необходимо) провести.
Метрики приживаемости – это количественные показатели проекта, которые позволяют оценить результативность работы и работоспособность модели. Метрики необходимы для фокусировки внимания на показателях проекта, как со стороны бизнес-заказчика, так и продуктовой команды, так как процесс разработки и реинжиниринг бизнес-процессов – это два неразрывных действия в рамках одной компании. Любое IT-решение должно улучшать процессы и идти, как минимум, в рамках стратегических целей компании, а в идеале – опережая их, предлагая инновационные решения. Если со стороны разработки успех зависит в основном от определения требований к реализации, планирования работ и от компетенций команды, то со стороны бизнеса основной успех на этапе внедрения в бизнес модель – это преодоление психологических барьеров к изменениям. Зачастую присутствует страх, что новое IT-решение заменит тебя, как специалиста, полностью.
По личному наблюдению отмечу, что за время работы в бизнес-анализе IT-компании, тесно взаимодействуя с заказчиком, уровень сопротивления к изменениям возрастает с увеличением опыта работы, но бывают и исключения. В основном эти специалисты всю свою профессиональную жизнь провели в определенных привычных условиях и не хотят выходить из зоны комфорта. Наиболее открытые к инновациям – это молодые специалисты, которые только начинают себя пробовать в различных профессиональных ролях, не любят рутину и видят горизонты расширения своего опыта за счет автоматизации процессов. Если со второй группой работается легко и быстро, то с первой иногда требуется применение инструментов управления изменениями.
Каждый специалист, вне зависимости от возраста или занимаемой должности должен быть вовлечен в процесс разработки, внедрения и эксплуатации. Да, к сожалению, очень часто судьба готового продукта может зависеть только от человеческого фактора. Чтобы этого избежать и грамотно внедрить готовое IT-решение, в «сложных» ситуациях, приходится задействовать инструмент KPI (key performance indicators – это числовые показатели деятельности, которые помогают измерить степень достижения целей или оптимальности процесса, а именно: результативность и эффективность, в крайне редких случаях административный ресурс, в лице вышестоящего руководителя). По примеру нашего продукта можно сказать, что спустя два года мы достигли максимального консенсуса и хорошо отладили процесс взаимодействия с представителями бизнес-заказчика.
Большинство метрик по нашим проектам (как на текущий момент, так и в исторических данных) можно посмотреть, отрыв аналитическую платформу данных. Ниже приведен пример метрик приживаемости: количество сессий, которые показывают, как часто пользователи используют реализованный продукт, и количество самих пользователей, где мы видим, что после запуска продукта, на второй месяц произошло ухудшение показателей. Получив данную статистику мы оперативно провели анализ причин, выявили факторы и предприняли меры для стабилизации положения (в том числе потребовалась незначительная доработка продукта), после чего показатели стабилизировались и зафиксировались на уровне выше чем на старте проекта.
Мое четкое убеждение: правильно определенные метрики на этапе проработки требований и при необходимости их уточнение после внедрения, выгодны как заказчику, так и команде разработки. Это позволяет создать востребованный и удобный продукт, показывает необходимость мониторинга показателей приживаемости. В идеале описанную ситуацию лучше не допускать, мониторинг необходимо вести с первого дня запуска, кроме того, нужно собирать обратную связь от пользователей на предмет соответствия ожиданиям по наличию информации и удобства использования.