Почему ни одна студия не называет точную стоимость разработки приложения?
Потому что это невозможно. По крайней мере на этапе идеи. Но ведь задумывая подобный проект, Заказчик хочет знать, какую сумму он вложит и когда приложение заработает! Ниже мы объясним, из чего складывается стоимость разработки приложения, и кто вовлечен в этот процесс. Обойдемся без спойлеров, расскажем по порядку.
Большинство студий, наша в том числе, используют гибкую систему разработки приложений: вся работа делится на небольшие этапы — спринты, стоимость рассчитывается за каждый этап отдельно после завершения предыдущего. Такой принцип оправдан и привлекателен по трем причинам.
- Простота в расчетах и оценке стоимости разработки. Когда исполнитель называет точную фиксированную стоимость разработки, он закладывает большие риски, и вы платите больше за те же работы и тот же функционал приложения.
- Гибкий процесс разработки. Вы можете вносить идеи на каждом из этапов, эти идеи примут и заложат в смету. Для фиксированной цены — фиксированное ТЗ. В этом случае вам придется дождаться завершения всех основных и прописанных в договоре работ и только после этого исполнители примут дополнительные правки. Естественно, за дополнительную плату.
- Выход за рамки ТЗ. Если исполнитель понимает, что какую-либо функцию можно сделать лучше, у него есть возможность добавить эти работы в смету. Процесс разработки направлен на создание качественного приложения.
Формула стоимости разработки приложения
Итак, как считается стоимость разработки приложения. Исходные данные для расчета во многих студиях совпадают. На цену влияют:
- набор функционала приложения;
- сложность и количество часов разработки;
- количество платформ и устройств.
Но сама формула расчета итоговой стоимости разработки у разных студий и команд могут отличаться.
В IT Brick используем простую для понимания и расчета формулу:
Итоговая стоимость разработки приложения = (Стоимость часа Специалиста 1 х Количество часов работы Специалиста 1) + (Стоимость часа Специалиста 2 х Количество часов работы Специалиста 2) + … + (Стоимость часа Специалиста N х Количество часов работы Специалиста N)
А теперь давайте разберем, как определить, кто из специалистов будет задействован на проекте и сколько стоит час работы.
Процесс разработки и участники
Состав команды и работ зависит от того, какое приложение вы разрабатываете — веб или мобильное. Логика и алгоритм процесса создания совпадают, но при нативной мобильной разработке для каждой платформы — Android и iOS — разрабатывается отдельно свое приложение. Это связано с разными языками программирования и соблюдением гайдлайнов.
Если разработка кроссплатформенная, приложение делается одно, но закладывается время на адаптацию под вторую платформу. Если в приложении нужно синхронизировать данные с сервером, или администрировать его через веб-интерфейс, то понадобится разработка серверной части.
Роль каждого специалиста в процессе разработки приложения (на примере команды IT Brick):
| Специалист | Веб-приложение | Мобильное приложение |
| Аналитик | Продумывает логику и сценарии работы программы, алгоритмы расчетов, разрабатывает архитектуру проекта, выявляет слабые места, пишет техническое задание | |
| Дизайнер | Разрабатывает дизайн и продумывает интерфейс | Дизайн для Android, дизайн для iOS, дополнительно — дизайн серверной части |
| Frontend-разработчик | Переносит нарисованный дизайн в браузер | Эту функцию выполняет основной разработчик. Frontend-ер привлекается только для верстки серверной части |
| Backend-разработчик | Пишет код программы | Разработка для Android, разработка для iOS, дополнительно — разработка серверной части |
| Тестировщик | Проверяет на ошибки и удобство пользования во всех браузерах и устройствах | Тестирует приложение на Android, тестирует приложение на iOS, дополнительно — тестирует серверную часть |
| Менеджер проекта | Координирует работу всех специалистов, общается с заказчиком, следит за сроками и качеством работы |
Сколько стоит специалист
Стоимость часа разработки специалиста зависит от трех факторов:
- города и региона (сейчас уже меньше, но все таки влияет);
- используемых технологий;
- уровня и опыта.
По данным агентства Tagline на 2015 год средняя стоимость рабочего часа российского специалиста, участвующего в разработке была 1 700 руб. — вычисляется из значений зарплат. Для Заказчика цифра выше в 4,2 раза.
Сметная стоимость разработки
Далее готовится смета. При расчете мы оцениваем время работ по каждому специалисту, указываем стоимость часа и по описанной выше формуле рассчитываем итоговую стоимость разработки приложения.
Выглядит просто? Возможно. Но теперь вы видите, что оценка стоимости разработки имеет свои нюансы. И по краткому описанию на этапе идеи оценить ее сложно. Ведь неизвестно, как именно будет реализовываться та или иная функция, а значит и сколько времени команды на это понадобится.
Но можно дать предварительную оценку. Напишите или позвоните нам, чтобы мы посчитали примерные стоимость и сроки разработки. А также сможем дать свои комментарии по задаче и вариантам реализации.
об авторе
Продакшн-директор интерактивного агентства «Космос-Веб». Вывожу продакшн на новый уровень, выжимаю из программистов максимум. За автоматизацию бизнес-процессов. Вдохновляюсь, когда вижу рост показателей. Люблю путешествовать, а другим не даю.
Представим, что ваш IT-продакшн насчитывает 11 человек (арт-директор, два дизайнера, два frontend-специалиста, тимлид, три backend-специалиста, контент-менеджер и QA).
Для оценки возьмём усреднённые данные по рынку, основанные на исследовании стоимости подобных продакшнов в час.
Допустим, вы ежемесячно платите такую зарплату:
Синим шрифтом показана средняя себестоимость работы отдела в час.
1 колонка — отдел/исполнитель.
2 колонка — чистая заработная плата до налогов.
3 колонка — себестоимость часа с учётом налогов, зарплат административного персонала, техники, аренды и прочее.
Разберём эти затраты подробнее в следующей таблице.
Как можно видеть, помимо затрат на производственный штат (660 тыс. рублей) у вас есть затраты в 1,2 млн рублей на аренду, зарплаты администрации, менеджера по продажам, премии, налоги, маркетинг, офис и оборудование. И эти затраты, разумеется, должны обязательно учитываться в себестоимости часа «производственных» сотрудников.
Неочевидный факт
Дневная выработка не может быть восьмичасовой — любой сотрудник тратит время на смежные срочные задачи, доработки, обсуждения. Никогда концентрация сотрудника не может быть равной рабочему времени, поэтому за выработку мы берём шесть часов в день (учёт загруженности производства, больничных, простоев).
Что в итоге
- Ежемесячные расходы — 1,85 млн рублей.
- Себестоимость — от 1 235 до 1 457 (в среднем 1 387) рублей.
Мы высчитали с вами себестоимость часа сотрудника, исходя из восьмичасового рабочего дня и дневной выработки в шесть часов. В среднем она составила 1387 рублей/час. Теперь закладываем маржинальность — к примеру, 37%, — и тогда стоимость часа для клиента составит 1900 рублей.
Вывод: чтобы получать прибыль, вам в месяц нужно закрывать проданных услуг более чем на 1,85 млн рублей — или 1000 клиентских часов.
Клиентские часы — это проданные по сметам часы ваших производителей работ.
Пример: вы продали этап «Дизайн» за 380 тысяч рублей (200 часов) и закрыли его за 200 часов работы дизайнера, арт-директора и проект-менеджера — на этот объем вы получите свою маржинальность 37% (140 тысяч рублей).
О том, как правильно считать рентабельность проектов, затраты на фрилансеров и тестирование, и об иных случаях работы с клиентскими часами я расскажу в следующей части — она будет посвящена «математике проектов».
{«id»:13972,»url»:»/distributions/13972/click?bit=1&hash=d38ecaa80d5012155d940fac389cf161ab0d570a8dfb5b7f089d72b1a23b9af3″,»title»:»u041au0430u043au0430u044f u0431u044bu0432u0430u0435u0442 u0444u0438u043du0430u043du0441u043eu0432u0430u044f u043eu0442u0447u0435u0442u043du043eu0441u0442u044c u0438 u0437u0430u0447u0435u043c u043eu043du0430 u0438u043du0432u0435u0441u0442u043eu0440u0443?»,»buttonText»:»»,»imageUuid»:»»}
Сколько должен стоить ИТ-проект
Мы часто сталкиваемся с вопросом: «Почему так дорого?» Настало время подробно рассказать о том, как рассчитывается стоимость IT-проекта.
Работа компании должна быть рентабельной – окупать все вложенные ресурсы и сохранять перспективы развития. Рентабельность измеряется в процентах и показывает долю прибыли в каждом рубле полученных от проекта средств. Иногда мы ориентируемся на определенный доход, а иногда проект несет в себе имиджевое преимущество. Например, имиджевым для нас было сотрудничество с баскетбольным клубом «Парма».
Разные по масштабу проекты требуют разных расчетов. Один и тот же процент от 100 тысяч и от 10 миллионов имеет разный вес, а труд работающих над проектом людей не может стоить по-разному. У менеджеров на маленькие проекты уходит не меньше, а иногда даже больше времени, чем на крупные. Поэтому во время предварительной оценки мы закладываем больший процент рентабельности в маленькие проекты. Сделки до миллиона рублей должны приносить рентабельность 30% и более. Сделки от миллиона – 20%. Проекты от пяти миллионов рассчитываются индивидуально.
Основные статьи наших затрат:
- зарплаты разработчиков,
- премии менеджеров,
- налоги,
- хостинг, подписки и т. п.
Эти затраты мы учитываем в денежном выражении.
Все остальные издержки (оклады менеджеров и административного персонала с налоговыми отчислениями, аренда и содержание офиса, реклама и маркетинг) мы закладываем в расчеты в виде коэффициента. Его величина оценивается экспертно и зависит от веса проекта в общем портфеле. Вес проекта – это доля всех операционных затрат компании, которая приходится именно на него.
Как происходит оценка проекта?
1. Встречаемся с заказчиком, проводим брифинг. Определяем цели, аудиторию, формат, технические аспекты.
2. Передаем информацию аналитикам. Они предварительно оценивают проект и составляют смету.
3. Проект рассматривает отдел продаж: он выявляет возможные риски, подводные камни, особенности.
4. Смотрим текущую загрузку производства. Сопоставляем ее с дедлайнами реализации проекта. Определяемся, нужны ли дополнительные и внешние ресурсы. Оцениваем технические и менеджментские риски.
5. Оцениваем финансовые риски: готов ли клиент платить аванс или нам необходимо обеспечивать проект своими средствами.
6. Вносим данные в таблицы с формулами.
Разберем один пример наших внутренних расчетов при оценке рентабельности проекта. Смету именно этого проекта вы видели в начале. Это был контракт на разработку мобильного приложения. Предварительная стоимость – 2 401 350 руб.
Считаем стоимость работы каждого специалиста. Для этого умножаем количество рабочих часов на стоимость часа с учетом налогов (см. таблицу ниже). Суммируем полученные результаты. Получаем 992 550 руб.
От предварительной стоимости проекта (2 401 350 руб.) считаем 7% на премии менеджерам и разработчикам. Получаем 168 094,5 руб. Умножаем на налоговый коэффициент, в нашем случае это 1,272. Итог: 213 816 руб.
Не забываем про налоги на доход. В нашем случае они рассчитываются по упрощенной системе налогообложения (УСНО): 6% от стоимости (2 401 350 руб.). Это 144 081 руб..
Для этого проекта необходимо приобретение хостинга и использование аутсорса. На первое необходимо 20 000 руб., на второе – 120 000 руб. В сумме получаем 140 000 руб.
Считаем коэффициент операционных издержек – 20% от стоимости (2 401 350 руб.). Это 480 270 руб.
Складываем все затраты на проект, получаем 1 970 717 руб.
В таком случае прибыль составит 430 633 руб (2 401 350 – 1 970 717). Рентабельность – 18%. Наш норматив для сделок такой категории – 20% Необходимо пересмотреть либо трудоемкость проекта, либо его стоимость.
Если у вас остались вопросы или вы хотите поделиться своим опытом – пишите нам.
Если вы когда-либо занимались разработкой приложений на заказ, то наверняка знакомы с довольно рутинным процессом расчета стоимости и сроков реализации проекта. И ладно бы, если расчет проекта выполнялся лишь единожды, но зачастую потенциальные заказчики не могут уложиться в бюджет, и начинают на ходу менять требования к продукту:
— Это слишком дорого, что если сделаем без функции Х?
— *делаем расчет* Столько.
— Все равно дорого, а сколько будет стоить разработка только под платформу Y?
— *делаем перерасчет* Столько.
— Ух ты, то есть, если мы откажемся от платформы Y, то сможем сделать не только Х, но и Z?
— *очередной перерасчет* Увы, нет.
— Жаль, тогда давайте сделаем без Z, во сколько нам обойдется?
Стандартные пути упрощения расчетов, такие как установка фиксированной стоимости дня работы сотрудника или компании, как правило ведут к потере точности результатов и все равно не избавляют нас от ручных вычислений.
Но, как и любой другой процесс, характеризующийся словами “рутина”, “точность” и “вычисления”, подобные расчеты скорее всего могут быть автоматизированы. Давайте проверим, действительно ли это так.
Процесс расчетов
Прежде всего нам следует определиться с тем, как в общем случае формируются конечные сроки и стоимость проектов.
Шаг 1: Оценка задач
Первое, что необходимо сделать после изучения требований заказчика, это разделить проект на независимые друг от друга функциональные части (задачи). К примеру, если мы выполняем оценку мобильного приложения для стандартного интернет-магазина, то деление может выглядеть примерно следующим образом:
- Каталог товаров
- Корзина и оплата заказов
- Новости магазина
- Контакты
После этого командой разработчиков осуществляется определение временных трудозатрат на реализацию всех перечисленных задач:
| Задача | UI/UX | Back-end | Android | iOS |
|---|---|---|---|---|
| Каталог товаров | 4 дня | 2 дня | 3 дня | 4 дня |
| Корзина и оплата заказов | 3 дня | 5 дней | 4 дня | 5 дней |
| Новости магазина | 2 дня | 2 дня | 1 день | 2 дня |
| Контакты | 1 день | 2 дня | 2 дня | 3 дня |
Шаг 2: Расчет сроков разработки проекта
Как бы ни старалась разработчики, но их оценка сроков крайне редко соответствует действительности. Так что, первым делом, отталкиваясь от сложности проекта и опыта команды, мы определяем страховку: количество дополнительного времени, необходимого для разрешения различных непредвиденных обстоятельств. Обычно страховка выглядит как некоторый множитель (процент), на который увеличивается общий срок разработки.
Далее нам следует определить очередность этапов выполнения работ (workflow). Вне зависимости от используемой методологии (agile или waterfall) нам нужно знать в каком порядке нашей командой выполняются различные виды работ. В рассматриваемом нами примере с мобильным приложением порядок мог бы выглядеть следующим образом:
То есть, сначала независимо друг от друга выполняется разработка бэк-энда и пользовательского интерфейса, и при их завершении начинается параллельное программирование приложения под разные платформы. После того, как все этапы будут завершены, проект будет считается выполненным.
Теперь мы располагаем всей необходимой информацией и можем приступить к расчету сроков:
В случае с Waterfall: суммируем количество времени для каждого вида работ (UI/UX, Back-end, etc.), добавляем к ним страховку, и, учитывая их очередность, находим самую длительную последовательность работ, которая, собственно, и представляет общее количество времени, необходимое для реализации проекта.
В случае с Agile: учитывая очередность работ, мы определяем время на реализацию каждой из задач (каталог товаров, новости, etc.), после чего, путем их суммирования и добавления страховки, получаем конечный срок реализации проекта.
Шаг 3: Расчет стоимости разработки проекта
Следующее, что нам следует получить — это себестоимость проекта, которая обычно формируется из двух типов затрат: общих ежемесячных расходов (аренда офиса, оплата серверов, лицензий на ПО, etc.) и зарплат непосредственных исполнителей проекта. Что касается зарплат менеджмента, то они больше подходят к первой категории, так как являются более “пассивной” статьей расходов, и в некоторых случаях они могут быть опциональными (к примеру, если речь идет о небольшой команде фрилансеров).
“Общие ежемесячные расходы” рассчитываются предельно просто: делим их сумму на среднее количество дней в месяце и умножаем на количество календарных дней, необходимых для реализации проекта.
Расчет расходов на зарплаты исполнителей зависит от используемой методологии разработки:
В случае с Waterfall: для каждого сотрудника делим ежемесячную зарплату на среднее количество рабочих дней в месяце и умножаем результат на количество рабочих дней, необходимых для реализации этапа работ, за который он ответственен; в конце суммируем все выплаты.
В случае с Agile: для каждого сотрудника делим зарплату на среднее количество рабочих дней в месяце и умножаем на количество рабочих дней, необходимых для реализации всего проекта, в конце суммируем результаты.
Теперь, зная себестоимость проекта (выплаты исполнителям + общие расходы), мы можем получить конечную стоимость, добавив к ней ещё пару вещей:
1. Прибыль: здесь все довольно просто, мы либо прибавляем желаемый процент от себестоимости проекта, либо добавляем соответствующий пункт к “общим расходам” (если желаем получать фиксированный ежемесячный доход).
2. Налоги: каждый считает их немного по-своему в связи с разнообразием систем налогообложения
и способов уклонениях от них
. В некоторых случаях можно считать налоги как некоторый усредненный процент от себестоимости проекта с включенной прибылью.
3. Комиссия менеджера по продажам: зависит от ваших условий сотрудничества, если вы выплачиваете процент от сделки, то это процент от суммы себестоимости, прибыли и налогов, и если вы выплачиваете процент от прибыли, то, очевидно, считаете ее как процент от заложенной прибыли, полученной в первом пункте.
Итак, теперь мы располагаем итоговой стоимостью проекта. Но что делать, если клиент, услышав результат, спросит нас: “А что если сделаем без X?”.
Автоматизация вычислений
Можно ли разработать приложение, которое бы производило подобные расчеты автоматически? Ознакомившись с процессом вычислений, теперь мы можем сказать, что да, это возможно, но не без пары нюансов. И первый из них — это расчет налоговой части.
Учет всех возможных вариантов налогообложения при расчетах требует не только значительных трудозатрат на разработку, но и на постоянную поддержку формул в актуальном состоянии. Вариантов решения проблемы здесь несколько: либо жертвуем точностью расчетов и считаем налоги как некоторый процент от стоимости проекта, либо же значительно усложняем систему расчетов, добавляя возможность ее ручной модификации.
Следующий нюанс — это способ безопасного хранения информации о всех расходах, зарплатах и проектах компании. Здесь тоже есть несколько возможных вариантов:
- Храним данные на сторонних серверах приложения (SaaS). Быстро и удобно, но требует доверия к владельцам сервиса.
- Разворачиваем приложение на собственных серверах. Этот вариант требует трудозатрат на настройку и сопровождение приложения, но позволяет самостоятельно контролировать безопасность данных. Дополнительно можно сделать приложение доступными только из собственной инфраструктуры, но это лишает определенных удобств, таких как возможность обратиться к расчетам с личного телефона за пределами офиса.
- Реализация программы для расчетов в виде самостоятельного десктоп-приложения, хранящего все данные в локальном файле. Этот случай не предполагает никакой настройки окружения и позволяет самостоятельно контролировать безопасность данных, жертвуя возможностью предоставления общего доступа к данным.
Тем не менее, несмотря на перечисленные проблемы, автоматизация процесса расчетов все равно возможна, и она несет за собой ряд преимуществ:
— Жизнь сотрудника, занимающимся расчетами, станет немного легче
— Клиенты смогут получать перерасчеты в считанные секунды
— Стоимость разработки станет чуть более справедливой и конкурентной
На сегодняшний день существует очень небольшое количество решений для подобного вида расчетов, и все они имеют достаточно высокий порог вхождения из-за своей монструозности. В связи с этим хотелось бы задать вопрос аудитории Хабра: а каким способом выполняются расчеты в вашей компании?
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Что вы используете для расчетов сроков и стоимости проектов?
30.67%
Ручку, блокнот и калькулятор
23
45.33%
Google Sheets, Microsoft Excel
34
13.33%
Собственное решение
10
10.67%
Специализированное приложение или сервис
8
Проголосовали 75 пользователей.
Воздержались 39 пользователей.
Финансовый учет — актуальная тема для многих растущих софтверных компаний. Особенно если компания занимается заказной разработкой ПО или внедрением ИТ-решений: по мере роста компании число проектов растет, денежные потоки становится сложно контролировать и становится очевидно, что нужен системный подход.
Мы попросили поделиться опытом управления финансами в ИТ-компании финансового директора CodeInside Елену Емелину.
CodeInside — ИТ-разработчик с офисом в Пензе. Компания с 2009 года разрабатывает программное обеспечение для госструктур, коммерческих компаний в России и за рубежом. В 2017 году CodeInside закрепилась и в рейтинге международных IT-разработчиков Top Custom Software Development Companies.
Елена, придя в CodeInside из лизинговой компании, в которой получила хороший опыт организации денежных потоков, полностью выстроила управленческий учет, расширила горизонты планирования бюджетов, создала систему контроля рентабельности проектной деятельности. Елена рассказала для блога Seeneco о том, как организован сейчас учет в их компании, и на какие вещи в управлении финансами нужно обратить внимание ИТ-предпринимателям.
Модели ценообразования в ИТ-проектах
Не секрет, что основной ресурс любой ИТ-компании – это люди. Именно их знания, умения и компетенции, выраженные в услугах для заказчиков, приносят деньги. Но это и основная статья затрат. Поэтому от того, как компания управляет этим ресурсом, и зависит ее денежный поток.
Сначала нужно отметить, что наша компания работает по двум моделям проектного ценообразования – Fixed Price и Time&Materials. Первая модель – это традиционная модель проектной разработки, когда заказчик и менеджер проекта определяют в техзадании весь объем работ, согласовывают фиксированный бюджет и точные сроки реализации проекта. В Fixed Price (или Fixed Fee) клиенты оплачивают конечный результат, а исполнитель – время своих разработчиков. В этом случае, если программисты проведут больше времени за разработкой, а бюджет не изменится, то прибыль компании снижается. Поэтому тут много зависит от умения менеджеров оценить заранее трудозатраты. Хотя риски и форс-мажоры могут возникнуть в любом проекте.
Вторая модель – Time&Materials (T&M) – это оплата заказчиком фактически затраченных ресурсов – времени разработчика. Сейчас такая методика встречается все чаще и чаще, и все больше наших проектов переходит также на эту модель. Конечно, она несет гораздо меньше рисков для нас. Но и для заказчика имеет свои плюсы, когда высока степень неопределенности. Безусловно, что с заказчиком при этом важно определить предел рентабельности, чтобы были определенные рамки конечного бюджета.
Как для проектов с фиксированной ценой, так и проектов Time&Materials важно иметь систему учета, которая показывает, каков общий бюджет, сколько уже сделано, какое количество часов при этом потрачено.
Особенности проектного учета
В нашей компании несколько десятков разработчиков и одновременно несколько разных проектов. Один сотрудник не работает постоянно над одним проектом. Часть рабочего времени он уделяет одному проекту, часть – другому. Может в течение дня выполнять различные задачи для нескольких проектов. Кроме этого, проекты заканчиваются, появляются новые, кто-то из сотрудников уходит в отпуск, кого-то нанимают на работу.
Чтобы во всем этом потоке корректно рассчитать, сколько же конкретный проект стоит для компании, мы настроили выгрузку данных о временных затратах сотрудников на проекты из системы тайм- и таск-менеджера (мы используем сервис Assembla). Далее, на основе этих данных уже в Google-таблицах группируются и анализируются финансовые результаты. Сейчас мы собираем данные по факту, но движемся к тому, чтобы оценивать рентабельность в real-time: сколько сделано, сколько часов потрачено и каков общий бюджет, чтобы мы заранее видели, когда мы приближаемся к тому, что мы «потратили» весь бюджет проекта.
Оценка рентабельности проектов
Четкий учет и распределение времени по проектам дает возможность оценивать рентабельность проекта. Расчет рентабельности мы строим на основе метода начислений – то есть на основе признания доходов и расходов проекта, – независимо от фактического времени поступлений и выплат денежных средств.
Проектный учет методом начисления позволяет разбивать денежные потоки по отдельным задачам. В итоге становится видно, сколько каждый заказчик заплатил и какую долю он нам приносит в общей выручке. Причем важен не сам валовый доход, а чистая прибыль от конкретного проекта. Миллионный бюджет, десятки программистов и множество задач в сухих цифрах могут обернуться мизерной прибылью.
Некоторые проекты у нас показывали низкую рентабельность. Если мы видим, что работать невыгодно – отказываемся от такого проекта, если заказчик не готов повысить стоимость.
Проект может становиться менее рентабельным из-за выполнения гарантийных обязательств. Это может случиться, когда проект уже сдан, но по договору нужно внести корректировки в программу. Такую работу компания оплачивает разработчикам самостоятельно, и заказчик не компенсирует такие затраты. Метод начисления выявляет подобные траты: проект уже закончился, выручка и основная себестоимость по нему начислена, а сотрудники продолжают работать над устранением недоработок. Анализ таких ситуаций позволял нам принимать более взвешенные управленческие решения на будущее.
Точки контроля и финансовые показатели
Раз в месяц мы в Codeinside – руководители, заместители, менеджеры – собираемся и для анализа финансовой ситуации по проектам и в целом по компании. Мы отслеживаем и обсуждаем ряд показателей:
- Себестоимость проектов: как выше уже сказали, мы вычисляем, сколько реально затрат мы понесли на реализацию проекта. При оплате по схеме Fix Price списываем эти траты из прибыли, а при Time&Materials можем переложить на оплату заказчиком.
- Количество продуктивного времени и потерь: финансовая эффективность складываются в нашей сфере из того, как расходуется время наших сотрудников, поэтому мы отслеживаем, как программисты отчитываются в системе учета. К примеру, если на проекты списано не 168 часов, а всего 130, пытаемся вычислить, что происходило в неучтенное время – решение внутренних задач, горящие хвосты, перекуры и кофе-брейки.
- Структура косвенных расходов: определяем, сколько денег потратили на аренду, развитие сотрудников, административный персонал и другие косвенные расходы.
- Чистая прогнозируемая прибыль от предлагаемых проектов: выбираем интересные заказы, обсуждаем бюджет, рассчитываем рентабельность.
- Планируемые расходы и поступления: анализируем прогноз денежного потока, сверяем платежный календарь, намечаем управление свободными средствами.
С такой информацией проще принимать управленческие решения. Это позволяет находить точки роста и повышать эффективность работы.
Планирование финансов
Раньше планирование финансов в нашей компании велось на относительно короткий срок. Сейчас горизонт планирования – 1 год.
Источник информации для планирования – это договора с заказчиками (планируемые доходы и сроки выплат) и информация от менеджеров проектов какие трудозатраты и расходы ожидаются. Постоянные расходы, как правило, нам известны, по предыдущим периодам. Плюс мы закладываем некоторую дельту.
На основе этого строится прогноз движения денежных средств и платежный календарь, который позволяет управлять наличием денежных средств:
- Поступления и расходования разносим на ближайшие месяцы так, чтобы не возникало кассовых разрывов, а временно свободные деньги были размещены на депозите.
- Поскольку мы как ИТ-компания имеем льготы по размерам страховых взносов, при условии, что сумма доходов от профильной деятельности составляет более 90%, – мы следим за структурой доходов внутри квартала.
Управление свободными деньгами
В Codeinside мы стараемся, чтобы деньги всегда работали, а не лежали на расчетном счете без дела. Полученная выручка хранится на депозите и к определенному сроку поступает на счет для оплаты ФОТ (зарплаты, страховые взносы, больничные и отпускные), налогов или аренды. Аванс выплачивается 20-го числа, зарплата – 5-го, затем уплата налогов – таки образом всегда легко просчитать, к какому дню, сколько денег понадобится. Именно к этому сроку деньги переводятся на расчетный счет. При этом там всегда есть небольшой резерв на неотложные нужды. Все остальное на депозите.
Банки предлагают депозиты для юридических лиц, где можно частично снимать средства в любой момент. Нет ничего страшного в том, чтобы полностью отозвать деньги досрочно – потеряны будут только проценты.
Рекомендации для ИТ-компании
Если вы начинающий предприниматель в ИТ-сфере или у вас в штате нет профессионального финансиста, есть ряд важных вещей, сделав которые вам будет проще управлять компанией и контролировать ее финансовое состояние. Вот некоторые из них:
- Введите учет рабочего времени сотрудников: введите дисциплину распределять рабочее время по проектам, задачам. В этом вам могут помочь множество специальных инструментов и сервисов.
- Определите стоимость часа каждого программиста: для ориентира можно взять текущую зарплату сотрудника и данные о заработке аналогичных специалистов по рынку.
- Старайтесь эффективно распределять трудозатраты по проектам: на проект с небольшим бюджетом посадить сотрудника с невысокой стоимостью часа, чтобы заказ не выполнял тот специалист, который обходится работодателю дороже.
- Рассчитывайте себестоимость услуг и полную стоимость разработки: для этого учитывайте все расходы и сопутствующие траты отдельно по каждому проекту.
- Планируйте все денежные потоки и составляйте платежный календарь хотя бы на пару-тройку месяцев, чтобы избежать кассовых разрывов. В любой момент времени нужно понимать, какие суммы будут поступать в ближайшее время по действующим договорам и проектам, а также какие расходы предстоят компании.