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

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

 

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

 

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

 

Разработчик в этом фильме — главный герой


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

 

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

 

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

 

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

 

Что делать?


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

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

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

 

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

 

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

 

«Нужно научиться компенсировать отсутствие визуального контакта через альтернативные источники коммуникации».

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

 

Дискриминация


 

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

 

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

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

 

Что делать?


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

 

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

 

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

 

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

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

Биполярное расстройство на проекте


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


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

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

 

Что делать?


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

 

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

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

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

 

Свой среди чужих, чужой среди своих


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

 

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

 

Что делать?


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

 

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

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

 

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

 

О дивный новый проект!


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

 

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

 

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

 

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

 

Что делать?


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

 

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

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

 

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

 

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

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

 

Поздравляем! У вас MATCH!


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

 

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

 

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

 

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

 

Что делать?


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

 

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

 

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

 

Мне все наскучило, я в гараж!


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

 

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

 

Что делать?


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

 

Ответственность нельзя выдать, ее можно только взять. Этот важный настрой и понимание со временем передается всем разработчикам в команде.

Что в итоге:


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

 

Какой смысл быть гениальным, но невостребованным специалистом?

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

 

  • Развивайте софт скиллы разработчика, объясняйте, почему и для чего они нужны, рассказывайте, что делать, чтобы стать успешным коммуникатором.
  • Формируйте у разработчиков привычку сортировать обращения.
  • Тратьте время и силы на создание внутренних коммуникаций в компании.
  • Проявляйте заботу и внимание, теперь они имеют еще бОльшую значимость и роль для предоставления качественных услуг.
  • Работайте с ожиданиями и фрустрациями своих специалистов.
  • Давайте специалистам более широкое видение проектов.
  • Корректируйте и формируйте корректные ожидания.
  • Соблюдайте профессиональную этику и мотивируйте к этому своих сотрудников.

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