После интервью мы попросили два разных агентства разработки что-нибудь на это ответить: их мнения в конце статьи. И вы тоже можете присоединиться — интересный экспертный комментарий с большой вероятностью прочитает потенциальный заказчик.
Аналитические материалы Рейтинг Рунета публикует в блоге на VC и в телеграм-канале.
Подписчиков ждут статьи с анализом digital-рынка, советы по выбору и работе с подрядчиками, полезные инсайды для исполнителей.
Присоединяйтесь!
Сергей Герштейн, CEO «Кнопки»
Сергей, в вашем публичном бэкграунде есть интересный момент, что у вас остались «фантомные боли насчёт разработки, руки чешутся». Насколько сильно чешутся?
Я начинал свою карьеру, как разработчик — страшно сказать, сколько это было лет назад :).
Лет пятнадцать активно занимался сервисами, связанными с разработкой, непосредственно много программировал. Потом постепенно уходил от разработки в сторону менеджмента. И последние лет пятнадцать к разработке прямого отношения не имею, при этом всё ещё руки тянутся в качестве хобби что-то поделать для себя, пусть и на сильно устаревших технологиях.
Раз речь зашла о технологиях, что вы думаете о текущем хайпе про нейросети? Сейчас есть два лагеря: один лагерь — прогресс не остановить, другой — давайте подумаем, какие-то нормы обозначим.
С одной стороны, я всегда за то, чтобы продумать этические нормы. Чтобы все примерно в одном понимании находились, что такое «хорошо» и «плохо».
Но при этом я очень сильный сторонник того, что прогресс остановить невозможно. Если что-то запретить, оно всё равно вылезет.
Революций экономика знала много — промышленная, аграрная. И может быть, что случится революция ИИ. Это не уничтожит человечество, а выведет на новый виток. И не уничтожит рабочие места, а как-то их трансформирует — как когда-то промышленная революция переделала аграрные места в рабочие места на фабриках. От этого меньше работы не стало.
Если говорить про работу с подрядчиками, про какие направления с вами уместнее разговаривать — больше про разработку или про рекламу, перформанс и прочее?
Мне ближе тема разработки. В разработке у меня есть своя позиция, почему мы сейчас такими подрядчиками не пользуемся. У нас был опыт с агентствами, поэтому нельзя сказать, что мы «не пробовали и осуждаем». Мы попробовали и пришли к такому выводу.
Эта тема мне близка, потому что такими запросами заваливают. Каждый второй человек, который стучится в LinkedIn, хочет предложить аутсорс разработки. Я не знаю, почему — возможно, я попадаюсь в какой-то нужной выборке. Эти предложения делают по-разному, бывают даже люди, которые хорошо готовятся и понимают, что у нас за компания, какой стэк.
Они приходят и говорят: «Мы знаем, что вы делаете на этом стеке. У нас есть нужные программисты, мы сделаем хорошо и правильно, это для вас будет дешевле и быстрее».
Какое соотношение между теми кто хорошо готовится и кто вообще не готовится?
1 к 10. Большая часть пишет очень стандартно с точки зрения кастомизации. «Мы можем сделать вам сайт».
Насчёт хорошей подготовки что я имею ввиду — человек понимает, кому он пишет, и знает, чем мы занимаемся.
Когда у меня есть настроение, я отвечаю на эти обращения и рассказываю, почему в нашем случае это не сработает. Тут небольшая история.
Что это за история, и где она берёт начало?
Мне кажется, услугами аутсорса разработки могут пользоваться два типа клиентов.
Первый тип — компании, у которых своей разработки нет. И если возникает необходимость сделать что-то айтишное, начиная от сайтика и заканчивая внутренней автоматизацией, то единственный способ — привлечь внешних подрядчиков. Конечно, всегда есть вопрос, как выбирать, но тут понятно, что есть потребность и её другими способами не удовлетворить.
И второй тип — это интересная ситуация, когда есть айтишная компания, и у неё есть свой ресурс. И здесь внешний подрядчик обещает две вещи:
это будет промышленно и «на уровне»;
это будет быстрее, потому что у нас ресурс свободный, а у вас занят.
Это на самом деле правда.
Потому что если у IT-компании есть свободный ресурс разработки, то что-то не так с этой компанией.
Это та история, когда коллеги из другого отдела, например, перформанса, приходят и говорят «Нам на сайте что-то пофиксите», а им говорят «У нас бэклог на полгода вперёд, отстаньте от нас»?
Да, примерно про это. Здесь внутренняя разработка выступает как исполнитель внутренних заказов. В правильных IT-компаниях всё построено вокруг продукта и весь ресурс в него вкладывается, он расписан на годы вперёд.
При этом понятно, что:
классные идеи продвигают без очереди;
не бывает такого, что сидит разработчик и скучает: «Блин, что-то мне на этой итерации заняться нечем» (если такое бывает, то в этой компании, опять же, системно что-то не так).
Тут встают два вопроса: может ли внешняя разработка быть дешевле, чем внутренняя? И может ли внешняя разработка быть быстрее? На первый вопрос в нашем конкретном случае мы отвечаем чётко «нет».
Компании бывают разные, у кого-то может быть какая-то своя дорогая разработка, и поэтому какие-то вещи можно делегировать индийцам или китайцам. Такие конструкции бывают.
Но мы находимся в России, и у нас разработчики, в среднем, стоят рыночно. Поэтому кажется, что другая российская компания технически не может сделать что-либо дешевле [и достаточно качественно]. Там такие же разработчики, которые в среднем имеют такую же зарплату, плюс у них есть какой-то менеджмент, бизнес.
Если мы начнём ставить задачу внешней компании, у нас неизбежно возникнет необходимость рассказать — что мы делаем. А чем сложнее предметная область, тем сложнее рассказать.
Мне в этом смысле откликается ваше интервью с Модульбанком. Предметная область сложная — финансы, бухгалтерия — классический разработчик в этом не разбирается. Там возникают циклы и дополнительный оверхед.
В какой-то момент мы решили поэкспериментировать. Наняли хорошую компанию, поставили ей достаточно оторванную от общих дел задачу, чтобы это было отдельным блоком. И в процессе поняли, что вопросов по взаимодействию всё равно возникает очень много. В рамках аджайла нужно постоянно общаться, корректировать, проверять, что сделали. Получается, что на это тратится часть внутреннего ресурса.
Теоретически можно было бы обсуждать китайских или индийских программистов — но вопрос коммуникации съел бы любую экономию.
Ещё момент, который мы не сразу поняли: подрядчик отгрузил нам результат. Сделано хорошо. Но дальше нужно этот результат поддерживать: мы должны постоянно арендовать услугу поддержки у той же компании или у кого-то ещё. А это снова расходы.
Мы должны их встроить в наш контур — интегрировать с нашими системами мониторинга, со всеми людьми, которые занимаются поддержкой. Это тоже дополнительные затраты времени и денег. Поэтому иногда проще что-нибудь переписать под нас, чтобы было легче поддерживать.
Вывод, который мы вынесли из этого эксперимента: в среднем, если всё идёт хорошо, то стоимость внешней разработки — это x3 от стоимости внутренней.
Я не говорю, что у всех так. Это у нас так работает, и вряд-ли это как-то существенно можно изменить.
С другой стороны, здесь действительно можно выиграть время. В той же самой ситуации, когда у нас нет свободного ресурса, и лучше что-то сделать дорого, чем не делать вообще, то внешняя разработка позволяет купить время за деньги. Мы платим х3, чтобы получить то, что можем сделать своими силами, но для этого придётся что-то отложить.
В итоге для меня конструкция выглядит так: привлечение внешней разработки для IT-компании — это:
Купить время за деньги (дорого).
В каких случаях это осмысленно, а в каких нет — это каждый бизнес решает по своему.
Вы выше сказали, что когда проводили эксперимент с внешним аутсорсом, то «дали задачу хорошей компании». Что вы вкладываете в понятие хорошей, как вы это для себя определили?
Во-первых, коллеги должны иметь опыт работы в той сфере, что и у нас. Если мы хотим взять поддержку, нужно, чтобы это был наш стек и мы могли их в свой контур интегрировать.
Во-вторых, понимание друг друга — то, что мы говорим на одном языке. Все задачи, связанные с разработкой, сложно формулировать в плане заданий.
Сейчас уже никто не мыслит в концепции водопадного, каскадного планирования. Все работают по аджайлу, который требует постоянной коммуникации, постоянного взаимодействия и для этого нужно понимать друг друга. Если у нас будут проблемы с пониманием и мы будем говорить на разных языках, мы не сработаемся. Это касается не только терминологии, но и культуры.
Наша компания внутри очень бирюзовая. У нас много свободы, гибкости и нет вертикальной структуры, когда приказы спускаются сверху вниз. Нам было бы тяжело взаимодействовать со структурой, непохожей на нашу. Подозреваю, что и наоборот. Для какой-то сложной, формальной структуры наша айтишная, «расхлябанная», бирюзовая компания тоже не зашла бы :).
Когда вы этот эксперимент закончили, оценили и поняли, что стоимость аутсорса выше внутренней разработки — вы это как-то обсудили с партнёрами? Наверняка же была какая-то беседа. Были ли с их стороны какие-то разумные аргументы, которые звучали логично, почему вам всё же не стоит отказываться от аутсорса?
Проект мы доделали до конца, не ушли и не остановили на середине. И потом уже подвели итоги.
У нас с ними было очень хорошее взаимопонимание, и они нам открыто объяснили, из чего складывается цена. Не было такого поведения, типа «Мы хотим на вас нажиться».
Они говорят: «Столько стоит час разработчика, и на эту задачу нужно столько-то часов». И здесь мы понимаем, что час разработчика стоит примерно столько же, как у нас.
Кроме часа разработчика сюда также включены часы менеджмента (на стороне агентства).
С нашей же стороны, когда мы ещё плохо понимали «на старте», чего ждать, то мы думали, что будем формулировать задачи и один раз в неделю смотреть — как идут дела. А по факту, выяснилось, что у нас один человек должен быть включен в этот проект если и не фуллтайм, то как минимум полдня тратить на общение и разные вопросы.
И хорошо, что мы выделили такого человека. Если бы мы этого не сделали, то партнёр принёс бы результат, который пришлось бы переделывать. Это либо увеличило бы цену, либо мы их как-то запинали бы ногами (смеётся) и сказали «Вы же обещали!», и они за свой счёт переделали бы, но остались в минусе.
В общем, общаться нужно — но мы недооценивали объём этого общения и его стоимость.
И мы вместе с подрядчиком поняли, что проблема не в том, что они неправильно цену выставили, или делалась какая-то лишняя работа. А в том, что внешний программист за счёт дополнительной коммуникации обходится дороже.
Эту логику вы рассказываете тем людям, которые к вам стучатся в LinkedIn и пытаются продать аутсорс? Кто-нибудь пытался как-то поработать с вашими возражениями?
Да, рассказываю. И пока не встретил сопротивления. Видимо, тут сложно что-то возразить.
Были люди, с которыми мы общались, и они предлагали: «Давайте сделаем внешнюю разработку с подключением конкретных людей, а если они вам понравятся, то отдадим их вам в штат». Это аутсорс, соединённый с HR.
Это интересное предложение, потому что оно решает часть проблемы. В систему поддержки всё равно надо нанимать разработчиков, но это сложно и дорого — их как-то надо предварительно тестировать.
А здесь получается, что мы их тестируем на наших проектах, потом забираем к себе, и они их поддерживают. Это двойная выгода, которая повышает ценность такого предложения, и единственный способ обойти противоречие.
А в остальных случаях люди очень быстро со мной соглашались. Я им говорил, что если нам нужно будет покупать «время за деньги», то возможно, обратимся к ним. На этом они уходили, чтобы поискать более выгодных клиентов. У них есть рынок компаний, у которых нет своей разработки, и это очень большой рынок, где всё понятно.
Вы сказали, что нанимать разработчиков сложно и дорого. Не пытались хантить людей из агентств?
Нет, в эту сторону не думали. Мне всё ещё кажется, что это скользкая тема, и я морально к ней не готов. Одно дело, когда сам по себе приходит человек и говорит «У вас интересно!», и другое дело — если ставить это как задачу.
Даже если смотреть на это цинично, я не уверен, что это окупится. Лучше уж купить рекрутинговые услуги, чем переплачивать за внешнюю разработку x3, чтобы присмотреться к команде, а потом надеяться, что ты успешно кого-то схантишь у подрядчика.
Раньше мы как раз платили рекрутинговым агентствам за поиск и привлечение разработчиков. Затем создали собственную службу и она стала эффективнее не с точки зрения денег, а с точки зрения результата. Удивительно, но теперь у нас лучше получается самостоятельно нанимать людей, чем делегировать эту функцию.
Почему внутренняя служба работает лучше внешних рекрутёров? Что вы сделали? Мне субъективно кажется, что в процессе можно очень многое пофиксить. Например, многие рекрутёры не отвечают на отклики соискателей.
Я тоже этому поражаюсь. На рынке рекрутинга многие вещи можно сделать лучше, только никто этим не занимается.
Мы сначала боялись идти в эту степь, думали: «Мы же не эксперты. Есть специальные агентства, они собаку съели на подборе». Потом оказалось, что это не очень сложно.
В чём самая большая сложность? Надо сидеть и отсматривать много ресурсов. К нам самим приходит очень мало входящих резюме. Надо искать интересных людей по разным базам, выходить на контакт.
Это холодные продажи, в которых первый этап — механический. Нужно вложить много труда, чтобы найти людей, отфильтровать нужных, каждому написать по несколько раз, и заранее понимать, что половина не ответит.
Дальше начинается этап собеседований. А поскольку разработка — это рынок кандидата, то надо и сформировать у разработчика положительное впечатление о компании, и заодно «просканировать» его, понять, насколько он вписывается.
И главная компетенция айтишных рекрутинговых агентств — это понимание технологий и терминологии. Будет неудобно, если кандидат начнёт о чём-то говорить, а рекрутёр не поймёт, о чём речь. Но если такие навыки прокачать у собственной службы, то дальше у инхаус-рекрутинга возникают сплошные преимущества.
Мы лучше понимаем нашу культуру и лучше можем объяснить кандидату — почему у нас хорошо (тогда как агентство скажет это общими вещами). Мы «бирюзовые», и нам важны не только hard skill кандидатов, но и то, насколько мы попадаем в его общекультурное пространство и ценности. Это очень сложно делегировать внешнему HR.
Возможно, по нашей беседе создаётся впечатление, что мы везде хотим всё делать сами. Но в маркетинге мы вполне пользуемся внешними подрядчиками, и нас это устраивает. Развитие инхауса — это не универсальная позиция про всё, а про те области, которые нам, судя по опыту, удаются лучше.
Давайте представим, что вы всё-таки захотели купить услугу аутсорс-разработки. По какому пути вы будете двигаться, чтобы начать общение?
С одной стороны, мы не хотим себя ограничивать узкими контактами знакомых, потому что можем потерять кого-то ценного. С другой стороны, бросать клич и собрать тысячу откликов, а потом с каждым общаться и пытаться выбрать — слишком большой оверхед для выбора подрядчика.
Как найти компромисс? Не знаю. Должны быть какие-то рейтинги, отзывы, чтобы с их помощью можно было собрать шортлист и дальше общаться.
А инфополе вы как-то мониторите? Например, кейсы на Хабре?
Читаю, но беспорядочно. Что-то в голове откладывается. Когда будет актуально (то, что я увидел в статье или кейсе), то попытаюсь вспомнить источник.
Что в целом думаете про PR-активности агентств? Компании стараются генерировать контент, чтобы привлечь заказчика.
Мне кажется это хорошим способом привлечения.
Контент и для нас (для Кнопки) хорошо работает. Мы делаем много контента, помогающего предпринимателям «просто так». И понимаем, что у людей где-то в голове откладывается впечатление, что это полезно, и в случае чего к авторам можно обратиться. По нашим данным, это работает.
Если бы я выбирал подрядчика, я бы смотрел на рекомендации и опыт тех, кого рекомендуют, даже если у них нет дикого инфошума. С другой стороны, наличие медийного уклона позволит о ком-то узнать, и это кажется важным.
А когда вы читаете кейсы, то на что обращаете внимание? Раз мы беседуем про разработку, могу для аналогии вспомнить разговор про аутстаф с Петровичем — там наш собеседник сказал, что в кейсах ему не нравится «отсутствие жизни»: выкатили сайт, нарисовали дизайн, а что дальше? Оно как-то было жизнеспособно в бизнесе?
Тут понятно, что такое оформление подрядчику подходит. Они работу закончили и пошли следующим кейсом заниматься.
А клиенту интересно, что было дальше. И когда агентство рассказывает только про свою часть, а не про часть клиента, тогда да, получается заход немножко не с той стороны.
Чтобы кейс был для меня интересен, я хочу там прочитать: что было сделано и когда, как оно работало, какие результаты принесло, и что дорабатывали через какое-то время (как правило, всегда нужно что-то дорабатывать).
Сергей, спасибо за беседу. Сформулируйте с вашей стороны финальный месседж агентствам.
Чтобы успешно себя продать нужно:
приходить подготовившись;
иметь публичность, кейсы;
показывать то, что было с разработанным проектом дальше.
Если бы мы хотели кого-то привлечь, то эти вещи были бы для меня важны.
Сергей сказал, что люди, которые приходят к нему в LinkedIn продавать услуги, не находят аргументов на его возражения. Мы подумали, что у кого-то, возможно, всё-таки найдётся конструктивная обратная связь.
Это обычная тема, что сначала, когда клиент заходит, с ним работают по аутсорс-формату, чтобы посмотреть, какой есть объём задач.
Но аутсорс-формат может быть не выгоден клиенту, потому что много времени уделяется на менеджмент. У нас обычно действительно включены какие-то дополнительные косты, менеджерские часы, что-то ещё. И плюс коммерческая ставка для прямых клиентов — если умножить её на 168 часов, то стоимость разработки действительно получается х2, х3, а у кого-то и x4 по сравнению с инхаусом.
Если у клиента много задач, то проще и дешевле брать аутстаф — когда разработчик загружен на фулл-тайм и работает с конкретной командой на конкретном проекте. Но в этом случае кто-то на стороне клиента должен руководить разработчиками.
В формате аутсорса прямые контакты разработчика, как правило, не даются. Всегда есть некая прокладка со стороны агентства, которая фильтрует и формулирует задачи.
А в случае аутстафа разработчик взаимодействует с клиентом напрямую. И если у клиента есть технический специалист (лид), то разница в цене не будет х2-х3.
Мы зачастую практикуем такой гибридный формат — когда у нас есть некая стоимость зарплаты разработчика, и туда мы докручиваем лишь небольшой процент нашей выгоды. Агентство в этом случае зарабатывает не на «аренде» одного разработчика, а на массовой аренде.
Разработчик напрямую работает с клиентом, клиент сам его менеджерит, сам с ним общается. С нас, по сути, только рабочее место (если это не удалёнка), найм адекватных специалистов, отпуск (10% от ФОТ разработчика) и больничные.
Переплата x2-x3 — скорее всего, это сугубо аутсорсная модель. В случае, если клиент берёт разработчика и подписывается под аутстаф (юридически это называется «абонентская модель», когда клиент гарантирует, что они выкупят у нас столько-то часов, а при переработке выкупят больше), то формат аутстафа очень выгоден для всех, кому нужны временные разработчики на проект.
Мы продолжаем серию интервью с ЛПРами компаний разного профиля.
Чтобы не пропустить новые интервью, подпишитесь на телеграм-канал «Рейтинг Рунета» или наш ВК-паблик.
А все интервью с клиентами за 2022 и 2023 годы — с Hoff, МТС, Детским миром, Burger King, Кофеманией, Пятёрочкой, Перекрёстком, Петровичем, Самокатом, СДЭК-ом, ЮMoney, Модульбанком, Дикси, Мегапланом, СберАвто, Simple, Космобьюти, Timepad и другими компаниями мы положили в подборку с удобным рубрикатором.
Ссылка на оригинал.
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.
Директор alto.codes
Причин взять аутсорс у клиента всего несколько:
У компании нет целей технологического лидерства в отрасли, и им невыгодно в таком случае содержать свой штат разработки;
У компании выросли пиковые нагрузки — как правило, формируются проектные инициативы для достижения целей бизнеса — и чтобы их выполнить, нужно временно расширить команду. Привлечение аутсорса на3-12 месяцев решает задачу;
Компания и аутсорс могут и хотят работать как партнеры. Это когда аутсорс перестает говорить «вы написали это в ТЗ, мы сделали и это ваши проблемы», а компания перестает говорить «вы сами должны предусмотреть этот функционал, раз не спросили, делайте за свой счёт»;
Компания ищет редкого специалиста, либо требуется высокая квалификация, либо редкий стэк — например, не так давно была заявка на специалиста по Delphi;
Штатные разработчики устали поддерживать текущий проект за несколько лет и хотят переключиться на новый функционал, а поддержку нужно передать тем, кому проект еще не надоел.