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

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

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

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

Убедитесь, что вы с подрядчиком понимаете задачу одинаково

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

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

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

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

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

Так может выглядеть примерный call summary
Так может выглядеть примерный 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 на аутсорс, чтобы потом не краснеть перед начальством за потраченный бюджет

Бонус: на чем не стоит экономить, даже если страшно слить бюджет

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

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

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

Кейс из практики. Однажды мы разрабатывали приложение для фаундера из США. Промежуточная задача была в том, чтобы оформить адреса юзера. На стадии техпроектирования поняли, что библиотека, которую мы обычно используем, не подойдет. Ведь в Америке в поле с адресом сначала идет номер дома, затем название улицы и только потом номер квартиры. В итоге разработчики подобрали библиотеку, которая будет отдавать адрес в нужном формате. Так получилось дать заказчику более точные прогнозы, как будет функционировать будущее приложение.

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

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

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

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

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

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

3434
23 комментария

Понятно: на технологиях экономить нельзя, на тех проектировании и поддержке после релиза тоже. А на чем можно-то? 😹

2

На скрам-мастерах 🙂

2

Если агентство понимает, что выходит за рамки бюджета, что еще оно может предложить, кроме как отложить реализацию фич?

2

Может предложить помощь в привлечении инвестиций

1

Предложить вместе с увеличением бюджета какие-то дополнительные функции, которые для агентства ничего не стоят, но ценны для заказчика

1

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

"понимание" с подрядчиком это конечно важно, но из практики, самый важный документ, который нужно подготовить вместе с подрядчиком, это описание пользовательских сценариев (use-cases). Кто куда нажимает и что происходит, максимально подробно.

Из этого документа можно сделать ТТ, ТЗ, ЧТЗ. Они помогут в случае юридических тёрок.

Также в идеале нужно сделать программу приемо-сдаточных испытаний, хотя в целом принимать можно и по сценариям.

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

2