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

На эту тему уже написано множество статей, поэтому далее опишу вкратце.

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

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

Сегодня расскажем, как мы в InstaDev, пошли дальше и не остановились на расчете оверхеда.

Статья будет полезна для руководителей направлений, операционных менеджеров и СЕО продакшенов/агентств.

Первый шаг: расчет рейтов

Начнем с теории: что такое оверхед и как его посчитать.
Считается он по такой формуле: (косвенные расходы + ФОТ непроизводства)/ФОТ производства (не забываем про налоги и страховые взносы, если таковые имеются на конкретного человека). Встречается мнение, что в хорошей ситуации он должен быть в районе 3-4, но на деле обычно ниже (по крайней мере так было в относительно недалеком прошлом).

После расчетов оверхеда обычно переходят к расчетам внутренней ставки исполнителей: (стоимость исполнителя/количество раб. часов)*оверхед.
Количество рабочих часов в месяц стоит брать в районе 150, тогда учитывается отпуск, ну и будем честны: никто не работает по 8 часов в день, поэтому для расчетов можно взять даже 140 часов в месяц.

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

Теперь можно определить для себя ставку внешнюю. Это просто внутренняя ставка, помноженная на дополнительные коэффициенты: целевая рентабельность, дополнительные риски и т.п. В идеальной ситуации при аутстаффинге исполнителя в проекте его ставка должна быть не ниже внешней. Её же мы используем с проджект-менеджерами (далее ПМ) при оценке рентабельности проектов (внутреннюю они не знают). Целевая рентабельность проекта будет достигнута автоматически, опираясь на внешнюю ставку.

Если идти дальше, то может понадобиться чистая ставка исполнителя: (ФОТ+налоги)/кол-во рабочих часов. Это буквально ставка, по которой человека окупает затраты на самого себя.

Зачем нужны три разных ставки? Каждая из них выполняет свою функцию:

• Внешняя. Ориентир для ПМов в проектах, четкий показатель по какой стоимости нужно “продать” исполнителя, чтобы компания была в желаемом плюсе.
• Внутренняя. Для расчетов реальной рентабельности проектов и оценки точки безубыточности, в том числе для оценки ПМов, исполнителей и их эффективности.
• Чистая. Для оценки эффективности исполнителей, по этой ставке они не должны выходить в минус, иначе человек себя даже не окупает.

Посчитали рейты? Супер, теперь есть на что опереться и главное не останавливаться на этом.

Второй шаг: отслеживание загрузки исполнителей

В InstaDev мы используем плагин Tempo для Jira.
Каждый исполнитель у нас заносит потраченное время на задачи, над которыми он работал. Если это какие-то внутренние активности, не связанные с проектами клиентов, то такое время тоже логируется в отдельный внутренний проект.

Например, рабочая неделя человека, который бы сидел и тестировал Tempo, могла бы выглядеть так.

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

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

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

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

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

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

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

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

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

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

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

Третий шаг: планирование ресурсов

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

В том же самом Tempo есть удобный календарь куда ПМы могут вносить планы на конкретных исполнителей, тем самым “бронируя” их и выстраивая прозрачную картинку, кто и чем будет заниматься и, самое главное, сколько.
Выглядит это следующим образом.

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

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

А вот и вывод

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

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

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

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

Источник: VC.ru