Причины провалов ваших проектов, нездоровая коммуникация в команде, изменения в PMBOK, матрица Эйзенхауэра, ИИ-камуфляж и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Расширенные дайджесты, новости, обзоры книг и курсов для РП и аналитиков — в моем канале «Проектный дайджест», а теперь ещё и в удобной базе знаний, где я собрал уже почти 1900 статей по управлению проектами — с резюме, тегами и даже pdf‑ками.

Основы, гайды и инструменты

PMBOK 8. Что изменилось?

Автор делает обзор ожидаемых изменений в PMBOK 8 и показывает, что развитие стандарта все дальше уходит от жестких "процессных списков" к более гибкому, принципиальному и контекстному взгляду на управление проектами. В центре внимания оказываются не только артефакты и процедуры, но и адаптация подхода под среду, работу с ценностью, неопределенностью и реальными потребностями команды и организации. Материал помогает понять общий вектор и то, что стандарт становится все больше про способность осмысленно управлять сложностью.

Матрица Эйзенхауэра в корпоративной системе: почему не работает и что делать

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

Системы управления ИТ-проектами: подборка российских решений 2026

Ииииии очередной обзор российского ландшафта систем управления проектами. В этот раз с упором на то, что выбирать инструмент нужно по зрелости процессов, требованиям к безопасности, гибкости настройки, интеграциям и масштабу команды. Автор сравнивает решения по типовым сценариям использования: где важнее классический проектный контур, где нужна тесная связка с ITSM/ESM, а где критичны кастомизация, права доступа или on-prem.В главных ролях: SimpleOne SDLC (по случайному совпадению - авторы обзора), Битрикс24, ADVANTA, Kaiten, Weeek, YouGile и другие.

Зачем командам разработки и QA концепция DoR и DoD, и как не превратить ее в бюрократию

Три аббревиатуры в названии - это про сущности, которые часто смешивают: критерии приемки отвечают на вопрос, что именно должно уметь решение, а DoR и DoD - в каком состоянии задача может войти в работу и считаться завершенной. Польза от DoR/DoD - синхронизации ожиданий между аналитиками, разработкой, тестированием и бизнесом: меньше потерянных деталей в чатах, меньше двусмысленности, меньше сдвигов сроков из-за внезапно всплывших уточнений.

Петля на шее: почему фидбек душит проект и как это остановить

О ситуации, когда обратная связь из полезного инструмента превращается в бесконечный тормоз (узнали? согласны?). Замечаний становится слишком много, а еще и поступают они слишком поздно, не имеют общего приоритета и фактически не помогают двигаться к результату. Ну и проект начинает задыхаться - команда все время что-то дорабатывает, но ощущение прогресса исчезает. Резюме: фидбек должен быть встроен в ритм проекта, привязан к конкретным критериям и окнам обсуждения, а не наваливаться хаотично со всех сторон.

На что обращать внимание бизнес-аналитику при подготовке требований

Коллеги из ЛАНИТ предлагает смотреть на требования не как на "текст для согласования", а как на рабочий инструмент для разных аудиторий: бизнеса, разработчиков, тестировщиков, архитекторов. Отсюда важность не только пресловутых полноты и логики, но и проверяемости, отсутствие двусмысленности, явные ограничения, примеры сценариев и связь с целями изменения. Короче, хорошие требования экономят время дальше по цепочке, а плохие просто перекладывают издержки на разработку, тестирование и согласования.

Как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось

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

Почему проваливаются проекты? 5 столпов, на которых держится успех

“Магнит” раскладывает успешный проект не на “магические качества сильного РП”, а на набор опор: понятная цель, работа с ожиданиями, прозрачная коммуникация, дисциплина исполнения и способность адаптироваться по мере изменений. Когда одна из этих опор проседает, проект еще может выглядеть живым, но начинает разрушаться изнутри - через конфликт интерпретаций, потерю доверия, накопление скрытых проблем и т.д.

Техническое задание – что это и для кого

Текст возвращает ТЗ к его базовой функции: это не "бумага для галочки", а договоренность между участниками о том, что именно создается, в каких границах, с какими условиями и по каким критериям можно понять, что работа выполнена правильно. ТЗ нужно разным людям по-разному: заказчику - чтобы зафиксировать ожидания, исполнителю - чтобы понимать объем и ограничения, тестированию - чтобы проверять ��езультат, а менеджменту - чтобы управлять сроками и рисками. Хорошее ТЗ, по сути, снижает цену всех последующих споров, потому что убирает двусмысленность раньше, чем она превратится в конфликт.

Стратегия в условиях неопределенности: как планировать развитие

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

Business Model Canvas: что такое модель Остервальдера, шаблоны и примеры

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

Менеджер проекта — карьера и навыки

Создатели, менеджеры и люди процесса. Кто на самом деле двигает продукт

Автор делит участников продуктовой организации на три группы: создатели делают продукт руками и головой, менеджеры растят и усиливают этих людей, а "люди процесса" отвечают за ритуалы, стандарты и фреймворки. Главная мысль в том, что процесс сам по себе не зло, но в больших компаниях он слишком легко превращается в самоцель и начинает жить отдельной жизнью, подменяя лидерство и ответственность формальными правилами. Особенно интересно разобран “Product Ops”: если он снимает административную боль и помогает продактам больше времени тратить на клиентов и аналитику, это усиливает команду; а вот если его задача - просто насаждать правильный процесс, значит, организация, скорее всего, лечит не ту проблему.

ИИ не делает вас лучше как лидера. Зато сэкономит часы на рутине - опыт 4 руководителей

Kaiten собрал практические кейсы четырех руководителей и показывает интересную картину: ИИ сильнее всего помогает не в стратегии и лидерстве, а в рутине - отчетах, метриках, протоколах встреч, инструкциях, резюме интервью и предварительном анализе данных из таск-трекеров. Освобожденное время можно направить на управленческое мышление, но сами решения, приоритеты и интерпретации никто с человека не снимает. ИИ не делает вас глубже, мудрее или сильнее как лидера, но действительно дает ощутимую экономию времени, если использовать его как помощника и обязательно проверять ответы на галлюцинации и смысловые промахи.

Почему жесткий тайм-менеджмент больше не работает

Текст критикует тотальный таймбоксинг, когда весь день нарезан на плотные слоты без воздуха и запаса, и объясняет, почему такой подход так соблазнителен: мозг любит иллюзию контроля и награждает нас уже на этапе красивого планирования. В статье это названо "дофаминовым авансом" - ощущением, будто работа уже сделана, хотя реально мы всего лишь аккуратно заполнили календарь. В итоге жесткий тайм-менеджмент нередко становится легализованной прокрастинацией: человек чувствует себя организованным, но при первом же отклонении реальности начинает сыпаться и терять не только план, но и ощущение управляемости.

Уволить 40% штата из-за ИИ: как плохой менеджмент прячут за красивыми технологиями

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

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

Выстраданный текст о том, как перфекционизм и привычка держать все под контролем не исчезают при переходе из разработки в менеджмент, а просто находят новую форму: процессы, коммуникации, онбординг, ретроспективы, формулировки задач, встречи 1-1. Хороший менеджер действительно должен заботиться о понятности, ритме и качестве работы команды, но если не понять, где можно ослабить контроль, эта забота начинает пожирать самого руководителя. в целом, менеджерское выгорание часто рождается не из безразличия, а как раз из гиперответственности и постоянной внутренней проверки, "достаточно ли хорошо все устроено".

ИТ-лидер в финтехе: не менеджер, а "операционный центр" кросс-функциональной команды

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

Команда проекта

Новая норма ИТ-команд: недоговаривать

Автор описывает распространенную проблему "дефицита внимания" как, увы, скрытую норму рабочих отношений. Руководители недообъясняют, коллеги достраивают смысл сами, а команда тратит силы уже не на решение задачи, а на интерпретацию того, "что на самом деле имелось в виду". В итоге информационный вакуум быстро превращается в демотивацию, подозрения и токсик-вайб. Причем все это особо не поменять - недосказанность в командах никуда не денется, поэтому сотруднику важно уметь распознавать этот вакуум, а руководителю - не просто раздавать задачи, а наполнять их смыслом и объяснять контекст, иначе энергия коллектива уходит в догадки вместо работы.

Ричард Гельдрейх из Valve о работе в геймдеве и корпоративной культуре. Часть 1

Если вы, как и я, мечтали работать в компаниях а-ля Вальв, то вот можно почитать этот перевод откровенного текста Ричарда Гельдрейха о "самоорганизующихся" компаниях, где внешняя свобода и культ гениальности легко маскируют внутренние игры, манипуляции и неочевидные механизмы власти. Автор буквально пишет учебник по выживанию: надо быть осторожнее с корпоративным маркетингом, не раскрывать работодателю лишнюю личную информацию и не путать красивый образ компании с качеством среды. Потому что за фасадом "плоской структуры" может скрываться не взрослая автономия, а довольно токсичная борьба без явных правил и ответственности.

"Прикинься шлангом и не высовывайся": главное правило работы в системе

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

Как за неделю собрать курс для отдела поддержки по базе знаний компании

У многих компаний уже есть все нужное для быстрого обучения - статьи в базе знаний, рабочие инструкции, CRM или клиентская система, - но нет упакованного курса. Статья как раз о том, как превратить существующий контент в учебный контур без долгой методической стройки: взять готовые статьи, связать их в последовательность, добавить тесты, дедлайны, статусы прохождения и получить рабочий онбординг почти без переписывания материалов. Самое полезное - обучение подается не как отдельный "большой проект", а как способ быстро капитализировать уже накопленные знания компании и перестать каждый раз объяснять одно и то же вручную.

Почему Крош становится тимлидом, а Нюша выгорает: психология привязанности в ИТ-командах

Автор переносит теорию типов привязанности в профессиональную среду и показывает, как эмоциональная устойчивость, реакция на фидбек, отношение к дистанции и потребность в одобрении влияют на карьеру в ИТ едва ли не сильнее, чем техническая глубина. Надежный тип легче выдерживает обратную связь, конфликты и рост ответственности, поэтому чаще естественно дорастает до лидских ролей; тревожный и избегающий типы по-разному уязвимы к перегрузке, неопределенности и выгоранию. Короче, не все проблемы сотрудников решаются советом "будь увереннее", потому что за их рабочим поведением часто стоит более глубокий эмоциональный паттерн.

Как давление ожиданий ломает коммуникации в команде

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

Системный аналитик в эпоху ChatGPT: эволюция или революция

Одна из самых практичных статей в подборке: автор не спорит, заменит ли ИИ аналитика (гм…), а прямо показывает, что именно модели уже умеют делать хорошо - черновики требований, user stories, структурирование интервью, поиск противоречий, прототипы диаграмм и API-описаний. Но главный тезис не в автоматизации, а в смещении роли: аналитик все меньше "писатель документов" и все больше редактор, валидатор, синтезатор контекста и проектировщик процессов в команде.

Управление проектами: дайджест публикаций #51