IT-аутстаффинг со звездочкой: задачки менеджмента для продвинутых

Фаундер агентства Staff-Hub, Андрей Лядков, рассказывает, как позаботиться о моральном здоровье разработчиков и настроить систему взаимоотношений с клиентом.

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

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

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

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

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

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

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

Чтобы снижать тревожность команды и тимлидов заказчика, нужно учить разработчиков всегда фиксировать задачи на день, своевременно озвучивать важные моменты, которые могут сместить срок работы или повлиять на ее результат. Где-то даже уметь управлять ожиданиями тимлида, чувствовать момент, когда надо напомнить о себе и прогрессе выполнения вверенной задачи.

Важно доносить до сотрудников главную мысль — не только хард-скиллы определяют уровень специалиста.

Всегда есть трудность обучения софт-скиллам. Мы со своей стороны рекомендуем разъяснять разработчикам причины и суть:

IT-специалист растет в цене, если обладает опытом. Речь не только о качестве его кода, но и о достаточном количестве трудных ситуаций, в которые он попадал и знает, как их избежать и как себя в них вести. Это просто еще одна сторона профессионализма.

Несмотря на то, что любой тимлид скажет вам, что к аутстафферам и внутренней команде он относится совершенно одинаково, к внешним специалистам у него, скорее всего, будет более предвзятое отношение. С чем это связано?

Если у самого тимлида софт-скиллы на хорошем уровне, то эту разницу он постарается не демонстрировать.

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

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

«У меня нет времени так нянчится с каждым разработчиком», — заявил как-то один из тимлидов рабочей группы заказчика, к которой мы подключили уже порядка 20 специалистов на разные отделы. Мало того, что это было необоснованно, так еще грубо и непрофессионально. Подобная токсичность сведет на нет мотивацию не только аутстафф-специалиста, а вообще любого.

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

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

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

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

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

Внутри аутстафф-компании нужен человек, про которого специалист знает, что с ним он может и должен решать любой организационный вопрос: он устал, на проекте проблема, не может найти общий язык с кем-то, задумался об отпуске. Тот, кому можно сказать все, не боясь быть неправильно понятым.

Доверенным лицом может быть ресурс-тимлид или эйчар. Они помогают с онбордингом, иногда подключаются в коммуникации и чаты, присматривают и подстраховывают. Они не ведут проект, но помогают специалистам, поддерживают, а порой и консультируют их.

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

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

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

Его коллеги закончили проект, вся команда радуется: «Ура! Мы успели до всех дедлайнов!» — парень сидит в уголочке и пилит свой проект. Команда получила новый проект: «Ура! Мы попробуем новые технологии, которые давно хотели использовать!», а парень по-прежнему сидит в уголочке и пилит другой проект.

Если не уделять этому внимания, это приведет к выгоранию сотрудников и расколу в коллективе.

Аутстафф-проекты меняются чаще обычных, в среднем раз в 3-6 месяцев. Для разработчиков каждый раз это возможность попробовать что-то новое, испытать себя в крутых проектах. Почти у всех разработчиков на определенном уровне развития возникает желание делиться своим опытом и учить других, поэтому важно, чтобы в компании была возможность эту потребность реализовать: внутренние обучалки и митинги, оффлайн и онлайн мероприятия.

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

Такое перекрестное взаимодействие подкрепляет связи внутри коллектива. Разработчики чувствуют себя частью одной команды, несмотря на то, что у них разные проекты.

Все разработчики любят начинать проект с нуля. Для них это возможность реализовать себя, заложить идею, создать собственную логику работы. Все они уверены, что сделают систему без ошибок, а работая с чужим кодом, ворчат и занудничают: «Ой, банковский проект — это 10 лет легаси-кода разбирать».

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

Еще одна причина — никто не любит переделывать работу несколько раз под разные бизнес-требования, из-за того, что кто-то не продумал все заранее. Тратить время на то, что потом не пригодится, любому человеку неприятно.

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

У нас большой опыт работы с крупными проектами, и каждый раз при подключении на новый проект жалобы на легаси поступают в полном объеме.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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