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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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