Начав говорить про трансформацию программного продукта, я сразу рванул с места в карьер, подняв одну из самых неочевидных, но с моей точки зрения, важных проблем. Это и хорошо, и плохо одновременно. По развернувшейся полемике можно предположить, что сама тема вызывает интерес — и это хорошо. С другой стороны, прежде чем поднимать тему, нужно начать с основ. Что такое трансформация? И плохо, что я не начал именно с этого. Поэтому сейчас я исправлю эту ситуацию.
Я хочу поделиться своим мнением о том, что же такое эта пресловутая трансформация, что ей предшествует и какие выгоды и трудности ждут на пути.
Давайте начнем с самого начала. Что же такое трансформация? То есть дадим определение этого процесса, на которое будем впоследствии опираться.
Прямо скажем, существует большое количество вариантов определения этого процесса, но я не смог найти такого, которое для меня отражало бы картину, с которой я сталкиваюсь на практике. Поэтому я взял на себя смелость и сам сформировал определение трансформации:
Трансформация — это полное обновление существующего программного продукта. Это процесс фундаментальной переработки или переосмысления имеющегося программного обеспечения с целью приведения его к современным стандартам, решения существующих проблем, повышения функциональности и улучшения пользовательского опыта. В отличие от частичных изменений, обновления или рефакторинга, полное обновление затрагивает практически все аспекты продукта: начиная от архитектуры и кода до пользовательского интерфейса и бизнес-логики.
В это определение еще не включена финансовая составляющая, но мне не удалось вместить ее так, чтобы определение не получилось на целую страницу. Если кто-то хочет написать свое определение — пишите, если оно будет лучше отражать суть, я буду только рад и обещаю указывать авторство.
С определением разобрались. Теперь нужно обсудить, при каких обстоятельствах возникает необходимость задумываться о проведении трансформации.
Для себя я определил 11 пунктов, каждый из которых в отдельности, и тем более совокупность двух-трех из них, обязывает задуматься о том, что в текущих процессах функционирования программного продукта необходимо провести радикальные изменения:
1. Использование устаревших технологий и сред разработки:
— Используемые технологии, языки программирования, базы данных или фреймворки больше не поддерживаются, либо стали слишком сложными и затратными в обслуживании.
— Продукт не поддерживает современные требования к безопасности или производительности.
2. Невозможность дальнейшего масштабирования:
— Программный продукт не справляется с увеличивающейся нагрузкой или количеством пользователей. Его архитектура не рассчитана на дальнейший рост, и внесение улучшений требует слишком больших усилий.
3. Неудовлетворение современных требований бизнеса:
— Продукт не поддерживает новые требования рынка, отраслевые стандарты или законы (например, GDPR, требования безопасности и пр.).
— Функциональные возможности продукта перестали соответствовать ожиданиям пользователей или отстают от конкурентов.
4. Невозможность интеграции:
— Продукт сложно или невозможно интегрировать с современными системами и сервисами, что мешает эффективной работе компании или клиентов.
5. Высокие эксплуатационные расходы:
— Поддержка и обновление текущего программного обеспечения стали слишком дорогими или трудоемкими. Требуются значительные ресурсы для исправления ошибок, обновления версий или внедрения новых функций.
6. Негативный пользовательский опыт, жалобы клиентов:
— Продукт вызывает большое количество жалоб со стороны пользователей из-за устаревшего интерфейса, низкой производительности или неудобных функций.
— Продукт не соответствует современным стандартам UX/UI, что приводит к снижению клиентской базы.
7. Технический долг:
— Кодовая база продукта содержит много накопившихся ошибок и неоптимальных решений (технический долг), что замедляет разработку новых функций и усложняет поддержание стабильности.
8. Серьезные проблемы безопасности:
— Продукт имеет уязвимости, которые сложно или невозможно исправить без полного обновления. Старые технологии или архитектурные решения создают риск для данных пользователей и компании.
9. Изменение бизнес-модели:
— Программный продукт не соответствует новой стратегии бизнеса, например, переходу от десктопного решения к мобильным, облачным или SaaS-моделям.
10. Проблемы совместимости:
— Продукт больше не совместим с новыми версиями операционных систем, браузеров или устройств, что ограничивает возможности его использования и обновления.
11. Отсутствие поддержки со стороны разработчиков:
— Разработчики программного обеспечения (как сторонние, так и внутренние) больше не могут поддерживать продукт из-за прекращения поддержки технологий или исходного кода.
По моему опыту, если хотя бы два-три из этих пунктов выполняются в полном объёме, необходимые изменения не могут ограничиться мелкими доработками или патчами — требуется полная переработка, чтобы соответствовать современным требованиям и продолжать успешно зарабатывать деньги.
С одной стороны, это достаточно очевидные моменты, и на первый взгляд всё просто: если соблюдаются два-три пункта, значит, нужно серьёзно задуматься о трансформации, именно о трансформации, а не о доработке системы. Однако очень часто ответственность за выполнение этих 11 пунктов лежит на разных подразделениях или даже департаментах. Разработка может даже не знать о проблемах клиентов, если между этими отделами находится качественный отдел поддержки пользователей, который зачастую относится не к техническому департаменту, а к коммерческому подразделению. В результате складывается ситуация, когда у разных подразделений есть по одному проблемному пункту из моего списка, но общей картины нет ни у кого. Это приводит к тому, что понимание необходимости трансформации сильно задерживается, и в какой-то момент трансформацию уже нельзя провести с малыми затратами, требуются значительные ресурсы для исправления сложившейся ситуации.
Обмен информацией между департаментами, как правило, не работает. По моему опыту, подразделения концентрируются исключительно на своих задачах, в крайнем случае — на задачах ближайших смежных подразделений. Например, инженеры внедрения могут сообщить отделу разработки, что развернуть продукт у пользователей стало сложнее по ряду причин. Однако на общих совещаниях часто акцентируют внимание на том, что отдел внедрения, несмотря на технологические трудности, с огромными усилиями всё же сумел развернуть продукт и сдать его в эксплуатацию. Это воспринимается как подвиг, за который полагаются премии, ведь если нет подвига, то и премию платить не за что.
Что касается коммерческого отдела, они могут продать всё что угодно, (за что я отношусь к продавцам с уважением), в том числе и то, что продукт в принципе не может выполнить, хотя индустрия этого уже требует. Это отражено в третьем пункте. Однако, как правило, полную картину никто в компании не видит.
Есть разрозненные очаги напряжённости, но осознание того, что компания подошла к необходимости трансформации, приходит гораздо позже, чем могло бы. И вновь возникает вопрос: что делать в такой ситуации? Мы помним, что общие собрания не помогают собрать полную картину, так как быть?
Я применяю следующий подход для решения этой задачи:
В одной из своих предыдущих статей я писал о ключевых специалистах, которые стояли у истоков разработки продукта (https://habr.com/ru/articles/842260/). Вот ещё один вариант развития таких специалистов в компании. Именно из них нужно сформировать группу или выделить одного человека, который досконально знает продукт, понимает, как он задумывался и как работает. Освободив этого специалиста от текущих дел (как я упоминал ранее, у таких специалистов, как правило, уже есть люди, на которых можно переложить их работу с минимальным риском), можно поручить ему важную задачу.
Этому специалисту необходимо дать полномочия и довести до всех руководителей департаментов и подразделений: во-первых, важность поставленной задачи, во-вторых, то, что специалист наделён уникальными полномочиями для получения информации. Особое внимание стоит уделить получению информации: он может запросить любые данные в любом разрезе и с любой глубиной, но он не может диктовать, что нужно делать или что нужно менять прямо сейчас. Это очень важно, поскольку у меня были случаи, когда специалист, получив такие полномочия, пытался сразу повлиять на ситуацию, как он её видел. Увы, для изменения ситуации одного специалиста недостаточно. Его задача — собирать информацию и формировать общее представление о работоспособности бизнеса в технической части продукта.
Такой подход позволяет получить объективную и целостную картину состояния продукта компании. Специалист, наделённый уникальными полномочиями, может глубже погрузиться в проблемы, не ограничиваясь формальными отчётами и поверхностными выводами. Его главная задача — выявить реальные, зачастую скрытые, причины, которые могут тормозить развитие и требовать трансформации. Только у него есть необходимые исторические данные для выполнения этой задачи. Важно, чтобы этот человек не вмешивался в текущие процессы, чтобы не нарушить их стабильность, а сосредоточился исключительно на анализе.
Следующий шаг — подготовка детализированного документа, возможно, схем, в которых будет чётко изложено, по каким из 11 пунктов продукт нуждается в полной трансформации. Этот документ станет основой для принятия управленческих решений владельцем бизнеса, потому что такие решения можно принимать только на самом высоком уровне. На основании этого отчёта руководство будет решать, в каких направлениях нужно проводить изменения и какие ресурсы на это потребуются. Здесь особенно важно донести до всех заинтересованных сторон, что выявленные проблемы — это не повод для паники и тем более не повод для поиска виновных (я писал об этом в другом тексте: https://habr.com/ru/articles/844088/). Это возможность улучшить продукт, оптимизировать процессы и избежать будущих рисков.
После подготовки отчёта и принятия решений начинается этап планирования и распределения задач. Об этом я напишу в следующих текстах. На этом этапе придётся вовлечь все подразделения, чтобы процесс трансформации стал общей задачей. Каждое изменение должно соответствовать бизнес-целям компании, а команда разработки, поддержки, отдел продаж и другие ключевые подразделения должны работать скоординированно. Такой подход минимизирует возможные сбои и поможет компании успешно пройти через сложный, но необходимый процесс трансформации.
ссылка на оригинал статьи https://habr.com/ru/articles/845792/
Добавить комментарий