Переходный этап в управлении проектами или как выживать, когда на тебе не менее 4 управленческих ролей

10
Апр
2026

Переходный этап в управлении проектами или как выживать, когда на тебе не менее 4 управленческих ролей

ИИ не спасёт. Российские кейсы, цифры и методы выживания.

Контекст 2024-2025 – уже не просто делать быстрее, а делать так, чтобы один PM заменял аналитика, тестировщика и частично DevOps. ИИ не снял нагрузку, а перераспределил её.

Переходный этап в управлении проектами или как выживать, когда на тебе не менее 4 управленческих ролей - 1

1. Добро пожаловать в эпоху один за всех

Сокращения, заморозка найма, повсеместное внедрение ИИ – всё это привело к простой формуле: одного сотрудника теперь наделяют минимум 4 управленческими ролями.

Классический набор выглядит так:

Роль	Ответственность
Project Manager	Отвечает за сроки и бюджет.
Product Owner / Business Analyst	Собирает требования, приоритезирует бэклог.
QA / Тестировщик	Проверяет, что результат работает.
Технический писатель / DevOps (частично)	Документирует, настраивает окружение.

А если повезло, добавляется ещё роль Scrum-мастера (проводить ретро для самого себя) и Support (отвечать на вопросы клиентов).

Топ-менеджмент называет это повышением эффективности и цифровой трансформацией. А сотрудник называет это бессонницей и чувством, что всё валится.

2. Почему это происходит именно сейчас? Три кита переходного этапа

Прежде чем говорить о выживании, поймём причины. Их три, и все они бьют одновременно.

2.1 Кит первый: Иллюзия безграничной экономии на ИИ

Топы увидели презентации: «ChatGPT заменяет 5 джунов за $20». И подумали, а зачем мне команда из 10 человек, если можно оставить трёх и добавить нейросеть? Они не учли скрытые затраты (о них – в главе 6), но решение об увольнениях уже принято.

В результате вы остаётесь один, а помощник в виде ИИ требует вашего же времени на настройку промптов и проверку галлюцинаций.

2.2 Кит второй: Страх перед человеческим фактором

Человек может заболеть, уволиться, не договориться с коллегой, ошибиться из-за настроения. ИИ казался предсказуемым. При этом практика показала, что ИИ тоже ошибается, но делает это с полной уверенностью. Теперь вы ещё и тратите время на верификацию его ответов.

2.3 Кит третий: Конкурентная гонка и психология топов

Если конкурент отчитался о сокращении 20% ФОТ за счёт ИИ – ваш совет директоров потребует того же. Признать, что это была ошибка, – политическое самоубийство. Поэтому гонка продолжится. А вы остаётесь с 4 ролями и надеждой, что переходный этап когда-нибудь кончится.

3. Как выживать: новые правила для методологий

Когда на вас 4 роли, классические Agile-методологии в чистом виде не работают. Они рассчитаны на команду. Но это не значит, что нужно всё выбросить. Просто каждую методологию придётся жестоко донастроить под себя. Ниже – пошагово, что и как.

3.1 Scrum для одного человека (или двух)

Ломается покер-планирование, daily standup, ретроспектива – всё это бессмысленно, когда участник один или два.

Как применять (понятно и по шагам):

№ п.п.	Шаг	Примечание
1.	Спринт 3–5 дней, вместо 2 недель.	Короткий цикл позволяет быстро реагировать на то, что вы провалили какую-то из ролей. Если спринт 2 недели, то к концу первой вы уже тонете в хаосе.
2.	Планирование – асинхронное, через бота (см. кейс Cloud.ru).	Вы закидываете задачи в мессенджер, бот собирает оценки и предлагает свою на основе истории. Результат – за 15 минут, вместо двух часов.
3.	Daily standup	Один вопрос себе: «Что из запланированного на сегодня я реально сделаю с учётом всех четырёх ролей?». И второй вопрос: «Какую роль я сегодня игнорирую?» Если каждый день игнорируете QA – потратьте на неё час вечером.
4.	Ретроспектива	5 минут на три вопроса: — Что сделано за спринт (по каждой роли)? — Где застрял? — Где ИИ мне сегодня наврал и сколько времени я потратил на проверку?
5.	Scrum-мастер вам не нужен.	Вы сами себе Scrum-мастер. Единственная его функция – не давать вам брать в спринт больше, чем вы физически можете сделать за 3–5 дней. Например, не более 3–4 задач на спринт (суммарно по всем ролям).

Пример из жизни.

Вы один. В спринте (4 дня) вы взяли:

— [PM] согласовать сроки с заказчиком

— [BA] написать требования к новой фиче

— [QA] протестировать старый багфикс

— [Doc] обновить инструкцию

Если вы видите, что тестирование (QA) требует 6 часов, а у вас их нет – вы не берёте задачу QA в этот спринт. Или заменяете её на «запустить автотесты и посмотреть лог».

3.2 Kanban для одного человека с 4 ролями

Ломается классический Kanban, предполагающий непрерывный поток задач и команду, которая может переключаться. Один человек с 4 ролями быстро превращает Kanban-доску в помойку. Задачи висят, WIP limits не работают, лид-тайм стремится к бесконечности.

Как применять (понятно и по шагам):

№ п.п.	Шаг	Примечание
1.	Введите не одну колонку «In Progress», а четыре – по ролям.	Например: — В работе (PM) — В работе (BA) — В работе (QA) — В работе (Doc)
2.	WIP limits – для каждой колонки отдельно.	Максимум 2 задачи в каждой ролевой колонке. Если в колонке QA уже 2 задачи – вы НЕ берёте новую задачу на тестирование, пока не закроете одну из старых. Это защищает от ситуации, когда вы взяли 10 задач и делаете их все параллельно (по сути, никакую).
3.	Добавьте колонку «Ждёт внимания» или «Backlog ролей».	Сюда вы кидаете задачи, которые требуют вашего времени, но сейчас вы заняты в другой роли. Раз в день вы смотрите на эту колонку и решаете, что перетащить в «In Progress» какой роли, а что делегировать ИИ или отложить на неделю.
4.	Обязательный регулярный обзор – раз в 2 дня, 15 минут.	Вы не работаете с доской постоянно. Два раза в неделю вы садитесь и честно смотрите: — Где задачи зависли дольше 2 дней? — Какая колонка переполнена? — Не пора ли закрыть что-то как не приоритетное?

Кейс «Диасофт» (Россия).

Разработали внутреннюю платформу, которая делает видимой реальную загрузку по ролям. У них ИИ-подсказка при назначении задачи: «Ты уже взял 3 задачи как аналитик, возьмёшь четвёртую – сроки по всем посыпятся». Для одного человека это можно сделать простой таблицей или цветовой индикацией в Jira.

3.3 OKR для выживальщика

Главная ошибка пытаться менять OKR каждую неделю. Это приведёт к хаосу. OKR – это про стабильность цели на квартал. Недельная смена Objective – не OKR, а «метод тыка».

Как правильно применять (понятно и по шагам):

№ п.п.	Шаг	Примечание
1.	Objective – один, жёсткий, на квартал.	Например: «Закончить проект X и передать его в эксплуатацию». Этот Objective не меняется, даже если всё вокруг горит. Он ваш компас.
2.	Key Results – 3 штуки, измеримые.	Например: — KR1. Завершить разработку модуля А (100% задач Done). — KR2. Провести приёмочные испытания с заказчиком (без критических замечаний). — KR3. Написать документацию (покрыть 100% функций). Обратите внимание: эти KR соответствуют вашим ролям (разработка – Dev, испытания – QA, документация – Doc). Вы не берёте четвёртый KR, потому что четвёртая роль (PM) уже в Objective: «закончить и передать».
3.	Корректировка Key Results.	Key Results можно (и нужно) корректировать раз в 2 недели, но осторожно. Если вы видите, что KR3 (документация) совсем не двигается, а до конца квартала 2 недели – вы меняете KR3 на более реалистичный: «Написать документацию на 50% ключевых функций». Но Objective остаётся прежним.
4.	Еженедельный чек-ап.	Не пересмотр OKR, а честная сверка. Каждую пятницу – 15 минут. Три вопроса: — Где я сейчас относительно каждого KR? (зелёный / жёлтый / красный) — Какая роль тормозит сильнее всего? (например, QA не успевает) — Что я делаю на следующей неделе, чтобы подтянуть отстающую роль, не меняя Objective? Чек-ап нужен, чтобы зафиксировать фокус на неделю, а не чтобы менять цели.

Пример из жизни.

— Objective (на квартал): «Вывести модуль оплаты в релиз».

— KR1: Все API модуля написаны и покрыты тестами (Dev).

— KR2: Проведено 3 цикла регрессионного тестирования без блокаторов (QA).

— KR3: Готовы пользовательские инструкции для 5 типов операций (Doc).

На второй неделе вы понимаете, что QA отстаёт (KR2 красный), а Doc вообще не начинал (KR3 красный).

Вы не меняете Objective.

Вы меняете тактику: выделяете на QA 2 часа в день вместо 1, а Doc временно делегируете ИИ (генерация черновика).

Через 2 недели пересматриваете KR3: «Готовы инструкции хотя бы на 2 типа операций».

Это не хаос. Это адаптация без потери цели.

3.4 А если никакая методология не лезет – используйте «Простой список дел с ролями»

Бывают недели, когда даже облегчённый Scrum или Kanban не работают, потому что вы просто зашиваетесь. На этот случай – самый простой, почти без методологии, вариант.

Как применять:

1. Заведите один текстовый файл или лист в блокноте.

2. Разделите его на 4 раздела: PM, BA, QA, Doc.

3. Каждый день утром (5 минут) напишите в каждый раздел не более 2 задач.

4. В течение дня работайте последовательно: сделали одну задачу из раздела – вычеркнули. Не переключайтесь между разделами каждые 10 минут.

5. Вечером, если в каком-то разделе остались невыполненные задачи – перенесите их на завтра, но не более 2 в разделе. Если накопилось больше – честно признайте, вы взяли слишком много, скиньте часть в бэклог на неделю.

Этот метод работает, когда:

— У вас нет сил на Jira, доски и метрики.

— Вам нужно просто выжить и не забыть, что есть 4 роли.

— ИИ пока не внедрён или не помогает.

Он неэлегантный, но он предотвращает выгорание за счёт одного простого правила: «Не бери больше 2 задач на роль».

4. Какой методологией пользоваться — таблица выбора

Ваша ситуация	Какую методологию взять за основу	Что донастроить
Вы один, задачи приходят непредсказуемо, роли смешаны	Простой список дел с ролями	Лимит 2 задачи на роль в день
Вы один, но поток задач более-менее стабилен, есть повторяющиеся операции	Kanban с ролевыми колонками	WIP limits по 2, колонка «Ждёт внимания»
Вы + ещё 1–2 человека, хотите спринты и ритм	Облегчённый Scrum	Спринт 3–5 дней, асинхронное планирование, ретро 5 минут
У вас есть квартальные цели, но каждый день всё меняется	OKR с фиксированным Objective	Пересмотр KR раз в 2 недели, еженедельный чек-ап без изменения целей

5. Российские кейсы: как другие выживают и иногда даже побеждают

5.1 Cloud.ru: асинхронный покер через бота

Ситуация	Команда из 5 человек (уже после сокращений) не могла тратить 2 часа на планирование спринта. Люди перегружены.
Решение	Перевели голосование в Mattermost-бота. Оценки скрыты до конца. ИИ предлагает свою оценку на основе истории. Экономия времени: 75%. Вовлечённость выросла на 40%.
Донастройка	Добавили поле «рекомендация ИИ» к каждой задаче. Человек не обязан соглашаться, но видит подсказку.

5.2 Сбер: Sberspace — AI-эксперт для 4000 команд

Ситуация

50 000 технических документов. Один аналитик физически не может всё помнить. Время на поиск информации – часы.

Решение

Создали AI-эксперта, который отвечает на вопросы по базе знаний.

Результат: 36 000 запросов в месяц, экономия времени на запрос – 10–15 минут. Для одного человека с ролью аналитика – это спасение.

Донастройка

Семантический поиск, гибридная модель (BM25 + эмбеддинги). Не просто нашли документ, а дали ответ с ссылкой на источник.

5.3 Росатом: трассировка требований за 1/6 времени

Ситуация	Инженер-аналитик тратил дни на ручную привязку требований к документам. Плюс роль QA – проверять, всё ли учтено.
Решение	Обучили ML-модель на уже страссированных документах. В итоге время сократилось в 6 раз. Человек перестал быть перекладывателем бумажек и начал анализировать.

5.4 «Автобан» + Lad: ИИ предсказывает задержки

Ситуация

Руководитель проекта в дорожном строительстве одновременно управляет сроками, бюджетом, подрядчиками и документацией. 4 роли в чистом виде.

Решение

Внедрили Project Lad с ИИ-помощником. Система подтягивает данные из 1С, строит прогнозы.

Эффект: одна незавершённая задача в разработке ИТ-продукта обходится в 10 млн рублей потери дохода. ИИ стал страховать человеческую забывчивость.

5.5 Teleperformance Россия: база знаний как фундамент

Ситуация

Операторы и один аналитик не могли найти информацию. Поиск работал только по точному слову. Тратили часы.

Решение

Переработали базу знаний. Контекстный поиск, версионирование, self-service для клиентов.

Ключевой урок: без чистой базы знаний ИИ бесполезен. Сначала порядок в данных – потом автоматизация.

6. Перекос затрат: почему «бесплатный ИИ» обходится в миллионы

Скрытые затраты на ИИ:

Статья затрат	Реальный масштаб для одного сотрудника
Настройка промптов и fine-tuning	5–10 часов в неделю на первых порах
Проверка результатов ИИ (галлюцинации)	2–3 часа в день, если ИИ используется активно
Апстрим инфраструктуры (GPU, API)	Счета в 2–3 раза выше плана
Обучение работе с ИИ-инструментами	От 20 часов личного времени

70% российских компаний не окупили инвестиции в ИИ. Средний срок окупаемости – 2–3 года. А вы – не компания, вы один человек. Ваше время не бесконечно.

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

Вы можете адаптировать методологии под себя, честно признать границы ИИ и научиться защищать своё время с помощью ролевых WIP limits и асинхронных ритуалов.

Через пару лет появятся новые роли («Оркестратор ИИ», «Промпт-инженер»), и нагрузка, возможно, перераспределится. А пока – держитесь и помните, что вы не обязаны быть идеальным во всех 4 ролях. Достаточно быть живым.

Автор: Svetlana_Purik

Источник

Опубликовано в Без рубрики