Сайт, портал или кабинет вместе с внутренней ИТ-командой заказчика

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

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

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

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

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

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

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

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

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

Как выглядит обмен, когда его много, видно по перезапуску GrandeBoutique.ru — сети мультибрендовых магазинов с историей больше двух десятилетий. В карточке проекта названы свыше 35 000 позиций каталога и более тридцати интеграций, а переезд с прежней коробочной платформы на новый стек шёл с задачей сохранить объём поисковой выдачи.

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

Оговорка по честности: в кейсе описаны внутренние системы и обмен с ними, но не сказано, кто именно их сопровождает на стороне компании. Читать пример стоит как устройство границы, а не как рассказ о работе с конкретной ИТ-службой.

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

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

Вопрос о стеке — это вопрос найма, а не вкуса: спрашивают не «какой фреймворк лучше», а «сколько людей на рынке труда умеют это сопровождать и сколько их в команде сейчас». У такого вопроса есть проверяемый ответ.

Пример, где граница прошла именно так, — приложение EdPro для Международной академии дополнительного профессионального образования: Топ-3 сегмента, более 10 000 выпускников, аудитория продуктов свыше 150 000 человек. Платформа академии уже работала в вебе — то есть у заказчика были и продукт, и команда, которая его ведёт.

Приложение не заменяло платформу и не дублировало её логику. Серверная часть интегрирована с существующей платформой через защищённые API, авторизация построена на ролях — студент, преподаватель, администратор, — а управление ролями и доступом осталось централизованным, на стороне платформы. Изменение контента в веб-среде автоматически отражается в мобильном решении, а кроссплатформенный Flutter дал единый код для iOS и Android.

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

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

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

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

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

Со стороны внутренней команды выдача доступа — не кнопка, а оформленный риск: кто-то подписывает, что внешние люди получили права в системе с живыми данными. Если подрядчик просит «полный доступ, чтобы разобраться», медленный ответ рационален. Плюс у команды свой план на квартал, где ваш проект не первый.

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

Второй сюжет: внутренняя команда открывает код и видит, что он написан не по её правилам — другая структура, другие имена, свои решения вместо принятых в компании. Реакция предсказуема: «это нам сопровождать», и она справедлива.

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

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

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

Это не вопрос добросовестности, а следствие деления по системам: у границы две стороны, и если никому не поручено смотреть на сценарий целиком, никто и не смотрит. Лечится назначением: у продукта есть человек со стороны заказчика, который отвечает не за систему, а за сценарий от начала до конца, и у него есть право собрать обе команды без согласования.

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

Есть и человеческая часть. Привлечение подрядчика внутренняя команда иногда читает как оценку своей работы — это нормальная реакция, а не вредность. Снимается она распределением ролей, в котором предметная экспертиза явно остаётся за внутренней командой: она знает, как устроен учёт, какие случаи считаются исключениями и почему прошлая попытка не взлетела.

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

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

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

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

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

И то, чего такая схема не обещает. Разделение по системам не ускоряет проект само по себе — оно делает ответственность определимой. Записанные договорённости не отменяют споров — они сокращают их до предмета.

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

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