Трансформация или чемодан без ручки (часть 5) Так дальше работать нельзя! Нужна трансформация. И что дальше?

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

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

На совещаниях начинают задавать вопрос: «Ну, как проходит трансформация?» И те, к кому направлен этот вопрос, даже что-то отвечают на этот вопрос. Но на самом деле трансформация не начата. И тут единственный, кто может фактически запустить процесс трансформации, — это владелец или ЛПР. Именно он должен объявить о начале реального процесса и назначить ответственного за этот процесс, наделив его необходимыми полномочиями — что очень важно. Если в компании приняты приказы, то я очень рекомендую начало трансформации оформить именно приказом и довести его до если не всех сотрудников, то до максимального количества.

Потому что, как я писал ранее (тут и тут), этот процесс крайне болезненный, и для его реализации нужно зафиксированное решение и назначение ответственного за весь процесс трансформации целиком. По моему опыту, тут есть три варианта:

1. Первый вариант — когда есть доброволец, который обладает авторитетом в компании и в силу своей зоны ответственности сильно заинтересован в трансформации, например, СТО, если он реально управляет разработкой, или руководитель отдела поддержки, у которого куча незакрытых заявок от клиентов. Но я такого в своей практике не встречал. Добровольцев на такую задачу, по моему опыту, не находится*.

2. Второй вариант — назначить одного из руководителей: либо руководителя отдела разработки, либо руководителя отдела поддержки и внедрения. Это вполне рабочий вариант, но есть один риск. У обоих руководителей уже очень большой спектр текущих задач, и грядущая трансформация только усугубит количество нерешённых задач. А мы помним, что один из критериев необходимости трансформации — это негативный пользовательский опыт и жалобы клиентов (см. пункт 6 и 7  здесь). Дополнительная нагрузка такого объема для них практически неприемлема. Если при назначении ответственного за трансформацию вы обозначите это как причину, по которой не предлагаете назначить этих специалистов, то вы уберёте конфликтное мнение, что ЛПР ими недоволен, и покажете своё тонкое понимание реальной ситуации в компании.

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

Что в итоге мы имеем:

• Трансформация запущена не на словах, а фактически.

• Ответственный специалист тоже известен.

Чтобы начать глобальную трансформацию программного продукта, стоит выполнить следующие шаги:

1. Четко определить цели трансформации:

   • Определить стратегические цели: что вы хотите изменить или достичь? Это могут быть улучшения функционала, производительности, масштабируемости или адаптация к новым требованиям рынка. Или всё это вместе взятое, а также другие пункты, которые важны лично вам.

2. Оценить текущее состояние продукта:

   • Провести полный аудит существующего ПО: выявить сильные и слабые стороны, устаревшие технологии и архитектурные недостатки.

   • Оценить удовлетворённость пользователей и клиентов, чтобы понять их ожидания от изменений.

3. Определить технические и бизнес-требования:

   • Создать подробный список требований к новому продукту, который учитывает как технические, так и бизнес-цели.

   • Убедиться, что новая версия продукта будет поддерживать основные процессы и задачи клиентов.

4. Оценить наличие необходимых ресурсов:

   • Убедиться, что у вас есть доступ к нужным ресурсам: командам разработки, аналитикам, дизайнерам, инфраструктуре и бюджетам.

   • Рассмотреть возможность привлечения внешних экспертов, если требуются специфические знания.

5. Разработать первый вариант этапов проведения трансформации:

   • Разработать пошаговый план с чёткими сроками, этапами и критериями успеха для каждого шага.

   • Определить, какие части продукта будут обновляться, перерабатываться с нуля, а какие сохраняться.

6. Обеспечить гибкость и адаптацию методологий разработки:

   • Выбрать подходящую методологию разработки (Agile, DevOps, Scrum и др.) для обеспечения гибкости и быстрого реагирования на изменения.

   • Планировать регулярные итерации с тестированием и обратной связью.

7. Рассмотреть возможные риски и управление ими:

   • Оценить риски проекта, такие как технические сложности, задержки или сопротивление со стороны пользователей, и разработать план их минимизации.

8. Обеспечить тестирование и обратную связь:

   • Включить обширные тестирования на всех этапах, начиная с первых прототипов, и получать обратную связь от пользователей на ранних стадиях разработки.

9. Организовать коммуникацию с заинтересованными сторонами:

   • Постоянно поддерживать связь с ключевыми заинтересованными сторонами (пользователями, клиентами, партнёрами, командами разработки и менеджментом).

   • Обеспечить регулярное информирование о ходе трансформации.

10. Подготовить пользователей к изменениям:

• Подготовить обучающие материалы, инструктажи и техническую поддержку, чтобы облегчить переход на новую версию продукта.

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

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

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

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

Трансформация не так страшна, как кажется на первый взгляд. Это вполне решаемая задача, если знать, как её реализовать. И именно об этом мы и говорим.

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