Инхаус-разработка или аутсорс: как агентству встроиться в процесс

Инхаус, аутсорс и смешанная команда

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

Внутренняя разработка и агентство не противники. Чаще всего зрелый продукт приходит к смеси: ядро и архитектура у своих, а пиковые задачи, новые направления и узкая экспертиза у подрядчика.

Сравниваю три модели по тому, что меня волнует на старте проекта:

Когда своя команда выгоднее

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

Когда лучше агентство

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

Как разделить фронтенд и бэкенд между командами

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

• контракт API описан заранее, например в OpenAPI, и изменения в нём согласуются;
• есть общий тестовый стенд, где фронтенд видит актуальную версию бэкенда;
• задачи обеих команд живут в одном трекере;
• раз в неделю проходит общая синхронизация с участием обеих сторон;
• на время, пока API не готов, фронтенд работает на заглушках с тем же форматом данных.

Договор и ответственность на стыке

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

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

Кто координирует инхаус и аутсорс

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

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

Как агентству погрузиться в продукт заказчика

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

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

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

Ошибки смешанной команды

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

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