Процессы в агентстве разработки: оверхед это только начало
На эту тему уже написано множество статей, поэтому далее опишу вкратце. Оверхед это коэффициент нагрузки на исполнителей в проектах относительно непроизводственного персонала и других затрат агентства. То есть исполнители в проектах должны окупить не только себя лично, но и всю компанию в целом с сопутствующими расходами и даже вывести ее на прибыль.
Те, кто знаком с работой агентств, возможно вспомнят такие слова как оверхед, рейты и будут правы. Некоторые даже про это забывают. Сегодня расскажем, как мы в InstaDev, пошли дальше и не остановились на расчете оверхеда.
Статья будет полезна для руководителей направлений, операционных менеджеров и СЕО продакшенов/агентств.
Первый шаг: расчет рейтов
Начнем с теории: что такое оверхед и как его посчитать.
Считается он по такой формуле: (косвенные расходы + ФОТ непроизводства)/ФОТ производства (не забываем про налоги и страховые взносы, если таковые имеются на конкретного человека). Встречается мнение, что в хорошей ситуации он должен быть в районе 3-4, но на деле обычно ниже (по крайней мере так было в относительно недалеком прошлом).
После расчетов оверхеда обычно переходят к расчетам внутренней ставки исполнителей: (стоимость исполнителя/количество раб. часов)*оверхед.
Количество рабочих часов в месяц стоит брать в районе 150, тогда учитывается отпуск, ну и будем честны: никто не работает по 8 часов в день, поэтому для расчетов можно взять даже 140 часов в месяц.
Внутренняя ставка отражает минимум, по которому должен работать исполнитель, чтобы агентство выходило в ноль. Поэтому правильный расчет безубыточной ставки обязателен и дает понять, какие ставки являются пограничными для продажи исполнителей.
Теперь можно определить для себя ставку внешнюю. Это просто внутренняя ставка, помноженная на дополнительные коэффициенты: целевая рентабельность, дополнительные риски и т.п. В идеальной ситуации при аутстаффинге исполнителя в проекте его ставка должна быть не ниже внешней. Её же мы используем с проджект-менеджерами (далее ПМ) при оценке рентабельности проектов (внутреннюю они не знают). Целевая рентабельность проекта будет достигнута автоматически, опираясь на внешнюю ставку.
Если идти дальше, то может понадобиться чистая ставка исполнителя: (ФОТ+налоги)/кол-во рабочих часов. Это буквально ставка, по которой человека окупает затраты на самого себя.
Зачем нужны три разных ставки? Каждая из них выполняет свою функцию:
- Внешняя. Ориентир для ПМов в проектах, четкий показатель по какой стоимости нужно «продать» исполнителя, чтобы компания была в желаемом плюсе.
- Внутренняя. Для расчетов реальной рентабельности проектов и оценки точки безубыточности, в том числе для оценки ПМов, исполнителей и их эффективности.
- Чистая. Для оценки эффективности исполнителей, по этой ставке они не должны выходить в минус, иначе человек себя даже не окупает.
Посчитали рейты? Супер, теперь есть на что опереться и главное не останавливаться на этом.
Второй шаг: отслеживание загрузки исполнителей
В InstaDev мы используем плагин Tempo для Jira.
Каждый исполнитель у нас заносит потраченное время на задачи, над которыми он работал. Если это какие-то внутренние активности, не связанные с проектами клиентов, то такое время тоже логируется в отдельный внутренний проект.
Например, рабочая неделя человека, который бы сидел и тестировал Tempo, могла бы выглядеть так. Для контроля загрузки исполнителей мы проводим еженедельные встречи с ПМами, где смотрим на загрузку в течение, например, прошлой недели и обсуждаем проблемные места, если кто-то был недозагружен или наоборот перегружен. В этом нам помогают отчеты, которые есть в самом Tempo. Например, у того же человека, который всю неделю тестировал Tempo, отчет был бы немного однообразен, но не составляет труда просмотреть всех исполнителей и понять, кто над какими проектами и задачами работал, и сколько времени на это ушло. А они уж точно занимались интересными задачами. Глобально мы здесь стараемся следить за двумя крайностями загрузки исполнителей: она не должна быть маленькой, но и перегружать человека тоже не нужно. Обе ситуации одинаково плохи на дистанции для компании. Первая ведет к уменьшению прибыли, так как люди простаивают и не приносят пользы на проектах или внутренних задачах компании. Вторая же приведет к выгоранию сотрудника, чего мы тоже не хотим допускать. И за всем этим мы вместе следим на наших встречах. В итоге баланс выстраивается через регулярный мониторинг и выявление проблемных мест, также такие встречи помогают собирать качественный фидбэк по исполнителям от ПМов. После мониторинга загрузки исполнителей у нас есть все данные для расчетов рентабельности проектов. С помощью ставок исполнителей и их фактических часов это совсем нетрудно посчитать. Так можно оценить прошлые проекты, если такие были, и текущие. И для этого необязательно использовать дополнительные сервисы, можно все в полуавтоматическом режиме собрать в google sheets. Если исполнителей несколько на проекте, то можно «разделить» бюджет проекта на исполнителей, также вписывать их часы, а общую рентабельность проекта считать уже через сводную таблицу на другом листе, например. Здесь возникает важный момент по отслеживанию текущей ситуации с проектами. Мы же не хотим, чтобы проекты улетали в минус, а информация об этом всплывала уже после завершения проекта. С помощью такой таблички, где будут отслеживаться часы и рентабельность проектов, контролировать ситуацию становится проще. Тут поможет старая добрая регулярность и чем чаще будет отслеживаться рентабельность проектов, тем более оперативно вы сможете среагировать и помочь ПМам в проектах, если что-то пошло не так. Мы выстроили этот процесс так же на еженедельной основе: встреча с ПМами, где проходимся по статусу проектов и смотрим их текущую рентабельность, обсуждаем кто нам еще не заплатил за выполненные работы и другие подобные вопросы. Основная цель выявить возможные проблемы и помочь друг другу. И третий шаг, который поможет комфортнее себя чувствовать в работе это взгляд в будущее, то есть планирование. В том же самом Tempo есть удобный календарь куда ПМы могут вносить планы на конкретных исполнителей, тем самым «бронируя» их и выстраивая прозрачную картинку, кто и чем будет заниматься и, самое главное, сколько. Выглядит это следующим образом. Для обсуждения планов мы проводим еженедельную встречу в конце рабочей недели и смотрим какая картинка складывается на следующую неделю минимум, в лучшем случае месяц. К сожалению, не во всех проектах удается отодвинуть границу планирования на месяц из-за большой неопределенности, но к этому нужно стремиться. Очень хорошо если у вас будет подобный календарь для планирования ресурсов, как Tempo или другой подобный аналог, куда можно зайти и понять кто и чем будет заниматься, не дергая дополнительно ПМов. И даже если поначалу планы будут не точные, не стоит опускать руки, со временем и вы, и ваши ПМы привыкнут, и все начнет получаться. В итоге мы имеем три базовых шага, которые значительно помогут облегчить работу агентства на первых порах в целом и помочь людям чувствовать себя комфортнее. Все это кажется очевидным на первый взгляд, но иногда именно очевидное ускользает из виду. Такую основу мы, в свое время, выстроили в InstaDev для комфортной работы и надеемся наш подход будет полезен всем начинающим в этой сфере или тем, кто хочет перенастроить операционку. Часто ли вам приходилось перестраивать свои рабочие процессы? На чём особенно спотыкались? Также мы готовим еще одну статью, в которой поговорим про рентабельность проектов подробнее и про построение мотивации для команды. Подписывайтесь на наш блог на VC, чтобы не пропустить. Еще больше полезного по менеджменту и мобильной разработке в нашем ТГ- канале InstaDev mobile или на официальной странице в ВК.
Третий шаг: планирование ресурсов
А вот и вывод
Я как операционный менеджер принимал прямое участие в продвижении этих идей и выстраивании новых процессов в команде. Результат не заставил себя ждать: появилось общее синхронизированное понимание что происходит на проектах, в команде в целом. И ПМы уже ходят довольные, так как им теперь не нужно держать все где-то в голове или бежать спрашивать чем занимается человек на другом проекте. А когда ПМы довольны, то можно и за проекты в какой-то степени быть спокойнее, а значит я вдвойне спокойнее: выстроился порядок, если что вдруг мы всегда можем друг другу помочь и самое главное ребятам стало легче работать.