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

И вот если не сложилось? Что тогда?

Расскажу свою историю, как мы справлялись с этой проблемой и какие инструменты нам помогали.

Приглашаю почитать!

Привет! Меня зовут Илья Прахт, я опытный менеджер в IT, тренер и консультант. До недавнего времени я руководил продакшном аутсорсинговой IT компании (все разработчики, тестировщики, ПМы, 150+ человек нас было). И о проблемах стаффинга знаю не понаслышке. Мы с командой делали многое в этом направлении.

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

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

Данная статья – текстовая версия моего доклада на SaintTeamLeadConf2022.

Наша история

События, о которых пойдет повествование, происходили в незапамятном 2021 году, когда мир отошел от пандемии и отрасль переживала очень бурное развитие. Были мы в ту пору международной аутсорсинговой компанией, с офисами разработки в РФ и головным офисом в Нью‑Йорке. Работали на американском рынке. В среднем, одновременно у нас шло порядка 30–35 проектов, на которых трудились суммарно 150+ человек.

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

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

В компании были очень счастливые сотрудники. Уровень тимморали был 5+ из 6, ротации запрашивали редко, 1–2 в месяц, а текучка не доходила и до 10%. Очень крутые показатели для отрасли.

Кстати, о том как мы меряли тиммораль я уже писал в этой статье и вот в этой статье. Можно там подробнее почитать.

Естественно, счастливых сотрудников мы получали не бесплатно. У нас была развесистая структура кураторов и линейных менеджеров, огромное количество внепроектных активностей, которые были полезны, но далеко не необходимы. Как итог, компания была неэффективна. Утилизация еле-еле дотягивала до 70%, а стоимость менеджмента доходила до 30%! Т е на каждый рубль ЗП инженера мы платили 30 копеек менеджерам. Многовато, согласитесь?

И все было бы ничего, если бы не пандемия. Мы испытывали сложности с проектами, с новыми продажами, и компании пришлось начать считать деньги. Быстрым решением стало сократить менеджмент и сделать реорганизацию.

После реорганизации ситуация выправилась. Мы, действительно, убрали много активностей и уменьшили количество управленцев. В итоге утилизация достигла рекордных 90+%, а стоимость менеджмента упала до 5-10%. Нормально для отрасли.

Но наш энтузиазм разделяли не все. Мы убрали очень много того, что давало большой тимбилдинговый эффект и удерживало лояльность сотрудников на высоком уровне. Ну и как итог – тиммораль упала. Это было уже 4 из 6 по компании, 5-6 запросов ротаций в месяц, текучка 30+%.

А это был 2021 год, год великого “броуновского движения” ны кадровом рынке. Мы не выделялись принципиально на фоне других компаний и найм шел сложно. Поэтому ситуация приближалась для нас к новой катастрофе.

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

Улучшение пипл-менеджмента

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

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

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

Мы вернули некоторые внепроектные активности, которые стоили недорого, но давали большую пользу компании: воркгруппы, внутренние митапы и т п.

И еще хорошенько поработали над нашим процессом ИПР. Это был ключевой для нас процесс, вся корпоративная культура держалась на развитии сотрудников. Мы изменили периодичность встреч, сделали аттестации 2 раза в год, а также разделили ветки развития на техническую и тимлидскую. Раньше они были вместе и был бардак и субъективность менеджеров. Теперь получилось все систематизировать.

Улучшение стаффинга

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

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

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

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

Наш процесс прозрачных ротаций включал всего 4 основных пункта:

• Сотрудник может инициировать ротацию

• Четкий SLA

• Четкие критерии, когда можно, когда нельзя

• Постоянные апдейты по статусу

Улучшение интересности проектов

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

Мы расширили круг вопросов в тимморали про проект. Стали оцифровывать информацию и пристально за ней следить. Это давало нам понимание, в правильном направлении мы идем или нет.

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

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

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

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

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

Результаты

Примерно за полгода интенсивной работы нам удалось выправить ситуацию. Мы пришли к некоторому состоянию баланса, в котором существовали и дальше. Тиммораль не падала ниже 5 из 6. Интересность проектов (которую мы стали измерять) также держалась на уровне 5 из 6. Запросов на ротацию редко было больше 2-3 за месяц. А текучка выровнялась со средним значением по отрасли 10-15%. При этом мы смогли сохранить утилизацию на уровне 90%, и стомость менеджмента в пределах 5-10%.

Дальше год с номером 2021 завершился и наступил новый год с номером 2022. И это было новое испытание для нас, но совсем другого характера. И я могу сказать, что все то, что мы смогли проделать в 21 году, очень помогло нам выдержать и пройти все челленджи 22 года.

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

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

P.S.

Присоединяйтесь к моему телеграм-каналу Седой директор. Пишу там про управление людьми, про менеджмент в IT. Отвечаю на ваши вопросы и разбираю ваши кейсы.

Подписывайтесь https://t.me/sedoydirector