В аутсорсинговой разработке есть один парадокс.
Команда может быть полностью укомплектована, проектов много, разработчики постоянно заняты — но прибыль при этом растёт гораздо медленнее, чем ожидается.
Мы столкнулись с этим, когда компания выросла до нескольких десятков сотрудников и десятков параллельных проектов. Снаружи всё выглядело нормально: проекты шли, задачи закрывались, команда работала. Но внутри постепенно становилось заметно, что экономика проектов начинает вести себя непредсказуемо.
Проблема оказалась довольно типичной для компаний, которые занимаются разработкой на заказ. Планирование ресурсов команды, фактические часы и финансы проектов жили в разных местах. Загрузку сотрудников мы планировали в одном инструменте, реальные часы собирались в другом, а экономика проектов считалась в Excel.
Соединить всё это и понять реальную рентабельность IT-проекта было сложно. Внешне проект мог выглядеть успешным, но внутри постепенно уходить в минус из-за переработок или простоев.
Когда команда становится больше пятидесяти человек, такие перекосы начинают сильно влиять на бизнес. Даже небольшая недогрузка специалистов превращается в ощутимые потери, потому что время разработчиков — самый дорогой ресурс компании.
Именно тогда мы решили сделать собственный инструмент для управления загрузкой команды.
Начали с простой диаграммы Ганта
Первая версия системы была максимально простой. По сути, это была визуальная диаграмма Ганта, которая показывала загрузку сотрудников на временной шкале.
Менеджеры получили возможность видеть, кто свободен, кто перегружен и как распределены проекты между специалистами. Это сразу упростило планирование команды разработки и помогло быстрее подключать людей к задачам.
Но довольно быстро стало понятно, что одного планирования недостаточно.
Когда компания растёт, важно понимать не только то, как распределены люди по проектам, но и то, как эта загрузка влияет на деньги. План без факта не даёт полной картины. А план без финансов иногда вообще вводит бизнес в заблуждение.
Когда прототип перестаёт быть прототипом
Первая версия системы была собрана на Firebase. Это позволило быстро проверить идею и начать пользоваться инструментом без сложной инфраструктуры.
Но по мере роста компании ограничения начали становиться заметными. Данных становилось больше, появлялись новые сценарии работы, а финансовая аналитика уже не помещалась в первоначальную архитектуру.
В какой-то момент стало ясно, что система перестала быть просто удобным инструментом планирования. На неё начали опираться управленческие решения. А значит, ей нужна более серьёзная архитектура.
Мы решили не менять интерфейс и не ломать привычный процесс работы команды. Вместо этого перенесли систему на собственный сервер и начали развивать её как полноценную систему управления проектами и ресурсами.
Когда план, факт и деньги оказываются в одной системе
После обновления система стала объединять несколько вещей, которые раньше существовали отдельно. Теперь в одном месте можно увидеть загрузку сотрудников, фактические часы работы и экономику проектов.
Это изменило сам подход к управлению. Мы начали раньше замечать ситуации, когда проект начинает выходить за рамки плановой рентабельности. Простои и перегрузы стали видны почти сразу, а не спустя месяцы.
Постепенно инструмент перестал быть просто системой планирования. Он превратился в часть управления компанией.
Результат
После обновления системы нам удалось увеличить общую рентабельность проектов примерно на 8%.
Мы не увеличивали продажи и не сокращали команду. Изменилось другое — стало намного понятнее, как именно распределение ресурсов влияет на экономику проектов.
Когда управление загрузкой команды, фактические часы и финансы находятся в одной системе, бизнес начинает работать гораздо предсказуемее.
📌 Мы подробно разобрали этот кейс — от Excel-таблиц до полноценной системы управления ресурсами — в отдельном кейсе.
В нем рассказываем, как внутренняя система планирования выросла в платформу управления проектами и почему контроль загрузки сотрудников напрямую влияет на рентабельность разработки.
