«Введение в управление проектами внедрения ERP-систем» А. Э. Бобровников (2-е издание).

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

Автор вроде бы опытный методист, теорией не перегружает, говорит на языке бизнеса. В книге по верхам собрано всё: от оценки сроков и бюджета до управления конфликтами и рисками. Акцент сделан на практику внедрения ERP на платформе «1С:ERP».

🔹ЦА книги - это заказчик системы. А поскольку ассоциация 1С с продуктами для регламентированного учета всё ещё актуальнее других, отдельная глава посвящена тому, чем ERP-система отличается от системы для бухучёта (и почему она такая дорогая🌚).

Дальше - про стартовый этап проекта:
🔹про функциональные требования и их сбор, у кого и как собирать, в каком формате
🔹про выбор подрядчика (тендер) и этапы RFI, RFP, RFQ (если кто не знал, что это)
🔹про fit-gap-анализ (в среде 1С это зовут еще выявлением функциональных разрывов)
🔹и об оценке IT-инфраструктуры, включая нагрузочное тестирование, и расчет окупаемости.

🔹Сам процесс внедрения может идти по принятым подходам (PMBOK, ISO, ГОСТ 34, Agile), а может и по фирменным методикам 1С (ТБР и т.д.). Стандартная модель - каскадная: инициация → анализ → проектирование → разработка → тестирование → ввод в эксплуатацию. Акцент на важности реинжиниринга бизнес-процессов (чтобы не автоматизировать хаос).

🔹Отдельная глава - про стороны проекта внедрения. Команда исполнителя (внедренцы, методисты, разработчики), рабочая группа заказчика (ключевые пользователи), управляющий комитет (топы, принимающие решения).Само собой, говорится про важность мотивации, коммуникации и командообразования — иначе всё развалится.

🔹Документация - тут всё очень кратко, в основном про использование бизнес-нотаций (IDEF0, BPMN, EPC) и прототипирование.

🔹Говоря про сроки и бюджет, автор касается методов оценок (аналогия, экспертная, PERT, «сверху вниз» и «снизу вверх») и вспоминает классику - «мифический человеко-час», ошибки планирования, скрытые доработки. Отдельная глава - про управление рисками, про типовые риски (текучка кадров, ошибки ТЗ, сопротивление пользователей), управление|борьбу с ними.

🔹По разработке и вводу в эксплуатацию - акценты на использовании нескольких контуров или баз (тестовая, рабочая и даже “грязевая” для экспериментов), и конечно же, на важности обучения пользователей и сбору обратной связи
Ну и “жизнь после смерти” - собственно, перевод проекта на стадию поддержки и сопровождения, поддержка пользователей и развитие системы.

▶️Из интересного: второе издание книги оказалось стереотипным, т.е. перепечаткой с первого издания 2021 года. Конечно, хотелось бы обновлений - уж столько поменялось и в самих ИС, и в российском контексте их внедрения, - но, похоже, что у фирмы 1С всё хорошо и без этого и книга - своего рода стандарт.

▶️Кому рекомендую: прежде всего, тем, кто готовится на роль ПМа в проектах 1С, особенно идущим на собесы, - идеальный конспект идеального внедрения (пусть его и не существует). Особенно в сочетании с одностраничными планами (приложил пример, который лично мне нравится больше других). Ну и тем, кто хочет слегка систематизировать проектный опыт.

🙋‍♀️ На "замедленном" Youtube вышла новая подборка видео от команды SQA ANALYST с полей XIX конфы по системному и бизнес-анализу.

Да, там больше для BA и SA😐, но в целом, думаю, что многим из нас будет очень интересно.

Выбрал наиболее близкие к теме и просто хорошие:

▶️ В чем смысл цели? - про практику использования адаптированного инструмента ХМатрица, который помогает видеть смысл цели, способ достижения и оценивать результат.

▶️Проектировочная документация - практический опыт и проверенные шаблоны
"О практическом подходе к ведению проектной документации в компании, без углубления в теоретические детали. Поделюсь шаблонами постановок и правилами работы с документацией"

▶️Мир канвасов - какие канвасы и когда применять, как можно использовать канвасы в работе аналитика.

▶️Модели личности — основа для успешной коммуникации и развития - модели softskill позволяют понять, как думают и действуют другие люди, которые на тебя непохожи. Модели также помогают взглянуть на себя со стороны, оценить потенциал своего развития.

▶️Куда приводит Discovery. Как работать с неопределенностью - В Discovery-фазе проекта мы, зачастую, сталкиваемся с такой степенью неопределенности, которая ставит бизнес-аналитика в сложное положение. Мы собираем требования и ожидаем, что какие-то области нам прояснят продукт менеджер или маркетолог. Но что, если этих специалистов на горизонте нет?

▶️Максим Шаломович, Евгений Асламов, Event storming. Способы применения

▶️«Коллеги, я отключаюсь, у меня следующий созвон», или руководство по выживанию в мире встреч

▶️«Достучаться до небес»: 7 способов, как убедить стейкхолдера и улучшить продукт. Кейсы из практики

▶️Объединять и развивать: игровые методики в развитии и объединении команды

▶️Управление требованиями в масштабных проектах

▶️Разные проекты — разные подходы: как системным аналитикам адаптировать свои инструменты и методы

🔥 Самые интересные материалы по управлению проектами за 2 недели
😾Основы, гайды, кейсы (ч.1)

🐱 Как составить карту стейкхолдеров

Сталкивались с ситуацией, когда передали проект, а кто там и о чем - не сказали?) Текст - о том, как с помощью карты заинтересованных сторон понять, кто влияет на решение и чьё мнение критично для хода проекта. В основу авторы взяли простую схему с зонами влияния и интереса, которая помогает не забыть «невидимых» участников и заранее выстроить с ними отношения. Типовые случаи применения (запуск продукта, выход на рынок, сложные корпоративные внедрения) и пошаговые инструкции прилагаются. Плюс рекомендуется регулярно обновлять карту по фазам проекта, чтобы коммуникация всегда была «в тонусе».

🐱Исследование показало, Agile-проекты проваливаются на 268% чаще

Пересказ результатов опроса инженеров в США и Великобритании - и внезапно у англосаксов гибкие проекты чаще сходят с дистанции, и наоборот, чётко зафиксированные ожидания повышают вероятность успеха. Однако не всё так просто, и хвала автору, что замечает это - во втором случае респондентам явно нравится не собственно waterfall, а связь с реальной большой проблемой и психологическая безопасность команды (все знают, куда идти и как долго идти). В общем, думайте…

😺 Карта эмпатии: как понять клиента и составить рабочую схему

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

😼Управление проектами: чек-лист для порядка

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

🐈Ради чего люди ходят на работу? Пять типов мотивации по Герчикову

Кто-то знает, кто-то не знает, но это довольно известная типология мотивации сотрудников (инструментальная, профессиональная, патриотическая, «хозяйская» и избегательная). Для каждого типа - на что “жать”/ как вовлекать и что демотивирует, с учетом, что чистые типы - это абстракция, а чаще всего типы смешаны. Короче, торты пряники и кнуты нужно дифференцировать по типу личности.

🐈‍⬛ 30+ мессенджеров под разные бизнес-задачи. Чем заменить Teams, Slack и Jabber?

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

🐱 Делегирование без боли: как передавать задачи, чтобы их не возвращали обратно

Эссе о том, почему постановка «сделай вот так, как я бы сделал» ломает и людей, и сроки (потому что убивает инициативу и превращает лидера в «бутылочное горлышко»). А как надо? Автор предлагает схему: дать контекст задачи (зачем это нужно бизнесу), обрисовать ожидаемый результат (что именно должно быть на выходе) и дать свободу способов исполнения. (Там сложнее, еще договариваться о критериях приёмки, промежуточной демонстрации и тд, но в целом норм).

🔥 Самые интересные материалы по управлению проектами за 2 недели
Основы, гайды, кейсы (ч.2)


🐱 Как фанфик по Гарри Поттеру стал лучшей книгой по рациональному мышлению для программистов

Да, вот так вот - материал про легендарный фанфик про ГП (а какие фанфики читаете вы, мы знаем). Коротко - про полезные приемы типа: обновления гипотез по мере появления данных, борьбы с искажениями мышления, силы экспериментов. Отдельно подчёркивается важность различать совпадение и причинно-следственную связь при разборе инцидентов. В целом - учимся сами и учим команду сомневаться в первых объяснениях, проверять альтернативы и фиксировать, что именно привело к улучшению (или ухудшению). 

🐱 Jira для управления тестовыми проектами: советы по организации работы и документированию

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

🐈 Парадокс Джевонса и «эффект Черномырдина» ИТ проектов: как оптимизация приводит к катастрофе

О том, как улучшение отдельного узла системы может усилить нагрузку на весь поток и обернуться падением качества. Парадокс Джевонса - это когда повышение эффективности увеличивает потребление ресурса. В проектах это проявляется как «успели больше — на нас свалили ещё». (ну и что-то напоминающее «хотели как лучше, а получилось как всегда»). 

🐱 Разработка и управление требованиями
Систематизация работы с требованиями: от постановки цели и границ до формулировок, сценариев и критериев приёмки. Отдельный акцент - на свойства «качественного требования»: однозначность, проверяемость, осуществимость, связность с другими, на ведение единой структуры артефактов, прослеживаемость от задачи до результата и порядок изменения требований с оценкой влияния.

🐱 Почему ваше проектное управление никогда не будет работать
Автор разбирает типичные иллюзии: попытку заменить ясные цели количеством совещаний, надежду «урегулировать» неопределённость регламентами и веру в «срок из воздуха». Корни сбоев — отсутствие понятного результата для пользователя, несогласованные приоритеты и слабая ответственность за решение. Что делать? Вести единый список работ, делать открытые критерии «готово», ограничить параллельность и регулярно проверять пользу.

😺 Маленькое эссе о техдолге

Эссе напоминает: технический долг — это сознательное заимствование времени (“по-быренькому” залатаем), за которое мы потом платим ростом сложности и рисков. И опасность не в самом долге, а в том, что о нём забывают и не закладывают погашение. Что предлагает автор - вести явный реестр долгов, оценивать «процентов» (во что выливаются задержки и ошибки) и плановую долю времени на возврат. 

🐱 Kaiten после 7 лет в Jira: рассказываю про свой опыт

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

🔥 Самые интересные материалы по управлению проектами за 2 недели
😸#Менеджер проекта - карьера и навыки (ч.1)

😹Почему люди слышат не то, что вы говорите?
Простая, но важная статья - автор через личные кейсы показывает, как один и тот же разговор по-разному воспринимают люди с разным опытом и настроем. Даже такие вещи, как непривычная пунктуация, отсутствие смайликов, перекос в акцентах или «оценка результативности» без контекста порождают стресс и ошибочные выводы. Что делать? Проверять понимание («как ты это понял?»), подбирать подачу под адресата и не заменять смысл риторикой. Эмпатия и регулярные встречи один на один снижают шум в коммуникации и предотвращают накопление обид. 

😼Начальник контролировал всё: ввел отчеты по часам, просил скрин экрана и считал походы в туалет
Ух, мощная статья - сама по себе и по собранным комментариям. На примерах разбираются бессмысленные форматы отчётности: «таблицы по часам», всеобщие видеосовещания-пересказы, «видеодневники» и внезапные требования «срочно отчитаться». Ну и рецепты “как правильно” - вместо тотального контроля прозрачность по данным: сводки задач в трекере, короткие рабочие созвоны, редкие показы результатов и отчёты, собранные автоматически. Отчётность «ради формы» подменяет работу, усиливает ошибки и ведёт к выгоранию. 

🙀Почему управлять людьми сложнее, чем писать код
Код предсказуем, а люди — нет: у сотрудников есть эмоции, личные обстоятельства и разные трактовки «готово». Автор подчёркивает важность бережной обратной связи, личных встреч и проговаривания очевидных вещей — иначе «сделано» для разных ролей значит разное. Конфликты и выгорание замечают раньше, если есть доверие и регулярный контакт, а критику подают лично и конкретно. Короче, надо менять фокус с инструментов на культуру и состояние команды.

😿«Генералы», «Цезари» и «Псевдоэксперты»: как договориться со сложным заказчиком
Что-то вроде практической типологии трудных клиентов: «вечно недовольный», «генерал», «цезарь», «истерик» и «скрытая угроза» — с признаками и рабочими тактиками. Советы варьируются от переговоров «через равных по статусу» и апелляции к нормам — до «двойной фиксации» договорённостей и аккуратного перевода решения в «его идею». 

😾Про IT в 2025 году
Нужная статья, хоть и не про менеджмент. Автор трезво описывает перекосы рынка, в котором мы с вами работаем: избыток новичков, слабое качество при завышенных ожиданиях и ужесточение отбора компаниями. Прогноз — больше очных собеседований, тщательная проверка резюме (привет, волки и чатгпт) и возврат к внутреннему росту из поддержки и начальных ролей. Параллельно усиливается кризис среднего возраста у опытных специалистов и эйджизм, но бизнесу всё равно придётся «вспомнить ценность экспертизы». 

😺Про роль тимлида, а также несколько простых и полезных советов
Статья в каком-то смысле приземляет роль тимлида: это не «суперразработчик» и не «психотерапевт на полставки», а человек, который ведёт команду к результату. Его задача - понятные договорённости, распределение ответственности, регулярная обратная связь и защита времени на разработку. Не надо героизма, в общем)

😻Памятка менеджеру: Запрещённые фразы в IT. Часть 2
Автор разбирает ещё две «токсичные» фразы, которые портят отношения с заказчиком и командой и демонстрируют беспомощность и нежелание управлять. Вместо них предлагается использовать более уместный язык: уточнение контекста, предложение вариантов и договорённость о следующем шаге. И вообще, в статье много приземлённых формулировок, которые помогают выходить из тупиков на встречах.

🔥 Самые интересные материалы по управлению проектами за 2 недели

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

🇨🇦 Как правильно вести учёт рабочего времени
Коллеги из weeek объясняют, что учёт времени - не про слежку, большого брата и просмотр камер, а про планирование и выравнивание нагрузки. Отсюда и роли ответственных (кадровая служба, администраторы систем, руководители направлений и руководители проектов), основные форматы учёта (по дням, по задачам и др.) и как выбирать их под тип работ. Есть критерии выбора инструмента: простота фиксации, отчёты по людям и задачам, связка с задачником и календарями.

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

🫧 Сотрудник «буддист»: анализ уязвимостей и краткий мануал для руководителя
Буддист - это тип сотрудника, который внешне спокоен и не вступает в конфликты, но легко уходит в пассивное сопротивление. Главные риски с таким товарищем - размытые договорённости, отсутствие явных сроков и надежда на «само как-нибудь сложится». А способ работы с ним - это максимальная точность целей, результатов, критериев и т.д.

🤕 Как создать самообучающуюся команду: рабочие инструменты, способы мотивации и чек-лист
Статья собирает практику постоянного обучения прямо в потоке работы. Тут и короткие разборы ошибок, и обмен знаниями, и наставничество, и «малые эксперименты». Важно создать цикл «заметили -попробовали - измерили - внедрили», только так обучение даёт результат, а не копит презентации.

😩 Пять паттернов поведения: где у команды «кнопки» и почему люди выгорают?
Автор выделяет пять устойчивых моделей реакции людей на неопределённость, от «око за око» до рационалистского поиска правил, - и показывает, как каждая ведёт к напряжению и усталости. Один и тот же управленческий приём вызывает разную реакцию в зависимости от паттерна. А значит, надо подбирать подачу: кому-то нужны чёткие границы, кому-то — поддержка, кому-то — логика и правила.

😠 Как за один слайд увидеть, кого в команду нанимать, кого учить, а что перестать делать
Что-то вроде простой «карты выбора» на один слайд: ценность задачи для цели × способность команды выполнить её сейчас. В одном поле карты нанимаем, в другом - учим своих, в третьем - отказываемся или откладываем. Инструмент снимает «хотелки» и возвращает обсуждение найма к пользе и возможности. Результат - меньше распыления и понятная стратегия роста компетенций.

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

🤟 Как одновременно заонбордить три новые команды
Реальный опыт одновременной адаптации трёх команд. Что помогло - так это единая программа, наставники, база знаний и календарь первых недель. И если вы сделали общие правила постановки задач и одинаковые критерии «готово», то и кривотолков и недопониманий будет меньше. В качестве метрик смотрим на скорость выхода на самостоятельные задачи и долю блокеров на каждом шаге.

✅И напомню, что все дайджесты, с тегами, рубриками, ссылками и даже pdf - тут.

🔥 Самые интересные материалы по управлению проектами за 2 недели

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

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

😃От раздражителя к гению: работает ли знаменитый подход Патрика Ленсиони в IT?
Авторы потестили модель “шести гениев” Ленсиони, разложив работу на этапы (задумка, изобретение, оценка, гальванизация, поддержка, доводка), отметили у себя зоны “гения”, “навыка” и “раздражителя”, а затем обсудили, как это проявляется в повседневных процессах внутри команды. А проявляется в виде общего словаря для быстрой коммуникации более осознанный найм и ротацию внутри команды (типа надо,чтобы сотрудник как раз был в зоне “гения”).

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

🍕 Симулятор команды — вместо десятка ретроспектив
В Dodo придумали простую игру. Суть - участники команды временно меняются ролями и на практике отыгрывают работу коллег, решая реальные кейсы в ускоренном игровом формате.Игра длится несколько условных рабочих дней, каждый день состоит из короткого митинга и двухминутной “работы”. Участники тянут задачи из бэклога, распределяют их и придумывают, как бы выполнили их в роли коллеги. После нескольких итераций команда подводит итоги и делится инсайтами. Главная цель - прочувствовать “эффект кресла”, то есть увидеть трудности, ожидания и перегрузку других ролей изнутри, - и как результат лучше сработаться.

📖 Две книги о проблемах ИТ-команд
Автор рассказывает о двух своих книгах для менеджмента. Первая - про сотрудников, которые тянут команду вниз: от “души компании” и “критика-иллюзиониста” до перфекциониста, срывающего сроки в погоне за идеалом. Даются приёмы работы с каждым типом. Вторая - про типовые конфликты: от “спора о кондиционере” и ревью кода до соперничества и несогласованных полномочий. Лейтмотив обеих книг - успех проекта зависит не только от техники управления проектом, но и от поведения участников, их ожиданий и культуры общения.

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

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

🔥 Самые интересные материалы по управлению проектами за 2 недели

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

😱 Разделяй и властвуй: как не погрязнуть в режиме многозадачности
Автор показывает, что “многозадачность” чаще иллюзия, чем реальный навык: мозг просто мечется между делами, падает качество и растет усталость. Выход - сознательно возвращаться к однозадачности: упорядочивать реестр дел, расставлять приоритеты и защищать отрезки сосредоточенной работы. Из приемов - матрица Эйзенхауэра и метод помодоро, плюс гигиена внимания и короткие восстановления. Ну и ежедневно подводить итоги и корректировать рутину под себя.

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

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

😵Книга Хватит выгорать! Инструкция для руководителей: ключевые тезисы и ссылки
Обзор книги для руководителей о том, как распознавать ранние признаки истощения и перестраивать рабочую среду до кризиса. В центре внимания - ритм нагрузки, понятные приоритеты, оговоренные границы и поддержка восстановления. Из практики: договоренности о времени без созвонов, трезвая постановка целей, корректировка объема. Короче, заставляем сотрудников отдыхать и игнорить нас на выходных и по ночам…

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

📱 Великие усложняторы: кризис управления верхнего уровня
Автор описывает ситуацию, когда наверху (ну или вы сами) любят усложнять ради усложнения - бесконечные отчеты, комитеты, инициативы без эффекта перегружают людей и гасят ответственность. Цель подменяется ритуалами, модными практиками и постоянными “перестройками” без оценки пользы. Что делать: упрощать контур управления, обозначать ясные полномочия на уровне команд, ограничивать параллельные инициативы, держать открытую связь с пользователями.

📞Project Manager/Product Manager/Program Manager: в чём разница и зачем это бизнесу?
Статья разводит три часто путаемые (наверное) роли. Менеджер проекта отвечает за сроки, бюджет, качество и риски, менеджер продукта - за востребованность и рост ценности, менеджер программ - за согласование множества инициатив под стратегические цели. Соотв., у них разные горизонты планирования, типовые метрики и круг общения каждой роли, от пользователей до руководителей компании.

🤗Delivery Manager и Project Manager в реальных кейсах
А тут еще про две роли, которые часто рядом. И сравнивают их на четырех ситуациях: срыв релиза, перерасход бюджета, критический дефект в эксплуатации и внезапные изменения требований. ПМ фокусируется на перепланировании, контроле сроков и прозрачной коммуникации; а DM оценивает влияние на бизнес, качество релизов, устойчивость решения и часто подключает техническую экспертизу.

🔥 Самые интересные материалы по управлению проектами за 2 недели

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

👨‍💻Управление кросс‑функциональной командой
Кросс-функциональные команды состоят из экспертов непохожих специальностей — каждый из своей команды. Профессионалов временно перебрасывают на определённый вид работы: отдельный проект, спринт или комплексную задачу. Гайд рассказывает, как управлять временно созданной командой на временно возникающие задачи. Примером выступит объединение команд для клиентского проекта внутри агентства

😎От интроверта до CTO: как прокачать коммуникации и построить систему обучения в команде
CTO крупной компании про свой путь от "немого интроверта" до руководителя, для которого коммуникации - главный инструмент. Как учился у продажников разговаривать с людьми, почему архитектура - это еще больше про общение, чем про технологии, и как пандемия заставила перестроить командные связи. Про обучение - простое правило "учишься нужному бизнесу - оплачиваем полностью; перспективному - 50/50; для себя - поддержим морально", плюс обязательное "выучил - расскажи команде".

😠 6 принципов эффективной коммуникации с коллегами (или нет?)
Любимый жанр - сатирический список "правил", которые на деле разрушают работу: не здоровайтесь, пишите приказным тоном, не давайте вводных, шлите голосовые "на полчаса", ставьте нереальные сроки и пишите в чаты по ночам (узнали себя??). Понятно, что цель как раз показать показать обратное, но читатель легко узнает офисные боли. Мораль: уважение к времени и психике коллег - основа продуктивности.

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

💩Возвращаем команде ответственность на все деньги
Три практики, которые вернули команде вовлеченность и предсказуемость. (1) Сроки оценивает сама команда: тогда исчезают "чужие ожидания" и появляется личная ответственность за план.(да, звучит наивно). (2) Команда сама презентует результаты на ревью - это повышает сопричастность и качество обсуждения. (3) Выращивание "мини-директоров" по зонам (тестирование, аналитика, дизайн, фронт, бэк) позволяет делегировать решения.

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

⛔️От хаоса к системе: как построить эффективный онбординг в ИТ-команде
Как вслед за бурным ростом команды пришло понимание: без единой схемы онбординга новички тонут в вопросах "кто за что отвечает?" и "где что лежит". В итоге пришло решение прописать структуру команды и зон ответственности, собрать базу знаний со скриншотами, назначить ментора и ввести регулярные 1-на-1 по расписанию. Отдельный блок - доступы: пошаговый гайд сократил этап с трех дней запросов до одного рабочего дня; ну а дальше - погружение через простые задачи и матрица компетенций как маршрут развития. Да, и главной метрикой успеха стала самостоятельность: по набору критериев онбординг может закончиться раньше/позже испытательного срока.

“Управление проектами для заинтересованных сторон (стейкхолдеров)” (В.Воропаев, Я.Гельруд, О.Клименко)

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

Я прочитал новинку, и вот тезисно про книгу, ее плюсы и особенности.

👍 Плюсы:
✅Нацеленность на сложные крупнобюджетные проекты, вне зависимости от сферы (не столько привычные ИТ-проекты, но и “стройки века” и производственно-добывающие проекты). Сейчас комплексных материалов в этой сфере сильно не хватает, имхо, если знаете - напишите в комментах.
✅Здоровая хардкорность. Да, тут не заскучаешь над авторскими эмоциями и отступлениями. Книга на 70% состоит из математического аппарата, формул, которых "гуманитариям не понять" (с), но которые прекрасно впишутся в excel и ИСУП и помогут проекту. Авторы именно считают, а не оценивают эффективность проектного управления.
✅Комплексность. Не одна мат.модель, а набор, от детерминированных до вероятностных, с разбором их ограничений для сложных проектов. В итоге получается обобщенная сетевая модель.
✅Несколько точек зрения, соответствующих разным стейкхолдерам: инвестора, заказчика, поставщика, регулирующих органов, коммерческой службы и, конечно, команды проекта. Каждому — свои цели, функции, компетенции и метрики. И еще отдельная карта связей.
✅Из этого складывается основа (скорее ТЗ) для интегрированной информационной системы управления проектами, которая должна собрать вместе всё: архитектуру, логику взаимодействия сторон, планы финансов/поставок/налогов, функции по всем стадиям жизненного цикла.
✅Есть практическая оптика для разных ролей: таблицы с ожиданиями, целями, ограничениями и инструментами по каждой стороне призваны помочь быстро собрать «карту интересов» под конкретный портфель/программу. Причем тут без формул 👍

😑 Особенности

🔹Монографический стиль. Среди авторов - доктор технических наук, и книга ни разу не лайтовый гайд, к которым многие из нас привыкли, а солидная академическая работа с формальными постановками и алгоритмами. Листается в целом быстро, но ожидает от читателя готовности к моделям и матанализу.
🔹Математический аппарат - это и достоинство, и порог входа. Но, с другой стороны, есть понятные гуманитариям выводы, и если они ок, то дальше можно погружаться и в расчеты с шарящими коллегами.
🔹Логика “сверху вниз”, от универсальной модели проектного управления к конкретным календарям, ресурсам, финансам и решениям стейкхолдеров. Если вы привыкли «от Jira к стратегии», придётся развернуть взгляд.

❗️Резюме.
Рекомендую книгу, в первую очередь, PMO, руководителям портфелей/программ, менеджерам крупнобюджетных проектов, интеграторам и консультантам, кто “варится” в многосубъектных проектах с конфликтующими интересами.

🔥 Самые интересные материалы по управлению проектами за 2 недели

🔄 Основы, гайды, инструменты (часть 1)

🍔Почему Agile больше не спасает проекты в России?
Автор эпатирует, и Agile в РФ не умер - он "приземлился" в гибриды под реальность импортозамещения, ограничений и давления сроков. Ритуалы и "чистые" фреймворки в крупных компаниях уступают месту упрощенным процессам с упором на DevOps и автоматизацию (спасибо ИИ и бьютификации). Малые команды сохраняют гибкость, но тоже меньше гоняются за формой и больше - за результатом. И самое главное - это нормально)

🔄Wardley Map: прекратить переизобретать и сфокусироваться на ценности продукта
А это такой инструмент. Карты Уордли помогают увидеть, что покупается "как товар", а что требует собственных инвестиций, и сопоставить это с ценностью для пользователя. Картирование вскрывает лишние "велосипеды" и подсвечивает, где лучше стандартизировать, а где можно удариться в эксперименты. Как результат - получаем более реалистичную стратегию и понятные приоритеты.

🪳Метод MoSCoW - универсальный инструмент для приоритизации задач любого масштаба
Классическая схема Must/Should/Could/Won’t (пользуйтесь, пока не запретили) объясняется на примерах из продуктовой и личной практики, где они могут и сочетаться с другими методиками (например, тот же RICE). Еще хорошо написано, как эти инструменты помогают общаться с заказчиками при переносах сроков.

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

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

🍌Как правильно формулировать нефункциональные требования
О том, что "падения на проде" часто идут не от логики, а от неописанных НФТ - производительности, надежности, безопасности, удобства, совместимости и др. У автора есть конкретные метрики вместо расплывчатых "быстро/удобно", с опорой на ISO 25010 и реальную проверку через нагрузочные, юзабилити-тесты и SLA/SLO. Ещё поясняется, как вытаскивать у бизнеса численные ожидания (время отклика, допустимый простой, поддерживаемые платформы) и не забывать про регуляторику.

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

🐧Оценка сроков выполнения задач: покоряем закон Хофштадтера
Разбор интересного кейса, где "6 месяцев" на проект растянулись почти на 2 года (хе-хе, не так уж и много), иллюстрирует разницу между оценкой и обязательством. Куда деваться, если проекты так непредсказуемы? Автор советует говорить в вероятностях, закладывать в сроки "открытие масштаба" и фиксировать неопределенность явным буфером. Дополнительно важно увязывать риски с соседними функциями - маркетингом, продажами, поддержкой, чтобы коллеги вас не возненавидели (если еще не поздно).

🔥 Самые интересные материалы по управлению проектами за 2 недели

👀 Основы, гайды, инструменты (часть 2)

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

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

🤗Жизнь после внедрения глазами системного и бизнес-аналитиков
Да, поддержка - не "хвост проекта", а отдельный режим работы с собственными правилами. Нужны SLA, понятные каналы, отдельная доска в битриксе, канбан-подход к потоку, договоренности с соседними командами и дисциплина в документации. Автор делится практиками рутинных ритуалов, чтобы не тонуть в "пожарах" и переключениях.

👍 ТОП-10 канбан-досок для управления задачами в 2025 году
Обзор сравнивает популярные доски по настройке колонок, WIP-лимитам, автоматизации и аналитике, а также по тарифам и целевым сценариям. Упомянуты варианты для маленьких команд и крупных процессов, различия в интеграциях и отчетности - Кайтен (да, это их текст…), Shtab, Teamly, Aspro, TeamStorm, любимый Битрикс24 и т.д.

👀 Дневник проекта: заметки на полях
Подборка антипаттернов управления проектами: старт без образа результата, набор фич, собранный рандомно "по дороге", зависимость от одного сценария без плана Б. В рецептах - метод RICE для приоритизации, явные критерии приемки до кода и обязательная (!) работа с рисками. Отдельный акцент - на защите проектного документа и согласовании ожиданий до работы спринтов.

🙂 Напомню, что все дайджесты, со ссылками, тегами, pdf-ками и с удобным поиском можно посмотреть на спец.сайте. Пользуйтесь как базой знаний для себя и коллег!

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

🤔 Тональность - позитив без оптимизма, рост замедляется, “плановое охлаждение” работает. “Энтерпрайз” (крупные проекты автоматизации) сильно задумался, тренд на сокращения команд, часть проектов - на паузе/перенесена, ждут эффекта от снижения ставки и т.д. Многие переведены на сопровождение, без активного развития. Новых грандиозных мало, количество пресейлов припало (с), однако есть и “перевнедрения”. Средние проекты - всё пока хорошо, разве что бюджеты урезают, но не критично. В целом, фокус компаний - не столько на рост, сколько на удержание позиций.

😐 Число вакансий сократилось на 20 - 40% за год по всем ролям (разрабы, аналитики и конечно РП), хотя вот якобы прямо сейчас рынок оживился. Работодатели предлагают 100% удаленку всё реже, чаще гибрид или вообще офис. Кандидаты топят за удаленку, но таки прогибаются. Меняется и структура работодателей: если год-два назад большинство было от интеграторов, то сейчас уравниваются с инхаус.

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

🥲 И раздавались посылы формата: “Если вы востребованный ПМ у себя в компании, который хочет выйти на новый уровень и заняться более “стройками века” у других, - готовьтесь, что таковых просто может не оказаться в ближайшие полгода (якобы срок от выхода на рынок до оффера прям так растянулся). Так что или прокачивайтесь у себя (втч за счет универсализации), или готовьте подушку безопасности, пока ищете работу”. При этом актуальны оба тренда: работники выходят на рынок, чтобы получить оффер и потом запросить у себя контр-оффер (ну тут вроде ничего нового), - но и компании частенько стали практиковать доведение кандидата до без пяти минут приёма (прохождение СБ и даже встреча с руководством) с последующим резким отказом от оффера.

😏 В общем, думойте (с)

🔥 Самые интересные материалы по управлению проектами за 2 недели

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

🐑 8 примеров диаграмм Ганта: от классической до с зависимостями и ресурсами
Отличный текст для любителей и заложников Ганта. Показаны разные варианты диаграммы: иерархический, с зависимостями, с критическим путём и распределением ресурсов. Для каждого - когда применять, какую управленческую задачу закрывает и чего опасаться (напр., перегруз визуализацией, неверные связи). Есть мини-инструкции по построению и рабочие лайфхаки из практики. Полезно как для старта, так и для "пересборки" вашего план-графика.

🔧 Пропускная способность в Канбан: как считать throughput
Вы же прочитали сейчас вслух это слово, да? Автор пишет про разницу между velocity (план в спринте) и throughput (фактическое число завершенных элементов за единицу времени). Поясняет, как собирать данные, строить распределение и зачем смотреть в паре с другими показателями - cycle time и WIP. И на что влияет этот показатель (позволяет делать прогнозы и корректировать ожидания заказчика).

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

🍪Одна грязная чашка, или как мелкий беспорядок разрушает великие компании
Если вы в мелочах (не критичных для процесса) допускаете бардак и несистемность, то… у автора статьи для нас плохие новости) На примерах "разбитых окон", “грязных чашек” и неубранных наблюдателей он показывает, как мелкие сигналы хаоса множат нарушения и снижают стандарты работы. Среда "учит" поведению, поэтому порядок в деталях - это не душнилово и педантизм, а профилактика системных проблем. Будешь убирать мелкие разрывы (имена файлов, правила общения, чистоту рабочих зон - будешь тратить меньше сил на "пожары", получишь меньше когнитивного шума и более предсказуемую дисциплину.

🍪 Я собрал 21 канбан-доску на все случаи жизни (от запуска IT-продукта до похода на свидание)
Больше для досуга, чем для вашей работы, но… вот большая подборка готовых канбан-досок: от обучения и путешествий до подарков и "апокалипсис-канбана". В каждой автор прописал назначение, определил структуру колонок и подсказки, как держать фокус и отслеживать прогресс.

💰 Миграция здорового человека: как переехать на новую IT-систему без нервного срыва
Структурированный план переезда на новую версию ITSM. Сначала ребята сделали аудит интеграций и процессов, затем - план переноса данных, пилотный запуск, катовер (это план раскатки, если кто не знал) и пост-мониторинг. Авторы предлагают чек-листы и логику "никакой импровизации в день X". Ну и в качестве выигрыша получаем меньше регрессий, меньше легаси и всякие релизные новинки.

😌 Чем заменить Jira и MS Project? Обзор российского решения для комплексного управления проектами
Обзор системы Project Ruler (видимо, рекламный, но информативный). Система закрывает не только задачи и проекты, но и портфельный уровень - инициативы, приоритизацию под цели, базу знаний, с общим акцентом на “платформенность”, которая должна заменить собой привычный “зоопарк” софта. Также приведены сценарии внедрения и экономический эффект.

😱 "Мы думали, это займёт три дня": как сократить разрыв между бизнесом и IT
Автор называет главной проблемой "разорванный ландшафт": бизнес и IT живут в разных реальностях, а это ведёт к монолитам, лишним интеграциям и срывам сроков. А решение? Надо смотреть на ландшафт совместно - как на единую систему зарабатывания денег, разделять домены и назначать владельцев процессов. Нужны совместные аудиты, участие архитекторов в бизнес-встречах и договоренности о границах ответственности.

🔥 Самые интересные материалы по управлению проектами за 2 недели

😐 Проджект-менеджер, навыки и карьера

🕺 Тимлид и agile: как команда стала пионером продуктового подхода в Банке
Команда Уралсиба хвастается, как ушла от "водопада" к продуктовому подходу и уже много спринтов стабильно поставляет работающий функционал. Из значимого - срезали бюрократию, меньше согласований и протоколов, больше быстрых встреч по сути и общих демо раз в три недели. На старте буксовали из-за нехватки декомпозиции (приводят грустный пример даже), но выручили прозрачные роли, право просить помощь и дисциплина. Итог - всё прекрасно и бизнес стал доверять еще больше)

🤬 Как заткнуть внутреннего критика и получить отличный результат проще и быстрее?
Для вас, перфекционистки! При всех ваших плюсах, автор считает, что ориентация на некое расплывчатое “качество” тянет вас к бесконечной "полировке" и срыву дедлайнов. И предлагает сменить оптику: мерять не "идеальность", а скорость старта, простоту самого решения, ясность и раннюю обратную связь. Надо упрощать задачи под имеющиеся ресурсы, проверять сложные узлы вплоть до рисования в тетрадке, быстрее прототипировать и доделывать не под абстрактные идеалы, а под задачи бизнеса.

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

🐕ИТ-менеджер, который перестал быть "пожарным". История управления 40 проектами и система, которая меня спасла
Кейс - на одного менеджера свалилось 20+ проблемных проектов, и спасла его не "героика", а система из десяти заповедей принципов. Кртк: группировка схожих проектов, использование шаблонов документов, обязательная база знаний и циклы рутин (да) по расписанию. Плюс "правило пяти задач в день", быстрые ответы на простые запросы, умение отложить "неидущую" проблему. И плюс внимание к личным психо-эмо-ресурсам (хобби, восстановление).

😨 Проектный офис: база знаний для обучения и повышения квалификации сотрудников
О том, что база знаний в ПМО - это не архив, а именно среда обучения: онбординг, методологии, уроки проектов и ответы на частые вопросы. Такой подход снимает "утечку знаний", снижает нагрузку на экспертов и выравнивает стандарты между командами. В статье дан план внедрения: пилотная группа, понятная структура, первые 5–7 шаблонов и глоссарий, регламент обновлений и мотивация авторов.

🥣Рынок эйчара
Как не упомянуть один из топовых текстов месяца) Про любимых всеми HR-специалистов, как скрининги отсекают кандидатов еще до встречи с командой, как эйчары принимают решения по чек-листам и "табличкам". Примеры "блиц-опросов" с перекрученной терминологией (очень знакомо) и отказов без чтения резюме. Увы, выросла роль посредника, а не нанимающей команды - и это тормозит здравый отбор. Особенно с учетом изменений на рынке труда…

🔥 Самые интересные материалы по управлению проектами за 2 недели

😍 Проджект-менеджер, навыки и карьера (I)

🥺 Как делегировать задачи и не стать эксплуататором: ищем золотую середину
Автор предлагает приземленный набор деда руководителя: качественный найм под контекст, индивидуальный план адаптации, постановка задач с ясным смыслом и планом от самого исполнителя (а не от постановщика), контрольные точки вместо микроменеджмента и запрет обратного делегирования.

😂 Выгорание – это манипуляция (памятка, как не выгорать для ИТ менеджера)
Тезис статьи - отпуск (хоть на три дня, хоть на 2 недели) не лечит систему и не помогает от выгорания, если в самой рабочей рутине нет границ и возможностей для оперативного восстановления. Концентрацию на 8 часов ежедневно и месяцами подряд поддерживать невозможно, потому нужно встроить заботу о себе в режим дня. Автор делится личным списком "коротких/средних/длинных" переключений и формулирует позицию: выгорают те, кто не удержал границы и тянет героизм в одиночку, поэтому планирование преемственности и защита личного времени - часть профессионализма.

😢 Мы тонем: как менеджер спасал свои проекты
История о том, как проекты жили в чатах и Excel, статусы устаревали, задачи терялись, сроки плыли. Потом решили сделать переход в единую систему управления проектами - и он дал общий план (включая диаграмму Ганта и критический путь), карточки с красными индикаторами, коммуникацию прямо в задачах 😐 и согласования. В итоге шаблоны проектов и дашборды по загрузке сократили ручную рутину, повысили рентабельность и перевели разговор с руководством на язык данных, а команда перестала "тонуть" в бардаке переписок.

😨 Чувство вины, размытые ТЗ и страх говорить: о чем молчит ваша команда
Автор предлагает заменять культуру поиска виноватого культурой “разбора контекста”. Косяк и прокрастинация - это часто сигнал о неясности критериев или перегрузе, а не о лени сотрудника. Делу помогают открытые разговоры на ретро/синках, явное формулирование опасений и запросов о помощи, а также перевод ошибок из "клейма" в входные данные для улучшения процесса.

😂 Менеджер в квадрате: как принцип "Одна голова хорошо, а две лучше" работает на практике
Кейс про то, как в проектном офисе с 80 проектами в квартал еженедельные часовые статусы "по 45 секунд на проект" не давали глубины (внезапно, да?), поэтому ввели роль куратора: опытный менеджер ведет 3–4 команды, проводит недельные 30-минутные сессии и синхронизируется с руководителем. Такая надстройка разгружает общего руководителя, повышает качество обратной связи и масштабирует развитие менеджеров через регулярную поддержку с ближней дистанции.

😔 Флуд, "звоночек на 5 минут", голосовое гендира в час ночи: 7 рабочих привычек, которые ненавидит каждый
Анти-топ офисных привычек: бесконечные чаты, пассивная агрессия, "всегда на связи", бесцельные пятиминутки, голосовые вместо текста, игнор и т.п. Автор предлагает приземленные контр-меры - перенос переписок в трекер задач, "тихие часы", фиксирование итогов созвонов, авторасшифровка голосовых и мягкая модерация флуда. Короче, всё для того, чтобы разговоры перестали подменять работу и ничего не терялось.

🤔 Проверьте, развито ли у вас ресурсное мышление, и чего вы себя лишаете, если нет?
"Ресурсное мышление" тут определено как умение создавать возможности в дефиците, когда нет ресурсов. Не ждать идеальных условий, а менять контекст под задачу. На примерах автор показывает, как перепридумывать правила игры и пытаться получать результат там, где обычно отступают.

🔥 Самые интересные материалы по управлению проектами за 2 недели

😛 Проджект-менеджер, навыки и карьера (II)

🙅‍♂️ Какие навыки необходимо развивать, если хотите стать руководителем
Если коротко, то брать ответственность даже когда не просят, проявлять инициативы и закрывать сложные задачи еще до должности, плюс работать по выходным поддерживать высокий уровень компетентности и производительности. Отдельный акцент на чистой коммуникации (умение "продать" результат), эмоциональной зрелости и работе с конфликтами. По сути, это короткая дорожная карта роста от специалиста к руководителю.

🧣 Риск - это не страшно: как команде проектного офиса превратить угрозы в точки роста
Автор (из интегратора) показывает, как карта/реестр рисков и база знаний превращают пожаротушение на проекте в предсказуемый процесс. “Всего-то” нужно внедрить хоть какое-то управление рисками - категории рисков, вероятности, планы реагирования и ежегодная ревизия. В примерах - разложение рисков по подразделениям, связка с “уроками проектов” (типа постмортемов) и автоматизация триггеров в системе управления работой. Всё это помогает команде действовать на опережение, а не по факту “пожара”.
PS. Помню, проходил курс РП в Яндексе. У нас было два куратора, причем один из СБЕРа, и обе сказали, что "мда, риски, конечно, мы особо не просчитываем и карты не составляем, да и не нужны они"...

🦯 Рецензия на книгу "Паттерны коммуникации: руководство для ИТ -разработчиков и архитекторов"
Книга Джеки Рид предлагает рассматривать общение как набор повторяемых ситуаций с паттернами и антипаттернами, чтобы не "импровизировать" каждый раз с нуля. Упор на визуальные средства, ясность аудитории и уровень абстракции делает навык конструктивного диалога таким же воспроизводимым, как архитектурные решения в коде, - и этот инструмент не устаревает вместе со стеком. И да, надо будет почитать саму книгу…

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

💪 Кризис – это возможности для роста: как мы переходили на отечественный софт
Интересный кейс проекта по массовой замене привычных инструментов (Windows/Outlook/Skype) на Astra Linux, R7 Office и TrueConf. Этот переход обрушил на линию лавину обращений и удвоил среднее время обработки, но единая база знаний с ролями, временные обходные решения, выделение "третьей линии" и связка с ITSM выровняли поток. Плюс внутренние утилиты, плюс приоритизация автоматизации по трудозатратам - и в итоге экономия на обращении и рост удовлетворенности.

Друзья и коллеги!
😱 Незаметно вас стало почти 1200 - это очень круто ! Приятно видеть среди читателей и начинающих ПМов, и опытных коллег 😛, и зубров-корпоратов, и авторитетных властителей дум...

Сегодня "Проектный дайджест" - это своеобразный продукт, включающий тг-канал, рубрику на Хабре и лендинг с базой знаний.

И нам кажется, самое время задать вопросы на тему "А как вы видите дальнейшее развитие канала и продукта? Что ок, что не ок, что добавить, что убрать?"...

И если вы выделите 4-5 минут, чтобы ответить на такие вопросы, - это будет лучший вклад в развитие "Проектного дайджеста".

Поможете?👀

https://docs.google.com/forms/d/e/1FAIpQLSd8y1OGAjIhBCtC4s-xWqh6lfca2na6d5tLGVDnka4z9xlYtg/viewform

🔥 Самые интересные материалы по управлению проектами за 2 недели

😔 Основы, гайды, кейсы, инструменты (I)

😎 19 видов диаграмм: какие бывают и как выбрать подходящую в 2026 году
Путеводитель по визуализациям объясняет, под какой вопрос подходит каждый тип графика: сравнение, распределение, состав, связь, изменение во времени. На примерах авторы показывают типичные ошибки вроде перегруза деталями, 3D‑эффектов и злоупотребления «пирогами», когда точнее подойдут столбики или водопад (а то и любимая сводная таблица 😉).

😐 Генри Гант и его диаграмма: путь от идеи до современных инструментов менеджмента
Краткая история метода Ганта — от бумажных линеек до онлайн‑сервисов с зависимостями, критическим путем и ресурсами. И объяснение, почему «лента задач» помогает держать сроки. Поясняются базовые элементы диаграммы Ганта и кейсы, где она дает максимум эффекта, если не усложнять и не пытаться вести ей все подряд. Главная польза диаграммы — видимость узких мест и точек, где проект реально держится.

🗒 Scrum и Kanban: отличия и советы по выбору методологии
Сравнение двух подходов: Scrum подходит там, где нужны ритм, роли и инкременты в спринтах. Kanban же - это непрерывный поток с WIP‑лимитами и временем прохождения. Статья касается метрик и типовых контекстов: разработка нового функционала, поддержка и операции, смешанные команды, и подсказывает, где уместен тот самый Scrumban.

😔 Идеи потерявшие смысл: Scrum и ООП
Автор возвращает Scrum к исходной логике месячного спринта и полного цикла улучшений вместо «галочек» ради процесса (там еще про ООП, но это отдельная история). Ну а критика коротких спринтов — в том, что исчезает пространство для анализа, критериев готовности и адаптации команды.

😘 Тайм ‑менеджмент: как правильно управлять временем
Систематизация базовых принципов личной и проектной эффективности: двигаться от целей к задачам, планировать реалистично, регулярно чинить свою систему и не перегревать себя множеством техник сразу. Авторы разбирают популярные приемы (матрица приоритетов, блочное планирование, «съесть лягушку», пакетная обработка, тверк), а также дают признаки того, что ваша схема дала сбой и пора упростить. Если совсем кратко — надо выбрать 1–2 привычки и связать их с недельными целями.

😱 Как дозированные боль и страдание делают нас счастливее и успешнее?
Популярный разбор нейробиологии мотивации: умеренный дискомфорт и тренировочные «провалы» могут укреплять систему вознаграждения, если чередуются с восстановлением. Речь о «ямах» дофамина, дисциплине и том, почему бесконечная гонка без пауз разрушает и результат, и настроение.

🍌 Как измерить удовлетворенность пользователей, у которых нет выбора
Когда аудитория привязана к корпоративному продукту (у которого нет особых альтернатив), классические NPS и ретеншн мало что говорят — важнее смотреть на эффективность выполнения задач, ошибки и когнитивную нагрузку. Тут‑то авторы и предлагают прикладной фреймворк (в духе CASTLE) и свои особые метрики. Такой подход якобы позволяет точечно улучшать критические шаги, а не «усредненную любовь к продукту».

🔥 Самые интересные материалы по управлению проектами за 2 недели

😔 Основы, гайды, кейсы, инструменты (II)

🫥 Краткий курс по менеджменту за 10 минут: база, которая вытянет любой проект
Базированный конспект ключевых основ PM: цели - декомпозиция - приоритизация - коммуникации - риски - контроль исполнения - сделаем позже, с простыми (ну и вроде рабочими же) правилами вроде «фиксируйте критерии готовности» и «держите короткий список приоритетов». Показаны базовые артефакты (доска задач, регулярные статусы, чек ‑листы) и типичные ошибки перегрева процесса ради процесса.

😁 Играем в Канбан на работе
Практический разбор канбан‑подхода от коллег из Контура - через игровой формат (всё для молодёжи!): прозрачность работы, ограничение WIP, вытягивание вместо "запихивания" и плавная оптимизация потока. На примерах показано, как метрики (lead/cycle time) связываются с реальными задержками и чем опасно скрытое многозадачие.

🤔 Глобальный упадок качества ПО: как катастрофа стала нормой
Провокационный текст о деградации качества софта: тонкие устройства и сервисы регулярно ломаются в простых сценариях, а срывы воспринимаются как неизбежная цена скорости. Знакомо, да? Среди причин этого кошмара - сложность стеков, дефицит тестирования «по месту использования» и культ релиза вместо культуры устойчивости. Текст мотивирует вернуться к инженерной дисциплине и осмысленным метрикам качества.

😢 Горе от Ума — почему IT‑проекты пишутся долго и стоят дорого (иногда)
Прикольная заметка и для менеджеров, и для заказчиков: одних «умных разработчиков» для проекта мало, проект ломается на ожиданиях, расплывчатых требованиях и постоянных мелких изменениях. Автор настаивает на согласованных границах, критериях «готово» и ответственности за каждую «быструю правку», иначе рост стоимости неизбежен. И в целом, четкая постановка проблемы помогает разговаривать о сроках и бюджете без розовых очков.

😰 Чему не учат на курсах бизнес‑аналитика: почему шаблоны ТЗ мешают работе
Шаблоны ТЗ создают ложное чувство завершенности и подменяют анализ копированием разделов, из‑за чего реальная потребность пользователя теряется. Автор предлагает идти от цели и сценариев, фиксировать ограничения и эффекты, а шаблон использовать как итоговую упаковку, а не как «каркас мышления».

🪨 Как запускать проекты без команды? Главное о кросс‑командном проджект‑менеджменте
Руководитель, у которого нет своей команды, тянет проект через влияние. Отсюда возникают карта стейкхолдеров, общая цель, понятные артефакты, договоренные ритмы и прозрачные правила приоритизации. Для таких команд важны ранние «малые победы» и аккуратная политика, потому что чужие ресурсы дают под измеримый результат, а прогресс фиксируется в открытых каналах.

🥲 Проектный офис: как соединить регламенты, базу знаний и совместную работу
Кейс QSOFT о том, как склеить процессы, знания и операционку в единую экосистему, чтобы перестать латать дыры десятком инструментов. Авторы показывают, как такой контур экономит время и бюджет, устраняет разрыв между «планами сверху» и реальной работой команд и как онбординг/управление рисками переводятся на рельсы единого пространства. Материал хорош как ориентир для минимально жизнеспособного проектного офиса.

🤷‍♀️Чем заменить MS Project? 7 российских ИСУП
Обзор дает краткие «профили» инструментов с плюсами и минусами: Kaiten (сильный Канбан, но без классического планирования), Планфикс (гибкая автоматизация, но скромнее по ресурсному планированию), Битрикс24 (универсальность экосистемы, но тяжелый интерфейс 😐), GanttPRO (простая диаграмма Ганта), WEEEK и др. Это помогает быстро сопоставить контекст проекта и ожидания по диаграммам, ресурсам и интеграциям.