Перегрузки, простои и сорванные сроки: зачем бизнесу нормирование задач

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

Причина в том, что емкость команды оценивается приблизительно. Отсюда и перегрузки, и простои, и сорванные сроки. 

Три стадии, которые проходят организации с перегрузками

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

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

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

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

Увидеть перегрузку до того, как она приведёт к техническому долгу, помогает нормирование. 

Что дает нормирование задач

Спросите любого разработчика, сколько времени займёт задача, — и получите честный ответ: «Часа четыре, но это неточно». Оценка всегда приблизительная, потому что в неё заложено только то, что человек видит перед собой: написать код. Аналитика, тесты, ревью, релиз, деплой — всё это остаётся за скобками. А потом эти часы не сходятся, и никто не понимает почему.

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

Разница принципиальная. Оценка «часа четыре» — это суждение, которое невозможно проверить и легко оспорить. Норматив — это измеримая единица, одинаковая для всех проектов и всех команд.

Как встроить нормирование в процессы

Встроить нормирование можно двумя способами: вручную или через PPM-систему. 

Ручное нормирование

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

На практике это выглядит так:

1. Аналитик описывает, из каких операций состоит задача.
2. Разработчик подтверждает трудоемкость по каждой.
3. Результат заносится в справочник — сначала в Excel, потом в корпоративную wiki, чтобы им могли пользоваться другие команды.
4. Постепенно справочник наполняется, и оценки начинают опираться на накопленные данные.

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

Но главное ограничение в другом. Ручное нормирование отвечает на вопрос «сколько стоит эта задача», но не отвечает на вопрос «сколько всего работы у отдельно взятого специалиста». А ведь именно здесь и возникает перегрузка — не внутри проекта, а на стыке нескольких.

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

Нормирование в PPM-системах

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

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

На уровне портфеля — позволяет оценить, сколько проектов организация может реально выполнить с имеющейся емкостью, а не сколько она хочет выполнить.

На уровне программы — выравнивание ресурсов (resource leveling) позволяет перераспределить задачи так, чтобы ни один специалист не был загружен выше емкости. Если временные ограничения жёсткие, применяется сглаживание (resource smoothing).

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

И главное: при любых изменениях система пересчитывает данные автоматически и всегда показывает актуальную загрузку. Именно так это устроено в Digital Q.PM: нормативы заводятся один раз и становятся общей базой для всех проектов, а загрузка специалистов пересчитывается в реальном времени — по всем командам сразу. 

В этом и есть ответ на ограничение ручного способа: не «посчитать одну задачу точнее», а «увидеть всю загрузку целиком — до того, как она превратилась в перегрузку».

Цена отложенного решения

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

Бизнес, который считает нормирование бюрократией, обычно платит за это дорого. Просто счёт приходит позже — и не в тот отдел, который принимал решение.