ООО Диасофт 
Тендеры и лиды
Информация
Спринты закрываются в срок, календарно-сетевой график не краснеет, статус-отчёты стабильно зелёные. Но на финальной встрече выясняется: фактические затраты превысили первоначальную смету на 20-30%. Откуда берётся разрыв, если работа идёт по плану, разбираем в статье.
«По плану» и «в смете»: два разных утверждения о проекте. Первое говорит, что задачи двигаются по доске, вехи достигаются, релизы выходят. Второе отвечает на вопрос, уложились ли мы в смету. И одно не вытекает из другого.
Потому что план работ управляет последовательностью и сроками и отвечает на вопрос «что делаем дальше». Бюджет же отвечает на вопрос «сколько это стоит по факту». И складывается он не из закрытых задач, а из стоимости людей, которые эти задачи делают:
из цены ожидания, пока задача ждёт своей очереди;
из стоимости изменений, которые по отдельности кажутся незначительными;
из технического долга, который накапливается незаметно, пока команда дисциплинированно закрывает спринты.
И вот что важно: ожидание, изменения и техдолг не видно на доске. Доска показывает, что задача закрыта. Но она не показывает, что эта задача месяц ждала свободного разработчика, потому что он был занят в другом проекте. А этот месяц ожидания — такая же стоимость, как и его зарплата.
Поэтому зелёный статус-отчёт и перерасход на 20-30% — не противоречие. Это два взгляда на один и тот же проект.
Если план и смета расходятся, то разрыв почти всегда складывается из нескольких статей, которые известны, но при этом редко попадают в смету.
Когда команда жертвует качеством кода ради скорости, например, чтобы уложиться в обещанный релиз, это не экономия. Это кредит. И платить по нему придётся техническим долгом, который увеличивает стоимость следующих итераций: больше времени уходит на поддержку, доработки становятся дороже, а масштабирование без переписывания рискованнее.
Но платёж по этому кредиту приходит не сразу. Кажется, что всё хорошо: план текущей интеграции выполнен, релиз вышел. Вот только стоимость следующей итерации уже выросла, просто это ещё не видно в отчете. В бюджете оно проявится позже, как «внезапно» подорожавшая доработка или увеличенный срок следующего этапа.
Требования меняются, и для разработки это нормально. Правка от маркетолога, «мелкая» хотелка стейкхолдера, неучтенная интеграция: всё это кажется мелочью. Но если такие изменения не попадают в смету, то и в бюджете их не будет. В итоге перерасход случается не потому, что кто-то плохо оценил работу, а потому, что часть работы вообще не попала в оценку.
Например, возьмём среднюю рыночную ставку дня разработчика в заказной разработке (около 25 тыс. руб.). Если «мелкая» правка занимает 1-2 дня, это будет 25-50 тыс. руб. Плюс тестирование, ревью и релиз, еще 15-20%. Итого одна такая правка обходится в 29-60 тыс. руб. Если таких правок набирается десять в месяц, речь идет уже о 300-600 тыс. руб., которых в смете не было. По отдельности каждая правка кажется незначительной, но в совокупности это полноценная статья расходов, которую никто не планировал.
Это самый недооцененный фактор. Отдельный проект может быть идеально управляемым: с прозрачным бэклогом и дисциплинированной командой. Но если он забирает лучшего архитектора у параллельного проекта, который в этот момент входит в критическую фазу, то стоимость второго проекта кратно растет. А если он запускается, когда портфель уже перегружен, растягиваются сроки у всех. То есть локальная оптимизация одного проекта не равна оптимизации бюджета компании. Более того, она может ухудшать общий бюджет.
Первые две статьи не видны в отчете, но их можно заметить внутри проекта. Третья проявляется только на уровне портфеля, где проекты конкурируют за одни и те же ресурсы.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13829 тендеров
проведено за восемь лет работы нашего сайта.
На уровне отдельного проекта ситуация может выглядеть управляемой: руководитель видит задачи, сроки, загрузку команды и текущие расходы. Финансовый отдел отслеживает платежи и сопоставляет их с бюджетом. Но эти данные собираются по каждому проекту отдельно и не сходятся между собой. А всё, что происходит на стыке проектов, остается за кадром. Отсюда и слепые зоны.
Ресурсы. Руководителю проекта нужен архитектор на две недели, но тот уже зарезервирован под другой проект. Задача ждёт, а в трекере это не видно: там она просто стоит в очереди, как будто её некому делать.
Бюджет. Фактические расходы по одному проекту можно сопоставить с плановыми, но не всегда удается точно оценить, как изменение в этом проекте повлияет на бюджет остальных.
Приоритеты. В трекере у каждого проекта свой бэклог и свой порядок задач. Но нет места, где видно, как приоритеты одного проекта соотносятся с приоритетами другого. Решение «сначала сделаем здесь» может означать «перенесем там», и негативно сказаться на другом проекте.
Прогнозирование. Никто не видит заранее, как решения, принятые сегодня, изменят стоимость портфеля через квартал. Срезали качество ради срока в одном проекте, перенесли запуск в другом, перебросили людей в третий. Каждое из этих решений меняет будущие расходы, но в прогнозах не отражается.
Каждую из этих слепых зон можно попытаться закрыть вручную: свести данные по всем проектам в Excel, сопоставить бюджеты, собрать загрузку людей. Но чем больше проектов, тем ресурсозатратнее поддерживать такую картину в актуальном состоянии.
В какой-то момент компания оказывается перед выбором: нанять человека, который будет заниматься только этим или внедрить PPM-систему, которая дает актуальные данные в любой момент.
PPM-система, в отличие от инструментов для задач и сроков отдельной команды, объединяет информацию о проектах, финансах, ресурсах и взаимосвязях между инициативами. Вот как это работает на примере возможностей PPM-платфоры Digital Q.PM:
Единая картина расходов. Система ведёт целевой, прогнозный и фактический бюджет одновременно и автоматически рассчитывает график платежей и статьи, поэтому руководство видит плановые и фактические затраты по каждому проекту и портфелю в целом. Это закрывает ту слепую зону, где бюджет планировался в одном месте, а факт собирался в другом.
Контроль загрузки ресурсов. Система показывает, кто и в каких проектах задействован, какие ресурсы зарезервированы и где возникает перегрузка. А оптимизатор ресурсов подсвечивает эти конфликты автоматически, с учетом календарей, отпусков и фактической занятости. В итоге ожидание, которое в трекере не видно, здесь становится видимой величиной: вы видите, что архитектор занят, до того как задача встала в очередь.
Оценка последствий изменений. Изменение сроков или приоритетов отражается не только на календарном плане конкретного проекта, но и на связанных с ним инициативах. Чтобы это увидеть, проекты группируют в портфели и выстраивают зависимости между ними: план портфеля по вехам строится автоматически из планов проектов. В результате видно, как даже самая мелкая правка отражается на всём портфеле.
Прогнозирование. Система ведёт прогнозный бюджет отдельно от фактического и обновляет его вместе с решениями по проекту. Поэтому видно, во сколько обойдётся завершить проект с учетом текущей загрузки, а не только сколько уже потрачено. Это закрывает ту слепую зону, где решения, принятые сегодня, меняли будущие расходы, но в прогнозах не отражались.
С PPM-системой руководители получают возможность контролировать бюджеты и платежи, планировать и резервировать ресурсы, отслеживать исполнение проектов и анализировать состояние портфеля через сводные показатели и дашборды.
И это меняет сам подход к управлению расходами. Вместо того чтобы разбираться, почему проект вышел за бюджет, когда деньги уже потрачены, компания получает инструменты для оценки финансовых последствий управленческих решений до того, как они превратятся в реальные потери.
Перерасход в IT-проекте складывается из мелочей, которые по отдельности не выглядят деньгами: ожидания в очереди, «незначительных» правок, отложенного техдолга и решений, принятых в одном проекте в ущерб другому.
Поэтому вопрос не в том, как точнее считать бюджет по проекту, а в том, где смотреть, чтобы увидеть эти статьи до того, как они стали перерасходом.
