Направления
Четыре класса систем и задачи, под которые они нужны
Направления различаются не набором технологий, а тем, что в системе главное: выдержать пик, посчитать деньги, свести три среды в один продукт или лечь на процесс компании. От этого зависит архитектура, а не оформление.
Выбор
С чем приходят и что из этого следует
Таблица читается слева направо: ситуация на входе, класс системы, который её закрывает, и результат, за который отвечаем.
| Ситуация | Класс системы | Что получаете |
|---|---|---|
Сервис держит среднюю нагрузку, но ложится на пике или на росте базы | Высоконагруженные платформы | Архитектура, которая переживает пик, и понятные пределы роста |
Нужны кэшбэк, бонусы или партнёрская программа со своими правилами | Cashback и loyalty-платформы | Трекинг, начисления, антифрод и выплаты в одном контуре |
Сайт, приложение и расширение живут своей жизнью и расходятся в данных | Веб, мобильные и расширения | Общее ядро: одни данные и одни правила во всех средах |
Коробочная система упирается в потолок и начинает мешать процессу | CRM и бизнес-системы | Внутренняя система под ваш процесс и связка с тем, что уже есть |
Разделы
Куда идти дальше
У каждого направления своя страница: что входит, как устроено решение и что обычно спрашивают.
01
Высоконагруженные платформы
Архитектура, которая переживает пик, а не только среднюю нагрузку. Проектирование, масштабирование и вывод из строя узких мест.
Подробнее02
Cashback и loyalty-платформы
Программы лояльности и кэшбэка целиком: трекинг, начисления, антифрод, выплаты. Включая white label под чужой бренд.
Подробнее03
Веб, мобильные и расширения
Продуктовая экосистема, а не набор приложений: общий бэкенд, единые данные и согласованный опыт во всех средах.
Подробнее04
CRM и бизнес-системы
Внутренние системы под процесс компании, когда коробочное решение упирается в потолок и начинает мешать.
Подробнее
Вопросы
О направлениях
01
Можно ли заказать разработку, если задача попадает сразу в несколько направлений?
Да, и так происходит чаще всего. Программа лояльности почти всегда одновременно высоконагруженная система, а продуктовая экосистема из веба, приложения и расширения обычно требует ещё и внутренней админки. Деление на направления нужно для разговора о приоритетах: оно показывает, что в системе главное и где будут основные риски. Команда на проекте одна.
02
Вы берётесь только за разработку с нуля?
Нет. Отдельное направление работы — существующие системы: аудит архитектуры и кода, расшивка узких мест, доработка модулей и постепенная замена частей системы. Начинаем с аудита, по результату видно, что дешевле — развивать текущее решение или переписывать его часть.
03
Кто определяет архитектуру решения?
Архитектуру проектирует команда разработки вместе с техническими специалистами заказчика. Результат этапа — документ с описанием решения, границами системы, интеграциями и оценкой. До согласования этого документа разработка не начинается: именно на нём дешевле всего менять решения.
04
Работаете ли вы по модели выделенной команды?
Да. Возможны два формата: фиксированная стоимость этапа с заранее описанным объёмом работ и выделенная команда, которая работает по приоритетам заказчика. Первый формат подходит, когда объём понятен, второй — когда продукт развивается и приоритеты меняются между итерациями.
Дальше
Расскажите, что за система нужна
Опишите задачу и состояние проекта: строим с нуля, дорабатываем существующее или разбираемся, что вообще происходит с нагрузкой. Ответим и предложим следующий шаг.