Март. Команда из пяти разработчиков готовится к релизу мобильного приложения — окно запуска согласовано с маркетингом за два месяца вперёд. За три дня до старта тимлид открывает Slack и понимает: двое в отпуске (утверждено HR ещё в январе), один уехал на недельный курс по архитектуре микросервисов, четвёртый на больничном. Пятый — единственный человек в команде, который знает фронтенд-часть приложения, — есть, но он один. Релиз сдвигается на три недели. Маркетинг уже запустил анонсы. Бизнес теряет окно запуска к сезону.
Проблема здесь не в том, что люди ушли в отпуск. Проблема в том, что информация об их доступности жила в четырёх разных местах: отпуска — в HR-системе, обучение — в личном календаре руководителя, загрузка по задачам — в таск-трекере, а знание о том, кто единственный носитель критической компетенции, — в голове тимлида. Никто не сложил это вместе до момента, когда стало поздно.
Матрица доступности команды собирает все эти данные в одну плоскость и делает планирование реалистичным, а не оптимистичным. Тема пересекается с управлением нагрузкой — если вас интересует, как выявить перегрузку до того, как люди начнут выгорать, это отдельная история.
Почему график отпусков в Excel — это иллюзия контроля
Большинство команд действительно фиксируют отпуска. Есть таблица, есть даты, HR доволен. Но эта таблица не отвечает на вопрос: «Что произойдёт с проектом, если этот человек исчезнет на две недели?»
Первый типичный сценарий — отпуск совпал с релизом. Технически это «утверждённый отпуск», поданный за месяц. Формально всё по правилам. Только вот задача, которую должен был закрыть этот человек за неделю до релиза, никуда не делась. Никто не проверял, есть ли пересечение между датой отпуска и критическим путём проекта, потому что отпуска и проектный план жили в разных документах.
Второй сценарий — два носителя одной компетенции ушли одновременно. Команда из десяти человек, два специалиста по интеграциям с внешними API. Оба взяли отпуск в августе — логично, дети, школа. В это же время партнёр прислал изменения в спецификацию, которые нужно срочно имплементировать. Остальные восемь человек смотрят на задачу и не могут её тронуть.
Третий — форс-мажор обнулил план спринта. Один человек уходит на больничный на неделю. Если команда планировала спринт с расчётом на его полную загрузку, спринт автоматически не выполнен.
Четвёртый — обучение, которое «забыли» учесть. Разработчик уехал на пятидневный интенсив, согласованный с руководителем ещё в прошлом квартале. Запись об этом осталась в личном календаре менеджера. Команда узнала в понедельник, когда человек не вышел на дейли.
Как точно описывают эту ловушку специалисты по организационным процессам: «Матрица ролей — это не просто табличка в Excel, которую показывают аудитору. Это живой механизм, который либо работает на вас, либо против, создавая иллюзию контроля и бесконечные согласования. Основная проблема в том, что её часто строят от абстрактных требований, а не от реальных бизнес-процессов.»
То же самое справедливо для учёта доступности: таблица с датами отпусков построена от формального требования HR, а не от реальных зависимостей в проекте. Поэтому учёт есть, а предсказуемости нет.
Что такое матрица доступности и из каких слоёв она состоит
Матрица доступности — не стандартизированный фреймворк с сертификацией и учебником. Это практический инструмент, который собирается из трёх зрелых практик: анализа доступности ресурсов (отдельный этап в управлении проектами до составления календарного плана), матрицы компетенций и учёта проектной загрузки. По отдельности каждая из этих практик существует давно. Работают они только в связке.
Слой 1 — Календарь присутствия
Всё, что делает человека недоступным для проектных задач: утверждённые отпуска, больничные, командировки, обучение, саббатикалы. Сюда же входят частичные отсутствия — обучение на полдня, сокращённые пятницы, регулярные внешние встречи. Если человек три дня в неделю занят на клиентском проекте вне основной команды, это тоже частичное отсутствие с точки зрения планирования.
Горизонт — минимум квартал вперёд. Меньше бессмысленно: отпуска подаются заранее, обучение планируется заранее, и если вы видите только следующие две недели, матрица не даёт никакого преимущества.
Слой 2 — Карта компетенций и взаимозаменяемости
Кто что умеет и кто кого может подменить. Строится как таблица «сотрудники × компетенции» с уровнями владения. Для целей матрицы доступности достаточно трёх градаций: «может работать самостоятельно», «может с поддержкой», «не может».
Логика простая: до начала отпускного сезона нужно пройтись по критичным функциям и назначить замещающих сотрудников — фактически сформировать «матрицу взаимозаменяемости». Если для какой-то роли нет ни одной замены — это красная зона, требующая отдельного решения: кросс-обучение, найм, ограничение на совмещение отпусков.
Слой 3 — Проектная загрузка
Сколько часов в неделю человек занят на конкретных проектах. Самый неочевидный слой: человек может быть «на месте», не в отпуске, не на больничном — и при этом фактически недоступен для новых задач, потому что загружен на 100% на текущих.
Итоговая матрица выглядит как таблица: по строкам — сотрудники, по столбцам — недели или спринты. В каждой ячейке — цветовой статус: зелёный (доступен, есть ёмкость для задач), жёлтый (присутствует, но загружен), красный (отсутствует), серый (может подменить при необходимости, но это не его основная роль). Именно эта визуализация, а не список дат, даёт реальную картину.
Как построить матрицу доступности за пять шагов
Построить матрицу можно за одну-две недели. Сложность не в построении — в поддержании актуальности.
- Собрать реестр людей и проектных ролей. Не должностей — ролей. Один человек может быть техлидом в одном проекте и рядовым разработчиком в другом. Важно фиксировать именно проектные роли, потому что именно от них зависит, кто критичен для конкретного релиза.
- Наложить календарь отсутствий на горизонт планирования. Минимум — квартал. Включить всё: утверждённые отпуска, запланированное обучение, известные командировки, регулярные частичные отсутствия. Если компания использует плавающий график отпусков (индивидуальное согласование, а не жёсткий план) — это усложняет задачу, но не отменяет её: собирать данные нужно активнее.
- Оценить текущую загрузку по проектам. Для каждого человека — процент занятости на каждом проекте в часах или долях ставки. «Примерно половину времени» не считается. Данные должны приходить из системы управления задачами, а не из опроса на встрече. Опрос даёт социально желаемый ответ; трекер задач даёт факт.
- Построить карту взаимозаменяемости для критических ролей. Для каждой роли, от отсутствия которой проект останавливается, определить: кто может подменить и с каким уровнем компетенции. Три градации: полная замена, частичная замена (нужна поддержка или больше времени), не может заменить. Если по критической роли нет ни одной полной замены — это управленческий риск, который нужно закрывать до того, как человек уйдёт в отпуск.
- Определить правила обновления. Матрица, которую обновляют раз в квартал, устаревает за неделю. Минимальный ритм — еженедельная сверка при планировании спринта. Оптимально — когда данные о загрузке и задачах обновляются автоматически из системы управления проектами, и матрица отражает актуальное состояние без ручной работы.
Главная сложность именно здесь: не построить матрицу, а поддерживать её актуальной. Данные о загрузке и задачах должны жить в одном месте с данными о доступности — иначе синхронизация превращается в отдельный проект.
Кейс: как продуктовая команда в e-commerce перестала срывать релизы в отпускной сезон
Команда мобильной разработки в e-commerce-компании: 12 человек, три параллельных проекта, двухнедельные спринты, стек — React Native + Go на бэкенде. Лето 2024 — традиционно тяжёлый период: в июле-августе четыре человека уходят в отпуск в разные недели, один разработчик на двухнедельном курсе по новому стеку. Два последних релиза сдвинулись на 2–3 недели каждый. Каждый сдвиг обошёлся примерно в 800 тысяч рублей упущенной выручки — компания теряла пиковый трафик перед началом учебного сезона. Причина каждый раз одна: «не учли, что столько людей будет недоступно».
После второго сдвига тимлид сел строить матрицу доступности на квартал вперёд. Наложил её на дорожную карту релизов — и увидел конкретную цифру: в две недели июля в команде доступны только пять из двенадцати человек. Из них — ни одного фронтенд-разработчика.
Решение оказалось простым, но его можно было принять только имея эту картину перед глазами. Один релиз перенесли на две недели раньше — до начала отпускного сезона. Второй разбили на два этапа: первый этап закрыли до отпусков, второй запланировали на сентябрь, когда команда вернётся в полном составе. Ни один релиз в итоге не сдвинулся.
Побочный эффект: по оценке тимлида, планирование спринтов стало занимать около 40 минут вместо прежних полутора-двух часов. Вопрос «а кто вообще доступен на следующие две недели?» перестал быть предметом устного обсуждения — ответ был виден в матрице.
Матрица не устраняет риск неравномерной доступности — но делает его видимым достаточно заранее, чтобы на него можно было реагировать. Если вас интересует, как встроить такие буферы в проектный план системно, — в статье про управление рисками в проектах разобраны конкретные подходы.
Почему «полная загрузка» команды — враг устойчивого плана
Команда, загруженная на 100%, — не признак эффективности. Это признак хрупкости.
Если матрица доступности показывает, что все 40 часов каждого сотрудника расписаны по задачам — один больничный, одна срочная задача от CEO, одна непредвиденная интеграционная проблема — и весь план рассыпается. Не потому что люди работают плохо, а потому что в системе нет ни одного свободного звена, которое могло бы абсорбировать отклонение.
Практика показывает: если буфер незанятого времени меньше 15%, план становится хрупким. SAFe, например, закладывает отдельную Innovation & Planning итерацию — примерно 10% от общей ёмкости — именно для этих целей. В реальных продуктовых командах буфер ближе к 15–20%, потому что помимо инноваций есть код-ревью, документация и технический долг. В нормальные недели это время тратится на них, а в форс-мажорные — на то, чтобы закрыть срочную дыру без срыва всего остального.
Матрица доступности должна визуализировать этот буфер явно. Если ячейка жёлтая (человек загружен на 80–100%) — он формально доступен, но фактически взять что-то новое не может. Жёлтый цвет в матрице — сигнал: здесь нет запаса прочности. Планировать на этого человека дополнительные задачи — значит создавать риск.
Как использовать матрицу при планировании спринтов, релизов и портфеля
Матрица доступности — не самостоятельный артефакт. Это входные данные для трёх уровней планирования.
Уровень спринта
Перед планированием каждого спринта — сверка с матрицей: кто доступен на ближайшие две недели и с какой фактической ёмкостью. Если ключевой разработчик доступен только 60% (три дня из пяти), объём спринта уменьшается — не «надеемся, что успеет», а математически. Ёмкость спринта считается как сумма доступных часов каждого участника, умноженная на коэффициент фокуса — обычно 0.7–0.8, чтобы учесть встречи, переключения контекста и непредвиденные мелкие задачи.
Уровень релиза
При планировании релиза на 1–3 месяца вперёд дорожная карта накладывается на матрицу доступности. Если в окне релиза доступность команды падает ниже 60% — это сигнал: либо сдвигать дату, либо сокращать скоуп. Принять это решение до начала работы несравнимо дешевле, чем объяснять задержку стейкхолдерам постфактум. Кстати, если вы строите календарный план проекта и хотите, чтобы он не превратился в мёртвый документ, — матрица доступности является обязательным входом для графика работ проекта.
Уровень портфеля
Когда компания ведёт несколько проектов параллельно, матрица доступности показывает реальное ограничение: не бюджет и не технологии, а люди с нужными компетенциями. Портфель проектов ограничен ёмкостью команды — и матрица делает эту ёмкость видимой. Запускать новый проект, когда все нужные специалисты загружены на 90%, — значит либо обеспечить его провал, либо замедлить текущие проекты.
Стоит добавить: приоритизация задач без учёта доступности — упражнение в вакууме. Можно расставить приоритеты идеально, но если людей для выполнения топ-1 задачи нет — приоритет не имеет значения.
Где вести матрицу доступности — и почему отдельная таблица не работает
Матрица доступности полезна ровно настолько, насколько актуальны данные в ней. А данные актуальны только тогда, когда они не требуют ручной синхронизации из трёх разных источников.
Типичная ситуация: отпуска — в HR-системе, задачи и загрузка — в таск-трекере, карта компетенций — в отдельном Google Sheets, который последний раз обновлялся три месяца назад. Чтобы собрать матрицу, нужно открыть четыре вкладки, свести данные вручную, потратить час — и получить картину, которая уже немного устарела к моменту, когда вы её закончили.
Решение одно: данные о задачах, людях и приоритетах должны жить в одной системе. Если команда уже ведёт задачи в Shtab, часть данных для матрицы — кто над чем работает, в каком приоритете, сколько задач на каждом — уже собрана. Матрица Эйзенхауэра в Shtab с фильтром по конкретному сотруднику показывает его фактическую загрузку и приоритеты задач на текущую неделю — это один из слоёв для оценки реальной доступности. Остаётся наложить календарь отсутствий, и матрица собирается без ручной работы.
Диагностика: работает ли ваша матрица доступности
Матрица существует — но приносит ли она пользу? Проверьте по этим критериям. Если хотя бы два пункта не выполнены — матрица работает как декорация, а не как инструмент.
- Роли, а не должности. В матрице указаны проектные роли каждого участника. Если там написано «разработчик» без привязки к конкретному проекту — вы не увидите, какой именно проект встанет при его отсутствии.
- Горизонт больше двух недель. Если матрица покрывает только текущий спринт, она не предупреждает о проблемах — она фиксирует их постфактум. Минимум — квартал.
- Загрузка в цифрах, а не «примерно». Процент занятости берётся из таск-трекера, а не из устного опроса на стендапе. Разница между «он вроде свободен» и «у него 6 часов из 40 не занято» — это разница между надеждой и планом.
- Красные зоны взаимозаменяемости закрыты. Для каждой критической роли есть хотя бы один человек, который может подменить. Если такого человека нет — в матрице должен стоять явный флаг, а в бэклоге — задача на кросс-обучение с конкретным сроком.
- Буфер заложен явно. 15–20% ёмкости не расписано по задачам. Если буфера нет — любой больничный превращается в срыв спринта.
- Матрица привязана к дорожной карте релизов. Без проектного контекста это просто таблица присутствия. С контекстом — инструмент, который показывает, где план нереалистичен.
- Есть ответственный и ритм обновления. Конкретный человек обновляет матрицу еженедельно при планировании спринта. Если ответственного нет — матрица устареет через неделю после создания.
Заключение
Матрица доступности не требует ни сложного ПО, ни месяцев внедрения. Первую версию можно собрать за неделю. Главное — дисциплина: один раз построить структуру, назначить ответственного за обновление и сверяться с ней каждый раз перед планированием спринта.
Решения о сроках и скоупе начинают приниматься до того, как проблема случилась — а не в момент, когда три человека уже в отпуске и релиз завтра.
Попробуйте прямо сейчас: возьмите следующий спринт и проверьте три вещи. Совпадают ли даты чьих-то отпусков с критическим путём проекта? Есть ли замена для каждой критической роли? Заложен ли буфер хотя бы в 15% ёмкости? Если хотя бы на один вопрос ответ «нет» или «не знаю» — у вас уже есть первая задача для матрицы доступности.
FAQ
Как убедить HR отдать данные об отпусках в общую систему?
HR часто сопротивляется, потому что боится утечки персональных данных или потери контроля над процессом. Работающий аргумент: покажите конкретный случай, когда несогласованный отпуск привёл к срыву релиза, и посчитайте стоимость этого срыва в деньгах. Обычно после одной такой цифры вопрос «зачем это нужно» отпадает. Технически достаточно выгружать из HR-системы только даты отсутствий без причин — это снимает вопрос конфиденциальности.
Что делать, если команда распределённая и работает в разных часовых поясах?
Часовые пояса добавляют ещё один слой: человек может быть «доступен», но его рабочие часы пересекаются с командой только на два часа в день. В матрице это отражается как частичная доступность — аналогично сокращённой пятнице. Фиксируйте не просто «доступен / недоступен», а количество часов пересечения с основной командой.
Что делать, если в команде нет взаимозаменяемости по критическим ролям?
Это главный сигнал матрицы — красная зона. Если единственный носитель компетенции уходит в отпуск или на больничный, проект останавливается. Решение: запланировать кросс-обучение как проектную задачу с конкретным сроком и ответственным. Поставьте её в спринт, назначьте ментора и обучаемого, определите критерий готовности — например, «может самостоятельно закрыть типовую задачу по интеграции с API». Пока кросс-обучение не завершено, в матрице должно стоять ограничение: отпуска этого специалиста согласуются только после проверки, что ни один активный проект не зависит от него критически.