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

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

🤩 Топ российских мессенджеров для работы в команде
Авторы анализируют отечественные мессенджеры и заодно предлагают свои (внезапно) решения, которые интегрируются прямо в таск-трекеры и облегчают коммуникацию внутри задач. Например, автоматическую транскрипцию голосовых сообщений, которая позволяет команде быстро найти нужную информацию, не прослушивая длинные аудиозаписи.

🤩Google Project Management: Professional Certificate, все самое главное из курса для начинающих, часть 4,
часть 5,
часть 6
Про первые три части писал в предыдущем дайджесте. А на этот раз автор касается таких тем, как описана иерархия ролей: Project‑Manager (отдельный проект), Program‑Manager (группа проектов) и Portfolio‑Manager (стратегический портфель); подготовка устава проекта на этапе инициации — от краткого описания до целей, результатов и чётких границ объёма; сочетание Agile и Waterfall для адаптации к различным условиям: предпочтениям стейкхолдеров, регуляторике, особенностям команды или внешних партнёров. И, кстати, в целом, приходит к гибридной модели: гибкость оценок и итераций по Agile, с формализацией документации и контрольных точек по Waterfall.

🤩 Почему мы выбрали Scrum как методологию командной работы
Команда Fix Price описывает выбор Scrum как оптимального пути выстраивания гибких и автономных команд. Основной аргумент: минимизация организационной перегрузки и быстрое получение результативного инкремента. Scrum позволяет разбить работу на циклы (спринты), а роли (Scrum‑Master, Product‑Owner) фиксируют ответственность за процессы. Всё это помогает «не слить фокус» в рутине и ускоряет реакцию на изменения.

🤩 Оркестр без дирижёра: квартальное планирование в продуктовом сервисе
Кейс hh.ru описывает, как несколько продуктовых команд (“оркестр”) синхронизируются без «дирижёра» — в рамках квартального планирования. Планирование осуществляется на макро-уровне каждые три месяца, что позволяет определить ключевые инициативы и исключить локальные конфликты. Роль PM — не дирижировать, а координировать обсуждение приоритетов и зависимостей между командами.

🤩 Проектирование Информационных систем. Часть 8. Разработка логической структуры данных
Целая серия статей про системный подход к выявлению и моделированию сущностей предметной области с помощью UML, классификацию объектов, выделение абстракций — сущностей, бизнес-объектов и интерфейсов, роль ER‑ и UML‑диаграмм для описания атрибутов, операций, интерфейсов и типов связей.

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

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

⛔️ Как выбрать AI‑курс для менеджера: подробный разнос
Обзор-анализ огромного выбор AI‑курсов, доступных сегодня с выводом, что не все из них полезны PM на практике. Большинство - про поверхностное понимание «что такое LLM», хотя основной целью должны быть прикладные навыки.

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

🆒Раскатываем дизайн-систему: от хаоса к процессам
Полутехнический, но прикольный материал от YooMoney. Описывают комплекс мер для ускорения доставки фич: оптимизация CI/CD, внедрение всяких удобных инструментов, автоматическое тестирование, «горячую замену» без деплоя — и регулярные ретроспективы. Роль ПМа - участие в формировании дорожных карт и приоритетов.

🚨 4, 3, 2, 1 — поехали! Реальная история запуска IT-продукта за четыре месяца
Про важность участия PM в архитектурных решениях, чтобы поддерживать стратегическую гибкость проекта. Если архитектура формализована с начала (а такое бывает… наверное…), PM может существенно снизить межкомандные зависимости и ускорить процессы. Особенно важны ранние спринты - сразу плюс 100 к управляемости.

🤡 Как методы Toyota, Дэвида Аллена, Барака Обамы и Мари Кондо делают IT-специалистов эффективнее и спокойнее
Как внедрение agile‑процессов возможно не только в IT‑разработке, но и в операционных подразделениях. Суть та же: короткие итерации, визуализация задач (канбан), регулярные ретроспективы и фокус на эффективности операций, а ПМ выступает как фасилитатор. Плюс использование PDCA-цикла и прочих привычных инструментов.

👍 Бесстыжий тимлид: как уязвимости делают сильнее
Коллеги из Avito - про то, как честные признания менеджера (“лидера”) о страхах и ошибках формируют доверие и усиливают командный дух. В IT, где давят дедлайны, умение показать уязвимость помогает команде выразить идеи и быстро реагировать на вызовы. ПМ может перенять практику такой эмпатии: открытость на ретроспективах, запрос мнения о решениях, признание ограничений.

🌧 Техники антипродуктивности
Какие подходы планирования работают на самом деле, а какие нет: утреннее детальное планирование, дробление задач, баланс дня или Pomodoro. И выходит, что и они могут быть вредны, а важен не универсальный рецепт, а адаптация техник под команду и контекст. И вообще нужно все в комплексе.

🔥 Как все успевать и не выгорать. 42 способа
Да, там именно 42 способа борьбы с выгоранием, включая Kanban, GTD, ZTD и утренние привычки и т.д. Тоже про, что без понимания “зачем” методы работают лишь наполовину, да и сам способы необходимо адаптировать под контекст и команду. Еще рекомендация - вводить привычки по шагам и измерять их эффект на циклами ретроспектив (ну типа “атомных привычек”).

💥 Тревожность и производительность: как стресс влияет на работу
Умеренный стресс по закону Йеркса–Додсона (да, еще одна ненужная информация) повышает концентрацию и работоспособность, но при чрезмерном — вызывает падение эффективности и риск выгорания, особенно в ИТ‑сфере. Ну и мы как менеджеры должны распознавать разницу. Рекомендации — развивать эмоциональный интеллект и формировать поддерживающую среду с помощью 1:1, командных встреч и здоровых границ.

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

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

😵‍💫Руководство по ресурсному планированию
Авторы из Weeek - про структурированный подход к ресурсному планированию в проектах, включая выявление необходимых навыков, анализ загрузки и учет резервов и отпусков. Основной инструмент — матрица загрузки, которая визуально показывает соответствие задач и специалистов, помогает выявить перегрузки и недозагрузки.

😱 Считаем риски: как планировать спринт без сюрпризов
Про фундаментальную формулу управления рисками: риск = вероятность × критичность, где критика воспринимается как воздействие на сроки, бюджет, качество или репутацию. Есть классификатор рисков — внешние (задержки команд, API), внутренние (техдолг, баги) и организационные (отпуска в Абхазии автостопом, инфраструктура).

🤬 5 причин, почему ваши Story Points не работают (и что делать)
О слабых сторонах Story Points: они не отражают поток задач, дают иллюзию точности и плохо масштабируются между командами. Да и в целом, Story Points — лишь внутренний инструмент для выравнивания понимания, но для прогнозов важны еще и другие метрики. Автор предлагает применять статистику (Monte Carlo) и прогнозировать диапазоны вероятностей, а не использовать фиксированные значения SP.

🥳 Зачем нужны и как использовать Story Points?
Story Points — это командная относительная оценка, учитывающая сложность, риски и накладные издержки. Основная цель — повысить предсказуемость командного потока, а не сравнивать скорость разных групп. Если использовать их как универсальную метрику межкомандного сравнения — возникает искажение и снижение ценности.

😎 Lean в IT: как сократить потери и повысить эффективность на практике
Про адаптацию практики бережливого производства для IT-процессов. Суть Lean — выявить потери (время ожидания, лишние действия, дефекты) и систематически их устранять через Kaizen-подход. Отсюда и акцент на эмпирический переход: сначала пилотирование, затем масштабирование — вместо «бросания» всей команды сразу. Ну и надо обучать команду анализу потока создания ценности, визуализировать “узкие места”.

🙁 Топ‑7 систем управления проектами. Все для контроля задач и команды
Подробное сравнение систем управления проектами (в основном отечественных) по пяти критериям: управление задачами, приоритезация, контроль метрик, автоматизация и интеграции. Приводятся кейсы, демонстрирующие, как каждая система помогает выявлять узкие места и распределять ресурсы. Отдельное внимание — генерации отчетов и прозрачности процессов.

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

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

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

🌚 Руководство по ресурсному планированию
Авторы из Weeek - про структурированный подход к ресурсному планированию в проектах, включая выявление необходимых навыков, анализ загрузки и учет резервов и (да-да, особенно сейчас актуально) отпусков. Основной инструмент — матрица загрузки, которая визуально показывает соответствие задач и специалистов, помогает выявить перегрузки и недозагрузки. Важный этап — постоянный пересмотр плана с учетом эффективности, изменений сроков и появляющихся алкогольных зависимостей, чтобы не допустить узких мест.

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

🎭 FFF: методология, которая принимает реальность
Идеально для нынешнего питерского "лета": про опыт применения метода FFF (First Features Freeze) — ранней заморозки объема задач (скоупа) перед разработкой, чтобы избежать излишней неопределённости. Подход позволяет зафиксировать первичный объем работ, не блокируя будущее развитие, и оставляет пространство для изменений. Особенно полезен для интеграционных проектов и крупных модулей.

🌚 Приоритизация бэклога: MoSCoW, ICE и RICE, и почему нам этого не хватило
Команда Content AI делится опытом: классические фреймворки (MoSCoW, ICE, RICE) перестали справляться с ростом бэклога. Авторы представляют собственный кастомный метод, учитывающий сложность фич, бизнес-приоритеты и технический долг, с итеративным пересмотром приоритетов на основе данных и обратной связи.

🧜‍♂️ Problem solving в ИТ
Про инструменты мышления для решения проблем в условиях неопределённости. Это подход длительного поиска решения, не шаблонная техника, а итеративный путь через гипотезы его причин и тестирование решений. Включает анализ корней проблемы (все эти наши/ваши “5 почему”), генерацию вариантов решений и их прототипирование.

😭 «А так ли хорош TOGAF?»
Авторы критически оценивают TOGAF как стандарт архитектуры предприятия — его применимость в проектах и ограничения. TOGAF охватывает бизнес-, data-, application- и технологическую архитектуру — но требует прям большой адаптации к проектному контексту. PM должен настраивать их под масштабы и срок проекта, без внедрения лишней бюрократии, поэтому рекомендуется использовать TOGAF как базис, но облегчённый, чтобы не выйти из agility. Кто не знает про TOGAF - ставьте огонек, поизучаем)

🐌Неработающие принципы Agile. Когда Agile не принесёт эффекта
Про причины, по которым Agile-принципы могут провалиться — от формального применения до отсутствия адекватной поддержки и культуры. Если ритуалы проводятся «по книжке» и без “зачем?”, то теряется смысл и энергия команды, да и вообще происходит нарушения главного принципа гибкости, что приводит к “затоксичиванию“ разработки.

👩‍🦱 «Спринт без смысла»: как Agile-принципы превратились в рутину — и что с этим делать
И еще один текст про «Agile-детокс», практической направленности) Автор - за пересмотр каждой церемонии, каждой ретроспективы под вопросом «зачем?». Всё лишнее и чересчур ритуальное нужно вычистить, не тратить время и силы на “псевдо-деятельность”. И в итоге команда снова начинает думать «мы делаем А не потому, что должны, а потому, что это приносит ценность».

☯️Концепция проекта: как собрать команду
Как выстроить концепцию проекта, чтобы привлечь нужную команду (если она у вас, конечно, есть): нужно ясно описать цель, ценность и результаты. Kick-off встреча на этой основе позволяет определить роли, ожидания и зоны ответственности ещё до старта. Из важного еще - упор на коммуникацию с ключевыми стейкхолдерами и оформление документа концепции, который станет договорённостью между заказчиком и командой.

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

🍫Исследование 5000 вакансий и резюме проектных менеджеров
Проанализировали более 3000 вакансий и 2000 резюме PM, - и выявил разрыв в ожиданиях (зарплатные ожидания в резюме превышают предложения примерно в 1.6 раза). Основные навыки — 1С😱, аналитика, продакт-менеджмент — востребованы, но часто вакансии не указывают вообще конкретных требований. Также выявили сильный разброс опыта: вакансии делятся на категории «младшие» и «старшие», а резюме показывают более равномерный рост. Ну и ожидаемо образовательный бэкграунд влияет меньше, чем опыт работы (я вот филолог по диплому так-то).

🍫Отпуск руководителя
История тимлида, который ушёл в отпуск сразу после релиза важного проекта, … и ничего не случилось!! Типа зрелость процессов и автономность команды. Запланированный отпуск становится «performance review» уровня PM: если всё работает без него — система управления выстроена хорошо. Успешный PM — скорее организатор, чем вдохновитель /ваш кэп/ (Недавно я тоже был в отпуске и тоже ничего не случилось плохого, спасибо, коллеги😄)

🍫Как не утонуть в операционке: система фокусов для тимлида
Статья предлагает трёхслойную модель фокусов тимлида: люди, продукты, система. В фокусе людей — регулярные 1:1 и внимательное слушание для выявления выгорания и мотивации. В продуктовом фокусе — вовлечение команды в ”почему” для фич(ей). Системный уровень — код-ревью, ретроспективы — часто отодвигается, но именно он обеспечивает устойчивость.

🍫Как масштабировать применение ИИ. Аналитика и рекомендации от McKinsey
Перевод исследования McKinsey: внедрение ИИ требует перестройки бизнес-процессов, а не просто добавления технологии. ИИ может взять на себя до 60% нагрузки — это требует стратегического планирования и участия CEO, адаптации инструментов, оценки рисков, прозрачности и контроля инфраструктуры. В общем, надо не внедрять ИИ изолированно, а интегрировать в систему принятия решений.

🍫Изменения. Инструменты, которые работают
Про то, как вносить изменения и как защищать их от всяких угроз. Для РП - тема важная, по моему личному опыту, сопротивление изменениям - один из ведущих факторов провала проекта. Потому и рекомендую материал и инструменты автора - сторителлинг, визуализированную аналитику, карту стейкхолдеров итп. Логика - выбрать пилотную зону, замерять результаты на ней, потом масштабировать. Участие команды - конечно же, тоже ключевой фактор.

🍫Хватит «внедрять таск‑трекеры». Просто попробуйте этот вариант для ленивых
6 простых процессов в таск-трекере YouGile, чтобы сразу увидеть эффект без перегрузки, втч простую Kanban-доску, песочницу для экспериментов, онбординг, стратегическое планирование, работу с подрядчиками и обзор проектов. Такой подход поможет быстро стартовать и учить команду работать структурированно, да и внедряется за час и вроде как на любом трекере.

🍫Тихая сила: как управлять не через контроль, а через влияние
Про резонансную роль лидера, который управляет примером, а не приказом. Типа не «скажи, чтобы сделали», а «сделай сам» (привет, делегирование). Важный инструмент — признание ошибок самим лидером, которое разрешает подобное поведение для других. Менеджер демонстрирует отсутствие токсичности и готовность нести последствия — и команда следует через доверие.

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

😐 Эмпатия: мощный ресурс руководителя в IT
Про эмпатию, которая позволяет строить глубокое доверие, удерживать таланты и улучшать мотивацию. PM с эмпатией слышит реальные проблемы, слышит эмоции, поддерживает психологическую безопасность и повышает вовлечённость. Такой стиль помогает формировать культуру, в которой люди остаются, радуются походу на работу, а не только выполняют задачи.

😬 Почему все ломается, или Зачем менеджеру в ИТ софт‑скилы
А тут в тему - 5 реальных кейсов, где проблемы не в багах, а в «тишине, обиде и недоверии» в команде. Без эмпатии и мягких навыков никакие таск‑трекеры не спасут проект. Менеджер/лидер — прежде всего коммуникатор, который задаёт тон доверия и обеспечивает безопасность диалогов. И конечно, в каждом кейсе софт-скиллы превратились в инструмент решения — будь то 1:1, фасилитация или построение атмосферы (нет, не душной).

😅 Как не убить инициативу в команде: ошибки тимлидов
Тимлид, берущий на себя всё, убивает инициативу и рост команды.Отсюда - важно документировать процессы, вводить формальную оценку рисков и распределять ответственность.

👍 Коммуникации: как говорить, чтобы вас слушали
Три практики для проджекта: говори кратко, не говори «невозможно», а начни с сути. Особенно важно привлекать внимание слушателя с первых слов . Так PM переводит разговор в конструктив: вместо формулировки проблемы — запрос ресурсов, вместо «мы не успеем» — «нам нужен аналитик до понедельника». Этот стиль ускоряет принятие решений и делает коммуникацию продуктивной.

👍 Ошибки молодого лида: что меняется, когда у тебя команда
Avito рассказывает о переходе от личному вкладу к командному, делясь болями начинающих тимлидов. Главные ошибки: попытка контролировать всё, неподготовленность к ответственности за несколько команд, недооценка коммуникаций. Рост менеджера — это переход на уровень структурирования работы, синхронизация между командами и настройка процессов. Рекомендации включают обучение софт-скиллам, делегированию и созданию видения для каждой команды.

🧃 Team‑building как инструмент ретроспективы
Большой гайд от команды Weeek (они вообще молодцы в контенте). А что если представить ретроспективу как тимбилдинг‑механизм со своими ролевыми упражнениями и визуализацией задач? Начинаем с анализа боли команды, чтобы сформулировать цель встречи. Затем — меняем формат, чтобы удерживать внимание и выявить глубинные проблемы. Роль ПМа - что-то вроде фасилитатора‑режиссёра: он создаёт атмосферу доверия, вовлекает всех участников и формирует почву для принятия решений.

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

😱 Модель Кано: как отличить “Вау!” от обязательного
Про модель Кано и как классифицировать фичи на Must‑Be, Performance и Attractive. Это даёт проджектам инструмент определения приоритетов: обязательное («must») vs дифференцирующее. Важно правильно интерпретировать ответы пользователей, чтобы не тратить ресурсы на ненужные «мяувау»-фичи, так чтобы фокус был на реальной ценности, а не на иллюзиях.

😶Сравнение методологий продуктовой разработки и фреймворков бизнес-моделей
Наглядное сравнение Lean Startup, Scrum, Shape Up, Design Thinking и других методологий — с их контекстом применения, плюсами и ограничениями. При этом выбор методологии зависит от стадии продукта: например, Lean Startup эффективен на ранней стадии запуска, а Scrum — при регулярном обновлении зрелого продукта. А еще можно комбинировать подходы (ура! эклектика!).

😁 «Да мы и без проектной документации справимся!»
Узнали? Согласны? Реальный кейс, где отсутствие проектной документации удорожило итерацию в пять раз (и это еще мало). Автор делает вывод: даже минимальное ТЗ + прототип экономят время и деньги. PM должен использовать документирование как инвестицию, а не ненужную формальность, а для этого делать ТЗ/доку легкой, понятной и согласованной.. Эффект: меньше рисков, меньше повторных правок, более точного попадания в потребности заказчика.

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

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

🚬Зачем и как писать ТЗ
Автор показывает, что качественно подготовленное техническое задание минимизирует стоимость, время и количество уточнений при старте проекта. Готовить ТЗ надо, даже если клиент этого не сделал — и обязательно согласовывать его. Хорошее ТЗ — это документ, защищающий от расползания скоупа и резервирующий бюджет под экстра‑вопросы.Ну и важно обновлять ТЗ при изменениях — а не оставлять устаревшие версии.

😐Эффективное взаимодействие с регуляторами в Agile
Материал на VC.ru показывает, как Agile‑подходы помогли наладить коммуникацию с регуляторами — через прозрачность и итеративность, регулярные встречи с compliance‑командами, анализ нормативных требований и адаптацию планов к регуляторным изменениям.

📕 “Правила потока для управления проектами” Эфрат Ашлаг-Голдратт (Литрес)

😐 Прочитал свежий перевод книги дочери Элияху Голдратта, которого вы все знаете по Теории ограничений (ТОС). И внезапно, несмотря на множество “но”, книга очень понравилась.

📖 Кратко - это 160-стр. “бизнес-роман”, аналогичный “Цели”, “Deadline”, “Фениксу”. Сюжет - менеджер мучается с пачкой проектов, куча переделок, заказчики ругаются и грозят судами,ну и в личной жизни проблемы. Но вот на курсах находит умного профессора и единомышленников, вместе с которыми приходит к новому мировоззрению. Да, пожалуй, именно это слово тут уместно. Автор не дает “методологии” и далека от академичности, отказываясь даже от терминологии ТОС в пользу “здравого смысла”.

🚰 В основе этого “проектного мировоззрения” понятие “потока”. Это поставка ценности заказчикам, над которой работает команда. Не диаграмма Ганта, не декомпозиция и бэклог, а непрерывный поток. Задача компании - дать потоку дорогу, не задерживать и не мешать превращаться в итоговый результат.

😱 Что же ему мешает?
Незавершенка. Точнее, “мультипроектность”, много одновременно взятых командой и специалистом незавершенных проектов и задач. Многозадачность и мультизагруженность - зло. Идеал - это одна задача / один проект, на которых нужно держать фокус. Но как минимум, провести "триаж" - приоритезацию проектов и задач с результатом в виде полной (!) заморозки тех, которые менее критичны. Контролировать кол-во задач и проектов в работе (WIP-лимит). Не запускать сразу много, а запустить один-два, но зато с полной подготовкой.

☑️ Полная подготовка (full-kit) - вторая ключевая идея книги. Увы, мы принимаем как данное то, что в проектах много неопределенности, и позволяем себе не до конца собирать требования и нужную информацию. А зря. Неполнота данных, выросшая из поверхностной подготовки, - путь к 1) переделкам (“ой, а тут еще такое пожелание выявилось”) и 2) накоплению препятствий для потока.

🪫 Еще негативный фактор - дозирование. Многозадачность приводит к тому, что на выполнение задачи специалист выделяет минимально необходимое время (низкое дозирование), не вникая достаточно глубоко и широко… А это приводит к тому, что задача может скоро вернуться в переделку из-за непродуманности решения. Поэтому дозирование нужно увеличивать.

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

▶️ Такой вот “роман” - и да, он местами наивен и слеп по отношению к реальной бизнес-среде, в которой мы работаем. Но посыл “сотруднико-сбережения”, которое должно стоять за любой методологией, - разумный и гуманистичный)

👍 Рекомендую к прочтению менеджерам и не-менеджерам: понятно, кратко и человечно о важном на любом проекте!

🔥 Самые интересные материалы по управлению проектами за 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: рассказываю про свой опыт

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