Главная особенность заказной разработки – это сложный стаффинг, распределение людей по проектам. Людей много, они разные. Проектов много, они тоже все разные. Получается многомерный пазл, который не всегда складывается идеально.
И вот если не сложилось? Что тогда?
Расскажу свою историю, как мы справлялись с этой проблемой и какие инструменты нам помогали.
Приглашаю почитать!
Привет! Меня зовут Илья Прахт, я опытный менеджер в 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