Тренды 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.
Обязательно — и ещё раз обязательно — после инцидента:
• разобраться, почему он произошёл;
• сформировать план, как этого избежать в будущем;
• внедрить изменения.

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

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

Матрица рисков 💣

Как-то я быстро забросил постоянные рубрики — исправляюсь.

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

В прошлом году я пошёл повышать квалификацию по «Управлению проектами», и там мне наконец показали матрицу рисков, которую реально удобно применять.

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

Логичный вопрос — зачем это вообще нужно?

Часто слышу мнение: «С очевидными рисками мы и так знаем, что делать, а остальные всё равно не предскажем».
И это правда для типовых проектов. Но если проект новый или отличается от привычных — матрица рисков становится отличным помощником.

Основные элементы матрицы:

1️⃣ Рисковое событие — событие, которое может оказать негативное или позитивное влияние на проект.

2️⃣ Причина риска — почему это событие может произойти. Иногда эффективнее работать с причиной, а не с самим риском.

3️⃣ Последствия — влияние риска на проект, обычно оценивается через сроки и стоимость.

4️⃣ Уровень влияния — оценка от 1 до 6, где 1 — незначительное влияние, 6 — угроза срыва проекта.

5️⃣ Вероятность возникновения — оценка от 1 до 6, где 1 — менее 5%, 6 — более 90%.

6️⃣ Уровень риска — произведение влияния и вероятности для сравнения рисков между собой.

7️⃣ Проактивный план — действия до наступления риска для его предотвращения или снижения влияния/вероятности.

8️⃣ Пассивный план — действия на случай, если риск реализуется (желательно несколько сценариев).

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

Как с ней работать:

1️⃣ Соберите максимум рисков (подключайте команду, заказчика, используйте GPT)
2️⃣ Оцените влияние и вероятность
3️⃣Перемножьте и отранжируйте — риски с высоким значением попадают в красную зону
4️⃣ В первую очередь проработайте планы для красной зоны
5️⃣ Выберите стратегию и начинайте действовать по проактивному плану

Какими бы мы ни были профессиональны, держать всё в голове невозможно. Матрица рисков помогает структурно подумать, зафиксировать и заранее закрыть до 90% проблем ещё на старте проекта — а значит, заметно повысить шансы на успех.

Кстати, в жизни она тоже отлично работает — например, при планировании отпуска или ремонта.

Дарю мой шаблон матрицы рисков

💬А как вы работаете с рисками?

#а_что_по_инструментам

Неидеальность 🩹

Читая каналы некоторых коллег, я часто замечаю, как красиво и уверенно они рассказывают про крутые практики, которые используют в работе.

Но по факту часть этих примеров сильно приукрашена, а иногда и вовсе не соответствует действительности.

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

Проблема начинается, когда ты постоянно читаешь про «идеальные практики» и успешный успех. В какой-то момент ловишь себя на мысли:
«Вокруг все такие умные и успешные, а со мной что-то не так».

Спешу успокоить, и с вами, и со мной всё нормально. Просто чаще всего люди показывают только хорошую сторону медали.

Мне хочется показать и другую. Мой личный топ неидеальностей:

1️⃣ Поставленная речь
Когда я нервничаю, слова-паразиты становятся моими лучшими друзьями, а мысли — кашей. Очков в общении с заказчиками это не добавляет.

2️⃣ Навыки презентации
Частично продолжение пункта выше — из-за волнения сложно чётко и эффектно доносить мысли.

3️⃣ Тайм-менеджмент
Я почти не организую своё время. Календарь есть, но его мало. Ведь дел, которые не успеваю, ещё больше — и это жёстко фрустрирует.

4️⃣ Внимание
Я ограничил соцсети до 30 минут, но всё равно регулярно отвлекаюсь на них или игры вместо важных дел.

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

Делает ли это меня плохим? Однозначно нет. Это лишь говорит о том, что я живой человек со своим списком неидеальностей.

💬 А какие неидеальности есть у вас?

🚀 - я идеален/идеальна
✍️ - есть куда развиваться

Сериал «Внедрение нового проектного инструмента»

В начале года я писал о внедрении изменений и о том, что было сделано не так.

Не прошло и месяца, как мне выпал шанс самому внедрить новый инструмент в рамках компании. Предлагаю вам пройти этот путь вместе со мной.

Можете глянуть предыдущий пост — там я всё красиво разложил по полочкам. Забавно, что написал я все красиво, а на практике все равно совершил несколько ошибок.

Что за инструмент

Внедрение удобного инструмента визуализации проектов в контуре компании или в простонародье графика Ганта.

Что уже сделано:

1️⃣ Определил, зачем нужна трансформация

Нет единого удобного инструмента визуализации проектов и их зависимостей.

2️⃣Зафиксировал AS IS / TO BE и критерии успеха

AS IS:
Руководители используют либо технически сложный Гант, который трудно поддерживать, либо Excel, который у всех лежит локально, а это непрозрачно для руководства.

TO BE:
• Все руководители используют новый Гант и умеют с ним работать.
• Ганты разных команд синхронизируются между собой.
• Проведено обучение по использованию нового инструмента.
• У руководства и стейкхолдеров есть доступ к Ганту для отслеживания прогресса по проектам.

3️⃣ Нашел единомышленников

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

Я взял одного такого смельчака и попробовал продать ему свой Гант. Успешно.
Мы обсудили, что он закрывает большинство текущих запросов, при этом остаётся достаточно простым и визуально понятным.

4️⃣ Продал руководству

Когда есть проблема, понятный запрос и обратная связь от коллег, продавать такие решения становится сильно проще.

5️⃣ Провел тестовый запуск

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

И здесь я допустил ошибку:

Я не презентовал изменения полноценно с объяснением причин, критериев успеха и плана действий, а сразу попросил руководителей команд привести свои проекты к нужному виду, чтобы запуск прошёл гладко.

Планирую исправиться и после этого этапа нормально презентовать все изменения фокус группе.

Пока я в этой точке.

Продолжение — в следующих сериях.

💬 Какой, на ваш взгляд, должен быть следующий этап?