Что делать, чтобы справиться с «текучкой» в компании

О неочевидных путях борьбы с быстрой сменой кадров в компании

Речь пойдет о фирме, которая занимается заказной разработкой программ, но подход можно применить и в других сферах. Проблемы с быстрой сменой кадров начались после бурного роста компании. HR-отдел в лице одного человека просто не успевал заниматься чем-то еще, кроме поиска новых сотрудников. Возможно, кто-то задастся вопросом: «А разве он должен заниматься чем-то еще?» Должен.

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

— Разработчики постоянно сменяются новыми людьми.
— И что?
— Им приходится давать много дополнительного времени, чтобы разобраться в проекте.
— И что?
— Срываются сроки, оплачивается время, в которое сотрудник по сути не работал.


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

1. Чтобы не срывались сроки, было рассчитано время для данного риска, исходя из текущего процента увольнений и средней скорости входа в проект. Теперь это время добавляется в изначальный расчет диаграммы Ганта.

Объясню на примере. В компании 100 разработчиков, за год увольняется 50. За это же время компания выполнила 1000 задач по разработке. Получается, что вероятность увольнения на каждую задачу 50/100/1000= 0.0005. Чтобы новый сотрудник вошел в курс дела, требуется 20 дней. Умножаем на полученную вероятность: 20*0.0005=0.01 дней — таков временной риск увольнения разработчика на каждую задачу.

К оценке нового проекта, продукт которого содержит 100 задач по разработке, мы теперь прибавляем 0.01*100=1 день.

У вас может возникнуть вопрос: «Как же один дополнительный день поможет, если разработчик уйдет во время проекта, а новому придется включаться 20 дней?» Дело в том, что это именно задержка с учетом вероятности риска. В списке есть и другие риски (задержится подрядчик, команда, бухгалтерия и т.д.), они все складываются, и получается, например, 30 дней возможной задержки. Если уволится разработчик и на 10 дней задержится подрядчик, то другие ситуации с учетом вероятности не произойдут. Аналогичным образом мы рассчитываем риски по бюджету и объему работ.

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

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

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

— Что вам нравилось?
— Что не нравилось?
— Что нравится на новом месте?

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

• Интересны новые технологии, но негде их применять;
• Нет перспективы карьерного роста;
• Твоя разработка будет «выброшена».

Ввели следующие решения:
1 Перешли на более современный стэк (инструменты) и разрешили практиковать самые последние технологии (хоть в большинстве случаев они не обоснованы).
2 Добавили уровни специалистов и с каждым сотрудником составлялся план, отслеживался прогресс для перехода на следующий уровень.
3 Усилили продуктовый менеджмент, чтобы наши разработки были полезны людям, а не только для отчета начальству (заказчиков убедить в этом оказалось несложно).

В конце хотелось бы добавить четыре важных уточнения:

• Прежде чем вносить изменения, нужно измерить и выразить в одной цифре текущую ситуацию, чтобы было с чем сравнивать.
• Чтобы измерить нужны данные. Проще всего получать их при работе в автоматизированной системе. В зависимости от вашего бизнеса, это может быть: call-tracking, CRM, ERP, task-tracking.
• Чтобы понять, какую систему выбрать, нужно хорошо знать процессы в вашей компании и разбираться в способах оптимизации. Если вы чего-то из этого не знаете, можно провести интервью с сотрудниками или специалистами.
• Не ставьте одновременно два эксперимента, которые влияют на одни и те же показатели. Так вы не узнаете, что именно повлияло и насколько.

Денис Силантьев

Возврат к списку