Преодолеваем барьеры внутреннего продукта для внешнего рынка Часть 2

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

• Проектируйте продукт сразу с расчётом на low-code и даже no-code архитектуру. Когда у вас есть конфигурируемость, вы сможете быстрее адаптироваться под нужды клиентов без переписывания кода.

• При проектировании фичи сразу закладывайте её конфигурирование через JSON и администрирование через feature toggling механизм, желательно используя готовые Open Source решения типа Unleash или LaunchDarkly. Это важно, чтобы потом, когда понадобится, было проще создавать UI для управления фичами и контролировать их жизненный цикл. Предусмотрите функциональность сохранения и смены конфигураций из файлов сразу и делайте её для каждой фичи. NB: с Unleash осторожнее — в коде есть недружественные закладки.

• При проектировании продукта сразу закладывайтесь под SaaS-модель. Tenant management по Pool-модели должен быть изначально. Даже если сейчас видите рынок только в On-Premise, это не значит, что через год-полтора не захотите в SaaS. А наличие сквозного tenant ID всегда полезно, даже для Enterprise-клиентов с дочерними и зависимыми организациями. Это позволит гибко масштабироваться и обслуживать разных клиентов на одной инсталляции.

• Ещё одна дорогая при позднем внедрении штука — локализация и интернационализация (i18n). Выберите решение для работы с локализацией и разметкой / хранением / администрированием языков UI как можно раньше и размечайте UI с самых первых фичей.

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

• При платформенной разработке сразу договаривайтесь между командами про владение компонентами. Например, одна команда делает таблицы с фильтрациями / сортировками, другая — карточный UI, третья — поиск и фильтрацию и т. д. Это позволит избежать rework и обеспечить reuse.

• Внимательно относитесь к часто переиспользуемым компонентам и выбору технологической базы для «высокого старта»: UI-kit, библиотеки frontend-компонентов, библиотек управления ролями и доступами. Лучше использовать Open Source решения, чем делать своё, так как туда заложены «человеко-столетия» работы.

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

• MVP платформенного слоя должен включать все ключевые компоненты: аутентификацию, управление ролями и доступами, механизмы интеграции (платформу API, асинхронную шину, API-Gateways), нотификации, общие справочники, резьбу для дальнейшего прокручивания CQRS и других подходов к масштабированию.

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

В современном мире, одно, даже маленькое, приложение рискует очень быстро превратиться в экосистему или супер-апп, в котором одну фичу будут пилить несколько команд. Учитывая этот риск, лучше сразу разрабатывать решение платформенным подходом, потому что платформа — это:

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

• конфигурируемость под нужды каждого продукта — больше гибкости,

• минимизация дублирования функциональности — меньше затрат,

• быстрая разработка новых модулей — выше скорость выхода на рынок.

Если идёте в платформенную разработку несколькими командами — не спешите сразу нанимать разработчиков. Начните с Product Owners, Tech Leads и аналитиков. На этом сделайте паузу в найме. Пусть лиды и аналитики сделают Discovery и Vision, сделают Product Evolution Canvas, проработают комплексные требования к общим компонентам и отдадут владельцам этих компонент.

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

• Группа архитектуры платформы — чтобы следить за целостностью.

• Команда платформенных компонентов — чтобы развивать Core и рефакторить Legacy. Именно эта команда будет задавать технологическую зрелость и актуальность технологического стека.

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

Новому продукту не нужно наследовать весь тяжелый процесс и все Quality Gates материнской корпорации, но некоторые вещи стоит делать сразу. Ориентируйтесь на модель зрелости по CMMI и постарайтесь побыстрее проскочить героический первый уровень зрелости. Что для этого нужно?

• Используйте CI/CD с автотестами, чтобы быстро доставлять изменения.

• Понятные зоны ответственности за общие компоненты и процесс работы с требованиями. При этом логика «кому нужнее, тот и делает» хорошая, но обычно чужие требования команды делать не хотят. Научитесь передавать владение компонентами.

• Обмен знаниями между командами. Это не только общая Wiki-система и документирование кода, это еще и каналы коммуникаций об обновлениях общих компонентов и обратной связью от пользователей.

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

С учётом того, что вы бежите по рельсам корпорации, концептуальная архитектура и даже архитектура решения у вас, скорее всего, появятся очень быстро. Вот несколько других моментов, о которых нужно подумать в части архитектуры.

• Реестр общих компонентов (с указанием ответственных за них) должен появиться сразу после концептуальной архитектуры

• Архитектура развертывания (Deploy Architecture) — это первое, что от вас потребует заказчик. И здесь не всегда тут достаточно диаграммы развёртывания: понадобятся ещё стратегия развертывания и отката, документы по сайзингам, хелмы и т. п.

• Внутренний интеграционный слой: продумайте его не только на уровне backend (REST и Kafka), но и на уровне frontend. Слой абстракции общего внутрифронтового API позволит вам потом легче обновлять ручки бэка, минимизируя телодвижения на фронте.

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

Следуя этим советом, вы сможете выстроить чёткий, понятный всем стейкхолдерам процесс разработки внутреннего продукта. Следите за нашим TG-каналом: скоро расскажем, как, опираясь на выстроенный процесс, «съесть слона» и довести разработку до PMF 💪