В последнее время стало модным использовать слово "трансформация". Даже приведение в негодность чемодана методом разрушения его ручки для переноски называют трансформацией. Если глубоко задуматься, то, конечно, так оно и есть: был полноценный чемодан, но после трансформации он стал чемоданом без ручки.
Вот именно об этом и хочется поговорить. Многие бизнесы (особенно ИТ-бизнесы с собственным продуктом или услугой), которые существуют на рынке более 5 лет, сейчас в той или иной степени представляют собой именно чемодан без ручки. К таким бизнесам вполне применимо выражение: "нести тяжело, но бросить жалко". Но если углубиться в суть вопроса, то проблема заключается в следующем.
Компании, которые несколько лет назад создали свой продукт или услугу, сейчас сталкиваются с ситуацией, когда технологические решения, использованные при разработке продукта пять лет назад, сильно устарели. Хотя эти технологии, конечно, ещё работоспособны, но они уже недостаточно эффективны. Для того чтобы перейти на новые технологии и воспользоваться всеми техническими возможностями сегодняшнего дня, нужно кардинально перестроить имеющийся продукт. А такие изменения сопряжены с большими затратами и рисками, так как уже есть пользователи, которые платят за использование продукта. Создать для них проблемы просто невозможно, потому что они могут перестать платить... В общем, круг замкнулся.
И вот компании, которые уже не могут существовать на старых технологических решениях, запускают процесс той самой трансформации, задача которой — перейти на современные технологии. Но тут возникает самое главное — условия перехода. Они выглядят следующим образом:
Для пользователей трансформация должна пройти незаметно.
Затраты должны быть минимальными.
Всё просто и логично, но только на первый взгляд. Те, кто сталкивался с подобной ситуацией, понимают, что провести изменения подобного масштаба незаметно и дешево невозможно. Здесь возникает серьёзный конфликт между бизнесом и разработкой. Появляется и другая серьёзная проблема — изменение целей у сотрудников компании, которых вовлекают в трансформацию. Но о сотрудниках поговорим позже.
Давайте по порядку. Владелец принимает решение о том, что трансформация необходима, и запускает процесс. Бизнес говорит разработке:
Делайте что хотите, но клиент не должен ничего почувствовать; ни в коем случае не допускайте перерывов в функционировании продукта.
Для пользователя всё должно остаться по-прежнему, так как пользователь привык к продукту и не готов тратить ресурсы на переучивание.
С точки зрения технической реализации изменить продукт так, чтобы использовались современные технологии при соблюдении требований бизнеса, невозможно. Вроде ситуация патовая. Но вы точно знаете, кто выигрывает в этой ситуации, — конечно, бизнес. Ведь его неопровержимый аргумент — пользователь платит деньги, а бизнес — это, в конечном счете, зарабатывание денег. При таком подходе технический отдел начинает сооружать невероятные костыли и ухищрения для реализации процесса трансформации.
Хотя я полностью понимаю необходимость трансформации продукта или услуги компании, путь, который выбирает большинство компаний, не приводит к нужному результату. Точнее, приводит, но к совершенно другому результату и с использованием совершенно других ресурсов. Продукт обрастает сложными адаптационно-переходными техническими решениями, появляется множество функционала для перехода со старых решений на новые, что приводит к новым ошибкам и падению эффективности. А о проблемах с данными, когда что-то теряется, что-то отображается неправильно, а что-то перестаёт корректно считаться, вы и сами прекрасно знаете. Появляются и специфичные проблемы внутри коллектива разработки, что также сказывается на бизнесе компании.
Некоторые могут сказать, что в их компании всё не так: технический департамент с самого начала разработки первого продукта использовал принципы независимой модульности и независимых сервисов, и всё это было основой их архитектуры. Да, возможно, но таких компаний не так много. И даже у них, несмотря на использование передовых методов того времени, возникают такие же проблемы. Это не говорит о непрофессионализме команды разработчиков, ни в коем случае. Они — суперпрофессионалы, создавшие востребованный на рынке продукт, за который пользователи платят деньги. Однако развитие технологий сейчас настолько стремительное, что те технические возможности, которые есть сегодня, несколько лет назад просто отсутствовали. Изменились не просто инструменты — базовые подходы претерпели значительные изменения, а иногда и вовсе стали новыми.
Я чувствую, что читатель, ознакомившись с описанной мной ситуацией, может сказать: "Всё это в той или иной мере верно, это всем известно, и другого решения задачи нет, трансформация не может происходить без всех перечисленных сложностей". Конечно, трансформация работающего бизнеса — процесс непростой. Но можно избежать большинства из вышеописанных проблем. Это не значит, что существует магическая формула, по которой трансформация пройдёт легко и просто, но этот процесс можно сделать принципиально иным. Важно, что при таком подходе сам процесс будет короче, менее ресурсозатратным и более безболезненным как для компании, так и для клиентов.
И первое, что нужно пересмотреть, — это отношение между бизнесом и разработкой. Я думаю, что это самое сложное, потому что конфликт между этими подразделениями имеет глубокие корни. Задачи этих подразделений принципиально разные, а порой и взаимоисключающие.
Может сложиться впечатление, что трансформация — это задача только отдела разработки, ведь именно он должен провести изменения в технологических решениях компании. Но если бизнес осознает и примет свою роль в процессе трансформации, всё будет иначе. Это как команда в одной лодке во время шторма: либо все выживут, либо шторм окажется сильнее.
Какая же задача стоит перед бизнесом в процессе технической трансформации продукта? Самая что ни на есть основополагающая. Давайте рассмотрим пример с обычной программой-калькулятором. Эта программа имеет большой функционал, но мы пользуемся лишь 6–8 функциями. Те, кто пользуется большим количеством функций, составляют крайние значения и не могут влиять на общую картину. Так какой вывод можно сделать? В любом продукте есть значительное количество функционала, которым пользователи или не пользуются вовсе, или пользуются очень редко. Именно это и должен выяснить бизнес у пользователей, разбить весь функционал продукта на три группы: то, чем пользуются постоянно; то, чем пользуются время от времени; и то, о чём не знают или просто забыли, потому что не нужно. Вы скажете, что это невозможно, и что пользователь не будет тратить время на процессы, которые не являются его прямыми обязанностями. Это так, но у вас есть профессионалы по работе с клиентами, которые могут решить эту задачу. Говорю это по своему опыту, так как занимаюсь процессами трансформаций уже долгое время.
Знаете, какую ещё задачу решит подобный подход? Задачу наличия документации на продукт. Речь идёт не о пользовательской документации, а о технической документации, которая зачастую в компаниях либо отсутствует, либо имеется частично и неактуальна.
Не хочу утомлять читателя долгим текстом. Итак, первый шаг к реализации процесса трансформации — это сотрудничество бизнеса и технического департамента и разделение существующего функционала продукта на три категории.
Я обещал коснуться отношений сотрудников к трансформации. Сейчас лишь обозначу проблему, о которой подробнее напишу в следующем тексте. Эту проблему можно назвать так: старые специалисты, зная систему вдоль и поперёк и стоявшие у истоков её создания, чувствуют, что стабильность, к которой они привыкли, с началом процесса перехода на новые технологические решения полностью утрачивается. И, как нормальные люди, они всеми силами стараются продлить время этой стабильности.
Итак, трансформация бизнеса — это не просто задача внедрения новых технологий, но и процесс, требующий глубокого понимания и участия всех подразделений компании. Важно осознавать, что неудачные попытки обойти проблемы, связанные с устаревшими системами, приводят к накоплению дополнительных сложностей, ухудшению качества продукта и, в конечном итоге, к падению доверия со стороны клиентов, а значит, и к уменьшению денежного потока. Однако правильный подход, основанный на взаимопонимании бизнеса и разработки, позволяет минимизировать риски и сделать процесс трансформации более управляемым и результативным.
Сотрудничество между бизнесом и техническими специалистами должно строиться на понимании, что оба подразделения "плывут в одной лодке" и трансформация направлена на достижение общей цели. Это потребует от бизнеса активного участия в процессе. Только при таких условиях возможно трансформировать продукт, который не только сохранит текущих клиентов, но и откроет новые возможности для роста компании.
Ставка на правильную стратегию, вовлечение всех сотрудников и готовность бизнеса принять новые реалии позволят превратить трансформацию из тяжелой ноши в средство для достижения успеха. Важно не бояться Трансформации, а использовать их как инструмент для развития и укрепления позиций на рынке, обеспечивая потребности клиентов а значит и устойчивости бизнеса. Иными словами чемодан без ручки - это не окончательный приговор, сейчас есть новые чемоданы на колесах и с не отрываемыми ручками
В заключение можно сказать, что трансформация — это не вопрос "если", а вопрос "как".
