Аутсорсинг не должен стать халтурой

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

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

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

С аутсорсом в IT три беды: обман, неэффективное техзадание и нежелание общаться.

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

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

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

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

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

Загрузка…

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

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

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

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

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

  • Представители заказчика занимаются проектом 50% рабочего времени.

  • Разработчик участвует в принятии решений.

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

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

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

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

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

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

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

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

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

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

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

Фотография на обложке: Michael Ochs Archieves / Getty Images

Источник