Как выстроить взаимоотношения с IT-подрядчиком так, чтобы результат не разочаровал
Запросы бизнеса к цифровым продуктам постоянно растут — количество задач увеличивается, и все они становятся более разнообразными. Закрывать их можно с помощью inhouse-разработки, но далеко не у всех компаний есть возможность и необходимость содержать внутренний IT-отдел. Альтернативным решением стали услуги сторонних подрядчиков — их применяют как для разработки IT-продукта «с нуля», так и для поддержки имеющихся проектов или закрытия точечных задач.
В 2023 году более трети российских компаний стали чаще пользоваться услугами IT-аутсорсинга, чтобы комфортно регулировать расходы и быстро адаптироваться к изменениям на рынке. Однако далеко не у всех есть опыт работы с вендорами — зачастую это приводит к просадке в коммуникациях, которые могут отразиться на итоговом варианте продукта. В статье мы расскажем, что нужно знать при первом опыте взаимодействия с IT-подрядчиком, чтобы ожидание и результаты работы совпали.
Как понять, что это тот самый подрядчик, который вам нужен
Разработчики сегодня — это как юристы и экономисты 15 лет назад. С одной стороны, на рынке их много, но с другой — велик риск нарваться на недобросовестного подрядчика.
Для того, чтобы не прогадать с выбором внешнего исполнителя, проанализируйте собственные потребности и обозначьте бизнес-задачи, которые будет решать продукт. Эффективный поиск подрядчика возможен только тогда, когда предприниматель точно знает, что он хочет получить от проекта на выходе. Когда первичный вектор работы определен, сформировать список требований к вендору становится проще.
Среди таких критериев могут быть следующие.
Стоимость услуг. Учитывайте, что вендоры по-разному подходят к оценке одной и той же задачи. Компания с меньшей ставкой за час может выполнять работу медленнее, чем конкуренты с более высоким прайсом. В итоге за счет увеличения времени разработки, конечная стоимость IT-продукта может стать даже выше.
Формат работы и модель формирования цены. Существует две модели оплаты: по почасовой ставке специалиста и за готовый продукт. Выбор способа зависит от ваших потребностей. Например, для закрытия отдельных задач по разработке подойдет оплата за час работы сотрудника, а при разработке «с нуля» — за завершение определенного этапа.
Средние сроки разработки. Если вы приходите к вендору с запросом выпустить продукт за определенное время, учитывайте, что он может не всегда совпадать с оценкой времени от вендора. В таком случае есть смысл уточнить, почему на реализацию потребуется больше времени: из-за расхождения планируемых сроков с реальным количеством работы или из-за недостатка ресурсов вендора для быстрого запуска проекта.
Возможность отслеживать ход работы. Это не значит, что вам будет необходимо контролировать весь процесс разработки «от» и «до». Однако регулярная обратная связь от вендора и отчетность помогут оставаться в контексте. Предоставлять такую информацию подрядчик должен минимум раз в неделю. Разработка IT-продукта тесно связана с работой внутренних подразделений: если процессы задерживаются со стороны программистов, это может повлиять, например, на запуск рекламных кампаний в отделе маркетинга. Когда вы четко знаете статус работ на стороне вендора, то планировать любые активности и реагировать на изменения в проекте становится проще.
Компетенции команды. Примерно понять уровень навыков разработчиков в аутсорс-компании можно, изучив их прошлые проекты: оценить визуальную составляющую сайтов, проверить удобство и функциональность. Если у вас есть доверенное лицо со знаниями в сфере разработки, вы можете подключить его к общению с программистами и провести с ними небольшое собеседование, как при приеме в inhouse-команду.
Отзывы и рекомендации от коллег и партнеров. Идеальным решением будет получить обратную связь напрямую от представителей компаний, которые уже взаимодействовали с подрядчиком ранее. Если такой возможности нет, то не лишним будет все равно изучить, что пишут о вендоре в интернете. Например, можно ознакомиться с отзывами на специализированных площадках или рейтингами IT-компаний.
«Красным флагом» в общении с вендором может служить использование огромного количества терминологии. Подрядчик должен говорить со своим заказчиком на одном языке, и если вы что-то не понимаете, просите объяснений. Если даже после этого картина не прояснилась, это может означать, что сотрудники компании недостаточно компетентны и сами не до конца понимают значение отдельных понятий. Существуют и исключения: если подрядчик вызвал доверие, но продолжает говорить непонятными словами, подключите к коммуникации знакомого из IT-сферы, который сможет оценить ситуацию.
«Красным флагом» в общении с вендором может служить использование огромного количества терминологии. Подрядчик должен говорить со своим заказчиком на одном языке, и если вы что-то не понимаете, просите объяснений. Если даже после этого картина не прояснилась, это может означать, что сотрудники компании недостаточно компетентны и сами не до конца понимают значение отдельных понятий. Существуют и исключения: если подрядчик вызвал доверие, но продолжает говорить непонятными словами, подключите к коммуникации знакомого из IT-сферы, который сможет оценить ситуацию.
В момент пресейла обратите внимание на задержки и то, как компания выполняет свои обещания. Если сложности заметны уже на этом этапе, то в дальнейшем они могут проскальзывать и в работе над проектом.
Перед началом сотрудничества запросите у вендора состав команды, которая будет работать над вашим проектом. Для успешного релиза продукта в нее должны входить:
- менеджер проекта — взаимодействует с клиентом и отвечает за весь ход разработки;
- аналитики — анализируют конкурентов, проводят «глубинные» интервью и переводят пожелания заказчиков в понятные для разработчиков задачи;
- дизайнеры — занимаются разработкой визуала;
- разработчики — пишут код для frontend’а и backend’а, при необходимости настраивают интеграции;
- тимлиды — проектируют frontend, backend, мобильную часть и курируют разработчиков. В зависимости от загрузки на проекте могут не только руководить командой, но и подключаться к выполнению сложных задач;
- тестировщики — проверяют функционал и работоспособность продукта.
Из каких этапов складывается разработка
Раскроем подробнее каждый из этапов.
Предпроектная подготовка и сбор требований. Будьте готовы особенно активно включиться в проект на первом этапе работы. Необходимо передать разработчикам максимально полную информацию о проекте. Взгляните на свой продукт глазами конечного пользователя и опишите, как потенциальный клиент должен видеть и пользоваться разработанным решением. Если у вас уже имеются подготовленные прототипы, макеты, описания пользовательских сценариев и любые другие наработки, смело передавайте их подрядчику. Стремитесь максимально погрузить специалистов в особенности сферы и проговаривайте даже те аспекты, которые могут показаться вам очевидными. Как правило, внешний сотрудник не всегда видит ситуацию так же, как внутренний.
Будьте готовы к тому, что за качественную предпроектную подготовку придется заплатить — так подрядчик сможет выделить время и специалистов для более глубокого погружения в сферу и проработки деталей. Вы же будете уверены, что разработчики действительно понимают ваши потребности и бизнес-цели.
Во время подготовки к работе стоимость разработки может измениться в сравнении с оговоренной на пресейле, в некоторых случаях даже кратно. Такое нередко случается, когда вендор получает более детальную информацию о планируемом проекте либо в ходе диалога выявляются новые запросы: дополнительный функционал, технические сложности реализации и другие. То же касается и сроков — при более подробном рассмотрении задач они могут как увеличиться, так и уменьшиться. Учитывайте это при планировании расходов и временных рамок.
Разработка дизайна. Визуальная составляющая проекта играет не меньшую роль, чем техническая. Именно эту часть продукта будет видеть конечный пользователь. От ее проработки зависит, как он воспримет информацию на сайте или в мобильном приложении, сколько проведет в нем времени и совершит ли целевые действия.
Часто случается, что излишние попытки выделиться и создать что-то принципиально новое приводят к низкой вовлеченности потенциального клиента. Пользователи привыкают к определенной навигации и сценариям использования сайтов и в мобильных приложениях. Например, это может быть привычное расположение кнопок и разделов, оформление заказа и заполнение формы обратной связи. Именно на этих паттернах основывается разработка дизайна решений.
Значительные отхождения от привычного дизайна могут снизить удобство использования и усложнить выполнение целевого действия. Однако это не значит, что любые нововведения под запретом — для таких случаев существует система A/B тестирования. Такой метод исследования делает перемены в продукте доступными только для тестовой группы — части посетителей сайта или приложения. По их реакции вы сможете понять, насколько оправдано решение.
Проектирование. На этом этапе участие предпринимателя необходимо минимальное. Самое главное — отследить, чтобы подрядчик действительно проводил проектирование и не пропускал этот шаг. Подтверждением того, что работа по этому этапу велась, станут макеты в Miro, прототипы, схемы сервисов и баз данных. Если разработчик сразу приступает к написанию кода, велик шанс, что впоследствии придется столкнуться со значительными корректировками или полностью переделывать весь продукт.
Разработка. Процесс программирования не требует сильной погруженности владельца продукта. В большинстве случаев увидеть результаты работы команды можно будет непосредственно на тестовой версии решения. Однако получать промежуточную обратную связь от вендора по-прежнему важно. Внимательно просматривайте отчетность, запрашивайте дополнительную информацию и записи экрана. Просите объяснить, если вам что-то непонятно, и сообщайте, если какие-то детали расходятся с вашими ожиданиями. Если не вести тесную коммуникацию с вендором, конечный вариант продукта может отличаться от ваших ожиданий.
Тестирование продукта. На результаты тестирования влияет, насколько хорошо было выполнено проектирование — чем менее вдумчиво оно было проведено, тем больше исправлений придется внести в продукт после проверки. Этот пункт обязателен, так как он помогает выявить ошибки, допущенные на более ранних стадиях. На эту стадию закладывается порядка 20% от общей стоимости проекта.
Внимательно проверяйте результаты работы на тестовой версии. Фиксируйте, если что-то расходится с вашим видением конечного продукта. Поставьте себя на место пользователя и пройдите по его пути, чтобы проверить весь функционал. Зачастую при тестировании выявляется основной спектр ошибок. После финальных улучшений продукт дорабатывается, и принимает законченный вид.
Ввод в эксплуатацию. Программисты настраивают серверы, прописывают все домены и интегрируют продукт в архитектуру клиента. После этого проект выходит в релиз.
Поддержка продукта. Процесс создания IT-решения не заканчивается вводом в эксплуатацию. После запуска продукта, даже если на текущий момент он кажется идеальным, его обязательно поддерживать: устранять баги, увеличивать нагрузку и масштабировать проект. Чтобы выявить слабые места решения, можно пообщаться с конечными пользователями и собирать аналитику — так вы сможете проверить, насколько продукт удобен с точки зрения потребителя и впоследствии привлечь разработчика к его улучшению.
Однако спустя время вы поймете, что проект уже перерос свои возможности либо на этапе планирования не были учтены определенные разделы или функции. Тогда необходимо вернуться к первому этапу и продолжить расширять нынешний продукт: добавлять новые разделы, функции и возможности для конечного потребителя.
Рекомендации по работе с IT-подрядчиком
Итак, ниже разберем, как работать с подрядчиком.
Дайте разработчикам возможность пообщаться с конечными клиентами.
Найдите единую точку коммуникации с подрядчиком. Определите ответственного, который будет вести коммуникацию с разработчиками и доносить финальное решение вашей команды. Лучше не допускать ситуации, когда с подрядчиком общается сразу несколько человек. Взгляды на работу у inhouse-сотрудников могут отличаться. Это размывает следующие шаги для программистов и замедляет процессы.
Приоритезируйте задачи. В фокусе должны быть задачи, которые напрямую влияют на вашу выручку. Например, восстановление нерабочей кнопки на странице, у которой два посещения в месяц, не так важно, как проблемы при оформлении заказа в интернет-магазине. Если не знаете, какую задачу поставить в приоритет подрядчику, спросите у него, что в первую очередь нужно сделать, чтобы не терять продажи. Вендоры, которые уже работали ранее в похожей сфере, понимают, какие функции будут важнее всего для достижения ваших целей.
Используйте дополнительные соглашения для разных этапов разработки. Заключите рамочный договор с IT-подрядчиком, а для каждого этапа разработки подпишите дополнительные соглашения к нему. Это сделает оплату проекта более удобной за счет дробления платежа на более мелкие суммы. Кроме того, каждое дополнительное соглашение станет своеобразной вехой проекта, которая покажет вам результат.
Если результата долго нет — проведите аудит. Прошло 1-2 месяца, а промежуточных вариантов продукта все еще нет, то здесь возможны два варианта:
- Так и должно быть. Например, программисты начали работу над сайтом с разработки и проектирования архитектуры в backend’е. Такой подход к работе логичен и особенно важен при создании масштабного и функционального продукта, так как от нее зависят все элементы будущего сайта. При этом увидеть результат сразу вряд ли получится, и чем крупнее проект, тем больше времени займет этот этап. Об этом подрядчик должен сообщить вам заранее.
- Ситуация SOS. Просили сделать одно, а сделали другое, или постоянно нарушаются сроки.
В первом случае попросите у вендора поделиться текущим статусом работы над административной панелью и рассказать, какие процессы сейчас происходят в команде разработки. Во втором — постарайтесь разобраться в ситуации и запросите информацию у подрядчика. Если у вас остаются сомнения, вы можете привлечь отдельного специалиста для проведения аудита.
А вы пользовались ранее услугами вендоров при разработке IT-продукта? Если да, поделитесь своим опытом.