Я Антон Калуцкий, руководитель партнерской сети Devcom. Есть один запрос, который мы слышим постоянно: «Нам срочно нужен разработчик 1С». Обычно дальше идет примерно одинаковое объяснение. Задач много, бэклог растет, сроки начинают ехать, свои разработчики загружены. Вроде бы логика очевидная: людей не хватает — надо добавить людей. Но я бы не спешил, потому что довольно часто после получаса разговора выясняется, что еще один разработчик проекту вообще не нужен. Или нужен, но не сейчас.
Например, есть пять разработчиков, которые физически могут делать больше. Только делать им особо нечего: задачи неделями согласовываются с бизнесом. Финансовый директор хочет один процесс, руководитель подразделения — другой, ИТ пытается все это как-то собрать в единое ТЗ. Добавить сюда шестого разработчика можно, вот только очередь задач от этого быстрее двигаться не начнет.
И это, кстати, одна из причин, почему я не очень люблю подбор «по названию вакансии». Когда к нам приходит запрос на двух разработчиков, мы стараемся сначала понять, что происходит на самом проекте. Что за конфигурация, какие доработки, кто ставит задачи, где сейчас самое узкое место. Иногда в итоге действительно нужны два разработчика, а иногда один аналитик.
Людей может не хватать по-разному
На проекте вообще редко бывает проблема типа «не хватает специалистов». Обычно не хватает чего-то конкретного. Бывает, что все нормально организовано: требования есть, архитектура понятна, задачи подготовлены, разработчики просто физически не успевают переварить весь объем. Вот здесь как раз никакой сложной диагностики не нужно. Берем еще одного разработчика, подключаем к команде, увеличиваем производительность. Но если разработчик выходит и начинает ждать задач — мы решали не ту проблему.
То же самое происходит, когда пытаются разработчиками закрыть нехватку технической экспертизы. Например, если система 1С тормозит, обмены периодически падают, каждая новая доработка цепляет три старых. Релиз нельзя выпустить без человека, который единственный знает, как там все на самом деле работает.
Можно добавить еще пару программистов. Скорее всего, они просто быстрее начнут производить новые изменения в системе, в которой и так уже накопились архитектурные проблемы. В такой ситуации я скорее смотрел бы в сторону архитектора, специалиста по производительности, интеграциям, DBA.
С тестировщиками похожая история. Иногда компания говорит, что ей нужны еще разработчики, потому что релизы идут медленно. Начинаем разбираться — разработка уже закончена, а дальше несколько человек вручную неделю проверяют, что ничего не сломалось. Значит, вопрос не в скорости разработки.
Все это звучит довольно очевидно, когда смотришь со стороны. Внутри проекта обычно сложнее. Когда сроки горят, естественное желание — добавить рук туда, где видна самая большая очередь.
Разработчик 1С — слишком широкое определение
Вторая проблема начинается, когда роль определили правильно, но пытаются выбрать человека по резюме. Допустим, нам нужен разработчик 1С с опытом от пяти лет. И что дальше?
Один пять лет проработал с сильно доработанной ERP на производстве. Разбирался с производственным контуром, интеграциями, производительностью, сам обсуждал часть вопросов с аналитиками и бизнесом.
Другой пять лет занимался в основном локальными доработками в бухгалтерских системах и всегда работал по подробному ТЗ. У обоих в резюме будет написано примерно одно и то же: разработчик 1С, пять лет опыта.
Это не значит, что второй хуже. Просто если его посадить туда, где заказчик ожидает, что человек сам придет, посмотрит на непонятный функциональный блок, разберется в чужих доработках и скажет, как лучше решить задачу, скорее всего, начнутся проблемы.
И наоборот. Нет большого смысла брать очень самостоятельного и дорогого специалиста на поток простых доработок, которые уже подробно описаны аналитиками.
Поэтому на собеседовании мне интереснее не количество лет и не список конфигураций. Гораздо полезнее спросить: «Расскажи, что конкретно ты делал на последнем проекте». И потом несколько раз уточнить, например, если участвовал во внедрении ERP, то что именно делал, какой блок, кто принимал решения, с какими проблемами столкнулся. На этом довольно быстро становится понятно, какой реальный опыт стоит за строкой в резюме.
Я вообще не большой сторонник технических интервью, которые превращаются в олимпиаду по знанию редких функций платформы. На работе человек все равно пользуется документацией, ищет информацию, советуется с коллегами. Для меня важнее увидеть, как он думает в ситуации, похожей на реальный проект.
Особенно это заметно с аналитиками и архитекторами. Аналитику можно задать прекрасный вопрос по методологии, и он правильно ответит. А потом поставить его между финансовым директором и руководителем производства, которые хотят от одной системы противоположных вещей, — и вот здесь уже начинается настоящая работа.
С архитектором то же самое. Красивое решение придумать мало. Надо еще понимать, кто потом будет его поддерживать, как оно будет жить с существующими доработками и что произойдет, когда через полгода бизнес принесет новое требование.
Не всегда нужен человек на полный месяц
Есть еще один момент, который мне кажется важным именно в аутстаффинге. Почему-то часто подразумевается, что если мы нашли специалиста, его надо обязательно загрузить на 100%. Но проект так не работает.
Допустим, компании нужен архитектор, потому что периодически возникают решения, которые разработчикам лучше не принимать в одиночку. Зачем в таком случае держать архитектора полный месяц? Он может подключиться в начале, посмотреть текущее состояние системы, договориться с командой о базовых принципах, а дальше участвовать в сложных вопросах несколько часов в неделю или прийти на аудит.
То же самое со специалистом по производительности. Есть проблема — разобрали, нашли узкие места, дали рекомендации, помогли исправить. Дальше он может быть просто не нужен.
Но здесь важно не уйти в другую крайность. Мы встречали ситуации, когда компания берет сильного эксперта буквально на несколько часов в месяц, а по факту разработчики ждут его решения чуть ли не каждый день. Получается странная экономия: на часах эксперта сэкономили, зато вся остальная команда регулярно простаивает.
Поэтому я бы отталкивался не от стандартного формата «человек на месяц», а от того, какая роль нужна проекту и с какой частотой. Где-то это один разработчик на полный день, где-то аналитик плюс разработчик, а где-то нужен архитектор на несколько часов в неделю.
Дальше начинается часть, о которой почему-то забывают
Предположим, нужного человека мы нашли. Резюме понравилось, техническое интервью прошел, дату выхода согласовали. Казалось бы, всё, но на самом деле в этот момент половина успеха еще находится на стороне заказчика.
Человек может быть очень сильным, но если в первый день у него нет доступа, на второй никто не может объяснить, где документация, а на третий выясняется, что задачу ему должны были подготовить, но ответственный ушел в отпуск, никакая экспертиза не поможет.
Особенно мне нравится ситуация: «Ну он же senior, сам разберется». В чем именно? В чужой системе, которую десять лет дорабатывали разные команды? В неописанных обменах? Senior действительно разберется быстрее, но время он на это все равно потратит.
Поэтому перед выходом внешнего специалиста я бы подготовил хотя бы базу: доступы, людей, к которым можно идти с вопросами, несколько первых задач, документацию. И я бы не начинал с самой критичной задачи проекта.
Дайте человеку нормальную рабочую задачу, на которой можно посмотреть, как он разбирается в системе, какие вопросы задает, как работает с кодом, насколько точно оценивает сроки, как реагирует на замечания. За первую неделю это дает больше информации, чем еще три раунда собеседований.
Кто вообще должен управлять внешним специалистом
В аутстаффинге здесь периодически возникает путаница. Заказчик берет специалиста у внешней компании и ожидает, что вместе с человеком кто-то снаружи будет еще ставить ему задачи, определять приоритеты и контролировать проектный результат. Но классический аутстаффинг так не устроен.
Человек подключается в вашу команду. Значит, задачи, приоритеты и приемка остаются внутри вашей команды. Поставщик со своей стороны должен сделать другое: понять, какой специалист нужен, провести отбор, проверить компетенции и доступность, организовать выход, потом не пропасть и регулярно собирать обратную связь.
Если человек явно не подходит — поставщик должен это решать. Если изменились требования — тоже надо обсуждать. Если нужна замена — искать замену. Но решить за заказчика, что сегодня важнее — интеграция или новый отчет для финансового директора, — поставщик не сможет. Иначе это уже не аутстаффинг, а другой формат работы.
Для меня вообще плохой признак, когда после выхода специалиста поставщик появляется только раз в месяц вместе со счетом. Первые недели как раз самые важные. Совпали ожидания или нет? Человек реально получает задачи? Хватает загрузки? Нет ли конфликтов с командой? Нужно ли что-то скорректировать?
Причем обратная связь «нам что-то не нравится» почти бесполезна. Если задача, которую планировали на день, заняла три дня — хорошо, давайте посмотрим почему. Два дня человек разбирался в задаче? Не понял архитектуру? Ждал ответа? Вот это уже можно обсуждать. А когда через два месяца выясняется, что заказчика все два месяца не устраивала скорость работы, исправлять ситуацию намного сложнее.
Самая простая ошибка — выбирать по ставке
Я понимаю, почему так делают, ставка — это понятно. Есть два резюме: один специалист стоит X, другой X минус 20%, второго брать выгоднее. Только вот разработчик с более низкой ставкой может сделать задачу за пять дней, а более дорогой — за два. Еще важнее, что вокруг первого может потребоваться несколько часов архитектора, руководителя и аналитика.
И я сейчас не про то, что надо всегда брать самого дорогого кандидата. Надо смотреть, какой уровень действительно нужен под эту работу.
Если есть хороший техлид, подробные технические задания и нормальный процесс код-ревью, возможно, проекту вообще не нужен дорогой senior. Но если внутренней команде некогда постоянно сопровождать внешнего человека, лучше сразу искать более самостоятельного специалиста.
И еще про знания
Есть сценарий, который я считаю довольно опасным. Компания берет внешнего специалиста под сложный участок. Он работает полгода, прекрасно во всем разбирается, решает задачи, все довольны. А потом проект заканчивается или специалист уходит. И неожиданно выясняется, что про конкретную интеграцию теперь вообще никто ничего не знает. Получается, проблему ресурсной зависимости решили созданием новой ресурсной зависимости. Поэтому я бы заранее думал, что останется внутри команды.
Код-ревью. Нормальные комментарии там, где они нужны. Документация по действительно сложным механизмам. Совместная работа с внутренними сотрудниками. Не надо документировать каждый чих. Но если внешний специалист стал единственным человеком, который знает, как работает критичный кусок системы, — это уже риск.
Что я в итоге считаю хорошим аутстаффингом
Не ситуацию, когда компания запросила трех разработчиков и через две недели получила трех разработчиков. Само по себе это вообще ни о чем не говорит. Хороший результат — когда после подключения внешнего ресурса исчезает проблема, из-за которой за этим ресурсом пришли.
Была очередь готовых задач и не хватало рук — очередь начала сокращаться. Разработчики ждали постановок — появился аналитик, и задачи пошли в работу. Команда боялась трогать архитектурно сложный участок — подключили эксперта, разобрались и дальше работают сами. Релизы постоянно откатывались — выстроили тестирование или процесс поставки. Вот это результат.
А то, сколько фамилий после этого добавилось в Telegram или корпоративный мессенджер, мне не очень интересно. В этом для меня и есть главное преимущество аутстаффинга: команда не обязана быть раз и навсегда собрана в одном составе.
На одном этапе проекта тебе нужен аналитик. Потом аналитик уже справляется, зато не хватает разработчиков. Перед запуском растет нагрузка на тестирование. Архитектор может вообще подключаться только периодически. Можно менять этот состав вместе с проектом.
Но для этого надо сначала честно ответить себе на вопрос: а что именно сейчас мешает проекту двигаться? Мы в Devcom именно с этого и стараемся начинать разговор: что происходит у клиента, что за система, какой состав команды, где сейчас проблема. Иногда после этого мы все равно идем искать двух разработчиков. А иногда говорим: «Смотрите, мне кажется, вам сейчас разработчик вообще не поможет». И вот второй разговор, на мой взгляд, намного ценнее.