---
title: 'Процесс запроса ресурсов'
description: 'Процесс запроса ресурсов задает понятный путь получения оборудования, бюджета, людей или времени, чтобы решения не зависели от личных договоренностей.'
type: knowledge-card
locale: ru
canonical: 'https://yoseno.com/ru/docs/knowledge/resource-request-process'
---

# Процесс запроса ресурсов

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

- **Темы:** Автономия и полномочия, Скорость операций, Доступность ресурсов

## Что это

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

## Когда помогает

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

## С чего начать

1. Выберите один канал для запросов: форму, таблицу или задачу в трекере, где видны инициатор, ресурс, причина и желаемый срок.
2. Назначьте владельца процесса, который проверяет полноту запроса и направляет его к ответственному за решение.
3. Зафиксируйте минимальные критерии: зачем нужен ресурс, какой риск снимает запрос, какие альтернативы уже проверены.
4. Опишите статусы запроса: принят, требует уточнения, согласован, отклонен, отложен, и укажите владельца каждого статуса.
5. Проверьте первые запросы за неделю и уберите поля или согласования, которые не помогают принять решение.

## Ожидаемая польза

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

## Типичные ошибки

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

## Что почитать

- Книга: Gene Kim, Kevin Behr, George Spafford, The Phoenix Project
- Книга: Eliyahu M. Goldratt, Critical Chain
- Руководство: Project Management Institute, PMBOK Guide, разделы Resource Management и Procurement Management
- Книга: David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business

## Вопросы и ответы

### Кто должен быть владельцем процесса?

Обычно это операционный руководитель, руководитель функции или PMO. Важно, чтобы владелец мог назначать ответственных за решение и регулярно чистить очередь запросов.

### Можно ли начать без новой системы?

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

### Как понять, что процесс работает?

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

### Что делать, если руководители обходят процесс?

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

## Связанные карточки

- [Стандартизация процессов (SOP)](https://yoseno.com/ru/docs/knowledge/process-standardization.md) — SOP описывает повторяющиеся и критичные рабочие процедуры так, чтобы люди выполняли их одинаково, видели этапы, роли и ожидаемый результат.
- [Методы приоритизации (WSJF, MoSCoW)](https://yoseno.com/ru/docs/knowledge/prioritization-methods.md) — WSJF и MoSCoW помогают команде выбирать задачи по ценности, срочности, риску и ограничениям, а не по силе голоса в обсуждении.
- [Принципы справедливых решений](https://yoseno.com/ru/docs/knowledge/fair-decision-making.md) — Принципы справедливых решений задают понятные критерии для распределения проектов, нагрузки, премий и карьерных возможностей.
- [Delegation Poker](https://yoseno.com/ru/docs/knowledge/delegation-poker.md) — Delegation Poker помогает руководителю и команде договориться, кто принимает решения в конкретных зонах ответственности и где нужен контроль.