Аутстафф вредных советов. Как (не) работать в IT с субподрядчиками, разработчиками и клиентами

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

Меня зовут Глеб Корсунов, я CBDO Holyweb. Мы аутстаффим в стеке JavaScript (от React до Node), PHP, Golang, Python, предлагаем услуги аналитиков и тестировщиков. На недавно прошедшем РИФ Воронеж я рассказал, какие ошибки чаще всего делают вендоры и клиенты, когда имеют дело с аутстаффом. Отборные вредные советы — в материале ниже.

Аутстафф вредных советов. Как (не) работать в IT с субподрядчиками, разработчиками и клиентами

Генеральный подрядчик — субподрядчик

Чем загружен разработчик

Вам не нужно узнавать,

Если вы на субподряде —

Это сделают за вас!

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

Что делать?

Главное, о чем важно помнить: даже если вы будете «пинать» менеджеров партнера, то собирать данные о ситуации на проекте, загрузке разработчиков, удовлетворенности работой вы будете очень долго и они будут не слишком информативны. Решение очень простое — постоянно мониторить ситуацию через разработчиков, которые организуют звонки с лидами/РП проекта и спрашивают то, что вы хотите выяснить. Беседы порой получаются очень интересными, кроме того — это продлевает вашу жизнь на проекте. Сами отследили и обнаружили проблему — сами решили ее.

Аутстафф вредных советов. Как (не) работать в IT с субподрядчиками, разработчиками и клиентами

Есть запрос на субподряд?

Делай как в последний раз!

Пусть не сходятся бюджеты,

Главное — энтузиазм!

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

Что делать?

Озвучить на старте свое отношение к двойным перепродажам. Мы считаем, что посредник может быть максимум один, в противном случае нет смысла заключать контракт. Хотя надо признать, что бывают исключения, когда федеральный интегратор, выигравший тендер на миллиарды, скупает весь рынок — тут могут быть и двойные цепочки. Если вы очень маленькие, то крупному бизнесу некогда подписываться с вами из-за 1-2 разработчиков, и лучше все агрегировать в одном окне. Но такие случаи надо рассматривать индивидуально.

Аутстафф вредных советов. Как (не) работать в IT с субподрядчиками, разработчиками и клиентами

Разработайте для запросов на субподряд скоринг-лист и начинайте общение с заказчиком с него. Важные моменты:

  • Что за компания, как оцениваем потенциал для сотрудничества?
  • На какой срок можем рассчитывать?
  • Есть запрос на команду специалистов или на 1-2?
  • Закрываете ли вы потребности по техническому стеку (или нужно будет привлекать субподрядчиков)?
  • С какими заказчиками работать не хотите. Стоит сразу потенциальному партнеру озвучить свой стоп-лист. Так как конечный заказчик вам известен не сразу, лучше сразу написать куда не пойдете: указать или конкретные организации, или целую отрасль, например, «банки/финтех».

Если шанс есть от партнера

Разработчика продать,

Ни за что не начинайте

Вы детали обсуждать!

Партнер прислал хорошее CV? Не спешите передавать его клиенту и получать апрув! Потому что так вы поставите телегу впереди лошади и окажетесь заложником ситуации, когда клиент уже рассчитывает на разработчика, а вы не можете его предоставить.

Дьявол, как всегда, кроется в деталях: партнер может сказать, что сотрудник через неделю уходит в плановый отпуск, а клиент запросит рабочее время с 02:00 до 10:00 по локальному времени специалиста или откажется работать с партнером из России.

Что делать?

Ответ очевиден — сначала выяснить все нюансы и ограничения, а уже после этого предлагать специалиста. Мы используем скоринг-лист, где учитываем ключевые факторы:

  • Какова конкуренция за кандидата, не рассматривается ли он еще на несколько проектов параллельно.
  • Удобный график прохождения интервью.
  • Если субподрядчик из другой страны, нет ли ограничений на работу с вашей.
  • Как давно кандидат работает в компании (и устроен ли он в ней вообще).
  • Не планируется ли в ближайшие 3 месяца отпуск?
  • В каком часовом поясе он находится?

Подрядчик/Клиент — разработчик

Настоящий разработчик

Сам поймет, кого спросить!

Позабудьте про онбординг —

Адаптируется сам!

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

Что делать?

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

  • Доступы.
  • Описание структуры команды. По каким вопросам к кому стоит обращаться?
  • Инструкция по настройке dev окружения.
  • Бэклог задач + приоритеты.
  • ТЗ на разработку, документация.
  • Правила коммуникации.
  • Дедлайн и этапы проекта.

Оптом можно взять сосиски!

Нам же это ни к чему —

Нанимать специалистов

Нужно лишь по одному!

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

Что делать?

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

Концентрацию на коде

Слишком просто потерять!

Отпуск вреден для разрабов,

Не давайте отдыхать!

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

Аутстафф вредных советов. Как (не) работать в IT с субподрядчиками, разработчиками и клиентами

Что делать?

  • Четко следить за графиком труда и отдыха. Не поощрять замену отпуска на денежную компенсацию.
  • Мотивировать на насыщенный и разнообразный досуг. У нас это программа HolyRelax — принудительная релаксация с денежной компенсацией внерабочих активностей.
  • Иметь в штате HR-менеджера (не рекрутера), в обязанности которого входит отслеживать атмосферу в коллективе и заботиться о душевном комфорте разработчиков.

Генеральный подрядчик — клиент

Обещайте, не ленитесь

Сделать все и всем подряд!

Чем вы больше суетитесь,

Тем стабильней результат!

Один из самых простых способов получить поток обращений — делать вид, что вы больше, чем есть на самом деле. Если у вас есть 20 специалистов в определенном стеке — пишите, что в наличии 100+ и стек не имеет значения. Получив запрос — обещайте все сделать и на ходу пытайтесь собрать разработчиков от партнеров, чтобы закрыть вопрос.

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

Что делать?

Четко определитесь со стеком, опишите его в презентациях и на своем сайте. Никогда не пытайтесь лихорадочно собрать команду субподрядчиков только чтобы удовлетворить запрос клиента любой ценой.

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

Деньги клиента

Не нужно считать!

Ваша задача —

Разработчика сдать!

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

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

Увы, таких клиентов, широко известных и крупных в том числе, немало. И перед вами стоит простой вопрос: нужно ли считать деньги клиента, ведь это не ваш бизнес и не ваше дело?

Что делать?

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

  • Позволит ли состав команды клиента решить поставленные задачи?
  • Насколько адекватны и достижимы цели?
  • Как выстроены текущие процессы?

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

Инхаус-команда —

Вселенское зло!

Нет ее у клиента?

Значит, вам повезло!

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

Может показаться, что такая ситуация идеальна для внешнего поставщика, потому что он фактически замыкает на себя весь проект и «привязывает» к себе клиента, но это не так. Если от клиента не исходят четкие цели и он не управляет ситуацией, рано или поздно (скорее рано) начинается самодеятельность, конфликты и споры о том, куда и как двигаться дальше. Как следствие — срыв сроков, потеря денег, выгорание и снижение вовлеченности внешних специалистов.

Что делать?

Для себя мы установили правило: отказываемся от сотрудничества, если у клиента нет внутренней команды с соответствующими компетенциями. А клиентам хочется пожелать: «Берегите свой инхаус, аутстафф хорош в меру!»

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

Думайте сами, слушайте чужие советы. Но не забывайте, что они могут быть вредными ;) Остались вопросы или возникло желание попробовать себя в аутстаффе? Пишите в комментарии или мне в Телеграм, буду рад пообщаться.

2424
4 комментария

Интересная и познавательная статья. Спасибо за советы.

Ответить

Статья правда крутая , хороший полезный совет

Ответить

Интересная статья. Чувствуется, что все это взято из жизни и выстрадано работой.

Ответить

Спасибо!

Ответить