Считать деньги в разработке — это не только весело, но и полезно

Привет! Меня зовут Антон Макаров. Я основатель и директор веб-продакшна Creonit. В минувшем 2020-м мы «пережили» самый большой прирост в прибыли за всю историю компании. Он произошел не за счет оголтелых продаж или привлечения крупных клиентов. Напротив — продажи и маркетинг я делегировал, оставил управление проектами, и внедрил управленческий учет.

Управление агентством или digital-продакшном рано или поздно приводит к важной мысли. Вы не артель старателей, не художники-митьки, не община самаритян. Вы работаете не из любви к ремеслу, не за респект от клиента, а ради денег. И даже если не ради них, а ради кайфа от любимого дела, но кайф без денег не бывает. Чем эффективнее бизнес, тем больше сил на кайф. Если у вас есть агентство, но такая мысль еще не посещала, у вас просто не было хорошего кассового разрыва или вы не видели минуса на проектах.

Web- и mobile-продакшны обычно запускаются вовсе не предпринимателями, а разработчиками. Сценарий у коллег похожий на наш: один или двое разработчиков вышли из найма и однажды просто не вошли обратно. Стали брать заказы на фриланс. Заказов стало столько, что даже перестав спать, невозможно сдавать все в срок. Тогда разработчик находит второго такого же бедолагу, потом третьего, и так далее. Однажды ты осознаешь, что все вместе вы вполне себе продакшн, только с «ценой в личку» и «оплатой на карту плиз», поднимаешь задницу, и идешь на поклон в ФНС. А потом выбираешь лучший банк для бизнеса %ref_url%.

Так же — дизайн-студии открывают дизайнеры. А агентства основываются маркетологами, также вышедшими из найма: с агентской или клиентской стороны. По типу мышления и товарно-денежных отношений никто из этих категорий за редким исключением вовсе не предприниматель. Порог входа в digital довольно высок. Так что кейсы, когда между строительством домов, торговлей автозапчастями, грузоперевозками, разливным пивом и диджиталом, предприниматель выбирает последнее — довольно редки.

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

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

Считать деньги в разработке — это не только весело, но и полезно

Шесть лет я эволюционировал до внедрения управленческого учета, то обходя то наступая на грабли. Без нужных инструментов невозможно посчитать стоимость факапа. А теперь есть цифра года: 818 381₽. Рекордный минус по проекту за прошлый год. Можно заверстать по гайдам брендбука и повесить на стену в офисе.

– 818 381₽
Рекордный минус по проекту за прошлый год.

Катализаторами экономический трансформации стали пандемия и несостоявшаяся сделка продажи доли компании.

Жили не тужили

Мы, честного говоря, никогда не были убыточным. Я бы рад рассказать о голодных временах, преодолении, войнам за копейку с конкурентами, употреблении в пищу последних корнеплодов без соли. Но такого не было. Мы не спали на газетах и не варили пельмени в чайнике. Хоть мы из Барнаула, с самого начала мы работали в сегменте сложной дорогостоящей разработки, и у нас всегда были клиенты. С некоторыми мы работаем со дня основания, больше 6 лет.

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

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

Если бы ко мне тогда подошли и сказали, что надо считать затраты на каждый проект и понимать, сколько денег он принес, я бы ответил «Да да, как-нибудь посчитаем. Но пока все ок, в банке X миллионов, этого нам хватит на N месяцев. Что тут считать? Все ок». Я не понимал, что принятие выражения «в этом месяце на зарплату хватает» уже могло считаться тревожным сигналом.

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

Посчитали — офигели

В начале 2020 года как один из способов масштабирования мы всерьез рассматривали вариант продажи доли бизнеса. И вели переговоры с одной очень крупной группой компаний. Прошли первичный пул оценки продуктов. И в качестве доказательства собственной окупаемости должны были принести им яйцо дракона (зачеркнуто) отчетность за последние 3 года: PL, CF и баланс. Также к этому нужны были «подтверждающая управленка в формате проектов и их выручки».

И тут стало понятно, что пришло время становиться предпринимателями. Мы с коллегами сперва приуныли, прикинув, сколько времени у нас займет сборка этого отчета вручную. Сначала пробовали считать показатели вручную. Делать excel-файлы с формулами, Google Sheets и потом даже обновляемый Google Sheets.

Уже на этом этапе стало тревожно. Проекты, удачную сдачу которых мы могли отмечать всей командой, часто были убыточными. Не один, с десяток проектов с минусом по 200, 300, 400, 800 тысяч. Покрытие этих убытков удавалось за счет других проектов, внезапно сверхприбыльных. Было ощущение адреналинового выброса, когда что-то плохое могло произойти, но обошлось.

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

Плюс много переменных составляющих: разные оклады (пока идет проект, оклад может вырасти, и нужен пересчет), разное количество рабочих часов в месяцах, разные затраты, разные уровни сотрудников. Файл нужен на каждый проект отдельный файл, на каждый месяц, на каждую работу для клиента. Кроме того, у нас есть разные типы расчетов с клиентом: где-то фикс, где-то Time & Materials, у клиента может быть и фикс для каких-то кусков работы и Т&М для поддержки.

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

Без особых граблей

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

В голове у меня к тому моменту уже год как существовал примерный прототип этой системы, но волшебным пинком послужила несостоявшаяся due diligence сделка. После нее я собрал MVP, который со временем эволюционировал до рабочей модели.

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

Как собрать магистра хрустальной совы в домашних условиях

1. Трекать время выполнения задач.

Здорово если сотрудник честно фиксирует тайминг сразу после закрытия задачи. Но это идеальная вселенная, в которой Сатурн сближается с Юпитером ровно на 6 минут раз в 400 лет. Поэтому рабочий вариант, когда время по задачам распределено в конце дня. Я давно сделал так, чтобы сотрудники фиксировали рабочие часы: по 8 часов в день 5 дней в неделю на каждую из задач по проекту. Можно вручную, можно таймером, но главное чтобы все рабочее время было зафиксировано. Мы используем Teamwork, но можно использовать любой таск-трекер с которым есть возможность интеграции по API.

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

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

Считать деньги в разработке — это не только весело, но и полезно

3. Считать косвенные затраты

У нас не было привычки считать что-либо, кроме кассы. Не учитывая косвенных затрат на производство, мы могли запросто сделать проект в минус, и не заметить этого.

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

Косвенные расходы на час любого производящего специалиста =

(Аренда и обслуживание офиса + затраты на рекламу + оклады административного персонала + всё что угодно, что не тратим на конкретный проект + неутилизированные часы людей * на оклад каждого) / кол-во часов часов производящего персонала.

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

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

Считать деньги в разработке — это не только весело, но и полезно

4. Считать прямые затраты на производство

Считаем все, что потратили конкретно на этот проект.

ФОТ команды + дополнительные затраты. Это может быть привлечение аутсорс-специалистов, покупка фото, видео, шрифтов.

Считать деньги в разработке — это не только весело, но и полезно
Считать деньги в разработке — это не только весело, но и полезно

5. Формировать нужные отчеты

А теперь самое интересное. То, для чего нужна была простейшая математика 5-го класса — управленческие отчеты.

Отчет о текущей рентабельности каждого этапа/контракта.

Рентабельность на момент закрытия проекта.
Рентабельность на момент закрытия проекта.

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

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

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

То же самое можно смотреть по клиенту: с фильтрацией по датам, менеджерам, типам и условиям работ (ТМ, фикс, дизайн, разработка).

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

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

6. Делать выводы

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

Что сработало в нашем случае?

  1. Мы расстались с несколькими неэффективными сотрудниками и целыми командами. На первый взгляд этот юнит работает не меньше других, может быть хорошим человеком или душой компании, но его проекты все как один (или большинство) показывают рентабельность близкую к нулевой или вовсе отрицательную, причем на уровне катастрофы. Или бывает вроде и проект несложный, и можно, казалось бы, доверить его парочке джунов, но по итогу получаем убыток в несколько сотен тысяч рублей.
  2. Мы в принципе отказались от работы с «вечными джунами» — конкретно в нашей системе (а мы работаем в основном со сложными комплексными проектами) они имеют отрицательную ценность. Но я допускаю, что какие-то продакшны могут бесконечно делить шкуру вечного джуна и строить на этом бизнес-процессы.
  3. Поменяли условия работы с несколькими клиентами: фиксированные оценки за техподдержку заменили на Time & Materials. Стало выгоднее и нам и клиентам.
  4. С несколькими клиентами просто пришлось расстаться, причину мы честно сказали — мы при текущих условиях не зарабатываем. Договориться об иных условиях нам не удалось.
  5. Стали помогать клиентам управлять бюджетом и продуктом при разработке MVP: объясняем, почему задача уже не помещается в текущий бюджет, или наоборот — почему стоит отгружать задачи в рамках текущего бюджета, пожертвовав чем-то менее приоритетным. Или «отсыпать» бонусом фичи, которые могут быть точками роста продукта.

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

В качестве оценки мы взяли основную метрику — показатель рентабельности проектов:

2019

Июль 2019 — 8%

Август 2019 — 9%

Сентябрь 2019 — 23%

2020

Июль 2020 — 37%

Август 2020 — 18%

Сентябрь 2020 — 35%.

0 (Bonus). План-факт: отслеживать поступления, прогнозировать финансовые результаты, видеть возможные разрывы

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

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

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

Считать деньги в разработке — это не только весело, но и полезно

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

Интерфейса примера план-факт отчета с графиком поступлений.
Интерфейса примера план-факт отчета с графиком поступлений.

How it’s made

  1. Мессенджер или система оповещений: Slack, Telegram, Microsoft Teams, dialog, Discord, Rocketchat — что угодно, лишь бы была возможность слать сообщения через API. Можно использовать хоть email, если вам это удобно.
  2. Любой таск-менеджер, который умеет трекинг времени, привязку к задачам, комментарии, статусы, аттачи файлов и обязательно API для получения данных. Мы используем Teamwork.
  3. Код написанный на любом языке программирования: у нас это php и фреймворк Symfony. Мы исторически работаем только на нем, поэтому и софт для управления компанией я писал на Symfony.
Считать деньги в разработке — это не только весело, но и полезно

Почему мы решили написать собственное решение, а не использовать готовое?

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

И второй очень важный момент — автоматизация. Сервисы для предпринимателей могут качественно посчитать cashflow подтягивая банковские выписки. Но для того, чтобы считать рентабельность проектов и людей они должны обрабатывать загружаемые excel-файлы. Эти файлы кто-то должен собрать, проверить и загрузить в систему. Скорее всего сам предприниматель/собственник агентства. А какой смысл во всей оптимизации, если человек с самым дорогим временем в компании должен делать это руками?

И если все же сравнивать со стоимостью подписки на аналогичный софт, и считать его окупаемость, то для нас собственные ресурсы разработки уже окупились за несколько месяцев 2020 года. Мы можем быстро дорабатывать отчеты, запускать новые интеграции. Например, в ближайших планах сделать интеграцию с GanttPRO: в нем мы ведём график производства и они совсем недавно открыли API.

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

Вывод

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

Там, где ты считаешь показатели, есть проблема, и ты можешь ее увидеть. А там, где не считаешь, кроется огромная катастрофа, скрытая фразой «да да, я знаю, но сейчас же все ок?».

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

Если остались вопросы, руду рад ответить в комментариях. Или добавляйтесь в Facebook.

4747
40 комментариев

Почему-то я всегда думал, что примерно так и происходит во всех компаниях которые деньги зарабатывают :)

5
Ответить

Интересно узнать немного больше про сами расчеты.

1. Неутилизированные часы людей считаете при расчете косвенных затрат, из чего они состоят? Иванов из 160 часов в месяц отработал 130, остальные - простаивал? Или поплохело один раз не вышел  на работу, а ещё пару раз отпросился пораньше - и вот уже 15 часов утилизировали. Но ведь это постфактум по итогам месяца известно же..?

2. А что на счёт "эффективных" часов, ведь даже избавившись от джунов нельзя ожидать что 8 из 8 часов человек работает над проектами. Да, есть ресерсч и аналитика и прочее по проекту - они все ушли туда. Но туалеты чаи и просто размышления о вечном глядя в стену - всё равно же съедают время?

2
Ответить

Хорошие вопросы, спасибо)

1. Считаем динамически. Если в месяце прошло N рабочих дней, то каждый производящий сотрудник должен был отгрузить по N*8 часов, а все что меньше — это неутилизированные часы. В конце месяца мы ищем "утечки" часов и точно узнаем сколько сколько у нас неутилизированных часов. И нам это ок, так как KPI менеджеров и выплаты бонусов завязаны на начало месяца.
2. Грубо говоря, походы на перекур и за чаем оплачиваются из бюджета того проекта на котором сейчас работает исполнитель. По-другому никак, людям нужно отрываться от работы, людям нужно в ходить туалет, а некоторым нужно даже покурить.
Дальше меня начинает засасывать в воронку из мыслей про регулярный менеджмент, поддержание дисциплины, найм сотрудников с высоким уровнем ответственности и т.д. и т.п.. Если хотите напишите в личку — пообщаемся на эту тему)

1
Ответить

Спасибо за очень подробную статью.

2
Ответить

Вангую, налетят те, кто «всмысле, это же очевидно, всмысле, только щас?»
но никогда не поздно. а не начавшие и отложившие промолчат)
вам респект

2
Ответить

Я много с кем общаюсь с директоров студий — есть компании старше и больше нашей, которые не считают или считают на очень приблизительно. Многие забивают, потому что в ИТОГО деньги есть, дивиденды есть, кассовых разрывов нет, значит всё ок (нет).

"дада у нас все ок" и "мы приблизительно знаем где у нас минуса"

Ответить

Комментарий недоступен

1
Ответить