Кажется, что это две разные истории: где-то мы считаем занятость людей, а где-то согласовываем правки в коде или инфраструктуре. Но на практике они жестко сцеплены.
Вот 3 точки пересечения, которые нужно учесть в регламенте, чтобы ресурсное планирование не превратилось в "фикцию в эксельке":
1. Изменения "съедают" ресурсы
В регламенте по учету изменений (особенно проектных) должно быть правило:
"Ни одно изменение не может быть утверждено, если под него не выделен ресурс в плане".
Если проектный комитет одобрил новую фичу, но разработчик уже занят 120% в спринте — это изменение либо:
- Откладывается (ставится в бэклог).
- Идет с приоритетом "критично", но тогда руководитель ИТ должен показать, кого и на сколько мы снимаем с текущих задач.
Вывод: В регламенте изменений должен быть пункт "Оценка трудозатрат и доступность ресурса". Без подписи руководителя ресурсного пула не идет на согласование.
2. Аварии и инциденты — это "скрытый потребитель" ресурсов
В ресурсном планировании часто забывают про неплановую загрузку:
- Прод сломался (инцидент).
- Срочный хотфикс (экстренное изменение).
- Срочные запросы от заказчика, не терпящие отлагательств.
Если у вас в ИТ-дирекции есть команда, которая и проекты ведет, и прод поддерживает, — без учета этих "пожирателей времени" ресурсный план разойдется с фактом уже через неделю.
Что делать в регламенте?
Ввести понятие "Буфер на незапланированные работы" (обычно 20-30% от емкости команды). И любой emergency change должен списываться сначала в этот буфер. Если буфер кончился — изменения либо не принимаются, либо снимаются плановые задачи.
3. Передача проекта в эксплуатацию
Классическая боль: проект дописан, код выкатили, а дальше его нужно сопровождать.
В ресурсном планировании отдела эксплуатации об этом часто забывают.
Правило для регламента:
Проектное изменение считается завершенным только тогда, когда в ресурсном плане эксплуатационной команды появилась выделенная единица поддержки (или доля человека) на эту новую систему. И это должно быть согласовано с руководителем эксплуатации до старта проекта, а не после.
🛠 Как это замкнуть в одну систему?
Если у вас внедрена ИСУП (вроде Jira + BigGantt, Yandex Tracker, Planfix, Kaiten и т.д.), логика должна быть такой:
- Проектная задача создается в системе.
- Она проходит оценку (часы * ставка = стоимость изменения для бизнеса).
- При утверждении система автоматически резервирует этих людей в ресурсном плане на указанные даты.
- Факт: разработчик списывает время на эту задачу (табели/логи работы).
- Отчет: Руководитель видит план/факт и понимает, не сгорел ли буфер на аварии, не перегружены ли люди, не пора ли нанимать еще.
Итог для твоей серии постов
Ты правильно пишешь, что "команда — это люди". А люди — это самый дорогой ресурс в ИТ.
Поэтому мой тезис в дополнение:
"Ресурсное планирование без регламента изменений — это гадание на кофейной гуще. А регламент изменений без ресурсного планирования — это бюрократия, которая не работает, потому что исполнителей на изменения физически нет."
Лечить эти боли нужно в связке.
Подписывайтесь на наш Telegram-канал: автопилот для бизнеса.