Что такое Иерархическая структура ресурсов
(англ. resource breakdown structure, RBS) — это схема, которая показывает, как распределяются ресурсы проекта. Наверху — сам проект, ниже — всё, что для него нужно: люди, инструменты, материалы, оборудование
Представьте, что планируете ремонт. Рабочие, краска, обои, инструменты — если записать всё в одну кучу, что-нибудь точно можно забыть. RBS раскладывает ресурсы по группам: например, «Люди» → «Отделочники» → маляр, плиточник, сантехник. «Материалы» → краска, обои, плитка.
Когда всё разложено по полочкам, проще планировать, кто что делает, на что уходят деньги и как избежать ситуации, когда один инструмент нужен сразу двум командам.
Пример использования термина
На планёрке по переходу на новую серверную платформу руководитель группы открыл схему на мониторе.
«Сверим нашу иерархическую структуру ресурсов», — сказал он. — «Вот раздел "Вычислительные мощности": серверы трёх видов — для баз данных, для основных программ и для тестов. Рядом "Сетевое оборудование" — внутренние маршрутизаторы для связи между системами и внешние для работы с клиентами. В разделе "Персонал" мы отдельно выделили инженеров по настройке и специалиста по информационной безопасности. Без такой детализации мы бы заложили в бюджет просто "системного администратора". А сейчас чётко видим: нужен эксперт по безопасности — это другая должность».
Ведущий архитектор кивнул и стал делать пометки. Детализация сразу высветила пробел в первоначальном кадровом плане.
Что ещё нужно знать про Иерархическую структуру ресурсов
Зачем это нужно
RBS помогает в нескольких ситуациях:
Показывает полную картину. Без чёткого списка ресурсы учитывают по памяти — и что-то обязательно выпадает: лицензия на софт, услуги внешнего переводчика. Структура заставляет продумать всё заранее.
Даёт основу для расчётов. Невозможно точно оценить бюджет, если непонятно, какие ресурсы и в каком количестве нужны. RBS превращает размытое «нужны программисты» в конкретику: два backend-разработчика, один тестировщик, лицензия на таск-менеджер.
Помогает избежать конфликтов. В больших проектах одни и те же люди или оборудование часто нужны разным командам одновременно. Структура позволяет увидеть это заранее и составить график так, чтобы ресурсы не простаивали и не создавали очередей.
Создаёт общий язык. Готовая структура — понятный документ для всех: заказчика, руководства, команды. Все смотрят на одни и те же категории и названия.
Из чего состоит
RBS строят как дерево — от общего к частному.
Наверху — название проекта, например «Разработка нового сайта». Дальше основные категории: люди, оборудование, материалы, инструменты и программы, помещения. Каждую категорию можно делить дальше: «Люди» → «Штатные» и «Подрядчики», «Оборудование» → «Транспорт» и «Производственное». На нижних ветках — конкретные ресурсы: имена, точные описания, модели.
💡 Уровней вложенности может быть сколько угодно. Главное, чтобы ресурсы на каждом уровне были однородными и не дублировали друг друга. На практике обычно не больше четырёх-пяти уровней
Как создать
Лучше строить структуру на этапе планирования, до старта работ.
- 1. Определите категории: по типу ресурсов, по отделам или по этапам проекта — зависит от проекта
- 2. Выпишите все ресурсы: пройдитесь по плану работ и к каждой задаче спросите «что для этого нужно?». Всё можно записать в общий список, не сортируя
- 3. Разложите по категориям: каждый ресурс должен попасть только в одно место. Если ресурс никуда не вписывается — добавьте новую категорию
- 4. Детализируйте: для сложных проектов разделите категории на подкатегории — например, «Люди» → по специализации и по типу занятости
- 5. Нарисуйте дерево: подойдут диаграммы в любом удобном инструменте или специальные сервисы для ментальных карт
- 6. Согласуйте и начните использовать: утвердите структуру с командой, свяжите с задачами и планом — и обновляйте по ходу проекта
Практические советы
Не усложнять и не упрощать. «Люди» и «Всё остальное» — слишком общо. Учитывать каждую мелочь — неподъёмно. Нужна разумная детализация, особенно для дорогих или дефицитных ресурсов.
Говорить на одном языке. Если в одной ветке написано «Верстальщик», а в другой — «Frontend-разработчик», возникнет путаница. Используй единые названия по всей структуре.
Связывать с другими планами. Ресурсы из RBS нужно привязывать к конкретным задачам и статьям бюджета — иначе структура висит в воздухе.
Не боястья изменений. В начале проекта невозможно предусмотреть всё. Структуру стоит периодически пересматривать, чтобы она отражала реальность.
Различать роли и людей. На старте в структуру заносят должности (например, «архитектор»). Когда на роль назначат конкретного человека, это можно отметить отдельно.
Подписаться 
