Как выстроить взаимоотношения с IT-подрядчиком так, чтобы результат не разочаровал

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

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

Разработчики сегодня — это как юристы и экономисты 15 лет назад. С одной стороны, на рынке их много, но с другой — велик риск нарваться на недобросовестного подрядчика.

Среди таких критериев могут быть следующие.

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

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

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

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

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

«Красным флагом» в общении с вендором может служить использование огромного количества терминологии. Подрядчик должен говорить со своим заказчиком на одном языке, и если вы что-то не понимаете, просите объяснений. Если даже после этого картина не прояснилась, это может означать, что сотрудники компании недостаточно компетентны и сами не до конца понимают значение отдельных понятий. Существуют и исключения: если подрядчик вызвал доверие, но продолжает говорить непонятными словами, подключите к коммуникации знакомого из IT-сферы, который сможет оценить ситуацию.

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

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

Раскроем подробнее каждый из этапов.

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

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

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

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

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

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

Ввод в эксплуатацию. Программисты настраивают серверы, прописывают все домены и интегрируют продукт в архитектуру клиента. После этого проект выходит в релиз.

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

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

Итак, ниже разберем, как работать с подрядчиком.

Дайте разработчикам возможность пообщаться с конечными клиентами.

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

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

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

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