Как отдать MVP на аутсорс, чтобы потом не краснеть перед начальством за потраченный бюджет

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

Всем, привет! Меня зовут Кристина, я менеджер по запуску новых проектов в Purrweb — студии дизайна и разработки MVP для стартапов. Иногда к нам обращаются сотрудники корпораций с грустными историями: хотели запустить внутренний стартап, но подрядчик всё загубил, и теперь нужно переделывать проект с другим агентством. В статье расскажу, как не оказаться в такой ситуации. А в конце вас ждет мини-бонус: подготовила шесть вопросов для первого разговора с подрядчиком. Они помогут оценить, как компания будет вести себя в работе.

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

Вот красные флаги, которые говорят о том, что агентство может создать некачественный MVP:

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

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

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

В галерее — примеры, как хороший и плохой менеджер ответит на ваши первые вопросы 👇

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

Когда во время созвона пора тревожиться:

❌ Менеджер не говорит, какой формат оплаты может предложить. Если компания юлит и уходит от ответа, вы рискуете переплатить. Существует два условных «тарифа»: Fixed Price и Time & Material. Кратко объясню, что есть что.

Fixed Price — это когда клиент договаривается с агентством на фиксированную сумму за весь проект. Допустим, 3,5 млн рублей за приложение. Минус — в фикс стараются зашить все риски. Из-за этого сумма может быть ощутимо выше фактической, и заказчик переплатит. А еще, если вы в процессе захотите убрать пару фич, деньги не вернут.

При Time & Material клиент платит за время команды. Представим, что час работы команды стоит 3 тысячи рублей. Если на разработку MVP понадобится ~900 часов, то в сумме выйдет около 2,7 млн рублей. Также к сумме могут прозрачно добавить сопутствующие расходы, например аренду серверов и лицензии на программы.

Я считаю, что Time & Material — наиболее гибкий и выгодный для стартапера формат. Изменить что-то в проекте можно в любой момент без сложных условий и потери денег. А мы знаем, что стартап — не статуя, отлитая в бронзе, а живой и подвижный организм. Поэтому мы в Purrweb работаем именно по Time & Material.

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

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

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

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

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

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

А вот что в действиях агентства должно насторожить, когда речь зашла о промежуточных результатах:

❌ Не проговаривают четкий план, как будут отчитываться клиенту. Если агентство не готово по шагам объяснить, как вы сможете отслеживать процесс, это красный флаг. В таком случае в финале вы, скорее всего, увидите MVP, который не совпадает с вашими ожиданиями.

❌ Готовы рассказывать о результатах регулярно, но только на словах. Если менеджер прямо говорит, что демонстрации или доступа к тестовой среде не будет, это опасно. Вы не сможете оценить удобство приложения, его сильные или слабые стороны. А значит, растет риск получить MVP, который не будет отвечать поставленным задачам.

Вот что можно спросить у менеджера на первом созвоне и каким может быть его ответ 👇

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

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

На техпроектировании мы в Purrweb продумываем логику, архитектуру и функции приложения. Изучаем сервисы и библиотеки, прикидываем, как внедрить фичи. И только после этого отдаем в разработку. Как ни странно, это не раздувает бюджет, а, наоборот, помогает его сохранить.

💸 Технологии для кастомных функций. Если планируете реализовать в приложении базовые возможности вроде личного кабинета, можно пользоваться фреймворками по типу FlutterFlow. Но с помощью no-code-фреймворков не получится быстро реализовать некоторые интеграции. Представьте: вам нужно разработать оплату в приложении, которое нацелено на рынок страны без известных платежных систем. Доступна только местная «платежка». В коробке no-code-фреймворка, скорее всего, будут только популярные системы вроде Stripe и PayPal, поэтому для разработки оплаты придется писать кастомный код.

💸 Техподдержка после релиза. Когда у заказчика особенно сжатые сроки и бюджет, он может предложить тестировать приложение сразу на первых юзерах. Не доводить продукт до сверкающего идеала перед релизом — рабочая практика. Но стоит изначально договориться на модель багов no major. Это схема, при которой не должно быть значительных ошибок в основном пути пользователя. Например, во время оформления заказа в приложении доставки еды. А чтобы вовремя отрабатывать ошибки, лучше заручиться поддержкой разработчиков после выхода на рынок — так получится оперативно править баги и внедрять улучшения без потери пользователей.

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

В статье мы рассказали, как найти идеального подрядчика для MVP в теории. А чтобы посмотреть на работу агентства на практике, переходите в наше портфолио на сайте и читайте кейсы из разных сфер.

Как думаете, какие еще признаки есть у плохого подрядчика?