Как решать управленческие кейсы: от ограничений к обязательству
В таком кейсе не нужно угадывать любимый фреймворк интервьюера. Нужно заметить, что весь scope не помещается в текущую backend capacity с учётом BAU, выбрать компромисс и дать commitment, который вы готовы защищать перед владельцем продукта.
Если хотите сначала решить кейс без подсказок, откройте кандидатский тренажёр. В нём четырнадцать коротких экранов: сначала вводные без полей, затем расчёт, commitment, roadmap и защита решения. Итоговый ответ собирается только в конце. Возвращайтесь к этой главе после решения.
В качестве сквозного примера возьмём внутренний продукт для кадрового планирования: фиксированная бизнес-дата приходится на десятую неделю квартала, через неделю начинается другой критичный цикл, продукт зависит от двух внешних систем, а backend scope заметно превышает доступную capacity команды.
Что на самом деле проверяет кейс
Сильный кандидат не пытается героически «успеть всё». Он делает пять вещей:
- отделяет факты условия от допущений и неизвестных;
- считает capacity по специализациям и до нужной даты, а не только до конца квартала;
- превращает приоритеты в commitment, опции и явный out of scope;
- ставит ранние проверки на самые опасные неизвестные;
- формулирует решение для бизнеса: что будет получено, к какой дате и при каких условиях.
Конкретный план может отличаться. Проверяется качество рассуждения: арифметика, причинные связи, управляемость риска и ясность обязательства.
Шаг 1. Назовите конфликт и свой выбор
Сначала скажите простую вещь: какие четыре параметра вам дали — scope, date, quality и resources — и какой из них придётся менять. Если все четыре объявлены фиксированными, это не план, а противоречие.
Факты нельзя менять без согласования. В нашем примере это две бизнес-даты, состав команды, оценки работ, накопленная срочная нагрузка и минимальные сроки выхода новичков.
Неизвестные нужно проверить. Например: подходит ли новая workflow-платформа, когда внешняя команда даст стенд и окно релиза, какой сквозной сценарий действительно нужен пользователю в первый день.
Решение — то, за что отвечает лидер. Это граница commitment, последовательность работ, контрольные точки, организация команды и предложение по найму.
Эта раскладка защищает от типичной ошибки: обсуждать неизвестность как уже доказанный факт или выдавать чужое ограничение за собственное управленческое решение.
Шаг 2. Проверьте capacity цифрами
В команде четыре backend- и четыре frontend-инженера. За 12 недель теоретическая capacity каждой группы равна 48 человеко-неделям. Но 15–20% времени исторически уходят на поддержку, инциденты и срочные запросы:
| Специализация | Gross capacity за квартал | После BAU 15–20% |
|---|---|---|
| Backend | 48 | 38,4–40,8 |
| Frontend | 48 | 38,4–40,8 |
План требует 54 backend- и 18 frontend-недель. Значит, общий размер команды скрывает проблему: frontend capacity достаточно, а backend не помещается даже к концу квартала.
Дедлайн находится в начале десятой недели, поэтому считать только весь квартал нельзя. К контрольной точке конца девятой недели backend располагает примерно 28,8–30,6 эффективными человеко-неделями. Часть времени до запуска потребуется на пилот, исправления и rollout, которых нет в исходных оценках. Реальный commitment должен быть ещё меньше.
Новый сотрудник, вышедший на седьмой неделе и работающий на 50% эффективности, даст до конца квартала около трёх человеко-недель. До ключевой даты — ещё меньше. Найм полезен для следующих кварталов, но текущий дедлайн он не спасает.
Нормальный capacity plan отвечает на четыре вопроса:
- какая capacity доступна отдельно по ключевым ролям;
- сколько времени реально есть до бизнес-даты;
- какой резерв подтверждён историей;
- что не входит в оценки, но всё равно потребует времени.
Шаг 3. Зафиксируйте commitment и out of scope
Если бизнес-дата действительно фиксирована, переменной становится объём. Разделите его на три корзины.
Commitment — минимальный сквозной сценарий, без которого бизнес-результата нет. Например, одна целевая группа пользователей проходит путь создания, согласования и передачи заявки, а критичные дефекты соседнего сервиса устранены до его цикла.
Опции — расширения, которые команда берёт только после прохождения контрольных точек: дополнительные роли, удобства, автоматизация редких веток, часть отчётности.
Out of scope — объём, который сознательно не входит в обещание. Это не «сделаем, если попросят громче», а зафиксированная граница плана.
Полезная формула commitment:
К дате X группа пользователей Y сможет выполнить сценарий Z с критериями качества Q, если до контрольной точки D подтверждены зависимости A и B. Остальной объём — опция.
Если заказчик требует весь первоначальный объём, лидер показывает не отказ, а выбор: сократить scope, перенести date, снизить quality bar или добавить resources с реалистичным сроком выхода. Нельзя объявить всё неизменным и считать это планом.
Шаг 4. Соберите roadmap вокруг dependencies
Плохой план сначала долго разрабатывает, потом интегрирует и в конце узнаёт, что ключевое допущение неверно. Хороший план атакует наиболее опасную неизвестность в первые недели.
Один из разумных вариантов:
| Недели | Результат и управленческое решение |
|---|---|
| 1–2 | Уточнить минимальный пользовательский сценарий; проверить workflow-платформу коротким прототипом; получить владельца, стенд и окно релиза внешней системы |
| 3–4 | Собрать первый сквозной путь на тестовых данных; принять go/no-go по workflow-платформе и интеграции |
| 5–6 | Расширить сценарий до пилотного; проверить роли, статусы, аудит, ошибки и наблюдаемость |
| 7–8 | Провести пилот на ограниченной группе; исправлять блокирующие проблемы, заморозить необязательный объём |
| 9 | Принять решение о запуске по измеримым критериям готовности |
| 10 | Контролируемый запуск с поддержкой и ручным резервным процессом |
| 11 | Отдельный фокус на старте цикла оценки сотрудников; повышенное дежурство |
| 12 | Стабилизация, разбор фактов квартала и подготовка следующего этапа |
Веха — это не «backend готов на 70%». Это проверяемый результат или решение: интеграция прошла на реальном стенде, пользователь завершил сценарий, пилот дал допустимое число ошибок, запуск разрешён или остановлен.
Шаг 5. Обновляйте forecast по velocity, а не по занятости
Отчёт «все заняты» ничего не говорит о дате. Для прогноза нужны:
- оставшаяся работа по узкому месту;
- фактическая пропускная способность команды;
- состояние внешних зависимостей;
- тренд дефектов и результат пилота;
- дата следующего необратимого решения;
- объём опций, который можно снять без разрушения обязательства.
Раз в неделю лидер обновляет прогноз и сравнивает его не с первоначальной надеждой, а с критериями контрольной точки. Если прогноз перестаёт помещаться, опции снимаются сразу. Эскалация должна звучать как предложение решения: «если стенда нет к концу второй недели, переходим на резервный экспорт и переносим полную интеграцию», а не как позднее сообщение «внешняя команда задержала нас».
Шаг 6. Зафиксируйте quality bar и rollout
Для внутреннего продукта ошибка может испортить решения о людях и бюджете. Поэтому «функция реализована» ещё не означает «её можно запускать».
До запуска стоит определить:
- ограниченную группу и реальные сценарии пилота;
- владельца решения go/no-go;
- критерии качества данных и допустимый уровень ошибок;
- аудит действий, метрики и оповещения;
- канал поддержки на время критического цикла;
- способ остановить новый путь;
- ручной или старый процесс, к которому можно вернуться без потери данных.
Откат — часть дизайна поставки, а не признание поражения. Чем дороже ошибка, тем раньше нужно проверить резервный процесс.
Шаг 7. Сделайте resource plan на квартал и дальше
Разделение команды в разгар квартала создаёт новые границы и дополнительные координационные расходы. Временно разумнее создать два потока с одним общим обязательством: основной сквозной продукт и поддержка критичного соседнего цикла. Владельцы потоков нужны, но жёсткую реорганизацию лучше принимать после того, как станет понятна устойчивая граница ответственности.
Найм обосновывается не текущей нехваткой «рук», а повторяющейся системной проблемой. Например:
- backend-инженер увеличивает мощность устойчивого узкого места;
- инженер по качеству строит риск-ориентированную проверку сложных бизнес-циклов;
- delivery- или engineering-менеджер снижает стоимость внешних зависимостей и освобождает технических лидеров от постоянной координации.
Это лишь один осмысленный состав. Сильный ответ может предложить другой, если связывает каждую позицию с проблемой на горизонте двух–четырёх кварталов и не использует найм как фиктивное спасение ближайшего дедлайна.
Как собрать ответ на одну страницу
Хороший итоговый документ читается сверху вниз как решение, а не как дневник размышлений:
- Цель и обязательство: кто получит какой результат и к какой дате.
- Арифметика: capacity по специализациям, BAU и резерв.
- Граница scope: commitment, опции и out of scope.
- Roadmap: ранние проверки dependencies, пилот и точки go/no-go.
- Управление: владельцы потоков, прогноз, эскалация и поддержка.
- Безопасность: критерии запуска, наблюдаемость и откат.
- Решение спонсора: какой компромисс нужно согласовать сейчас.
Короткая защита может начинаться так:
Полный scope не помещается в backend capacity даже до конца квартала, а фиксированная business date наступает раньше. Я предлагаю commitment на минимальный сквозной сценарий, две dependencies проверяю в первые две недели, остальное фиксирую как out of scope. На девятой неделе принимаем go/no-go по пилоту; rollout имеет ручной fallback. Сейчас прошу владельца продукта подтвердить границу scope. Quality bar я не снижаю.
Дальше вы показываете расчёт и условия, при которых прогноз изменится.
Типичные слабые ответы
- «Попросим команду ускориться». Не меняет ни мощность, ни объём, ни риск.
- «Наймём трёх человек и успеем». Игнорирует срок выхода и адаптацию.
- «Разобьём всё на спринты». Календарь задач не заменяет бизнес-вехи и проверки риска.
- «Сделаем сначала весь backend». Откладывает сквозную проверку и интеграционный риск.
- «Критичные дефекты починим по ходу». Не выделяет ответственность на период второго бизнес-цикла.
- «Весь объём критичен». Скрывает необходимость управленческого выбора.
- «Вот единственно правильная структура команды». Подменяет доказательство догмой.
Главный признак сильного решения прост: после его чтения бизнес может выбрать компромисс, а команда понимает границу своего обещания и момент, когда обязана поднять тревогу.
Связанные главы
- Планирование и оценки — как работать с диапазонами, неопределённостью и уже данным обещанием.
- Границы команд — как отделять устойчивую структуру от временного распределения работ.
- Вверх по цепочке — как принести руководителю выбор, а не только список проблем.
