У заказчика уже были разработчик и постановщик задач. Ещё один подрядчик поверх этой команды только добавил бы границ: отдельный список задач, отдельные решения, отдельная ответственность.
Мы выбрали другой формат. Встроили двух инженеров в команду заказчика, взяли техническое руководство и 632 дня работали в общем процессе. Цель была простой — продукт должен развиваться внутри компании, а не остаться чёрным ящиком внешнего подрядчика.
Сводка
| Отрасль конечного клиента | Производство и монтаж стеклянных конструкций |
| Конечный клиент | Под код-именем «Конфигуратор стеклоконструкций», Россия |
| Формат сотрудничества | 2 инженера бюро внутри команды заказчика; техническое руководство на нашей стороне |
| Задача | Усилить команду на разработке отраслевого продукта |
| Ритм | Спринты по 2 недели, до 20 часов аналитика на спринт |
| Инженерная основа | Проверка кода, отдельные контуры разработки и эксплуатации, автоматическая сборка и выкладка |
| Первый выпуск | Через 69 дней после старта модели, в опытную эксплуатацию |
| Состояние на 5 августа 2026 | Код и развитие остаются внутри команды заказчика; формальной сдачи продукта не было |
Постановка задачи
К моменту перезапуска у заказчика появились собственный разработчик и постановщик задач. Раньше проектом целиком занималось бюро. Теперь ответственность нужно было разделить так, чтобы не получить 2 команды, которые по очереди правят один и тот же код.
Заказчик решил вести разработку своими силами, а наших специалистов подключать на частичную загрузку. Не покупать отдельный подряд, а добирать нужные роли внутри своей команды.
Мы закрыли аналитику и фронтенд, а аналитик стал техническим руководителем всей команды. При этом владельцу бюро не пришлось превращаться в диспетчера: из 2 103 сообщений в рабочем чате ему принадлежали 11. Инженеры работали с заказчиком напрямую.
Что в этом сложного
Риск такого формата виден не сразу. Пока команда маленькая, изменения можно отправлять прямо в основную ветку, разработку и демонстрацию держать на одной машине, а доступы передавать в переписке. Всё выглядит быстрым — пока код не нужно проверить, развернуть без простоя или передать новому человеку.
Заказчик в такой модели платит не за пару рук — ему нужен код, который через 2 года можно передать другим людям без переписывания. Но внешний технический руководитель не начальник внутреннего разработчика. Каждое правило приходится отстаивать аргументами и работающим примером, а не должностью.
Как мы это сделали
1. Разделили ответственность по ролям. Бюро подключило аналитика-программиста и фронтендера. Аналитик дополнительно взял техническое руководство и проверку кода всей команды, включая разработчика заказчика. Инженеры решали технические вопросы напрямую, владельцы — финансовые. Работали спринтами по 2 недели, до 20 часов аналитика на каждый.
2. Ввели проверку кода до слияния. На старте изменения можно было отправлять прямо в основную ветку. Новое правило звучало просто: отдельная ветка на задачу, затем запрос на слияние и проверка. Привычка приживалась 2 месяца и потребовала повторного разговора. После этого разработчик заказчика уже сам работал по новому порядку.
3. Развели разработку и эксплуатацию. Сначала предлагали обойтись одной машиной: стадия ранняя, пользователей мало. Мы настояли на отдельном сервере для рабочей версии. Иначе запуск чужой ветки мог сорвать демонстрацию заказчику. Позже добавили автоматическую сборку и выкладку по веткам.
4. Закрывали споры кодом. Наш инженер предлагал вынести генерацию в отдельный слой, разработчик заказчика возражал. Решил вопрос не авторитет технического руководителя, а набросок кода: на нём новый вариант оказался понятнее. В другую сторону правило работало так же. Фронтендер показал риск скрытых ошибок при редактировании фурнитуры, и уже принятое решение заменили безопасным копированием записи за 3 суток.
5. Убрали разработчиков из наполнения каталога. Фурнитура и параметры вырезов заводятся через интерфейс. Постановщик задач со стороны заказчика сам внёс номенклатуру и отдельно отметил, что редактором удобно пользоваться.
Инциденты и реакция
У такого формата есть цена. Лучше всего её показывают 3 рабочих эпизода.
Боевой стенд лежал 2 часа 5 минут. После перезапуска системы не поднялись база, кэш и файловое хранилище: для контейнеров не задали политику автоматического запуска. Заодно нашли пароли в открытом конфиге и решили перенести управление пользователями в консольные команды. При этом источники не подтверждают, что политику перезапуска затем добавили. Этот долг не маскируем.
Разъехались координаты фурнитуры: 37 часов до исправления. Компоновку изменили на бэкенде, а сборщик геометрии на фронтенде остался прежним. Разработчик заказчика переписал чужой фронтовый скрипт сам, не передав задачу владельцу кода. Починили ночью. Правило проверять результат на тестовом сервере появилось уже после инцидента, не до него.
Разветвлённая история миграций: 1 час 52 минуты ночного разбора. После слияния веток бэкенд не поднялся: порядок миграций разошёлся с уже применённым на сервере. После 2 неудачных попыток схему свели вручную, минуя штатный механизм. На этом архив обрывается, поэтому закрытие остаточных дефектов мы не заявляем.
Остались и постоянные издержки. Проверка кода упиралась в 1 человека и копилась во время его отпуска. Частичная загрузка растягивала созвоны. А решения, принятые голосом, терялись: однажды команда полдня восстанавливала причину отдельной ветки, но участники так и не вспомнили её.
Результаты
| Метрика | Значение |
|---|---|
| Работа внутри команды заказчика | 632 дня по состоянию на 5 августа 2026 |
| До первой версии | 69 дней, затем опытная эксплуатация |
| Ритм аналитика | До 20 часов на двухнедельный спринт |
| Самостоятельность инженеров | 11 сообщений владельца бюро из 2 103 в рабочем чате |
| Закреплённые правила | Ветка на задачу, проверка кода, раздельные контуры, автоматическая сборка и выкладка |
| Наполнение каталога | Заказчик делает через интерфейс, без разработчиков |
| Открытые ограничения | Проверка кода зависит от 1 человека; решения из созвонов не всегда попадали в документы |
Код не остался у внешнего подрядчика. Команда заказчика участвует в разработке, сама наполняет каталог и может продолжать работу без отдельной цепочки согласований через владельца бюро. Цена такой самостоятельности тоже видна: правила приживались не сразу, а слабые места процесса приходилось находить на реальных сбоях.
Команда
- Аналитик-программист от бюро, техническое руководство и проверка кода всей команды
- Фронтендер от бюро, интерфейс конструктора и сцена 3D
- Антон Херсун, Xaver Pro, руководитель проекта
Если у вас есть своя команда, но не хватает людей или опыта в предметной области, опишите стек, задачи и то, как устроен ваш процесс. Скажем, кого имеет смысл подключить к команде, на каком регламенте и что вы получите на выходе первого месяца. Первый разговор бесплатный.