Инженерный процесс

ТЗ на входе, система на выходе, и живёт дальше.

Как здесь делается заказная инженерная работа — не WordPress-конвейер. Без Figma, без общей тестовой среды, без маркетингового запуска вживую. На входе ТЗ или репозиторий; на выходе работающая система, которая остаётся в строю. Дальше — по шагам, в том порядке, как это происходит.

Обсудить вашу систему Смотреть инженерную практику
В чём разница

Не конвейер сайтов — система, которая должна работать.

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

На входе — репозиторий, архитектурный документ или письменное ТЗ, а не Figma и таблица карты сайта. Сборка идёт на вашей инфраструктуре или нашей, а не в общей тестовой среде агентства. Проверка — это тесты на нагрузку и отказы на реальных объёмах данных, а не прогон Site Checker. А выход в прод — обратимый, под мониторингом деплой с runbook, а не разовый маркетинговый запуск вживую. White-label WordPress-конвейер живёт на своей странице: Процесс (WordPress).

Что переносится: оценка в фиксированных часах, сначала переписка, созвон по делу, и правило «кто написал код, тот его и ведёт».

  1. 01

    Приёмка: репозиторий, ТЗ, доступы

    Начинаем с реальной системы — репозиторий, архитектурный документ, медленный запрос, доступ к стейджу или реплике на чтение. Если принимаем легаси, руководитель сам читает его, прежде чем что-то предлагать.

  2. 02

    Оценка в фиксированных часах — рискованное прототипируем первым

    Объём оцениваем в фиксированных часах по письменному ТЗ. Всё, чья жизнеспособность не доказана — ИИ-функция, новый источник данных, допущение по нагрузке, — получает прототип на ваших данных до счёта, чтобы бюджет опирался на работающую вещь, а не на догадку.

  3. 03

    Сборка на вашей инфраструктуре или нашей

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

  4. 04

    Тесты на реальной нагрузке и отказах

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

  5. 05

    Деплой с runbook — обратимый и под мониторингом

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

  6. 06

    Держим живым — абонемент и реакция на инциденты

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

Есть система, которую нужно
собрать или спасти?

Пришлите ТЗ, репозиторий или часть, которая всё время падает. В течение дня — точные вопросы и честный разбор: объём, риски и что прототипировать первым. NDA по запросу.

Обсудить вашу систему
Прокрутить вверх