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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А вот и вывод

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

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

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

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

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

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

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