Code Pilots 
Тендеры и лиды
Информация
Выбор подрядчика на разработку почти всегда делается по одним и тем же признакам — портфолио, отзывы, цена. Все три говорят мало. В портфолио попадают удачные проекты, красиво снятые и часто сделанные людьми, которые в студии уже не работают. Отзывы пишут в момент сдачи, когда все довольны, а интересное начинается на третьем месяце поддержки. Цена без состава работ не значит ничего.
Проверить компанию по разработке можно иначе — разговором. Ниже двенадцать вопросов, которые я слышу от толковых заказчиков сам: в Code Pilots их задают нам на каждой второй встрече. С расшифровкой — что означает каждый ответ и какой считается плохим. Вопросы работают и для студии на сто человек, и для команды из пяти. Часть из них я задаю и сам, когда выбираю подрядчика для своих продуктов.
Документы показывают прошлое, вопросы — настоящее. Хороший подрядчик отвечает на них быстро и конкретно, потому что отвечает так каждую неделю. Тот, кто начинает объяснять, что «всё индивидуально», уже ответил.
Задавать всё сразу не нужно — разбейте на два разговора, до оценки и после неё. И записывайте ответы: через неделю переговоров с пятью студиями всё смешается.
Хороший ответ называет предмет, который вам передадут, — кликабельный прототип, схему данных, описание ролей и оценку по задачам. Плохой звучит как «проведём аналитику» без продолжения.
Здесь же выясняется, платный ли первый этап. Платный — нормально и часто честнее: бесплатная оценка либо поверхностная, либо её стоимость всё равно зашита в проект.
Вопрос неудобный, и потому полезный. У любой сметы есть граница, и проходит она обычно по текстам и фотографиям, наполнению каталога, аккаунтам в магазинах приложений, серверам и лицензиям. Отдельная история — доработки на стороне ваших систем, которые делает уже не подрядчик.
Если в ответ вы слышите «всё включено», просите перечислить границы явно. Всё включено не бывает.
Правильный ответ описывает процедуру: как это обнаруживается, кто сообщает, что подписывается, как считается. Тревожный — обещание, что такого не случится. Случается на каждом втором проекте, вопрос только в том, как это обработано.
Просите разложить срок по этапам и показать, где в нём заложены ваши согласования. Срок, в котором ожидание ответов заказчика равно нулю, всегда оптимистичен: на реальном проекте это недели.
Классическая история: продаёт один состав, работает другой. Спросите имена, роли и загрузку. Совсем хорошо, если можно поговорить с тимлидом до подписания — пятнадцать минут разговора с тем, кто будет делать, стоят трёх встреч с менеджером по продажам.
Ответ показывает зрелость процессов. У команды с нормальной практикой есть ответ про передачу контекста, документацию и парное ведение ключевых частей. У команды без процессов ответ звучит как «у нас такого не бывает».
Цифра важнее, чем кажется. Менеджер на восьми проектах физически не может знать детали вашего, и все расхождения в требованиях всплывут поздно.
Разница видна в проде. Когда макеты принимает тот, кто их рисовал, интерфейс выглядит так, как согласовали. Когда дизайнер ушёл на другой проект, получается «примерно так же», и спорить поздно.
Ответ «через месяц» или «каждые две недели демо на стенде» — норма. Ответ «на приёмке» — красный флаг: все риски проекта копятся до конца, и первый раз вы увидите результат, когда бюджет уже израсходован.
Спросите, что именно вы будете видеть — доску с задачами, отчёт по часам или еженедельный статус письмом. Здесь нет единственно правильного формата, но формат должен существовать. Если его нет, вы узнаете о проблеме в день срыва срока.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13755 тендеров
проведено за восемь лет работы нашего сайта.
Половина списка — про этот момент, и именно эти вопросы обычно не задают.
Уточните формулировку. «Исправляем свои ошибки три месяца» и «исправляем любые проблемы» — разные обязательства. Заодно спросите, что считается ошибкой: падение приложения — да, а «пользователям неудобно» — уже спорная территория, и её лучше проговорить заранее.
И сразу за гарантией спросите, что дальше. Продукт живёт, операционные системы обновляются, внешние сервисы меняют правила — после гарантии всё это переходит в поддержку с оговорёнными сроками реакции. Команда, у которой на этот вопрос есть готовый ответ, обычно и разработку ведёт спокойнее.
Правильный ответ: код ваш, репозиторий у вас с первого дня, по окончании работ передаются исходники, доступы и инструкция по развёртыванию. Сомнительный — «отдадим после полной оплаты» без деталей или «код на наших серверах».
Проверьте заодно, что будет с доступами к магазинам приложений и внешним сервисам: аккаунты должны быть оформлены на вашу компанию.
«Сделаем как в задании, вопросов нет». Если после описания проекта у подрядчика нет ни одного уточняющего вопроса, он либо не читал, либо посчитал не то. Нормальная реакция на задание — десяток вопросов, часть из которых неприятные.
«Наш процесс вам знать не нужно, доверьтесь». Доверие строится на предсказуемости. Если объяснить процесс нечем, значит, процесса нет.
«Такого у нас не случалось». Проекты без проблем бывают только в презентациях. Отсутствие историй провала означает либо короткий опыт, либо нежелание о нём говорить — оба варианта плохи, потому что вам важно понять, как команда действует, когда всё пошло не так.
Помимо разговора есть три быстрые проверки.
Возраст отношений с клиентами. Спросите не число проектов, а сколько лет живут самые долгие отношения и почему клиенты остались. Я на такой вопрос отвечаю так: с Эрартой мы работаем с 2018 года, с RoseMarkt — с октября 2015-го, фестивальное приложение VK Fest выпускаем каждый сезон с 2016-го. Длительность здесь говорит больше, чем количество логотипов на главной. Как такие отношения выглядят со стороны клиента, видно в кейсе Радиоэлементов — каталог на 500 000 позиций с подбором аналогов.
Публичные разборы. Если студия пишет о своей работе — не о победах, а о механике, — её процессы легко проверить чтением. Мы собирали такой разбор по рынку в обзоре компаний аутсорсинга разработки.
Договор. Прочитайте раздел про приёмку и гарантию раньше, чем раздел про цену. В хорошем договоре написано, как именно фиксируется факт выполнения работ и что происходит при разногласиях. В плохом на этом месте общие слова.
Вопросы выше работают в любом случае, но акценты смещаются.
Студия полного цикла отвечает за результат целиком, и с неё спрашивают процессы, состав команды и гарантию. Это подход, при котором вам не нужно управлять разработкой самому — как он устроен у нас, описано на странице заказной разработки.
Отдельные специалисты под вашу команду дешевле в час и дороже в управлении: планирование, приёмка и ответственность за срок остаются на вас.
Фрилансер подходит для изолированной задачи с понятным результатом. На продукте, который живёт годами, риск один: человек уходит, а вместе с ним уходит и знание системы.
Последнее, чем поделюсь из своего опыта. Двенадцать вопросов занимают час, и этот час — самая дешёвая часть проекта. Я свой первый продукт запускал без половины из них и заплатил за это годами переделок; с тех пор задаю все двенадцать, даже когда подрядчика мне рекомендовали люди, которым я доверяю.
Как проверить компанию по разработке до подписания договора? Задать двенадцать вопросов выше, поговорить с тимлидом, прочитать раздел договора о приёмке и гарантии и спросить о самых долгих отношениях с клиентами.
Что должно быть в договоре обязательно? Состав работ, порядок приёмки, гарантийные обязательства и права на код. Всё остальное — детали, эти четыре пункта определяют, что вы получите на выходе.
Нормально ли платить за оценку? Да. Платная оценка обычно означает разбор задачи, а не угадывание, и её результат — прототип со сметой — остаётся у вас, даже если вы выберете другого подрядчика.
Сколько студий стоит рассматривать? Три-пять. Дальше растёт не качество выбора, а время: ответы начинают повторяться, а сравнивать становится тяжелее.
Что делать, если предложения отличаются в разы? Сравнить состав работ, а не итоговые суммы, и попросить всех посчитать одинаковый объём. Обычно после этого разница объясняется за десять минут.
