Как выбрать IT-компанию для разработки проекта

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

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

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

Проверяйте не портфолио, а то, что живо

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

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

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

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

Просите вопросы, а не цену

Главный признак хорошей команды на первой встрече — она задаёт вам неудобные вопросы вместо того, чтобы называть цифру.

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

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

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

Узнайте, кто именно будет делать

На встрече обычно сидят основатель и менеджер по продажам. Работать с вами будут другие люди. Это нормально — ненормально, когда вам не говорят кто.

Спросите прямо: сколько человек в команде проекта, какие у них роли, будут ли они заняты чем-то ещё параллельно, кто ваш постоянный контакт и что происходит, если он уходит в отпуск. И попросите познакомиться хотя бы с одним разработчиком до подписания.

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

Спросите про седьмой месяц

Почти все вопросы на первых встречах — про запуск. Почти все проблемы — после него.

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

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

Бумаги, которые стоит прочитать

Два пункта, по которым не надо идти на компромисс.

Первый — NDA. Нормальное агентство подписывает его до того, как вы начали рассказывать детали, а не после.

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

С чем мы не согласны

В подборках критериев обычно есть два пункта, которые мы считаем переоценёнными.

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

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

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

Короткий список на встречу

Если некогда читать всё — возьмите с собой эти вопросы:

• Можно ссылки на живые проекты и контакт одного клиента?
• Какие вопросы вы зададите, прежде чем назвать цифру?
• Кто конкретно будет работать и сколько времени тратить?
• Сколько стоит поддержка после запуска и что входит?
• На кого оформлены домен, хостинг и репозиторий?
• Переходят ли ко мне все права на код?

Если на половину из них отвечают уверенно и конкретно — уже хороший знак. Если на все — редкость.