10 ошибок менеджера при миграции на импортозамещенное ПО
Вполне возможно, у вас в компании есть софт, использующий проприетарное ПО. Что если оно оказалось под санкциями или уходит из страны? Вы находите свободный или российский аналог, и теперь вам нужно произвести миграцию.
Это может быть относительно простой задачей. Например, миграция на Яндекс.Почту или даже переход на использование отечественных CAD-систем (прим. ред. — Computer Aided Design, система автоматизированного проектирования, САПР) — не такой уж сложный проект. Однако, возможен гораздо более сложный вариант. Например, вам нужно уйти от использования проприетарной BPM-системы (прим. ред. — Business Process Management, управление бизнес-процессами). Или вам приходиться отказываться от целой экосистемы продуктов вроде Oracle.
Для того, чтобы обеспечить миграцию, нужно полностью или частично переписать ваши ИТ-решения на новых технологиях с переделкой всей бизнес-логики или даже пользовательского интерфейса.
В этой статье мы поговорим о втором варианте. Мы рассмотрим 10 типичных ошибок такой миграции и кратко расскажем, как их избежать.
Содержание статьи
Водопад
Строится рядом с нуля отдельный продукт в течении месяцев или даже лет. Потом проводится внедрение с большими проблемами, так как новая система большая и многое не учтено. Кроме того, за время разработки многое успело измениться и система не удовлетворяет текущим требованиям.
Что делать?
Нужно менять систему на лету инкрементально, запуская в продуктив и тестируя отдельные части системы. Фактически, в продуктиве одновременно должны находится две системы — старая и новая.
Отдельная команда
Отдельная команда или вендор занимается созданием нового ИТ-решения. Из-за того, что в новой команде никто не имеет знаний о реальных бизнес-процессах, ей приходится получать информацию из частично устаревшей документации и при помощи реверс-инжиниринга старого кода. Итоговый результат не имеет бизнес-ценности и содержит много ошибок.
Что делать?
Нужно создать смешанную команду, куда входят новые разработчики и эксперты из старой системы.
Гонка функциональности двух продуктов
Старый продукт продолжает развиваться — добавляется функционал, меняются бизнес-процессы. Декларированная «заморозка» функциональности не соблюдается — продукт продолжает использоваться и практически невозможно остановить изменения. Новый продукт вступает в гонку со старым. Его команде нужно успеть переписать старые фичи и дополнительно реализовать новые, сделанные старой командой за время переписывания старых.
Что делать?
Помимо того, что по максимуму должны быть заморожены доработки в старой системе, нужно стараться новые фичи делать сразу в новом продукте и как можно быстрее выводить их в продуктив. Это влияет и на приоритезацию — важнее как можно быстрее реализовать наиболее изменчивую функциональность и внедрить ее в первую очередь.
Проектирование от модулей
При проектировании нового продукта двигаются от модулей, планируя замену модуля за модулем. При этом для большинства важных сценариев нужны практически все модули. Как следствие, готовый продукт не работает практически до самого конца проекта.
Что делать?
Нужно планировать замещение продукта от кейса к кейсу, от бизнес-процесса к бизнес-процессу. Модули при этом должны создаваться и развиваться инкрементально. В новую систему переводятся бизнес-процессы, а не модули.
Перевод на новую систему полностью бизнес-юнитами
Чем масштабнее внедрение, тем оно дороже. Часть требований к новому продукту требует долгого согласования. Приходится учитывать запросы разных категорий пользователей. При внедрении обнаруживаются провалы и противоречия.
Что делать?
В системе есть различные категории пользователей: разные типы клиентов (массовый сегмент, VIP), сотрудники региональных фронт-офисов, региональные менеджеры и прочие.
Лучше переводить в новую систему не сразу всех пользователей, а запускать отдельными группами. Тогда при каждом релизе нужно будет обучать только часть пользователей. Стоит приоритизировать работы так, перевести самые значительные категории пользователей в первую очередь. Например, начать с сотрудников региональных фронт-офисов, а менеджмент может пойти в следующей волне.
Мотивация старой команды
Сотрудников старой системы планируется уволить по окончанию проекта. Это снижает их мотивацию на эффективное взаимодействие с новыми сотрудниками и приводит к осознанному или не осознанному саботажу.
Что делать?
С каждым сотрудником старого продукта обсудить его планы — готов ли он переучиваться на новую систему? Это может означать переход в новую роль аналитика, так как тут важно его понимание старой системы, а значит и бизнес-процессов и деталей реализации.
Цель: «сделайте, как было раньше»
Менеджмент часто в качестве цели указывает: «сделать, как было раньше, но в новом продукте». Это может быть неоправданно дорого. В старой системе могут быть очень запутанные бизнес-процессы. Их сложность часто обусловлена наследием — «так сложилось исторически». Большая часть шагов такого процесса решает проблемы, актуальность которых в новой реальности под большим вопросом. Перетаскивать их в новую систему придется месяцами, а ошибок там будет слишком много.
Что делать?
Можно в разы сэкономить на разработке, упростив бизнес-процессы. Лучше вести речь о переписывании продукта и перестройке бизнес-процессов, а не импортозамещении как таковом. Цель: «сделайте, как раньше» — контрпродуктивна.
Отсутствие доступа к бизнес-заказчику
Проект импортозамещения кажется несложным, нужно просто повторить старую функциональность. Для этого можно нанять команду или вендора и передать им старый продукт и дать доступ к аналитикам и инженерам старой системы. Зачем им беспокоить бизнес-пользователей? Однако, по ходу разработки будут возникать ситуации, когда из-за особенностей новой архитектуры повторить старую функциональность один в один очень дорого. Можно сделать быстрее и проще, немного изменив подход относительно старой системы. Новая команда общается с аналитиками и запрашивает упрощение, но аналитики отказывают в этом. Такое решение может принять только заказчик, но доступа к нему нет.
Что делать?
Проект не должен делаться в отрыве от бизнес-заказчика. Могут появится вопросы по улучшению, изменению, развитию, упрощению и т.д. Могут даже найтись ошибки в старой системе, копировать которые в новую глупо. Новая команда должна быть на связи с заинтересованными лицами и пользователями точно также, как и при создании обычной системы.
Слишком агрессивный план запуска новой системы
Менеджмент требует высокой скорости перехода на новую систему. Внедрение новых частей системы планируются одна за одной. Времени на исправление дефектов не выделяется. Как следствие, новая система сбоит, лежит, глючит. Баги не исправляются. Репутация нового продукта низкая, его использование саботируется сотрудниками организации. Они переключаются на использования Excel или самостоятельно создают «инструменты малой механизации».
Что делать?
Явным образом выделять фазу стабилизации, которая должна следовать за внедрением каждой части системы. За это время должны быть исправлены основные дефекты. Потом можно переходить к внедрению следующей части системы.
Демо-ориентированная разработка нового продукта
При показе заинтересованным лицам продукта может показаться, что практически все готово. Дается команда отправлять все в бой. На самом деле на демо остается за кадром, что реализовано не более 20% кейсов. До окончания реализации нужно еще в 5 раз больше времени.
Что делать?
Должен быть управляемый бэклог продукта со списком замещаемых фич. Прогресс по нему должен явно коммуницироваться заказчикам.
Заключение
Все описанные в статье подходы снижают риски миграции, но выглядят страшновато. Они требуют совершенно другого уровня коммуникаций и взаимодействия. Придется строить совместные команды, обеспечивать доступ к бизнес-заказчикам, переводить в новую систему пользователей частями. Все это сложно, и вы в ходе проекта наткнетесь на неизбежное сопротивление от всех этих людей. Наверное, вы понимаете, что большинство этих подходов к решению задачи миграции навеяно ценностями Agile, а изменить мышление людей, которые к этим ценностям не привыкли, — ой как не просто.
Гораздо проще нанять вендора, поставить задачу «перепишите» и тем самым послать проблему в будущее. Новая команда в течении всего срока проекта не будет вас беспокоить, но я уверяю, результаты вас точно не порадуют. Весь вал негатива никуда не денется, просто сместится к концу проекта.
Подумайте, может все-таки стоит вложиться на старте и выстроить эффективную работу с самого начала? Будущий Вы будет вам благодарен!
Почему команды так не любят изменения? Как это проявляется и почему на самом деле сопротивление — это хороший знак? В этой статье обсудим, какую роль играет сопротивление и как Agile-коуч может не бороться с ним, а использовать в интересах команды, применяя различные техники.
Что такое интервизия и действительно ли она помогает скрам-мастерам и agile-коучам, как правильно организовать такую встречу и зачем интервизия нужна самой компании. В статье я постараюсь ответить на все эти вопросы и рассказать о своем опыте, а в конце поделюсь кратким чек-листом для участников, которые хотят извлечь из интервизии максимум пользы.
Современные компании сталкиваются с необходимостью постоянных изменений — будь то адаптация к новым рыночным условиям или улучшение внутренних процессов. Как найти способ эффективно внедрять изменения, причем так, чтобы сделать это быстро и с минимальным сопротивлением от команды? Один из инструментов, который может помочь в этом, — HADI-цикл.