Процессы в агентстве разработки: оверхед это только начало

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

Процессы в агентстве разработки: оверхед это только начало

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

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

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

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

Начнем с теории: что такое оверхед и как его посчитать.

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

После расчетов оверхеда обычно переходят к расчетам внутренней ставки исполнителей: (стоимость исполнителя/количество раб. часов)*оверхед.

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

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

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

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

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

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

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

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

В InstaDev мы используем плагин Tempo для Jira.

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

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

скрин Tempo
скрин Tempo

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

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

cкрин Tempo
cкрин Tempo

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

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

И за всем этим мы вместе следим на наших встречах.

рабочая встреча ПМов и операционного менеджера
рабочая встреча ПМов и операционного менеджера

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

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

С помощью ставок исполнителей и их фактических часов это совсем нетрудно посчитать.

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

скрин google sheets
скрин google sheets

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

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

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

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

Основная цель выявить возможные проблемы и помочь друг другу.

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

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

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

Выглядит это следующим образом.

cкрин Tempo
cкрин Tempo

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

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

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

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

А вот и вывод

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

  • Правильно просчитать ставки исполнителей. Пригодятся три варианта: внешняя, внутренняя и чистая.

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

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

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

Александр Пивненко, операционный менеджер InstaDev

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

Часто ли вам приходилось перестраивать свои рабочие процессы? На чём особенно спотыкались?

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

Подписывайтесь на наш блог на VC, чтобы не пропустить.

Еще больше полезного по менеджменту и мобильной разработке в нашем ТГ- канале InstaDev mobile или на официальной странице в ВК.

2424
4 комментария

Спасибо, что поделились! А сколько человек производственников в компании?
(интересно с какого количества человек вы начали выстраивать этот процесс)

По статье есть ощущение, что звучит сложновато... Оверхэд, так сказать :)
Но возможно это из-за большого коллектива.

Ещё интересно, как давно вообще появилась позиция операционного менеджера? На каком объёме сотрудников появилась необходимость выстраивания процессов?

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

2
Ответить

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

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

Если у вас большая команда, то скорее всего будут сложности с перестраиванием процессов, но главное не бояться, делать поэтапно и тогда все получится!))

У нас тоже лежит идея накастомить свою систему, но пока что до нее не дошли.

2
Ответить