ИИ не спасёт. Российские кейсы, цифры и методы выживания.
Контекст 2024-2025 – уже не просто делать быстрее, а делать так, чтобы один PM заменял аналитика, тестировщика и частично DevOps. ИИ не снял нагрузку, а перераспределил её.
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 ролях. Достаточно быть живым.
