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

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

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

😋Управление изменениями в проекте с помощью service desk
Как новые требования возникает внезапно и могут сорвать сроки и бюджет, если их не сопровождать структурными процессами. А таким процессом и может стать сервис-деск, - как единая точка входа для запросов на изменения: формы, статусы, согласования и отслеживание, механизм объективного учёта изменений. Хаоса меньше, трассировка больше и больше связи с дорожной картой проекта (если она, конечно, у вас есть).

👊 Когда фидбек может уничтожить продукт
Автор предупреждает о риске слепо следовать каждому пользовательскому комментарию, идее, так как часто они не репрезентативны. Менеджер должен отбирать обратную связь, фокусируясь на её частоте, профиле пользователя и влиянии на продукт. Без фильтрации и структурирования фидбэк приводит к «лоскутному» интерфейсу и невнятной логике. Или просто пользователи не будут пользоваться тем, что долго и упорно просили… (знакомо?)

🤩Что такое пайплайн (Pipeline) в разработке, продажах и проектах
Пайплайн - это последовательность шагов от идеи до релиза, визуализированная для прозрачности и контроля потока задач. Что-то вроде конвейера управления: каждый этап — от подготовки до QA — отслеживается и оптимизируется. Всё это вместе позволяет обнаружить “узкие места” и управлять потоком задач в реальном времени.

🐕Были тысячи способов управлять проектами, но наши тимлиды выбрали эти
YouGile описывает планирование релизов через диаграмму Гантта и Miro: в результате имеем, “обратное планирование”, цели и ретро-проекции. Miro задействуем как стратегическую карту, а Гантт помогает увидеть сдвиги и задержки. И конечно же, канбан - доски поддерживают текущий поток работы, не перегружая сотрудников.

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

🐾Лучшие Канбан‑доски 2025: обзор для команд до 50‑ти
Обзор доступных российских канбан‑систем для команд до 50 человек (YouGile, Strive, Shtab, TEAMLY и другие, даже Б24), - авторы смотрят на скорость запуска, гибкость регулирования доступа и наличие бесплатных тарифов, лёгкость внедрения, возможность пригласить подрядчиков как гостей и наличие простых автоматизаций. Отдельно выделяются функции персонального планировщика, диаграммы Гантта и автоматических «сводок» — отчётов по задачам.

🤪«Фича ради фичи»: как не потерять продукт, улучшая его бесконечно
О ловушке постоянного добавления фич без фокуса и бизнес‑цели и вводе своего рода KPI для фичей: уменьшение оттока, увеличение конверсии, снижение барьеров. Иначе, если бэклог растёт быстрее исполнения, команда теряет способность доводить релизы до конца, специалисты тонут в задачах, интерфейс распухает как зефир, а пользователи почти не замечают изменений.

🍌Как использовать карту влияний при разработке продукта
Автор предлагает “карту влияний” как ментальный каркас проекта на старте. Формат: Зачем (цель), Кто (роли или сегменты), Как (действия), Что (функции). Менеджер вместе с заказчиком проговаривает SMART‑цель, строит связи с функциональностью и фильтрует лишние задачи. Это помогает сократить объем задач, улучшить бюджетную предсказуемость и четкость видения. Карта становится контролем: решение принимать фичу или отказаться от неё сразу видно по влиянию на цель.

🥺Example Mapping - как способ структурировать Product Backlog Refinement (PBR)
Метод Example Mapping помогает структурировать чистку бэклога на основе User Story, бизнес‑правил, примеров и вопросов, оформленных визуально на стикерах (!). Менеджер проводит сессии с представителями бизнеса, разработчиками и QA: записываются правила (синие), примеры (зелёные), вопросы (красные). Процесс длится до 25 минут на единицу бэклога.

🚶‍♀️10 книг, к которым возвращаются тимлиды, когда всё идёт не по плану
Авторы собрали 10 проверенных книг по управлению проектами, к которым руководители команд возвращаются на разных этапах: от старта до масштабирования. На этапе изучения основ рекомендуются «PMBOK», «Scrum» и «Канбан» — они формируют базовое понимание методологий и подходов. Для найма и построения эффективной команды полезны «Кто» (про системный подход к подбору людей), «Пять пороков команды» (о причинах провалов в коммуникации) и «Радикальная прямота» (о честной, но бережной обратной связи). На этапе постановки целей предлагаются «OKR» и «Lean Analytics» (как задать измеримые ориентиры и работать с данными). Когда дело доходит до внедрения изменений, пригодится «Переключайтесь» с моделью Всадника, Слона и Тропы. Для роста — «Масштабированный скрам», помогающий сохранить гибкость в крупных командах.

😰Практика управления масштабным IT‑проектом в Magnit Tech
Magnit Tech описывает кейс трансформации монолитной ERP-платформы на новую инфраструктуру — ответ на проблему устаревших систем и препятствий для time‑to‑market. Стратегия для такого масштаба — разделение работы на этапы: выявление скрытых зависимостей, оценка рисков, пилотные миграции. Особое внимание уделялось изменениям среды, мониторингу производительности и четкой дорожной карте будущего проекта. И конечно, важна коммуникация: регулярные встречи на всех уровнях — от технарей до заказчиков, с визуализацией прогресса. Ну и всё получилось)

👀Когнитивные искажения в принятии решений
Пересказ легендарной книги “Думать медленно - решать быстро” (знаю, что среди подписчиков есть те, кто еще не читал). В том числе - эффект ложной срочности, Зейгарник и другие — и как они мешают продуктивности. Отдельное спасибо - за акценты на искажения в управлении проектами и командами.

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

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

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

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

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

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

😎Как стать идеальным менеджером и не выгореть: советы из практики
Автор из Avito делится адаптированным разбором книги Джули Чжо, бывшего руководителя продукта Facebook, и показывает, как стать эффективным менеджером, не теряя себя в роли лидера. Управление — это не о личных достижениях, а об успехе команды, где ключевые аспекты — люди, процессы и продукт.

💃Трансформация руководителя из «подавителя» в лидера
Портрет руководителя «Кирилла» (гм…), который подавляет инициативу подчинённых, раздувая контроль и страх в команде. Цикл такой: использование эксперта, подавление при проявлении инициативы, слив сотрудника. И это аукается - команда разрушается. Рекомендации - переходить от устрашающего контроля — к влиянию через доверие и признание, т.е. помощь другим, а не подавление.

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

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

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

😆Как сдать на РМР в 2025 году, если ты из России
Да, у героини материала получилось заиметь международный сертификат PMP, находясь в России. Несмотря на ограничения, экзамен доступен и подтверждён — на него можно подать заявку и сдавать на русском языке. Она прошла курс, использовала симуляторы, получала поддержку от преподавателей и коллег. Ну и еще важно заранее подготовиться к логистике и поддерживать мотивацию.

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

🥹Служить и защищать: тимлид на страже команды
Опыт роли тимлида как президента своей команды: важно не управлять и контролировать, а заботиться и защищать. Такой “президент” автоматизирует рутину — отчёты, задачи, интеграции, чтобы освободить разработчиков для созидательной работы. Кроме того, тимлид защищает команду от чрезмерного вмешательства менеджеров и заказчиков, избавляя от излишней отчётности. Короче, лидерство как служение.

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

😌Как подготовиться к переходу на роль тимлида и как вернуться, если не вывезли
Аня из Avito описывает путь от сеньора к тимлиду, даёт советы, как переходить осознанно и что делать, если не справляешься. Вопросики себе: действительно ли готов быть руководителем, готов ли тратить время на митинги, “человекоугодничество”. Про сам переход, когда в первые месяцы наибольшее внимание уделяется обучению, установке границ ответственности и наставничеству. Ну и никто не запрещает выкатиться обратно - тут тоже много рекомендаций.

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

😐 Памятка менеджеру: Запрещённые фразы в IT
Интересный список типичных фраз, которые резко снижают эффективность общения с командой и заказчиками. Самая опасная — “какого, простите, х…” ”этого нет в ТЗ”: она обостряет конфликты и убивает коммуникацию, даже если вы правы. Такие фразы создают атмосферу отчуждения и непрофессионализма. Вместо этого автор предлагает быть помощником, а не критиком, и помогать клиенту, а не доказывать свою правоту.

🚑 Вас наняли спасать проект — вот что пойдёт не так
Часто компании нанимают "спасателя" проектов, которому дают карт-бланш (ура!) и хаос (не ура…). Но увы, без чёткой цели, полномочий и поддержки сверху он обречён. Чаще всего такие менеджеры тушат пожары (и совсем не всегда успешно) - и теряют силу. И если вас берут на такую роль, лучше заранее проверить на собеседовании, действительно ли организация готова к изменениям. А еще статья предлагает три инструмента для запуска перемен, если всё-таки вы решились спасать мир.

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

😏 Как расти в карьере и не сгореть: руководство для тех, кто хочет всё успеть и всему научиться
Не будет открытием, что большинство IT-шников выгорают не из-за денег, а из-за неправильного подхода. И советы автор статьи дает весьма несложные: вместо героических трудов — микрообучение по 20 минут в день, а само деление задач должно быть по энергии, а не по времени. Работайте в пиковые часы, отдыхайте каждые 90 минут, автоматизируйте рутинные задачи. Цели должны быть достижимыми, причем шаг за шагом, а не какими-то героическими усилиями (от которых потом долго отходишь).

👀 7 актуальных метанавыков, чтобы вести за собой команды
Блог Хабра представил семь “метанавыков” (записываем словечко), которые, по мнению авторов, отличают эффективного лидера. Среди них — осознанность, умение быстро вникать в новое, слушание и спокойное реагирование на кризис, способность замечать детали. Еще сегодня важны гибкость и эмоциональный интеллект. Метанавыки помогают адаптироваться и вести команду в условиях изменений.

😡 Как управлять джуном, мидлом и сеньором одновременно: применяем модель Херси — Бланшара
Модель Херси — Бланшара — это управленческая модель, которая помогает выбирать стиль руководства в зависимости от зрелости сотрудника по конкретной задаче. Она основывается на двух ключевых параметрах: компетентности (навыках) человека и его мотивации (готовности работать над задачей). Автор применяет модель для команды разработки с разной зрелостью: джун доверяешь меньше, сеньору — больше. По мере роста компетентности и мотивации меняется стиль руководства — от прямых указаний до делегирования. Ну и рассказывает, как определить текущий уровень сотрудника и адаптировать подход, чтобы избежать выгорания лидера и сохранить мотивацию команды.

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

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

🤫 "Со мной что-то не так": психологическая работа с виной и агрессией у IT-специалистов
Статья погружает в эмоциональные запросы IT-специалистов, которые страдают от синдрома самозванца и ощущают внутреннюю вино вину и агрессию. Надо работать не только с ситуацией, но и с внутренними установками: выявлять глубинные причины, бережно их прорабатывать. Важно научить выпускать агрессию конструктивно, направляя её на достижение целей, а не на самоуничтожение. Короче, не конфликт, а диалог (везде бы так).

😐 Должен ли аналитик уметь всё?
Полина, SA с десятилетним опытом, разбирает, насколько реалистично и эффективно требовать от аналитика владения всеми методами и подходами. Автор рассматривает ключевые инструменты: CustDev (интервью с пользователем), декомпозиция гипотез, анализ данных и создание брифов — и разбивает их по месту в процессе. Якобы подобный арсенал помогает не блуждать в догадках, а понимать реальные нужды бизнеса. А системному аналитику важно знать свои сильные стороны и работать в тандеме с другими специалистами, чтобы не превращаться в "универсала", теряющего глубину экспертизы...

🚶‍♀️ Секреты сильной команды
Психолог и руководитель делится секретом (?): команда — внезапно не просто группа сотрудников, а живой организм (я/мы), который достигает результатов благодаря синергии и взаимному росту. Оптимальный размер команды — 5–9 человек, иначе возникают проблемы взаимодействия и ответственности. Фишки сильной команды — договорённости, прозрачные отношения, личная ответственность и баланс лидерства: нужны и "тот, кто ведёт к результату", и "тот, кто создает атмосферу". А в идеальном мире можно еще и внедрить внутренний манифест, чтобы прям как отдельная республика)

😌 Пересечения и различия между бизнес-аналитиком в ИТ и бизнес-психологом
Сравнение роли бизнес-аналитика и бизнес-психолога: оба стремятся глубоко разобраться в проблемах и помочь организации, но работают с разными объектами. Аналитик меняет процессы, технологии и документацию, используя методики анализа и визуализации. Психолог — с людьми, групповой динамикой и коммуникациями. Вместе такие специалисты могут значительно повысить результативность изменений, преодолев сопротивление и сбои в взаимодействии. Так что если пользователи плачут вам в жилетку - это нормально)

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

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

🤩 Agile! — паразит поедающий до костей
Автор ненавидит жёстко критикует подход "гибкости без структуры": без чётких правил и дисциплины Agile превращается в хаос, выгорание и бесконечные переделки. И вот пример команды, которая тратит время не на задачи, а на бессмысленные обсуждения, теряя фокус и мотивацию. Вывод такой, что свобода должна быть осознанной и ограниченной рамками, иначе привет, обратный эффект и бесполезная работа. Как вариант лечения, нужно создать минимальные, но устойчивые процессы: один бэклог, короткие итерации, демо, автоматизированные проверки и вести проекты в Битрикс24.

👍 Как внедрить Agile и Канбан в нетехнических командах: опыт маркетинга, HR и юристов
Команда Kaiten собрала практический опыт применения Agile и Канбан вне ИТ — в маркетинге, HR и юридических отделах. Кратко - методики помогают строить итерации, тестировать гипотезы, ускорять коммуникацию и повышать эффективность. Юристы, например, использовали комбинацию спринтов и канбан-досок, чтобы закрывать стратегические задачи и текучку одновременно, повысив результативность с 15% до 60%. В маркетинге Agile помог интерактивно планировать кампании и синхронизироваться с другими функциями.

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

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

😊 Базовые понятия бизнес-анализа и применение их в работе
Что-то вроде фундаментальной модели бизнес-анализа: 1) изменение в контексте вызывает потребность, которая 2) формируется в требование, далее — 3) решение, которое приносит ценность заинтересованным сторонам. После реализации решение становится 4) частью нового контекста и запускает последующий цикл анализа. Есть практический чеклист для инициатора задачи (выяснить контекст, потребность, добиться понимания ценности, выявить заинтересованных и оценить реальные решения). Подход помогает структурировать работу аналитика, избегая поверхностности и неопределённости.

❓ SLA в проектах внедрения программных продуктов 1С
Коллеги из КОРУСа объясняют, как важен документ SLA (соглашение об уровне услуг) в проектах внедрения 1С. SLA задаёт правила игры: фиксирует обязанности и сроки обеих сторон, избавляя от неоднозначностей и конфликтов. В примерах показано, как задержки с доступом или данными могут сорвать сроки, если их не прописать заранее. Рекомендуется включить в SLA ресурсы, ответственных, форму данных и оплату, а также проводить регулярный мониторинг и корректировки.

🍑 11 диаграмм, которые помогут избежать кризисов и переработок
Целых 11 визуальных инструментов (WBS, PERT, диаграмма Исикавы, RAID-log, VSM и другие), которые помогают управлять проектами и предотвращать ошибки. Примерчики, когда диаграммы спасали от кризисов, находили узкие места, распределяли ответственность и прогнозировали риски.

«Введение в управление проектами внедрения 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 живут в разных реальностях, а это ведёт к монолитам, лишним интеграциям и срывам сроков. А решение? Надо смотреть на ландшафт совместно - как на единую систему зарабатывания денег, разделять домены и назначать владельцев процессов. Нужны совместные аудиты, участие архитекторов в бизнес-встречах и договоренности о границах ответственности.