Тренды 2026 года

Я задумался, какие будут тренды в управлении проектами в 2026 году, и ребята из Google тоже об этом подумали и подготовили исследование. Ниже — коротко основные выводы. Более подробно можно почитать тут.

1️⃣ Рост влияния генеративного AI

2️⃣ Автоматизация PM-задач

3️⃣ Удалённая и гибридная работа становятся нормой

4️⃣ Важно развивать технические навыки

5️⃣ Эмоциональный интеллект выдвигается в плюс

6️⃣ Экологический и социальный импакт выходит на первый план

7️⃣ Рост внимания к управлению изменениями

8️⃣ Оптимизация ресурсов — приоритет организаций

9️⃣ Кибербезопасность становится критически важной

На какие мысли меня это наводит:

1️⃣ AI всему голова. Думаю, все уже поняли: нравится нам это или нет, но мы будем всё больше внедрять AI-инструменты в нашу жизнь. Спрос на менеджеров, которые умеют эффективно использовать разные инструменты, будет расти, а те, кто способен внедрять AI в процессы, будут на вес золота.

2️⃣ Гибрид и удалёнка становятся нормой, а это значит, что люди, которые умеют выстраивать работу «через экран», будут востребованы. Мне пока не до конца понятно, как это измерять и проверять, но сам тренд мне однозначно нравится.

3️⃣ Дальше очень интересны пункты 4 и 5. Нам как будто говорят: «Друг, мы хотим, чтобы твои хард-скиллы были на хорошем уровне, но будет круто, если и софт-скиллы не будут проседать». Для меня это означает, что требования к проектным менеджерам в целом будут расти. На мой взгляд, это позитивный тренд, который будет способствовать повышению компетенций в профессии.

4️⃣ Пункты 7 и 8 прямо говорят о том, что компании стали считать деньги. Мы должны быть гибкими, чтобы выжить, и эффективно использовать ресурсы, которые у нас есть. Управленцы, которые умеют мягко проводить изменения и при этом повышать эффективность, будут особенно востребованы.

5️⃣ Про кибербезопасность, думаю, всё понятно. Это важно и нужно обязательно уделять этому внимание.

Практически со всеми трендами я согласен. Единственный момент — найти управленцев, которые будут сильны хотя бы по 6 пунктам, уже на грани фантастики. Тем не менее, это хороший ориентир для развития.

💬 А какой тренд в 2026 году, по-вашему, сыграет самую важную роль?

🧑‍💻 — AI
❤️ — Удалёнка
⚡️ — Развитые харды и софты
🤝 — Эффективность
😎 — Кибербезопасность

Управление изменениями

С этой темой я плотно соприкоснулся в этом году. Я оказался по обе стороны процесса изменений — как инициатор, так и их непосредственный участник.

Сегодня хочу разобрать как раз второй случай. В рамках ИТ-подразделения у нас происходил переход со Scrum на Kanban. С моей стороны было довольно сильное сопротивление. И, что забавно, не потому что Kanban плох — по итогу он мне даже нравится больше.

Сопротивление возникло из-за того, как именно эти изменения внедрялись.

Разбираясь в теме, я наткнулся на модель ADKAR — модель индивидуальных изменений, состоящую из пяти последовательных этапов:

• Awareness — я понимаю, зачем это изменение

• Desire — я хочу участвовать

• Knowledge — я знаю, как действовать

• Ability — я умею это делать

• Reinforcement — я продолжаю так делать

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

1️⃣ Оглядываясь назад, становится понятно, откуда взялось сопротивление. Если сильно упростить: пришёл CTO и сказал, что мы работаем неэффективно, а эффективно — это Kanban. При этом никто не измерил, как мы работаем сейчас, и сразу решили внедрять новое. То есть этап «зачем?» просто пропустили.

2️⃣ Моя команда стала тестовой — на нас решили обкатать методологию. Выбора или права голоса у нас не было. Была мотивационная речь в духе Тони Робинсона «просто начните, и всё получится». Здесь был пропущен этап вовлечения.

3️⃣ Больше всех про Kanban на тот момент знал сам CTO. Команда не знала ни принципов, ни философии подхода. Обучения не было — только набор регламентов, которым нужно следовать. Соответственно, никто толком не понимал, как действовать.

4️⃣ Изменения шли тяжело и с большим количеством проблем. Любые вопросы и возражения воспринимались как сопротивление изменениям со стороны сотрудников, которые «просто не хотят работать по-новому».

5️⃣ Результаты в тестовой группе были неоднозначными, но решение о масштабировании на всю компанию всё равно приняли. Никто толком не научился работать по Kanban — но мы продолжили.

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

До сих пор непонятен эффект: нет метрик, которые бы показали, что мы стали работать эффективнее. Хотя почва для этого, кажется, уже подготовлена.

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

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

Управление изменениями. Часть 2

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

1️⃣ Чётко сформулировать, зачем нужна трансформация.
Причины могут быть разными: «текущий процесс непрозрачен для бизнеса», «сложно выявлять узкие места», «непонятно, как повысить эффективность». Важно, чтобы проблема была озвучена в явном виде.

2️⃣ Зафиксировать as is / to be и критерии успеха.
Можно было оценить производительность до начала изменений и измерить её после внедрения. Тогда появились бы понятные критерии того, что трансформация прошла успешно.

3️⃣ Презентовать изменения.
На такой встрече можно рассказать об идее, собрать обратную связь, выразить поддержку и обозначить выгоды, которые принесёт трансформация.

4️⃣ Отработать возражения — или принять их и скорректировать план.
Здесь тонкий лёд: возражения бывают как конструктивными, так и деструктивными. Мне близко правило «критикуешь — предлагай». Не «мне не нравится», а: «это не будет работать, потому что…, но вместо этого можно сделать вот так…». Споров может быть много, но важно убедиться, что изменения действительно принесут пользу.

5️⃣ Провести обучение для руководителей.
Можно даже самостоятельно провести курс лекций с разбором базовых принципов. Про Kanban, кажется, слышали все, но внутри него есть философия, которую важно понять. Без целенаправленного обучения это сделать довольно сложно.

6️⃣ Найти соратников.
Важно найти людей, которые будут гореть идеей, готовы пробовать новое и показывать реальные изменения.

7️⃣ Двигаться через маленькие победы.
Лучше идти небольшими шагами: чем короче итерации, тем лучше. Это помогает участникам увидеть пользу как можно раньше. В этом месте можно сказать, что для внедрения Kanban неплохо бы использовать Scrum)

8️⃣ Не выдавать желаемое за действительное.
Когда мы пробуем что-то новое, всегда есть риск и соблазн «подтянуть» метрики под желаемый результат. Поэтому ещё на старте важно определить критерии успеха и способы измерения, чтобы данные отражали реальную картину, а не ту, которую хочется увидеть.

9️⃣ Дать право на ошибку.
Самое важное правило. Изменения всегда связаны с неопределённостью и рисками, и здесь нужна поддержка, а не «какого чёрта вы сделали не так».

1️⃣0️⃣ Регулярно собираться и обсуждать прогресс.
Что получается, а что нет, что работает, а что стоит подкорректировать. Изменения — это живой организм: в каждой компании он уникален, и его нужно адаптировать под текущую реальность.

1️⃣1️⃣ Хвалить за успехи.
Поддержка особенно важна в период турбулентности, а изменения — это как раз он.

1️⃣2️⃣ Оценить эффект от изменений.
Если трансформация успешна — открыто показать результаты. Если нет — разобрать ошибки и понять, что было сделано не так.

Мне хочется верить, что если бы изменения шли по такому сценарию, всё прошло бы гораздо более гладко и эффективно. Но этого мы уже никогда не узнаем)

💬 А вы бы что-нибудь добавили, чтобы изменения проходили успешнее?

📚Закончил книгу Психология влияния Роберта Чалдини.

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

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

Вот 6 ключевых принципов влияния, которые описывает автор:

1️⃣ Взаимный обмен
Если нам что-то дали — мы чувствуем обязанность ответить.
Даже маленький «плюс» (помощь, подарок, внимание) резко повышает шанс согласия.

2️⃣ Последовательность и обязательства
Если человек публично или письменно с чем-то согласился, он будет стремиться быть последовательным.
Маленькое «да» → большое «да».

3️⃣ Социальное доказательство
Мы считаем правильным то, что делают другие, особенно «похожие на нас».
Отзывы, кейсы и «все так делают» часто работают сильнее логики.

4️⃣ Симпатия
Мы легче соглашаемся с теми, кто нам нравится:
— внешне
— по стилю общения

5️⃣ Авторитет
Форма, титул, статус, уверенный тон — и мы склонны подчиняться. Даже если экспертность мнимая.

6️⃣ Дефицит
То, что ограничено или «скоро закончится», кажется более ценным, даже если по факту таким не является.

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

Тот, кто понимает эти принципы, может:
- осознанно применять их в жизни и работе,
- вовремя остановить манипуляцию, направленную в его сторону.

Ещё одна мысль, которая мне особенно откликнулась: люди, которые подверглись влиянию, чаще всего активно отрицают, что на них вообще можно повлиять. Мы склонны считать себя более рациональными и «непробиваемыми», чем есть на самом деле.

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

💬 А вы считаете себя подверженными влиянию 💯 — или «со мной такое не работает» 😈?

🧌Чужой против Хищника: бизнес против ИТ

Когда я только начинал путь в ИТ, мой руководитель (CPO) не общался с руководителем разработки (CTO). Для меня это тогда было дико: два топ-менеджера, от которых зависит продукт, просто не могут договориться.

В итоге мы с ПМом разработки синхронизировались в курилке, пытаясь понять, как вообще выпуститься в срок. Забавное было время 🙃

Со временем я понял, что это не исключение, а довольно распространённая история. Во многих компаниях бизнес и разработка не умеют нормально жить друг с другом.

Немного статистики:

1️⃣ больше 50% стейкхолдеров недовольны результатом (Gartner);

2️⃣ 45% требований меняются уже после старта разработки (PMI);

3️⃣ только 1 из 3 руководителей считает взаимодействие ИТ и бизнеса эффективным (McKinsey).

Мягко говоря, так себе картина.

Почему так происходит? Где ломается взаимодействие?
Как и в любом конфликте — виноваты обе стороны.

Моё непопулярное мнение:

1️⃣ ИТ живёт в настоящем, бизнес — в будущем
Бизнес думает, как фича повлияет на метрики.
ИТ — как встроить её в систему и ничего не сломать.

2️⃣ Нет общего понимания цели
Говорят о решении, но не о проблеме.

3️⃣ Раздувание фичи

4️⃣ Изменение требований по ходу проекта

Чаще всего — всё сразу.

Типичный сценарий:

Заказчик подробно описывает фичу, добавляет детали, идеи льются рекой. Хотя по факту нужно быстро проверить одну гипотезу. Разработка, не задавая вопрос «какую проблему мы решаем», берёт задачу и называет срок.
По дороге заказчик понимает, что 80% не нужно, убирает их и добавляет «всего пару деталей». В его голове это −60% работы.
В голове разработки — половину выкинули, новые 20% сложнее старых 80%, итого +20% к объёму.
Результат — недовольны все.

Я работал по обе стороны баррикад и точно знаю: все хотят сделать хорошо.
Просто «хорошо» в этих мирах означает разное:

для бизнеса — прибыль и рост 📈

для ИТ — стабильность и надёжность 🔒

Объединять эти миры обычно должен менеджер проекта.

В следующем посте расскажу, какие есть способы это сделать.

Чужой против хищника: бизнес против ИТ. Часть 2

В предыдущем посте размышлял, почему ИТ и бизнес так часто не могут договориться друг с другом.

А сейчас хочу пофантазировать о том, что вообще нужно, чтобы это взаимодействие стало эффективным, а не «мы опять не поняли друг друга».

1️⃣ Диалог

Звучит банально, но про это регулярно забывают.
Наладить диалог зачастую важнее и сложнее, чем выстроить процессы, регламенты и диаграммы. Пока люди не разговаривают — никакие фреймворки не спасут.

2️⃣ Взаимное уважение

Мы не обесцениваем работу друг друга и признаём её важность.
ИТ без бизнеса не имеет смысла, как бизнес без ИТ.
Как только одна из сторон начинает считать себя «главнее», всё ломается.

3️⃣ Сначала Discovery, потом Delivery

Любую гипотезу перед реализацией нужно проверять.
Минимальными усилиями, быстро, без строительства замка из кода.
Сначала проверяем, что это вообще нужно, а уже потом делаем полноценную фичу.

4️⃣ Регулярная обратная связь

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

5️⃣ Прозрачное ведение проекта

Самый сложный пункт, потому что он про доверие.
Про умение открыто говорить о проблемах, ожиданиях и рисках.
Тут уже не «заказчик — исполнитель», а партнёрство.

Жена еще сказала, что можно просто жениться и не париться. Но это, как говорится, на любителя🙃

Резюмируя:
Чтобы между ИТ и бизнесом были рабочие отношения, в этом должны быть заинтересованы обе стороны.
Все должны понимать, что работают на одну цель, и быть готовыми вкладываться в диалог и доверие.

Как и в любом конфликте: если хотя бы одна сторона не готова разговаривать — ничего не получится.

💬 А у вас в компании налажено взаимодействие бизнеса и ИТ?

🔥 - да, все гуд
😭 - никак не можем договориться
😈 - послушаю лучше совета твоей жены

Эта картинка напомнила мне себя пару лет назад.

Так вышло, что я совмещал роли ПМа и ТЛ. Команда только строилась, процессы были, мягко говоря, не идеальны, и иногда это приводило к техническим сбоям.

Должен признаться: техничка — точно не моя сильная сторона, а на тот момент тем более.
Но я был ТЛ и ПМом, а значит — нёс ответственность за команду и нужно было принимать сложные решения.

Прекрасно помню моменты, когда девопсы спрашивают:
— Что будем делать?

А я в душе не ебу представить не мог, но ситуацию нужно исправлять — и быстро.

Возможно, кто-то из вас с этим столкнётся в будущем. Вот что можно сделать, чтобы принять адекватное решение.

Если вы не понимаете, что происходит:

1️⃣ Привлекайте команду

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

2️⃣ Включайте логику

Узнайте: когда начались проблемы, был ли в это время релиз (у вас или у соседней команды), были ли изменения в инфраструктуре или сети.
Ищите закономерности. Случайности случаются редко.

3️⃣ Смотрите на графики

Надеюсь, они у вас есть)
Если проблему не удаётся быстро идентифицировать — логи и графики ваши лучшие друзья.
Ищите отклонения и возвращайтесь к п.2.

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

4️⃣ Перезагрузка

Если можно что-то безопасно перезапустить — попробуйте. Иногда решение гораздо проще, чем кажется.

5️⃣ Думайте наперёд

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

6️⃣ Сомнительно, но окей

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

Редкий случай. Использовать осторожно. Не является инвестиционной рекомендацией.

Мораль:

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

P.S.
Обязательно — и ещё раз обязательно — после инцидента:
• разобраться, почему он произошёл;
• сформировать план, как этого избежать в будущем;
• внедрить изменения.

Без этого такие ситуации станут вашей реальностью.

💬 А вы как часто оказывались в подобных ситуациях?
Что ещё, по вашему опыту, стоит делать?