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

Что за платформа такая

Ну…вот есть у вас продукт, вы его придумали силами менеджмента, а потом сели и реализовали силами разработки, всё это вы, вероятно, старались делать быстрее, так как пилить IT дело затратное и чем быстрее вы на рынок выйдете тем быстрее докажете (или не докажете), что ваша бизнес-модель работает как замышляли и стоит дальше напрягаться. В этот момент о далёком светлом будущем особо никто не думает — запустить бы успешно текущий бизнес.

Немного перемотаем пленку вперед.

Бизнес у вас процветает: в продукте много пользователей, их количество растёт — батут работает!) И в этот момент появляется невероятной силы мысль: “Надо дальше развиваться — дать пользователю другие продукты, а там может и экосистему построим!”. Мысль амбициозная и правильная, погнали придумывать и делать новые продукты, но у нас ведь уже есть опыт, набитые шишки, ну и мы уже можем надеяться на какой-то небольшое эффект масштаба бизнеса, в общем мы можем новые продукты делать как-то эффективнее чем первый, да? Да, можем, а вот с эффектом масштаба интереснее: можем “переиспользовать” офис, специалистов, сервера, маркетинговые каналы, да много что…и можем сделать платформу разработки.

Итак, определение от ИИ:

Платформа разработки (Development Platform) — это комплекс программ, инструментов и сервисов, который служит фундаментом для создания, тестирования и развертывания приложений.

То есть это решения, которые можно переиспользовать в разным местах.

В этой статье я буду говорить даже в более широком контексте: помимо программ, инструментов и сервисов я еще присовокуплю еще процессы.

Из чего может состоять платформа

О, тут будет много всего, разделю на несколько разделов:

Инструменты управления инфраструктурой:

k8s, виртуалки;
CI/CD, система контроля версий, разнообразные хранилища артефактов, библиотек, образов;
мониторинг инфры (дашборды, алертинг).

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

Из ходового, почти всем средним и крупным компаниям в пользу приходится контейнеризация и k8s, эти штуки оптимизируют ресурсы, упрощают и ускоряют управление средами, деплой, разработку, тестирование, анализ, снятие телеметрии, улучшают отказоустойчивость и т. п., кому-то так же понадобится service mesh, использование нескольких ДЦ и переключение между ними, CDN, управление многочисленными БД и т. д. Всем этим добром обычно занимается одна или несколько команд и по-хорошему всё это успешно автоматизируется и упаковывается в продукт для внутренних пользователей.

Информационная безопасность:

WAF, NGFW, SIEM и прочие инструменты;
автоматизация комплаенса;
антифрод-системы.

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

Разумеется, такие внутренние продукты пронизывают многие, если не все направления бизнеса, как продукты, так и операционку и проще сделать нечто универсальное чем кастомное под каждое место где нужны инструменты ИБ.

Второй момент это то, что спецы по ИБ это люди, которых зачастую трудно найти, легко потерять ~~и невозможно забыть~~, мало кто любит и, в случае чего, очень сильно нагибают. Так что помочь им делать их работу “по красоте” это благородная и очень полезная задача.

Дизайн-система:

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

Про дизайн-систему: думаю, почти всё и так понятно. У бизнеса есть, так сказать, фирменный стиль (может и бренд-бук имеется) и есть система элементов пользовательских интерфейсов, которые используются в том числе и для формирования UI приложений, сайтов компании. Не буду вдаваться в подробности зачем это нужно, но для базового понимания можно сказать что такое единообразие улучшает дизайн экранов, с которыми взаимодействует пользователь и упрощает формирование новых экранов, как со стороны дизайнеров, так и со стороны разработки.

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

Отдельно коснусь токенизации дизайн-системы. Стандартное использование концепции подразумевает использование стандартных параметров элементов, как токенов, таких как цвета, шрифты, отступы, эффекты, переменные в CSS можно считать одной из реализаций (подробнее). Я предлагаю идти глубже и токенизировать целые элементы. То есть элемент на экране становится изолированным контейнером, объединяющим визуал и функциональность элемента. Например, выпадающий список, он может находяться в разных состояниях и каждое состояние выглядит определенным образом, переход между состояниями вызывается определенными триггерами, у элемента есть логика работы, которая позволяет выбирать элемент из списка. Это цельная самодостаточная микросистема, которая позволяет встраивать ее в UI и получать предсказуемый функционал и внешний вид.

Возвращаясь к токенам, не должно быть возможности менять токен извне — токен всегда выглядит и работает одинаково, но можно изменить токен в дизайн-системе и он изменится везде где используется.

Мы называли такие токены дизайн-слотами.

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

Инструменты разработки (DevEx):

cli-apps
библиотеки, фреймворки;
линтеры;
AI-инструменты.

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

Здесь часто бывают проблемы с UX, инструменты придуманные инженерами для инженеров, казалось бы, что может пойти не так? но тут как и с любым другим продуктом нужно следить за метриками, собирать обратную связь и развиваться в направлении увеличения пользы пользователю.

Dev portal — что у вас есть можно:

визуализировать;
дать управлять через UI.

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

Маркетинговые инструменты:

баннеры, сторисы, пуши и прочее, зачастую портящее пользовательский опыт, но помогающее пользователя направлять на целевые продукты;
CPA-платформы;
геймификация, баллы, промокоды.

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

Данные и дата-инструменты (Data platform):

хранилища;
потоковая обработка;
CDC;
feature store;
инструменты доступа к сырым и обработанным данным;
инструменты визуализации и отчётов.

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

Сбор данных:

сбор данных о действиях пользователей;
сквозная аналитика;
история критичных изменений;

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

Company ID:

аутентификация;
авторизация;
идентификация.

Неоднозначная тема, так как требования, с точки зрения безопасности, могут быть разными по отношения к разным системам. Однако, чаще всего системы, как минимум, можно поделить на группы и использовать внутри групп одни и те же протоколы и IAM.

Технический мониторинг и менеджмент инцидентов:

хранение и визуализация логов;
хранение и визуализация технических метрик;
алертинг;
on-call инструменты.

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

Платформа a/b-тестирования, фичетоглинг, сегментация пользователей.

Давайте по порядку, фичетоглинг это фактически “мастхэв” для любой качественной разработки, не вижу смысла что-то тут обсуждать.

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

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

BDUI (он же SDUI) и graceful degradation.

Разные темы, но объединил их, так как реализации могут быть близкими.

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

Про GD и говорить нечего, это тоже мастхэв, экраны вашего приложения не должны отваливаться из-за второстепенных проблем, а если и отвалились по делу, то давайте показывать вразумительные экраны ошибок, а не Something went wrong…

ML и AI:

ML-платформа;
локальные модели ИИ;
инструменты встраивание в сервисы и процесс разработки.

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

Что касается ML-моделей, то не всегда очевидно что их можно платформизировать. И действительно сами модели зачастую затачиваются под конкретную задачу, но вот само обучение и использование вполне себе хорошо платформизируется в крупных компаниях.

Интеграции:

с партнерами;
с корпоративными инструментами коммуникации;
с государственными сервисами.

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

Локализация:

сервер;
админка;
библиотеки встраивания в продукты.

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

Автоматизация QA:

TMS;
платформа нагрузочного тестирования (performance testing as a service);
инструменты упрощения реализации автотестов (библиотеки, AI).

Думаю и так всё понятно, коснусь только performance testing as a service (PTasS), до такой штуки обычно руки доходят не сразу и это вполне оправдано — чтобы команды начали систематически сталкиваться с проблемами производительности после релиза фичи, чаще всего, требуется уже значительная нагрузка. Но рано или поздно такой инструмент может понадобиться и это однозначно общая платформизируемая функциональность.

Админка — все настройки всех продуктов в 1 месте.

Совсем не очевидно что настройки должны жить в одном месте, но я видел такой подход не раз и это работает. Видел и когда развивают админку исключительно овнеры (команда админки) и это кажется однозначно плохим подходом из-за бас-фактора в обе стороны (задачи на админку выстраиваются в длинную очередь, а админка вынуждена разбираться в каждом продукте) + это всегда, мягко говоря, не самая желанная работа в компании.

Но вот изобретение и платформизация инструментов для быстрой разработки своей админки или быстрого добавления чего-либо в общую админку выглядит ультимативный благом.

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

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

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

Platform as a service

ИМХО, все платформенные решения должны упаковываться в продукты для внутренних пользователей. На то есть несколько причин:

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

Теперь немного подробнее.

Сложности внедрения

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

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

В любом случае, ИМХО, правильнее всё же подтолкнуть людей к “органическому” переходу на платформенные решения. И это может быть сложно.

Возражения, с которыми мы сталкивались:

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

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

Что же делать?

Упрощать жизнь внутренним пользователям.

Это простая идея, не противоречащая идеям оптимизации разработки и стремлению к эффективности, при этом улучшающая жизнь абсолютно всем! В целом это именно то к чему нужно стремиться: упрощать жизнь пользователей.

С чего начать

И так, мы задались целью упростить разработку руками инженеров, чтобы выделить то, что нужно упрощать и запланировать реализацию соответствующих проектов нам необходимо:

1) подумать над тем что можно платформизировать для улучшения эффективности бизнеса, пообщаться с бизнесом, продактами, задокументировать;

2) пообщаться с инженерами и выяснить что им мешает, тормозит их работу, бесит и т. п., составить из этого таблицу, выделить “популярные”, действительно насущные и доступные к исправлению проблемы;

3) соотнести пожелания инженеров и платформизацию с целью повышения эффективности;

3) придумать, описать, декомпозировать и приоритизировать проекты по результирующим проблемам, выстроить дорожную карту.

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

Как развивать и повысить шанс на успех

Что еще можно сделать, чтобы повысить шансы на итоговый успех?

Мы можем затягивать пользователей в платформу и создавать ситуацию, в которой использовать ее по максимуму становится гораздо выгоднее, чем частичное использование: ценность использования всей платформы становится выше чем сумма ценностей каждого инструмента в отдельности, масштабное использование платформы удобно, инструменты легко объединяются друг с другом и создают синергию, дающую дополнительные ништяки, вход лёгкий. Самая близкая аналогия — AWS: разворачивать приложения в Амазоне быстро и просто…и дорого, но на начальных этапах дороговизна не так сильно ощущается, а скорость и порог входа очень важны, так облако от Безоса подсаживает пользователей на иглу своего сервиса и потом слезть с AWSa, если хочется, очень не просто.

Но наша цель благороднее: мы никого не хотим “подсадить” на нашу платформу и денег на этом не зарабатываем (пока платформу не начнём продавать) мы только пользователей хотим направить и дать максимум пользы.

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

Как я предлагаю объединять элементы экосистемы:

Элементы хорошо интегрируются друг с другом — не нужно поступать как Apple: изобретать оригинальные протоколы, форматы и т. п., мы не должны бояться конкуренции со стороны опенсорса — на нашей стороне близость к пользователю, понимание потребностей и технических особенностей использования, вместо этого простое подключение через стандартизированные интерфейсы и кодогенерацию со стороны кода, подсоединение экранов админки “в пару кликов”, мониторинг по стандартам компании из коробки и т. п.
Эффективное встраивание новых инструментов в уже существующие системы, пайплайны, дашборды и т. п., например, через систему плагинов. Давайте представим некую платформенную маркетинговую систему, которую мы сами сделали и хотим использовать для продвижения всех наших продуктов. Система включает много инструментов, как уже выше писалось, баннеры, сторисы, пуши, CPA,

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

Платформа использует платформу. Например, все системы и инструменты платформы требующие разграничения используют платформенную же систему авторизации. И так везде, встраивая некий платформенный инструмент мы прицепом получаем мониторинг, пользовательскую аналитику, продвижение и т. п.

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

Тогда и внедрять систему проще и пользы на единицу проделанной работы становится больше.

Эпилог

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

Внедрение платформы разработки