Менеджмент

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

Аутсорсинг не должен превращаться в халтуру.

В 2016 году компания Deloitte опубликовала исследование, согласно которому 31% всех IT-задач выполняются специалистами на стороне.

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

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

Что не так с аутсорсингом

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

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

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

Аутсорс-разработчики не думают о будущем проекта, но они не со зла подходят к задачам механически. Небольшие IT-компании живут за счёт потока клиентов — исполнители не могут задерживаться на одном проекте дольше, чем договорились в начале. Строгие техзадания уместны, когда у заказчика есть технический эксперт со свободным временем и пониманием, как выглядит конечный продукт. В остальных случаях лучше дать разработчикам больше свободы.

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

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

Аутсорс сочетается с продуктовым подходом

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

Вот как мы объединили аутсорсинг и продуктовую разработку:

  • Компания-разработчик влияет на требования к продукту, работа идёт в связке «разработка — маркетинг — аналитика»
  • Представители заказчика занимаются проектом 50% рабочего времени

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

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

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

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

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

Как найти команду с продуктовым подходом

С первого взгляда проектную команду от продуктовой отличить трудно. Но вы сразу поймёте, кто есть кто, когда начнутся переговоры.

Проектная команда

делает продукт правильно

техническое задание

просит составить требования и концепцию продукта

контролирует сроки, стоимость и соблюдение требований

разрабатывает продукт

запрашивает дополнительные требования и дорабатывает проект на поддержке

продукт, который просили сделать

Продуктовая команда

делает правильный продукт

KPI для создания MVP

тестирует идеи: исследует аудиторию и конкурентов

ищет лучшее решение

запускает и тестирует MVP

анализирует обратную связь и метрики, выпускает новые версии продукта

востребованный продукт, приносящий деньги

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

Другие варианты

Инхаус-разработка — создание команды с нуля либо покупка готовой продуктовой команды. Долго, дорого и чревато проблемами — что делать с новыми разработчиками, когда проект закончится? Хорошие менеджеры, разработчики и маркетологи в дефиците. Учитывайте, что сотрудников приходится ждать до трёх-четырёх месяцев.

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