Пожалуй, нет ни одной крупной IT компании, которая бы не страдала от огромного и неповоротливого legacy, состоящего из тесно переплетенных между собой решений. Каждое решение связано с несколькими другими, и добавление одной новой, на первый взгляд незначительной, фичи требует изменения чего-то в каждом. Отдельные решения устарели настолько, что они в принципе не могут дать новый нужный функционал, и их нужно переписать полностью или заменить современным решением - и его, соответственно, также встроить во всю архитектуру. Это делает новые запуски сложными и долгими.
Иногда размер технического долга оказывается настолько большим, что для его устранения запускаются отдельные проекты, рассчитанные на месяцы и годы - а это сопоставимо с 5-10 time-to-market новых решений. Соответственно, все новые запуски откладываются до тех пор, пока авгиевы конюшни не будут расчищены, покрашены и перестроены. Отдельное зрелище - СТО, который убеждает СЕО и добрую половину правления, а также акционеров, потратить несколько тысяч человекочасов драгоценных разработчиков на то, что по завершении не поможет бизнесу моментально, а только ускорит на неизвестное время получение выгод от новых продуктов в будущем. Правда, после того, как запуск каждого из этих продуктов будет отложен на несколько месяцев.
В моменте, руководителям компании предстоит пройти через множество трудных обсуждений, оценок сроков и приоритезаций. Стратегически же, пренебрежением техническим долгом и отсутствие видение в создании IT архитектуры может вылиться в то, что более мелкий и гибкий конкурент обойдет компанию на рынке, так как сможет быстрей выйти на рынок с перспективным продуктом.
Углубляясь в детали, можно найти большой набор конкретных проблем, которые исходят из недальновидного развития IT архитектуры. Сегодня же я бы хотел сосредоточиться на двух конкретных проблемах, которых можно в значительной степени избежать, потратив буквально две недели на заре создания новой IT архитектуры.
Проблема 1. Ваша архитектура построена на микросервисах, обменивающихся данными. Одни и те же данные могут храниться в нескольких местах, но ни одно из этих мест не назначено “местом правды” (”the single source of truth”). В результате работы различных процессов в компании, данные в разных местах меняются, не синхронизируются, и потому начинают противоречить друг другу. Без иерархии источников данных не понятно, какие данные - самые актуальные. Яркий пример - мета данные о контрагентах (адрес, ЛПР, реквизиты, ИНН, номер банковского счета и т.д.), которые меняются не очень часто, но используются в нескольких местах: в бухгалтерии, в операциях, в продажах. Контакты контрагента поменялись по разу в каждом месте - и вот уже не ясно, каким образом теперь реально можно связаться с контрагентом, чтобы, например, что-то ему допродать.
Проблема 2. Ваша архитектура состоит из микросервисов, обменивающихся данными по API, и многие микросервисы связаны со многими. Вам понадобилось добавить новую фичу, но в существующих API и сервисах не предусмотрено полей под новые данные. В результате вам предстоит дописать большую часть всего IT ландшафта, чтобы запустить новый продукт.
Недавно мне довелось возглавить запуск новой вертикали в бизнесе, для которой предстояло создать несколько новых продуктов. Набив шишек в работе с легаси в старых вертикалях, мы проделали упражнение, которое, как я надеюсь, сделает две проблемы выше не такими значительными, как они могли бы быть. Ниже я делюсь подходом, следуя которому прозорливые продакты и разработчики (а на самом деле скорее руководители бизнеса) могут также обезопасить себя.
Ситуация:
Вы собираетесь запустить несколько новых продуктов, которые будут опираться на один и тот же набор сервисов.
Вы не знаете точно, каким будет каждый продукт - на текущей стадии есть только предположения о том, что продукты должны будут уметь делать и какие из них окажутся востребованными.
Тем не менее, вы примерно представляете, что новые продукты точно должны будут способны делать. Например, собирать историю событий для аналитики, рассчитывать стоимость услуг и хранить ее детализацию (биллинг), формировать документы для взаиморасчетов и сверок, обогащать CRM для работы коммерческой команды и так далее.
У вас возможно также есть набор процессов “большого” бизнеса, в который вы вероятно будете встраивать новые продукты. То есть вы не будете писать все модули с чистого лица, будете стараться использовать существующие процессы и команды с привычными им ПО. Вы также заинтересованы в том, чтобы между старыми и новыми процессами местами было много сходств.
Представим, что вы взялись за последовательное создание фич и продуктов и через несколько месяцев столкнулись с двумя проблемами выше. Что могло бы вам помочь не столкнуться с этими проблемами?
Решение:
Определите круг людей, кто фактически будет отвечать за выстраивание нового IT ландшафта. Как правило, это продакт / СРО и тех. лид / СТО. Если, как в моем случае, используется часть существующих модулей “большого бизнеса”, то в этот круг должны входить лиды по соответствующим модулям. Они должны понимать, с одной стороны, как модули работают сейчас, а с другой стороны, к чему идет развитие модулей исходя из задач “большого” бизнеса (хотя бы примерно).
Определите круг людей, которые будут использовать создаваемые решения, либо хорошо представляют потенциальные потребности клиентов, и какие из них более вероятно окажутся важными (например, “у конкурентов есть фича Х, это норма рынка и ей активно пользуются клиенты. Пока у нас нет идей по-лучше, нам придется сделать Х и у себя, иначе мы не убедим выбрать нас, а не конкурентов.”). Это могут быть сотрудники продаж, маркетинга, операций, бухгалтерии, аналитики и т.д.
Набросайте набор продуктов, которые вероятно предстоит запускать и/или развивать. Не все из них в дальнейшем приживутся или пойдут в рынок именно в том виде, как вы сейчас представляете. Но это не страшно - в какой-то момент вам вероятно все равно придется собрать MVP, чтобы проверить жизнеспособность вашей идеи. И лучшей информации все равно нет.
Проведите цикл бесед с представителями каждой функции из пункта 2, стараясь ответить на следующие вопросы
Какие процессы / действия / работу в целом нам вероятно предстоит делать на стороне этой функции, чтобы работать с / поддерживать продукты АВС, которые мы сейчас держим в уме?
Какие данные будут необходимы для этих процессов / действий / работы?
Насколько детальными они должны быть?
Как часто эти данные должны обновляться? Каждую секунду / минуту / час / день / месяц?
Как часто нужно будет обращаться к этим данным в ходе работы? То есть насколько большую нагрузку нужно иметь ввиду?
Собрав ответы на вопросы выше, у вас появится некоторое представление о будущих процессах и нужных данных. Следующих шаг - отрисовка примерной архитектуры продуктовой и технической командой, которая должна отвечать следующие вопросы:
Из каких модулей должна состоять будущая архитектура?
Какие данные должны быть доступны каждому модулю?
Где эти данные должны храниться и, что особенно важно, какое место должно быть “местом правды”, то есть содержащим самую корректную и актуальную информацию?
Как могут быть связаны модули (например, посредством API?)? То есть какой информацией и по каким маршрутам они должны обмениваться?
Отрисованная на предыдущем шаге архитектура - это первый черновик. Прежде чем на нее ориентироваться, необходимо проверить ее с “заказчиками”. Для этого нужно показать архитектуру, и проговорить ее. Например, в таком формате:
Вот те действия, которые вам нужно будет делать - мы их записали на предыдущем шаге. И вот же данные, которые нужны для процессов.
Вот как каждое из этих действий будет происходить в набросанной нами архитектуре. Вот где данные будут “жить”, вот как и куда они будут пробрасываться, вот как будет обеспечиваться актуальность и корректность этих данных. Вот как мы будем обеспечивать нужную пропускную способность (если это важный вопрос).
Вопросы к заказчикам:
Все ли вам кажется разумным и подходящим вам?
Есть ли новые требования, которые нам стоит учесть дополнительно? Например, не вспомнили о них в первый раз, либо между шагами 4 и 6 узнали что-то новое? Если такие есть, то нужно точечно повторить шаги 5 и 6.
Собрав обратную связь, вы убедитесь, что не упустили ничего критичного, и учли все важное для развития бизнеса на некоторую ближайшую перспективу. Теперь у вас есть, например, схема в Miro, которую следует использовать следующим образом:
В ходе разработки, на планировании очередного спринта, нужно соотнести предстоящие задачи с архитектурой и выстраивать модули, хранилища, API и интерфейсы в соответствии с ней. Так вы обеспечите, что нигде не забыли прокинуть заветную “ручку”, которая внезапно понадобилась под новый продукт.
На этом же шаге нужно проверить, что вы не забываете соблюдать “единые места правды”. То есть, например, если вы пишите интерфейс для поддержки, позволяющий актуализировать данные о клиентах, то нужно не забыть взять в спринт и кусок, обеспечивающий актуализацию данных о клиентах в соответствующем “месте правды”.
По мере того, как команда проекта будет получать опыт, ее представления о рынке, его потребностях, а потому - о будущих продуктах, будут меняться. Это будет означать, что и целевая архитектура будет меняться. Поэтому раз в несколько недель или месяцев следует повторять шаги 3-6, и таким образом поддерживать актуальность целевой картинки. СРО или менеджер продукта видится мне разумным лидером такого процесса. Хорошая новость - вторая и последующие итерации шагов 3-6 будут требовать кратно меньше усилий. Возможно, будет достаточно дня или нескольких часов.