От Эксель до собственной системы: история АЙТИФОКС Гант — как мы убрали простои и привязали деньги к загрузке

Главное о кейсе

Это история о том, как мы для самих себя построили систему управления проектами, финансами и людьми — от ненавистного Эксель до собственного продукта.

Компания АЙТИФОКС — ИТ-аутсорсер. Мы ведём десятки проектов параллельно, в штате 60+ сотрудников. До определённого момента мы, как и многие, управлялись Эксель и Гугл-таблицами. Планировали загрузку, следили за сроками, считали финансы — всё в таблицах.

Но в какой-то момент Эксель перестал тянуть. Ошибки из-за человеческого фактора, отсутствие данных в реальном времени, невозможность заглянуть на месяцы вперёд. А главное — полная слепота в деньгах: план работ, реальные часы сотрудников и финансы жили в трёх разных мирах. Внешне проект мог выглядеть успешным, а по факту съедать маржу.

Готовые системы на рынке не подходили — либо слишком сложные (настройка на годы), либо слишком простые (не дают нужной аналитики). Тогда мы решили: сделаем свой инструмент. Для себя. А потом покажем другим.

Так родился АЙТИФОКС Гант — сначала как внутренний прототип для планирования загрузки, а затем как полноценная система управления ресурсами и финансами.

Ключевые результаты:
- простои команды снизились на 5% через месяц после первой версии;
- время на еженедельное планирование упало с 4 часов до 1 часа;
- после второй версии общая рентабельность выросла на 8%;
- исчезла главная иллюзия бизнеса — «проект идёт, значит всё хорошо».

Главная ценность для бизнеса:
Система убила разрыв между планом, фактом и деньгами. Пока они живут отдельно — вы не видите, где проект теряет прибыль.

Как проект изменил жизнь пользователей

Под пользователями здесь — менеджеры проектов и руководство АЙТИФОКС.

До системы — хаос в таблицах.
Каждую неделю менеджер тратил полдня на ручное планирование в Эксель. Данные жили своей жизнью: кто-то мог случайно затереть чужую строку, а кто-то посмотреть не туда. Заглянуть на месяц вперёд было нельзя — только гадать. Финансы были в отдельной таблице у бухгалтера, и никто не мог быстро ответить на вопрос: «А этот проект вообще прибыльный?»

Первая версия — прозрачность загрузки.
Гант 1.0 — это единая доска, где видно всех сотрудников и их занятость на недели вперёд. Загрузка показывается цветом: зелёный — норма, красный — перегруз, серый или жёлтый — есть свободные часы. У каждого указана специализация, а менеджер может отфильтровать только свои проекты. Планирование устроено через ленту Ганта: менеджер перетаскивает задачи, назначает сроки и сотрудников, а система сама проверяет, не возникнет ли перегруза. В итоге вместо 4 часов в неделю на планирование уходит всего 1 час. А простои команды упали на 5% уже в первый месяц — это был хороший старт.

Вторая версия — управление деньгами.
Но быстро выяснилось: простая загрузка не равна прибыли. Внешне проект идёт, все заняты, акты закрываются — а по факту сложный проект с сеньорами может быть убыточным из-за затянутых согласований и задержек платежей. Гант 2.0 добавил финансовую аналитику прямо в тот же интерфейс. Теперь менеджер видит рентабельность в реальном времени и может принять решение: ускориться, пересмотреть план или остановить работу, пока минус не стал катастрофой. У руководства исчезла иллюзия благополучия — вместо неё пришли точные цифры.

Бизнес-задача и ее решение

Первый этап: победить простои.
Когда компания выросла до 60+ человек с десятками параллельных проектов, Эксель сломался окончательно. Ошибки из-за человеческого фактора, отсутствие данных в реальном времени, невозможность планировать на месяцы вперёд. Простой разработчика — это прямые потери денег. Перегруз — путь к выгоранию. Готовые системы на рынке оказались либо слишком сложными, либо слишком примитивными.

Решение первого этапа:
Свой прототип на Firebase с диаграммой Ганта, цветовой индикацией загрузки и привязкой сотрудников к проектам. Менеджер за секунду видит, кого можно добавить в новый проект, а кто уже «красный» от перегруза. Результат — простои упали на 5%, время планирования — вчетверо меньше.

Второй этап: связать часы с деньгами.
Но прошло время, и появилась новая боль. Бизнес стал замечать странный феномен: внешне всё отлично, а прибыль падает. План работ, реальные часы сотрудников и деньги жили в трёх разных мирах. Оценить реальную рентабельность проекта или эффективность конкретного специалиста было невозможно. Плюс сама платформа Firebase начала тормозить — с ростом данных и сложной логикой финансов она просто не справлялась.

Решение второго этапа:
Полностью переписали бэкенд на собственный сервер, но сохранили тот же интерфейс, чтобы не переучивать команду. Добавили финансовый блок в то же окно — теперь в одном месте собраны фактические часы по каждому сотруднику, плановая рентабельность, её отклонения и статусы оплат. Система сама предупреждает, когда проект начинает идти в минус.

Что в итоге:
План, факт и деньги сошлись в одной системе. Управленческие решения теперь принимаются по данным, а не по ощущениям: перераспределить нагрузку, скорректировать план, остановить бесполезную работу. Рентабельность компании выросла на 8% без расширения штата и без новых таблиц.

Крафт (мастерство), реализация, технические детали

Как начинался прототип (Гант 1.0).
За основу взяли Firebase — экосистему, которая позволяет быстро собрать работающее приложение. База данных Firestore работает по реактивной модели: клиент не отправляет запросы к серверу, а подписывается на изменения в документах и получает обновления автоматически. Это идеально для прототипа — минимум кода, максимум скорости. Команда собралась на месяц, менеджер ставил задачи в доске Штаб (колонки Сделать → Тестировать), разработчики брали задачи, тестировщики проверяли. Через четыре недели система уже работала.

Главный технический вызов — переход на Гант 2.0.
Когда система выросла из прототипа, Firebase стал тормозить. Но проблема была не только в производительности. Мы хотели добавить финансовую логику — расчёт рентабельности, статусы оплат, прогнозы. На Firebase это было больно и неэффективно. Решение — переезд на собственный бэкенд с GRPC и protobuf. Но как это сделать, не сломав фронтенд, к которому привыкли менеджеры?

Решение, которое сохранило интерфейс.
Мы реализовали слой адаптеров между старыми Firestore-моделями и новыми protobuf-объектами. Эти адаптеры эмулируют реактивные подписки поверх новых синхронных запросов. Фронтенд просто не заметил, что под ним поменяли всю инфраструктуру. Менеджеры продолжали работать в привычном окне, а под капотом уже крутилась сложная финансовая аналитика.

Почему свой путь оказался правильным.
Готовые системы на рынке либо слишком монструозны — их настройка займёт год и убьёт бюджет, либо слишком просты — не дают нужной глубины анализа. Firebase отлично подошёл для проверки гипотезы за месяц. А когда гипотеза подтвердилась, мы инвестировали в собственный сервис — и получили полный контроль над архитектурой, данными и скоростью.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

Уникальность этого кейса в том, что заказчик — сама команда разработки. Обратная связь была мгновенной и честной.

Инсайт 1: «Внешнее благополучие обманчиво».
Мы наивно полагали, что если убрать простои и наладить видимость загрузки, прибыль вырастет сама собой. Гант 1.0 действительно убрал простои на 5%, но общая рентабельность почти не изменилась. Почему? Потому что некоторые проекты, которые выглядели успешными, внутренне были убыточны из-за перерасхода дорогих сеньоров и долгих согласований. Без связи с финансами загрузка не гарантирует прибыль. Этот инсайт родил Гант 2.0.

Инсайт 2: «Не трогай интерфейс».
Мы проверяли гипотезу: менеджеры ненавидят переучиваться. Поэтому при переходе на Гант 2.0 сделали главную ставку на то, чтобы внешне система осталась прежней. Добавили финансовую аналитику «под капот» — новые данные появились в тех же окнах, без новых кнопок и закладок. Внедрение прошло без отторжения: сотрудники даже не заметили миграции, но руководство внезапно получило точные цифры по рентабельности.

Инсайт 3: «Свой бэкенд — это свобода».
Firebase — гениальная штука для проверки идеи. За месяц мы получили работающий продукт, который закрыл боль с простоями. Но когда система стала критичной и потребовалась сложная бизнес-логика, ограничения платформы стали душить. Переход на собственный сервер окупился за пару месяцев — просто потому что новые фичи стали выкатываться в разы быстрее. Главный урок: не начинайте с кастомного бэкенда, начинайте с прототипа на готовой платформе, а переезжайте только когда гипотеза доказана.

Как собирали требования:
Никаких абстрактных технических заданий. Мы опросили менеджеров проектов — собрали их реальные боли (Эксель, отсутствие единой картины, ручное перетаскивание часов). Отдельно поговорили с разработчиками — они указали на технические ограничения Firebase. Потом сели с финансовым директором. Только после этого родился прототип.

Еженедельные демо для внутреннего «заказчика»:
Каждую неделю менеджеры видели, как растёт система, и давали живой фидбек. Финансовый директор требовал больше цифр. Технический директор утверждал архитектуру миграции. Разработчики жаловались на тормоза Firebase. Так, шаг за шагом, прототип превратился в зрелый продукт.

Главный вывод, который теперь продаётся клиентам:
Не нужно начинать с большой сложной системы. Начните с прототипа, который закроет одну острую боль — например, простои и хаос в Эксель. Когда он докажет ценность (у нас это заняло пару месяцев), расширяйте его до финансовой модели. Путь «быстрый прототип → зрелый продукт» дешевле и безопаснее, чем годовая интеграция тяжёлой ERP или написание монстра с нуля. Именно так родился Гант 2.0 — и именно так мы теперь строим системы для заказчиков.

Скриншоты