Выбор агентства разработки без попадания в ловушку

Что может пойти не так, если вы наймёте не то агентство

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

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

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

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

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

Большинство неудачных отношений с агентствами попадают в одни и те же ловушки. Обещают старший персонал, а назначают младший. Строят быстро, но пропускают тесты и документацию. Держат админ‑доступ к коду, хостингу и доменам. Берут доплаты всякий раз, когда область работ проясняется. Или делают систему такой непрозрачной, что поддерживать её может только одно агентство.

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

Что нужно определить до переговоров с агентствами

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

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

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

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

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

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

С этими ответами разговоры с агентствами становятся понятнее. Предложения улучшаются, оценки сужаются, а дорогие сюрпризы становятся менее вероятными.

Как отсеивать агентства на первых звонках

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

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

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

Коротный набор вопросов работает хорошо:

• Какой проект, близкий к нашему, вы недавно выпустили?
• Кто будет работать над нашим проектом каждую неделю?
• Как вы разделяете discovery, разработку и поддержку?
• Какие риски или неизвестные вы уже видите?

Содержание ответа важно, но важен и тон. Хорошие агентства говорят «мы пока не знаем», когда это нужно, а затем объясняют, как снизят неопределённость. Слабые заполняют пробелы общими сроками, большими обещаниями и заученными фразами.

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

Один вопрос‑фильтр часто проливает свет: «Если ваш ведущий разработчик уйдёт в следующем месяце, что будет с моим проектом?» Серьёзные команды дадут реальный ответ.

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

Вопросы на интервью, которые показывают, как они работают

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

Вы хотите услышать, как они работают в обычный вторник, а не как продают.

• «Как вы делите работу на вехи и что вы проверяете на каждом этапе?»
• «Кто принимает решения по архитектуре и почему именно этот человек?»
• «Как вы тестируете фичи перед релизом?»
• «Что вы делаете, когда оценки не сбываются или объём меняется?»
• «Что происходит, если разработчик уходит посреди проекта?»

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

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

Хороший приём — задать один и тот же вопрос дважды разными словами. Если ответ меняется, вы нашли риск. Если остаётся таким же, команда, вероятно, понимает свой процесс.

Условия договора, которые защищают вашу компанию

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

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

Условия оплаты должны привязываться к ясным контрольным точкам. Не платите по фразам вроде «постоянный прогресс» или «непрерывная разработка». Связывайте каждый платёж с вехой и простым правилом приёмки, например: утверждённые дизайны, рабочая staging‑сборка или протестированный релиз. Если веха расплывчата — ожидайте споров позже.

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

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

Запросы на изменения нуждаются в собственном процессе. Небольшие команды часто просят «ещё одну вещь» и считают, что это вписывается в начальный бюджет. Так расходы утекают. Агентство должно приостановить работу, оценить добавленную работу и получить письменное одобрение до изменения объёма, цены или сроков.

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

Требования к передаче, о которых договориться до старта работ

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

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

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

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

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

Список передачи

До старта работ прикрепите к договору датированный чек‑лист передачи:

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

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

Практичный процесс, которому реально следовать

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

1. Напишите одностраничный бриф. Опишите проблему, первую версию, бюджетный диапазон, сроки и кто на вашей стороне может утверждать работу.
2. Отправьте этот точный бриф двум‑трем агентствам. Если каждому вы расскажете разную историю, сравнить их будет нечестно.
3. Попросите у каждого одно и то же: кто будет работать над проектом, как они поступят в первые 6–8 недель, как отчитаются о прогрессе и что им нужно от вас.
4. Интервьюируйте людей, которые реально будут делать работу. Отточенный продавец может скрыть слабую команду.
5. Оцените каждое агентство до обсуждения деталей договора или смены цены.

Держите оценку простой. Оцените каждое агентство по ясности, соответствию и риску.

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

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

Затем сделайте паузу. Если что‑то ещё кажется неясным — не подписывайте.

Задавайте уточняющие вопросы, пока агентство не даст чёткие ответы по объёму, запросам на изменения, правам на код, доступам к инфраструктуре, документации и передаче. Хорошие агентства обычно исправляют расплывчатые формулировки без драмы. Слабые подталкивают вас «начать сейчас» и доделать детали позже.

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

Реалистичный пример безопасного отбора

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

Она общается с двумя агентствами и одним фрилансером.

Первое агентство выглядит отполированно. Их продажник говорит быстро, обещает «полностью кастомную платформу» и присылает предложение, полное общих фраз. Цена высокая, но больше беспокоит то, что в предложении не сказано, кто владеет кодом, где будет хостинг, как утверждаются изменения и что происходит, если проект остановится на полпути.

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

Второе агентство менее обаятельно, но гораздо понятнее. Они делят работу на короткий оплачиваемый этап discovery и первую фазу поставки. Оценивают только то, что могут объяснить. Когда владелица спрашивает про передачу, они отвечают простым языком.

Их предложение включает код в собственном Git‑репозитории ритейлера, staging и production в аккаунтах ритейлера, еженедельные демо с письменными решениями, список передачи с документацией и шагами деплоя, и пункт, который позволяет владелице завершить проект и сохранить всё сделанное.

Внештатный CTO просматривает все три предложения и указывает на риск в расплывчатом предложении. Отполированное агентство продаёт уверенность, но владелица узнала бы только позже, что именно она купила. Фрилансер может быть полезен для мелких задач, но это не лучший вариант для полного билда.

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

Ошибки, которые ловят основателей и маленькие команды

Малые команды часто теряют деньги ещё до старта спринта. Ловушка редко в явном плохом намерении. Это расплывчатый объём, слабый контроль и отложенные решения об управлении правами.

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

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

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

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

Передача — ещё одна тема, которую основатели откладывают на конец, и именно поэтому она становится дорогой. Если договор не прописывает доступ к коду, доступ к инфраструктуре, документацию, шаги деплоя, учётные данные и поддержку в период перехода, агентство сохраняет рычаги влияния.

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

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

Быстрые проверки перед подписью

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

Проверьте, контролируете ли вы проект с первого дня или лишь арендуете доступ, пока агентство остаётся во главе. Эта разница вызывает многие неприятные разрывы.

• Убедитесь, что ваша компания владеет всеми аккаунтами и активами: репозитории кода, облачные аккаунты, аналитика, домены, доступ в магазины приложений, дизайн‑файлы и трекинг ошибок. Если агентство хочет что‑то держать в своём аккаунте — спросите почему.
• Прочтите раздел с вехами строка за строкой. Каждая веха должна иметь дату, ясный результат и простые правила приёмки. Если договор говорит, что работа принимается автоматически через несколько дней — настаивайте на изменении.
• Попросите реальные имена людей, которые будут работать над проектом. Часто хорошо звучащие звонки «растворяются», и работа идёт другой командой.
• Протестируйте план передачи коротким объяснением. Если вы не можете объяснить, как код, учётные данные, документы, деплой и поддержка перейдут к вашей команде — план всё ещё расплывчат.
• Пусть внешний технический советник прочитает предложение перед подписью. Хороший ревьюер поймёт слабый объём, отсутствие условий передачи, фальшивую старшинство или обещания доставки, не соответствующие бюджету.

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

Что делать дальше

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

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

Короткая финальная проверка помогает больше, чем ещё один звонок продаж:

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

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

Если вы не уверены, подключите опытного внештатного CTO для второго мнения. Одно внимательное ревью поймает пробелы в архитектуре, структуре команды, сроках и условиях поддержки до того, как они станут вашей проблемой.

Если нужна внешняя проверка, Oleg Sotnikov на oleg.is может просмотреть предложения агентств, пробелы в передаче и риски доставки до подписания. Это имеет смысл, когда вы хотите получить опытное техническое суждение без найма постоянного CTO.

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