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

Три коммерческих предложения часто описывают три разных приложения

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

Запрос предложений нужен именно для того, чтобы этого не произошло. В международной практике такой документ называют RFP, Request for Proposal. В России чаще говорят о конкурсе подрядчиков, тендерном брифе или запросе коммерческих предложений. Название не так важно. Важно дать командам общую исходную информацию и заставить их честно показать, что каждая поняла, включила и оставила за рамками.

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

Не пытайтесь заранее сделать работу выбранной команды

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

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

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

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

Сначала отберите подходящих, потом просите подробный ответ

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

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

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

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

Что положить в запрос предложений

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

1. Контекст и причина проекта. Чем занимается компания, как задача решается сейчас и почему приложение понадобилось именно теперь.
2. Пользователи и основные сценарии. Кто входит в систему и какие действия должны пройти от начала до результата.
3. Признак пользы. Какое наблюдаемое изменение покажет, что первая версия нужна бизнесу и людям.
4. Граница первой версии. Что обязательно, что можно предложить отдельно и что сознательно отложено.
5. То, что уже есть. Сайт, API, CRM, платежи, данные, контент, фирменный стиль, дизайн и внутренние специалисты.
6. Обязательные условия. Платформы, страны, языки, персональные данные, доступность, безопасность, работа без сети и целевые устройства, если это важно.
7. Ответственность сторон. Что предоставит заказчик и кто со стороны подрядчика отвечает за продукт, дизайн, разработку, тестирование, публикацию и поддержку.
8. Владение и передача. Репозитории, облачные и магазинные аккаунты, исходники дизайна, документация, сторонние компоненты и смена команды.
9. Порядок конкурса. Структура ответа, вопросы, сроки, рабочая встреча, критерии и принятие решения.

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

Попросите всех отвечать по одному оглавлению

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

Нумерация допущений кажется мелочью, пока не появляется важное уточнение. Если выяснилось, что CRM не позволяет записывать данные через API, можно попросить всех пересмотреть допущение D-06. Без номера это изменение растворится в звонках и переписке.

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

Оцените критерии до того, как увидите красивые презентации

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

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

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

Важные уточнения должны получать все участники

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

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

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

Вместо второй продажи устройте рабочую сессию

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

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

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

Перед сравнением условий соберите единый объём

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

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

В статье о фиксированной цене и Time and Materials разобрано, как форма договора зависит от неопределённости. Запрос должен обнаружить её заранее, а не спрятать под деловой формулировкой.

Исходный код, аккаунты и выход обсуждаются до договора

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

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

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

Короткий шаблон, который можно взять за основу

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

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

Какие ответы должны насторожить

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

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

Как Appfyl отвечает на хороший запрос

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

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

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Частые вопросы