🔥 Самые интересные материалы по управлению проектами за 2 недели
😐 Основы, гайды, инструменты
🙌 Google Project Management: Professional Certificate, часть 1, часть 2, часть 3
Большой и очень интересный обзор курса для проджектов от Гугла. Если вы думаете, что PM — это человек с планёрками и таблицами, Google вас нежно разубедит. Первая часть курса рассказывает, кто такой проектный менеджер, чем он отличается от просто организованного человека, и почему эмпатия важнее, чем PowerPoint. Здесь же — про жизненный цикл проекта, роли, артефакты и прочую терминологию, которую потом можно бросать в чаты, чтобы выглядеть умно. Вторая - про инициацию проекта, SMART-цели, распределение роли по RACI. Третья - про планирование, диаграмму проекта, риски, бюджеты и работу со стейкхолдерами.
😑 Анализ Cumulative Flow Diagram
Cumulative Flow Diagram (CFD) — это как кардиограмма проекта: показывает, где узкие места, где задачи застревают и какова общая производительность команды. Автор объясняет, как читать CFD, какие метрики извлекать и как интерпретировать типичные паттерны. Если линии расходятся — пора бить тревогу.
😟 KPI: Путь к успеху или ловушка неэффективности?
KPI — эти три буквы могут быть как путеводной звездой, так и камнем преткновения. Статья - о том, как превратить KPI из формальности в инструмент реального управления. Главное — связать их со стратегическими целями, а не просто измерять всё подряд.
👀 Каталог данных: что за зверь и с чем его едят
Каталог данных — это не просто список таблиц, а настоящий путеводитель по вашему информационному лесу. В «Спортмастере» решили навести порядок в данных, чтобы аналитики не искали нужную информацию, как иголку в стоге сена. Результат? Меньше дубликатов, больше понимания и, возможно, меньше головной боли.
🌀 Как сочетать календарное планирование и Agile
О том, как не сойти с ума, если вы вынуждены планировать по календарю, но живёте по спринтам. Рецепт автора: чёткие сроки — только для действительно «горящих» задач, всё остальное — по Agile, с гибкостью и свободой. Важно не противопоставлять методы, а сочетать их в зависимости от стадии проекта. Иначе вместо результата получите перегорание.
👋 Тестирую 10 систем управления проектами для агентств, веб-студий и не только
Автор протестировала 10 систем управления проектами, от YouGile до Easy Task, оценивая их функциональность, удобство и стоимость. Вывод: идеальной системы нет, но для каждой команды найдётся свой идеальный инструмент. Главное — понимать свои потребности и не бояться экспериментировать.
😎 Приоритизация бэклога. Максимальный гайд
Автор делится множеством методов приоритизации: от классической матрицы «Value vs Effort» до загадочного WSJF. Важно не столько выбрать идеальную методику, сколько создать систему, которая работает для вашей команды. И да, даже ChatGPT может помочь расставить приоритеты, если вы ему доверяете.
🏃♂️ Что такое Story Points и почему они причиняют боль командам
Story Points — идея хорошая, реализация... ну, как получится. Текст - о том, почему эти загадочные баллы иногда больше мешают, чем помогают. Оказывается, если превращать Story Points в часы, можно потерять весь смысл. А если использовать их правильно, они становятся мощным инструментом планирования.
🗡 Как контролировать выполнение и бюджет проекта. Простое руководство по методу освоенного объема (Earned Value Analysis)
Контроль проекта — это не только про дедлайны, но и про деньги. Метод освоенного объема (EVA) помогает понять, насколько вы отклоняетесь от плана и бюджета. Автор подробно объясняет, как применять EVA на практике, даже если вы не математик. С этим инструментом вы сможете не только отслеживать прогресс, но и прогнозировать будущее проекта.
😎 Дневники пиэма. Заметка 02: Функциональные колодцы (они же — silos)
Когда отделы компании живут своей жизнью, как соседи, которые здороваются только в лифте, возникают “функциональные колодцы”. Автор рассказывает, как такие «силосы» мешают кросс-функциональным проектам и что с этим делать. Из инструментов: RACI-матрица, раннее выявление зависимостей и здоровая инициатива.
🙌 Google Project Management: Professional Certificate, часть 1, часть 2, часть 3
Большой и очень интересный обзор курса для проджектов от Гугла. Если вы думаете, что PM — это человек с планёрками и таблицами, Google вас нежно разубедит. Первая часть курса рассказывает, кто такой проектный менеджер, чем он отличается от просто организованного человека, и почему эмпатия важнее, чем PowerPoint. Здесь же — про жизненный цикл проекта, роли, артефакты и прочую терминологию, которую потом можно бросать в чаты, чтобы выглядеть умно. Вторая - про инициацию проекта, SMART-цели, распределение роли по RACI. Третья - про планирование, диаграмму проекта, риски, бюджеты и работу со стейкхолдерами.
Cumulative Flow Diagram (CFD) — это как кардиограмма проекта: показывает, где узкие места, где задачи застревают и какова общая производительность команды. Автор объясняет, как читать CFD, какие метрики извлекать и как интерпретировать типичные паттерны. Если линии расходятся — пора бить тревогу.
KPI — эти три буквы могут быть как путеводной звездой, так и камнем преткновения. Статья - о том, как превратить KPI из формальности в инструмент реального управления. Главное — связать их со стратегическими целями, а не просто измерять всё подряд.
Каталог данных — это не просто список таблиц, а настоящий путеводитель по вашему информационному лесу. В «Спортмастере» решили навести порядок в данных, чтобы аналитики не искали нужную информацию, как иголку в стоге сена. Результат? Меньше дубликатов, больше понимания и, возможно, меньше головной боли.
О том, как не сойти с ума, если вы вынуждены планировать по календарю, но живёте по спринтам. Рецепт автора: чёткие сроки — только для действительно «горящих» задач, всё остальное — по Agile, с гибкостью и свободой. Важно не противопоставлять методы, а сочетать их в зависимости от стадии проекта. Иначе вместо результата получите перегорание.
Автор протестировала 10 систем управления проектами, от YouGile до Easy Task, оценивая их функциональность, удобство и стоимость. Вывод: идеальной системы нет, но для каждой команды найдётся свой идеальный инструмент. Главное — понимать свои потребности и не бояться экспериментировать.
Автор делится множеством методов приоритизации: от классической матрицы «Value vs Effort» до загадочного WSJF. Важно не столько выбрать идеальную методику, сколько создать систему, которая работает для вашей команды. И да, даже ChatGPT может помочь расставить приоритеты, если вы ему доверяете.
Story Points — идея хорошая, реализация... ну, как получится. Текст - о том, почему эти загадочные баллы иногда больше мешают, чем помогают. Оказывается, если превращать Story Points в часы, можно потерять весь смысл. А если использовать их правильно, они становятся мощным инструментом планирования.
Контроль проекта — это не только про дедлайны, но и про деньги. Метод освоенного объема (EVA) помогает понять, насколько вы отклоняетесь от плана и бюджета. Автор подробно объясняет, как применять EVA на практике, даже если вы не математик. С этим инструментом вы сможете не только отслеживать прогресс, но и прогнозировать будущее проекта.
Когда отделы компании живут своей жизнью, как соседи, которые здороваются только в лифте, возникают “функциональные колодцы”. Автор рассказывает, как такие «силосы» мешают кросс-функциональным проектам и что с этим делать. Из инструментов: RACI-матрица, раннее выявление зависимостей и здоровая инициатива.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤2⚡1🔥1💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😦 Менеджер проекта - карьера и навыки
💃 Как проджект‑менеджеру завершать проекты по разработке эффективно
Автор делится практическими рекомендациями по структурированному завершению цифровых проектов. Главный инструмент — чОткий чек-лист: убедиться, что все задачи или фичи закрыты, провести демонстрацию, оформить и подписать акты. Затем PM обновляет документацию, обучает пользователей и анализирует метрики (например, DORA, NPS, satisfaction) — чтобы понять, что прошло успешно, а что улучшить. А дальше -ретроспектива, отчёт по результатам и урокам, чтобы оптимизировать процессы в будущем.
🪨 Как стать project‑менеджером за год с нуля
Менеджер проектов из «Диасофта» (не знаю, зачем я тут упомянул компанию) рассказывает о пути от проектного администратора к PM‑руководителю за год. Ключевые шаги: вести статус‑отчёты😐 и Excel‑логирование, затем — параллельно брать на себя ведение проектов и взаимодействие с клиентами. Опыт показал: пять «почему?» и практика дают понимание проблемного ядра — это эффективный метод борьбы с поверхностными задачами. Ещё важна проактивность — брать инициативу выше должностных формальностей, быть готовым к ответственности. Чувство ответственности, оптимизм и умение находить нестандартные решения помогают преодолевать «точку кипения».
🤔 Личный опыт руководством проектами в ИТ и геймдеве
Сравнительный анализ управления IT‑проектами и геймдевом. Геймдев требует более глубокой интеграции различных дисциплин — арт, звук, UX, нарратив, - а значит, требует гибкости и высокой адаптивности PM. Описывается пошаговый процесс: сбор требований (BRD), формализация бэклога, проектирование MVP, контроль бюджета и управление рисками. PM‑роль сводится к фасилитации, координации коммуникаций и устранению блокеров, а не к директивному управлению.
😠 Успешность проекта зависит от уровня таланта лидера: от Google до Telegram
Про “метод Барского”, оценивающий когнитивные способности лидеров и их связь с результатами проектов. Метод выявляет сильную связь между уровнем таланта и способностью формировать команды, фундаментально влияющие на развитие продукта. Это позволяет инвесторам и PM анализировать риски и потенциал проекта на основе когнитивного профиля ключевых участников.
🔨 Путь из разраба в лида: что я понял об ответственности
Про переход от роли разработчика к лидеру, важность умения слушать и брать ответственность. Про важность неформального лидерства (техническая экспертиза медленно трансформируется в способность фасилитировать встречи). И еще про менторство: полезней не навязывать знания, а помочь людям найти свой путь развития.
😏 Как принимать решения под давлением — и не терять фокус
О стратегиях принятия решений при высоком давлении: выделять приоритеты, принять неопределенность, вовлекать ключевых участников и документировать мысли и т.д. Ну и важно вовлекать стейкхолдеров на ранних стадиях, чтобы исключить сюрпризы, - прозрачность решений укрепляет коллективную ответственность и доверие. А еще очень здорово внедрять хотя бы простые механизмы документирования, а то потом не добьешься - почему и зачем было принято решение…
👩💻 Грейды в управлении проектами (Junior/Middle/Senior)
Вкратце: Junior отвечает за администрирование, Middle — за управление проектом, Senior — за стратегию, многопроектность и наставничество. Среди ключевых навыков: Junior — базовые методы и внимательность, Middle — навыки коммуникации и риск‑менеджмента, Senior — стратегическое мышление и финансовая ответственность . Приводятся примеры поведения в конфликтных ситуациях и чек-листы для самооценки по грейдам.
☺️ Тимлид в команде джунов: путь к доверю и развитию команды
Опыт создания поддерживающей среды для команды из стажёров и джунов. Первый шаг — остаться «играющим тренером»: участвовать в аналитике и одновременно руководить, чтобы сохранять контекст и доверие. Система поддержки: обучающие 1‑на‑1, ретроспективы, пространство для ошибок. Адаптивность: каждый требует разного уровня контроля, поэтому подходы подбираются индивидуально.
Автор делится практическими рекомендациями по структурированному завершению цифровых проектов. Главный инструмент — чОткий чек-лист: убедиться, что все задачи или фичи закрыты, провести демонстрацию, оформить и подписать акты. Затем PM обновляет документацию, обучает пользователей и анализирует метрики (например, DORA, NPS, satisfaction) — чтобы понять, что прошло успешно, а что улучшить. А дальше -ретроспектива, отчёт по результатам и урокам, чтобы оптимизировать процессы в будущем.
Менеджер проектов из «Диасофта» (не знаю, зачем я тут упомянул компанию) рассказывает о пути от проектного администратора к PM‑руководителю за год. Ключевые шаги: вести статус‑отчёты
Сравнительный анализ управления IT‑проектами и геймдевом. Геймдев требует более глубокой интеграции различных дисциплин — арт, звук, UX, нарратив, - а значит, требует гибкости и высокой адаптивности PM. Описывается пошаговый процесс: сбор требований (BRD), формализация бэклога, проектирование MVP, контроль бюджета и управление рисками. PM‑роль сводится к фасилитации, координации коммуникаций и устранению блокеров, а не к директивному управлению.
Про “метод Барского”, оценивающий когнитивные способности лидеров и их связь с результатами проектов. Метод выявляет сильную связь между уровнем таланта и способностью формировать команды, фундаментально влияющие на развитие продукта. Это позволяет инвесторам и PM анализировать риски и потенциал проекта на основе когнитивного профиля ключевых участников.
Про переход от роли разработчика к лидеру, важность умения слушать и брать ответственность. Про важность неформального лидерства (техническая экспертиза медленно трансформируется в способность фасилитировать встречи). И еще про менторство: полезней не навязывать знания, а помочь людям найти свой путь развития.
О стратегиях принятия решений при высоком давлении: выделять приоритеты, принять неопределенность, вовлекать ключевых участников и документировать мысли и т.д. Ну и важно вовлекать стейкхолдеров на ранних стадиях, чтобы исключить сюрпризы, - прозрачность решений укрепляет коллективную ответственность и доверие. А еще очень здорово внедрять хотя бы простые механизмы документирования, а то потом не добьешься - почему и зачем было принято решение…
Вкратце: Junior отвечает за администрирование, Middle — за управление проектом, Senior — за стратегию, многопроектность и наставничество. Среди ключевых навыков: Junior — базовые методы и внимательность, Middle — навыки коммуникации и риск‑менеджмента, Senior — стратегическое мышление и финансовая ответственность . Приводятся примеры поведения в конфликтных ситуациях и чек-листы для самооценки по грейдам.
Опыт создания поддерживающей среды для команды из стажёров и джунов. Первый шаг — остаться «играющим тренером»: участвовать в аналитике и одновременно руководить, чтобы сохранять контекст и доверие. Система поддержки: обучающие 1‑на‑1, ретроспективы, пространство для ошибок. Адаптивность: каждый требует разного уровня контроля, поэтому подходы подбираются индивидуально.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3❤2👍2👏1🏆1💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😠 Команда проекта
😇 Дизайн бюджетной организационной структуры, ч. 1
О важности разработки бюджетной структуры в рамках проектного планирования, где каждый элемент (бюджетная единица) становится «сферой ответственности». Автор предлагает разбивать организацию на чёткие центры затрат и управления, что облегчает контроль ресурсов и позволяет нам (менеджерам) визуализировать и оптимизировать бюджетные потоки.
😠 Блеск и нищета KPI
О том, как KPIне работают в проектах: с одной стороны — мотивируют и дают направление, с другой — искажают поведение и способствуют формализму. KPI помогает менеджеру ориентироваться на ключевые показатели, но требует чёткого определения, периодического пересмотра и балансировки количественных и качественных метрик. Еще автор касается рисков использования KPI без контекста: ведь тупо увеличение показателя может не равняться реальному улучшению продукта.
🥰 Гайд по совмещению 5 работ
Любопытная статья о том, как можно (!) работать на 50 работах и что для этого потребуется - в первую очередь, жёсткая приоритезация и распределение времени с чёткими временными блоками, выделением зон ответственности, чтобы избежать пересечения. Также важно учиться делегировать и внедрять автоматизацию в задачи, особенно повторяющиеся. Короче, если есть желание…
😠 Почему джуны — это инвестиция
Да,РП джуны способны приносить значительную ценность, пусть и не сразу, но в будущем. Они источник свежих идей, энергии и мотивации, а своевременное включение и поддержка дают окупаемость через 6–12 месяцев. Ключевые шаги: выявление потенциала, честная оценка рисков, построение наставничества и планов роста. Затраты на обучение компенсируются вовлечённостью и созданием «культуры роста». Авторы дают методику работы с джунами, включая регулярные оценки прогресса, обратную связь и адаптацию задач под уровень новичка.
🥺 Профиль компетенций команды проекта
Про создание профиля компетенций для команды (навыки, знания и опыт, необходимые на разных этапах проекта). Описывается, как профили компетенций помогают выявлять слабости, выстраивать планы обучения и оптимизировать ресурсное планирование. Мощный инструмент для оценки зрелости команды и целей по развитию. Особое внимание уделено адаптивности: под видом ролей должны быть конкретные навыки, а не просто титулы.
🥳 Новые процессы без боли: интеграция без сопротивления
Автор разбирает, как внедрять процессы — Kanban, Scrum или ритуалы — минимизируя сопротивление (и непонимание мемов). Главная рекомендация: вводить изменения постепенно, «чуть-чуть» и незаметно, чтобы команда адаптировалась естественно. В идеале - запуск пилотов в небольших группах, получение обратной связи, последующий эскалация процессов.
🫣 Работник должен перестать плакать перед тем, как вернуться к работе
Автор критически рассматривает ситуацию, когда энтузиазм команды превращается в выгорание — ночные дежурства и переработки якобы «для пользы». Как раз менеджер проекта и должен тут отследить переход от здоровой инициативы к постоянному стрессу, что снижает качество работы и мотивацию. В чек-листе для руководителя — 1-on-1, конструктивная обратная связь и напоминания об отдыхе (да, те самые “почему ты мне пишешь по работе после 18”).
🤯 Вовремя увольнять — забота о команде
О том, что своевременное прекращение сотрудничества с неэффективным сотрудником — часть ответственности ПМа и лидера команды. После трёх неуспешных попыток помощи необходим «жёсткий разговор» — иначе негативное поведение распространится на весь коллектив, негативно повлияет на мотивацию и динамику команды.
🥳 Команда на одной волне: неформальные правила ИТ
Кейс Альфа-Банка описывает реальные практики гибкой работы крупной IT-команды, сохраняя ритм даже при 17+ участниках Интересный факт — 10-дневные спринты с индивидуальными встречами, дэйли и ретроспективами, адаптированные под культуру команды. ПМ в такой команде - фасилитатор: организует процессы, уточняет бэклог, проводит демо и ретроспективы.
О важности разработки бюджетной структуры в рамках проектного планирования, где каждый элемент (бюджетная единица) становится «сферой ответственности». Автор предлагает разбивать организацию на чёткие центры затрат и управления, что облегчает контроль ресурсов и позволяет нам (менеджерам) визуализировать и оптимизировать бюджетные потоки.
О том, как KPI
Любопытная статья о том, как можно (!) работать на 5
Да,
Про создание профиля компетенций для команды (навыки, знания и опыт, необходимые на разных этапах проекта). Описывается, как профили компетенций помогают выявлять слабости, выстраивать планы обучения и оптимизировать ресурсное планирование. Мощный инструмент для оценки зрелости команды и целей по развитию. Особое внимание уделено адаптивности: под видом ролей должны быть конкретные навыки, а не просто титулы.
Автор разбирает, как внедрять процессы — Kanban, Scrum или ритуалы — минимизируя сопротивление (и непонимание мемов). Главная рекомендация: вводить изменения постепенно, «чуть-чуть» и незаметно, чтобы команда адаптировалась естественно. В идеале - запуск пилотов в небольших группах, получение обратной связи, последующий эскалация процессов.
Автор критически рассматривает ситуацию, когда энтузиазм команды превращается в выгорание — ночные дежурства и переработки якобы «для пользы». Как раз менеджер проекта и должен тут отследить переход от здоровой инициативы к постоянному стрессу, что снижает качество работы и мотивацию. В чек-листе для руководителя — 1-on-1, конструктивная обратная связь и напоминания об отдыхе (да, те самые “почему ты мне пишешь по работе после 18”).
О том, что своевременное прекращение сотрудничества с неэффективным сотрудником — часть ответственности ПМа и лидера команды. После трёх неуспешных попыток помощи необходим «жёсткий разговор» — иначе негативное поведение распространится на весь коллектив, негативно повлияет на мотивацию и динамику команды.
Кейс Альфа-Банка описывает реальные практики гибкой работы крупной IT-команды, сохраняя ритм даже при 17+ участниках Интересный факт — 10-дневные спринты с индивидуальными встречами, дэйли и ретроспективами, адаптированные под культуру команды. ПМ в такой команде - фасилитатор: организует процессы, уточняет бэклог, проводит демо и ретроспективы.
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤3👍2💘2🔥1
🔥 Самые интересные материалы по управлению проектами за 2 недели
🤩 Основы, гайды, инструменты (ч.1)
🤩 Как спроектировать сложный цифровой продукт: метод КРИ
Про «Карту реализации историй» (КРЯ) — инструмент систематизации пользовательских историй и требований в дизайнерских и IT-проектах. КРИ строится на принципах анализа и синтеза: истории группируются, уточняются, выстраиваются в логическую последовательность по сценарию использования . Инструмент позволяет визуализировать связь между бизнес-целями, пользовательским опытом и технической реализацией, обеспечивая обоснованность каждого шага. Это помогает команде избежать разнобоя в подходах и создает «живую» карту продукта для планирования спринтов.
🤩 Почему нужен Nexus, когда команда не помещается в рамки двух пицц
Когда команда превышает ~15 человек («двухпиццный» лимит), классический Scrum перестаёт эффективно масштабироваться. Методология Nexus предлагает лёгкую, но систематизированную фасилитацию для синхронизации нескольких команд: общие спринты и объединённые артефакты. Это позволяет удерживать координацию без превращения в SAFe‑гиганта: минимальная бюрократия и максимальная гибкость. “Нексус” снижает риски, связанные с разбросом планов, дублированием работы и недостаточной интеграцией артефактов. Короче, адаптация аджайла для крупняка.
🤩 Может ли ИИ помочь в оценке проекта? Пробуем на реальном примере
Статья про систему Project Calc, сочетающую GPT‑4.1 и DeepSeek для оценки трудоёмкости задач и подсветки потенциальных рисков Подход использует ИИ как «второе мнение» — сравнивая аналогичные оценки, анализируя расхождения и поднимая вопросы, которые человек может упустить. ИИ задаёт уточняющие вопросы, например: нужна ли защита от ботов или админ‑панель, что помогает избежать скрытых требований, а ПМ на выходе получает расширенный список сценариев и рисков.
🤩 Голдратты. Выбор. Правила Голдратта (конспект книги)
Про принципы критического мышления по Голдратту, применимые к проектам и бизнесу. Суть — фокусироваться на ключевом конфликте, разделяя проблему на простые «почему?»‑вопросы, чтобы выявлять корневую причину и избегать поверхностных симптомов. Для проектов рекомендуется пятишаговая схема: определить цель, выявить препятствия, разработать план, выполнить и проверить результат. Ну и акцент на том, что только эмпирическая проверка гипотез (эксперименты) избавляет от догм и помогает принимать решения на честных данных.
🤩 Как выстроить работу с фичами в мобильной разработке
Автор вводит чёткий процесс перехода от абстрактных идей к специфичным задачам, ключ которого — три вопроса: «Что не так?», «Как понять, что стало лучше?» и «Почему именно сейчас?» Притормаживание на этапе анализа помогает собрать данные, уточнить требования и избежать технического долга и бессмысленного «делания кнопки», так что мы получаем формулу гипотезы: «если — тогда — то улучшится», - а это, в свою очередь, обеспечивает согласованное понимание между заказчиком, аналитиком и разработчиком.
🤩 Как мы перерабатывали подход к фичам от клиентов
Про внедрение гибридной схемы обработки клиентских запросов, сочетающей тикетинг и SLA, чтобы избежать перегрузки и выгорания команды На начальном этапе принимали почти все обращения — для создания доверия, затем ввели фильтрацию, чтобы сохранить стратегическую фокусировку . Системный подход включал контроль SLA, что позволило разграничить «горящие» задачи от «хотелок» и сформировать устойчивую нагрузку. Управление приоритетами через SLA усиливает прозрачность, делает процесс предсказуемым и повышает доверие со стороны клиента.
Про «Карту реализации историй» (КРЯ) — инструмент систематизации пользовательских историй и требований в дизайнерских и IT-проектах. КРИ строится на принципах анализа и синтеза: истории группируются, уточняются, выстраиваются в логическую последовательность по сценарию использования . Инструмент позволяет визуализировать связь между бизнес-целями, пользовательским опытом и технической реализацией, обеспечивая обоснованность каждого шага. Это помогает команде избежать разнобоя в подходах и создает «живую» карту продукта для планирования спринтов.
Когда команда превышает ~15 человек («двухпиццный» лимит), классический Scrum перестаёт эффективно масштабироваться. Методология Nexus предлагает лёгкую, но систематизированную фасилитацию для синхронизации нескольких команд: общие спринты и объединённые артефакты. Это позволяет удерживать координацию без превращения в SAFe‑гиганта: минимальная бюрократия и максимальная гибкость. “Нексус” снижает риски, связанные с разбросом планов, дублированием работы и недостаточной интеграцией артефактов. Короче, адаптация аджайла для крупняка.
Статья про систему Project Calc, сочетающую GPT‑4.1 и DeepSeek для оценки трудоёмкости задач и подсветки потенциальных рисков Подход использует ИИ как «второе мнение» — сравнивая аналогичные оценки, анализируя расхождения и поднимая вопросы, которые человек может упустить. ИИ задаёт уточняющие вопросы, например: нужна ли защита от ботов или админ‑панель, что помогает избежать скрытых требований, а ПМ на выходе получает расширенный список сценариев и рисков.
Про принципы критического мышления по Голдратту, применимые к проектам и бизнесу. Суть — фокусироваться на ключевом конфликте, разделяя проблему на простые «почему?»‑вопросы, чтобы выявлять корневую причину и избегать поверхностных симптомов. Для проектов рекомендуется пятишаговая схема: определить цель, выявить препятствия, разработать план, выполнить и проверить результат. Ну и акцент на том, что только эмпирическая проверка гипотез (эксперименты) избавляет от догм и помогает принимать решения на честных данных.
Автор вводит чёткий процесс перехода от абстрактных идей к специфичным задачам, ключ которого — три вопроса: «Что не так?», «Как понять, что стало лучше?» и «Почему именно сейчас?» Притормаживание на этапе анализа помогает собрать данные, уточнить требования и избежать технического долга и бессмысленного «делания кнопки», так что мы получаем формулу гипотезы: «если — тогда — то улучшится», - а это, в свою очередь, обеспечивает согласованное понимание между заказчиком, аналитиком и разработчиком.
Про внедрение гибридной схемы обработки клиентских запросов, сочетающей тикетинг и SLA, чтобы избежать перегрузки и выгорания команды На начальном этапе принимали почти все обращения — для создания доверия, затем ввели фильтрацию, чтобы сохранить стратегическую фокусировку . Системный подход включал контроль SLA, что позволило разграничить «горящие» задачи от «хотелок» и сформировать устойчивую нагрузку. Управление приоритетами через SLA усиливает прозрачность, делает процесс предсказуемым и повышает доверие со стороны клиента.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤2🔥2💘2⚡1👍1
🔥 Самые интересные материалы по управлению проектами за 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‑диаграмм для описания атрибутов, операций, интерфейсов и типов связей.
Авторы анализируют отечественные мессенджеры и заодно предлагают свои (внезапно) решения, которые интегрируются прямо в таск-трекеры и облегчают коммуникацию внутри задач. Например, автоматическую транскрипцию голосовых сообщений, которая позволяет команде быстро найти нужную информацию, не прослушивая длинные аудиозаписи.
часть 5,
часть 6
Про первые три части писал в предыдущем дайджесте. А на этот раз автор касается таких тем, как описана иерархия ролей: Project‑Manager (отдельный проект), Program‑Manager (группа проектов) и Portfolio‑Manager (стратегический портфель); подготовка устава проекта на этапе инициации — от краткого описания до целей, результатов и чётких границ объёма; сочетание Agile и Waterfall для адаптации к различным условиям: предпочтениям стейкхолдеров, регуляторике, особенностям команды или внешних партнёров. И, кстати, в целом, приходит к гибридной модели: гибкость оценок и итераций по Agile, с формализацией документации и контрольных точек по Waterfall.
Команда Fix Price описывает выбор Scrum как оптимального пути выстраивания гибких и автономных команд. Основной аргумент: минимизация организационной перегрузки и быстрое получение результативного инкремента. Scrum позволяет разбить работу на циклы (спринты), а роли (Scrum‑Master, Product‑Owner) фиксируют ответственность за процессы. Всё это помогает «не слить фокус» в рутине и ускоряет реакцию на изменения.
Кейс hh.ru описывает, как несколько продуктовых команд (“оркестр”) синхронизируются без «дирижёра» — в рамках квартального планирования. Планирование осуществляется на макро-уровне каждые три месяца, что позволяет определить ключевые инициативы и исключить локальные конфликты. Роль PM — не дирижировать, а координировать обсуждение приоритетов и зависимостей между командами.
Целая серия статей про системный подход к выявлению и моделированию сущностей предметной области с помощью UML, классификацию объектов, выделение абстракций — сущностей, бизнес-объектов и интерфейсов, роль ER‑ и UML‑диаграмм для описания атрибутов, операций, интерфейсов и типов связей.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥3❤2💘2⚡1👍1
Всем привет!
Встречайте https://pro-digest.ru/
Проектный дайджест существует уже пару лет и для многих стал привычным форматом) И автор этому очень рад 🥰
Но у формата есть ограничения, например:
- искать и делать подборки по телеге и по дайджестам на хабре/vc тяжко;
- часть материалов снимается с публикации или недоступна для каких-то регионов "по разным причинам"...
Поэтому я сделал простенький сайт, на котором любой желающий может:
а) увидеть сразу все материалы, участвовавшие в моих обзорах;
б) почитать микро-рецензии;
в) сделать подборки по ключевым словам (просто вводя текст);
г) сделать подборки по тегам (самые частые темы);
д) и даже скачать сохраненный pdf статьи (вроде работает).
Старожилы помнят, что раньше такое я делал в Notion, но, увы, работа с сервисом "усложнилась" 😒
Пока сайтик в бета-тесте: загружены статьи за последний год с чем-то (свыше 1000, и еще столько же на подходе), теги тоже размечены не везде, нагрузочные возможности непонятны etc.
В планах - сортировка, рейтинги статей и прочие приятные мелочи.
Но уже вполне себе база знаний по управлению проектами.
Пользуйтесь на здоровье, пишите отзывы и замечания в лс 😘
Встречайте https://pro-digest.ru/
Проектный дайджест существует уже пару лет и для многих стал привычным форматом) И автор этому очень рад 🥰
Но у формата есть ограничения, например:
- искать и делать подборки по телеге и по дайджестам на хабре/vc тяжко;
- часть материалов снимается с публикации или недоступна для каких-то регионов "по разным причинам"...
Поэтому я сделал простенький сайт, на котором любой желающий может:
а) увидеть сразу все материалы, участвовавшие в моих обзорах;
б) почитать микро-рецензии;
в) сделать подборки по ключевым словам (просто вводя текст);
г) сделать подборки по тегам (самые частые темы);
д) и даже скачать сохраненный pdf статьи (вроде работает).
Старожилы помнят, что раньше такое я делал в Notion, но, увы, работа с сервисом "усложнилась" 😒
Пока сайтик в бета-тесте: загружены статьи за последний год с чем-то (свыше 1000, и еще столько же на подходе), теги тоже размечены не везде, нагрузочные возможности непонятны etc.
В планах - сортировка, рейтинги статей и прочие приятные мелочи.
Но уже вполне себе база знаний по управлению проектами.
Пользуйтесь на здоровье, пишите отзывы и замечания в лс 😘
2❤10🎉7🔥3👏2🤯1💘1
🔥 Самые интересные материалы по управлению проектами за 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, командных встреч и здоровых границ.
Обзор-анализ огромного выбор AI‑курсов, доступных сегодня с выводом, что не все из них полезны PM на практике. Большинство - про поверхностное понимание «что такое LLM», хотя основной целью должны быть прикладные навыки.
Про реальные кейсы взаимодействия с заказчиками из разных культурных контекстов, - важны четкость, понимание ожиданий и умение вести переговоры «через переводчика» — буквально и метафорически. Часто главное — не техническое решение, а правильно выстроенный диалог на этапе требований.
Полутехнический, но прикольный материал от YooMoney. Описывают комплекс мер для ускорения доставки фич: оптимизация CI/CD, внедрение всяких удобных инструментов, автоматическое тестирование, «горячую замену» без деплоя — и регулярные ретроспективы. Роль ПМа - участие в формировании дорожных карт и приоритетов.
Про важность участия PM в архитектурных решениях, чтобы поддерживать стратегическую гибкость проекта. Если архитектура формализована с начала (а такое бывает… наверное…), PM может существенно снизить межкомандные зависимости и ускорить процессы. Особенно важны ранние спринты - сразу плюс 100 к управляемости.
🤡 Как методы Toyota, Дэвида Аллена, Барака Обамы и Мари Кондо делают IT-специалистов эффективнее и спокойнее
Как внедрение agile‑процессов возможно не только в IT‑разработке, но и в операционных подразделениях. Суть та же: короткие итерации, визуализация задач (канбан), регулярные ретроспективы и фокус на эффективности операций, а ПМ выступает как фасилитатор. Плюс использование PDCA-цикла и прочих привычных инструментов.
Коллеги из Avito - про то, как честные признания менеджера (“лидера”) о страхах и ошибках формируют доверие и усиливают командный дух. В IT, где давят дедлайны, умение показать уязвимость помогает команде выразить идеи и быстро реагировать на вызовы. ПМ может перенять практику такой эмпатии: открытость на ретроспективах, запрос мнения о решениях, признание ограничений.
Какие подходы планирования работают на самом деле, а какие нет: утреннее детальное планирование, дробление задач, баланс дня или Pomodoro. И выходит, что и они могут быть вредны, а важен не универсальный рецепт, а адаптация техник под команду и контекст. И вообще нужно все в комплексе.
Да, там именно 42 способа борьбы с выгоранием, включая Kanban, GTD, ZTD и утренние привычки и т.д. Тоже про, что без понимания “зачем” методы работают лишь наполовину, да и сам способы необходимо адаптировать под контекст и команду. Еще рекомендация - вводить привычки по шагам и измерять их эффект на циклами ретроспектив (ну типа “атомных привычек”).
Умеренный стресс по закону Йеркса–Додсона (да, еще одна ненужная информация) повышает концентрацию и работоспособность, но при чрезмерном — вызывает падение эффективности и риск выгорания, особенно в ИТ‑сфере. Ну и мы как менеджеры должны распознавать разницу. Рекомендации — развивать эмоциональный интеллект и формировать поддерживающую среду с помощью 1:1, командных встреч и здоровых границ.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤3👍3🔥2💘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 систем управления проектами. Все для контроля задач и команды
Подробное сравнение систем управления проектами (в основном отечественных) по пяти критериям: управление задачами, приоритезация, контроль метрик, автоматизация и интеграции. Приводятся кейсы, демонстрирующие, как каждая система помогает выявлять узкие места и распределять ресурсы. Отдельное внимание — генерации отчетов и прозрачности процессов.
😢 Как заморозить проект, но не отморозить команду
Бывает, что проект “замораживают”, - и автор пишет, что в этом случае делать, чтобы вообще не расстаться с сотрудниками и компанией) Из основного - необходимость ухода из режима активной разработки, сохранения поддержки и переориентации команды, чёткая коммуникация, проактивная трансформация ролей. Такой подход сохраняет мотивацию участников, позволяя избежать демотивационных синдромов.
😵💫Руководство по ресурсному планированию
Авторы из Weeek - про структурированный подход к ресурсному планированию в проектах, включая выявление необходимых навыков, анализ загрузки и учет резервов и отпусков. Основной инструмент — матрица загрузки, которая визуально показывает соответствие задач и специалистов, помогает выявить перегрузки и недозагрузки.
Про фундаментальную формулу управления рисками: риск = вероятность × критичность, где критика воспринимается как воздействие на сроки, бюджет, качество или репутацию. Есть классификатор рисков — внешние (задержки команд, API), внутренние (техдолг, баги) и организационные (отпуска
О слабых сторонах Story Points: они не отражают поток задач, дают иллюзию точности и плохо масштабируются между командами. Да и в целом, Story Points — лишь внутренний инструмент для выравнивания понимания, но для прогнозов важны еще и другие метрики. Автор предлагает применять статистику (Monte Carlo) и прогнозировать диапазоны вероятностей, а не использовать фиксированные значения SP.
Story Points — это командная относительная оценка, учитывающая сложность, риски и накладные издержки. Основная цель — повысить предсказуемость командного потока, а не сравнивать скорость разных групп. Если использовать их как универсальную метрику межкомандного сравнения — возникает искажение и снижение ценности.
Про адаптацию практики бережливого производства для IT-процессов. Суть Lean — выявить потери (время ожидания, лишние действия, дефекты) и систематически их устранять через Kaizen-подход. Отсюда и акцент на эмпирический переход: сначала пилотирование, затем масштабирование — вместо «бросания» всей команды сразу. Ну и надо обучать команду анализу потока создания ценности, визуализировать “узкие места”.
Подробное сравнение систем управления проектами (в основном отечественных) по пяти критериям: управление задачами, приоритезация, контроль метрик, автоматизация и интеграции. Приводятся кейсы, демонстрирующие, как каждая система помогает выявлять узкие места и распределять ресурсы. Отдельное внимание — генерации отчетов и прозрачности процессов.
Бывает, что проект “замораживают”, - и автор пишет, что в этом случае делать, чтобы вообще не расстаться с сотрудниками и компанией) Из основного - необходимость ухода из режима активной разработки, сохранения поддержки и переориентации команды, чёткая коммуникация, проактивная трансформация ролей. Такой подход сохраняет мотивацию участников, позволяя избежать демотивационных синдромов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥3👍1🎉1💘1
🔥 Самые интересные материалы по управлению проектами за 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 встреча на этой основе позволяет определить роли, ожидания и зоны ответственности ещё до старта. Из важного еще - упор на коммуникацию с ключевыми стейкхолдерами и оформление документа концепции, который станет договорённостью между заказчиком и командой.
Авторы из Weeek - про структурированный подход к ресурсному планированию в проектах, включая выявление необходимых навыков, анализ загрузки и учет резервов и (да-да, особенно сейчас актуально) отпусков. Основной инструмент — матрица загрузки, которая визуально показывает соответствие задач и специалистов, помогает выявить перегрузки и недозагрузки. Важный этап — постоянный пересмотр плана с учетом эффективности, изменений сроков и появляющихся
Метод Пирамиды Минто для структурированных коммуникаций: начинать с сути, краткого вывода, затем детали по принципу “вопрос-ответ”. Метод помогает эффективно донести идею за 5 секунд — идеально для перегруженных руководителей (да и исполнителей). При разрешении конфликтов или заявленных вопросах в проекте — сначала «выстрелить» главной мыслью, затем развернуть аргументы.
Идеально для нынешнего питерского "лета": про опыт применения метода FFF (First Features Freeze) — ранней заморозки объема задач (скоупа) перед разработкой, чтобы избежать излишней неопределённости. Подход позволяет зафиксировать первичный объем работ, не блокируя будущее развитие, и оставляет пространство для изменений. Особенно полезен для интеграционных проектов и крупных модулей.
Команда Content AI делится опытом: классические фреймворки (MoSCoW, ICE, RICE) перестали справляться с ростом бэклога. Авторы представляют собственный кастомный метод, учитывающий сложность фич, бизнес-приоритеты и технический долг, с итеративным пересмотром приоритетов на основе данных и обратной связи.
🧜♂️ Problem solving в ИТ
Про инструменты мышления для решения проблем в условиях неопределённости. Это подход длительного поиска решения, не шаблонная техника, а итеративный путь через гипотезы его причин и тестирование решений. Включает анализ корней проблемы (все эти наши/ваши “5 почему”), генерацию вариантов решений и их прототипирование.
Авторы критически оценивают TOGAF как стандарт архитектуры предприятия — его применимость в проектах и ограничения. TOGAF охватывает бизнес-, data-, application- и технологическую архитектуру — но требует прям большой адаптации к проектному контексту. PM должен настраивать их под масштабы и срок проекта, без внедрения лишней бюрократии, поэтому рекомендуется использовать TOGAF как базис, но облегчённый, чтобы не выйти из agility. Кто не знает про TOGAF - ставьте огонек, поизучаем)
Про причины, по которым Agile-принципы могут провалиться — от формального применения до отсутствия адекватной поддержки и культуры. Если ритуалы проводятся «по книжке» и без “зачем?”, то теряется смысл и энергия команды, да и вообще происходит нарушения главного принципа гибкости, что приводит к “затоксичиванию“ разработки.
И еще один текст про «Agile-детокс», практической направленности) Автор - за пересмотр каждой церемонии, каждой ретроспективы под вопросом «зачем?». Всё лишнее и чересчур ритуальное нужно вычистить, не тратить время и силы на “псевдо-деятельность”. И в итоге команда снова начинает думать «мы делаем А не потому, что должны, а потому, что это приносит ценность».
Как выстроить концепцию проекта, чтобы привлечь нужную команду (если она у вас, конечно, есть): нужно ясно описать цель, ценность и результаты. Kick-off встреча на этой основе позволяет определить роли, ожидания и зоны ответственности ещё до старта. Из важного еще - упор на коммуникацию с ключевыми стейкхолдерами и оформление документа концепции, который станет договорённостью между заказчиком и командой.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤3🔥3💘2👍1🤝1
🔥 Самые интересные материалы по управлению проектами за 2 недели
🍫 Менеджер проекта: карьера и навыки (ч.1)
🍫 Исследование 5000 вакансий и резюме проектных менеджеров
Проанализировали более 3000 вакансий и 2000 резюме PM, - и выявил разрыв в ожиданиях (зарплатные ожидания в резюме превышают предложения примерно в 1.6 раза). Основные навыки — 1С😱 , аналитика, продакт-менеджмент — востребованы, но часто вакансии не указывают вообще конкретных требований. Также выявили сильный разброс опыта: вакансии делятся на категории «младшие» и «старшие», а резюме показывают более равномерный рост. Ну и ожидаемо образовательный бэкграунд влияет меньше, чем опыт работы (я вот филолог по диплому так-то).
🍫 Отпуск руководителя
История тимлида, который ушёл в отпуск сразу после релиза важного проекта, … и ничего не случилось!! Типа зрелость процессов и автономность команды. Запланированный отпуск становится «performance review» уровня PM: если всё работает без него — система управления выстроена хорошо. Успешный PM — скорее организатор, чем вдохновитель /ваш кэп/ (Недавно я тоже был в отпуске и тоже ничего не случилось плохого, спасибо, коллеги😄 )
🍫 Как не утонуть в операционке: система фокусов для тимлида
Статья предлагает трёхслойную модель фокусов тимлида: люди, продукты, система. В фокусе людей — регулярные 1:1 и внимательное слушание для выявления выгорания и мотивации. В продуктовом фокусе — вовлечение команды в ”почему” для фич(ей). Системный уровень — код-ревью, ретроспективы — часто отодвигается, но именно он обеспечивает устойчивость.
🍫 Как масштабировать применение ИИ. Аналитика и рекомендации от McKinsey
Перевод исследования McKinsey: внедрение ИИ требует перестройки бизнес-процессов, а не просто добавления технологии. ИИ может взять на себя до 60% нагрузки — это требует стратегического планирования и участия CEO, адаптации инструментов, оценки рисков, прозрачности и контроля инфраструктуры. В общем, надо не внедрять ИИ изолированно, а интегрировать в систему принятия решений.
🍫 Изменения. Инструменты, которые работают
Про то, как вносить изменения и как защищать их от всяких угроз. Для РП - тема важная, по моему личному опыту, сопротивление изменениям - один из ведущих факторов провала проекта. Потому и рекомендую материал и инструменты автора - сторителлинг, визуализированную аналитику, карту стейкхолдеров итп. Логика - выбрать пилотную зону, замерять результаты на ней, потом масштабировать. Участие команды - конечно же, тоже ключевой фактор.
🍫 Хватит «внедрять таск‑трекеры». Просто попробуйте этот вариант для ленивых
6 простых процессов в таск-трекере YouGile, чтобы сразу увидеть эффект без перегрузки, втч простую Kanban-доску, песочницу для экспериментов, онбординг, стратегическое планирование, работу с подрядчиками и обзор проектов. Такой подход поможет быстро стартовать и учить команду работать структурированно, да и внедряется за час и вроде как на любом трекере.
🍫 Тихая сила: как управлять не через контроль, а через влияние
Про резонансную роль лидера, который управляет примером, а не приказом. Типа не «скажи, чтобы сделали», а «сделай сам» (привет, делегирование). Важный инструмент — признание ошибок самим лидером, которое разрешает подобное поведение для других. Менеджер демонстрирует отсутствие токсичности и готовность нести последствия — и команда следует через доверие.
Проанализировали более 3000 вакансий и 2000 резюме PM, - и выявил разрыв в ожиданиях (зарплатные ожидания в резюме превышают предложения примерно в 1.6 раза). Основные навыки — 1С
История тимлида, который ушёл в отпуск сразу после релиза важного проекта, … и ничего не случилось!! Типа зрелость процессов и автономность команды. Запланированный отпуск становится «performance review» уровня PM: если всё работает без него — система управления выстроена хорошо. Успешный PM — скорее организатор, чем вдохновитель /ваш кэп/ (Недавно я тоже был в отпуске и тоже ничего не случилось плохого, спасибо, коллеги
Статья предлагает трёхслойную модель фокусов тимлида: люди, продукты, система. В фокусе людей — регулярные 1:1 и внимательное слушание для выявления выгорания и мотивации. В продуктовом фокусе — вовлечение команды в ”почему” для фич(ей). Системный уровень — код-ревью, ретроспективы — часто отодвигается, но именно он обеспечивает устойчивость.
Перевод исследования McKinsey: внедрение ИИ требует перестройки бизнес-процессов, а не просто добавления технологии. ИИ может взять на себя до 60% нагрузки — это требует стратегического планирования и участия CEO, адаптации инструментов, оценки рисков, прозрачности и контроля инфраструктуры. В общем, надо не внедрять ИИ изолированно, а интегрировать в систему принятия решений.
Про то, как вносить изменения и как защищать их от всяких угроз. Для РП - тема важная, по моему личному опыту, сопротивление изменениям - один из ведущих факторов провала проекта. Потому и рекомендую материал и инструменты автора - сторителлинг, визуализированную аналитику, карту стейкхолдеров итп. Логика - выбрать пилотную зону, замерять результаты на ней, потом масштабировать. Участие команды - конечно же, тоже ключевой фактор.
6 простых процессов в таск-трекере YouGile, чтобы сразу увидеть эффект без перегрузки, втч простую Kanban-доску, песочницу для экспериментов, онбординг, стратегическое планирование, работу с подрядчиками и обзор проектов. Такой подход поможет быстро стартовать и учить команду работать структурированно, да и внедряется за час и вроде как на любом трекере.
Про резонансную роль лидера, который управляет примером, а не приказом. Типа не «скажи, чтобы сделали», а «сделай сам» (привет, делегирование). Важный инструмент — признание ошибок самим лидером, которое разрешает подобное поведение для других. Менеджер демонстрирует отсутствие токсичности и готовность нести последствия — и команда следует через доверие.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤4🔥3💘2🙏1🏆1
Всем привет!
Помните, я запилил на основе ссылок и резюме из своих дайджестов простенькую базу знаний pro-digest.ru ?
🆕 А я с новостями:
- Добавил ещё полтысячи материалов — в основном за 2024 год.
Всё как обычно: с резюме, тегами и (почти везде) PDF-версиями, если оригинал вдруг «испарился». Теперь в базе свыше 1600 текстов.
- Появилась кнопка "⭐️" — можно отмечать любимые статьи.
Потом нажимаете "Избранное" — и всё, как будто у вас свой маленький дайджест. Действует только для конкретного устройства, но все равно прикольно)
🤔 Что дальше?
Буду прикручивать сортировки (например, по дате, объему, сложности, годноте), подчистим теги. Ну и другие фишки — по настроению и фидбэку.
Если вдруг у вас есть идеи, хотелки или баги — пишите в комменты или ЛС, порадуйте меня))
Пользуйтесь, сохраняйте, шерите, жалуйтесь — мне всё полезно.
pro-digest.ru — заходите, пока не положили хостинг 😅
Помните, я запилил на основе ссылок и резюме из своих дайджестов простенькую базу знаний pro-digest.ru ?
🆕 А я с новостями:
- Добавил ещё полтысячи материалов — в основном за 2024 год.
Всё как обычно: с резюме, тегами и (почти везде) PDF-версиями, если оригинал вдруг «испарился». Теперь в базе свыше 1600 текстов.
- Появилась кнопка "⭐️" — можно отмечать любимые статьи.
Потом нажимаете "Избранное" — и всё, как будто у вас свой маленький дайджест. Действует только для конкретного устройства, но все равно прикольно)
🤔 Что дальше?
Буду прикручивать сортировки (например, по дате, объему, сложности, годноте), подчистим теги. Ну и другие фишки — по настроению и фидбэку.
Если вдруг у вас есть идеи, хотелки или баги — пишите в комменты или ЛС, порадуйте меня))
Пользуйтесь, сохраняйте, шерите, жалуйтесь — мне всё полезно.
pro-digest.ru — заходите, пока не положили хостинг 😅
3🔥9👏4❤3💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😐 Менеджер проекта: карьера и навыки (ч.2)
😐 Эмпатия: мощный ресурс руководителя в IT
Про эмпатию, которая позволяет строить глубокое доверие, удерживать таланты и улучшать мотивацию. PM с эмпатией слышит реальные проблемы, слышит эмоции, поддерживает психологическую безопасность и повышает вовлечённость. Такой стиль помогает формировать культуру, в которой люди остаются, радуются походу на работу, а не только выполняют задачи.
😬 Почему все ломается, или Зачем менеджеру в ИТ софт‑скилы
А тут в тему - 5 реальных кейсов, где проблемы не в багах, а в «тишине, обиде и недоверии» в команде. Без эмпатии и мягких навыков никакие таск‑трекеры не спасут проект. Менеджер/лидер — прежде всего коммуникатор, который задаёт тон доверия и обеспечивает безопасность диалогов. И конечно, в каждом кейсе софт-скиллы превратились в инструмент решения — будь то 1:1, фасилитация или построение атмосферы (нет, не душной).
😅 Как не убить инициативу в команде: ошибки тимлидов
Тимлид, берущий на себя всё, убивает инициативу и рост команды.Отсюда - важно документировать процессы, вводить формальную оценку рисков и распределять ответственность.
👍 Коммуникации: как говорить, чтобы вас слушали
Три практики для проджекта: говори кратко, не говори «невозможно», а начни с сути. Особенно важно привлекать внимание слушателя с первых слов . Так PM переводит разговор в конструктив: вместо формулировки проблемы — запрос ресурсов, вместо «мы не успеем» — «нам нужен аналитик до понедельника». Этот стиль ускоряет принятие решений и делает коммуникацию продуктивной.
👍 Ошибки молодого лида: что меняется, когда у тебя команда
Avito рассказывает о переходе от личному вкладу к командному, делясь болями начинающих тимлидов. Главные ошибки: попытка контролировать всё, неподготовленность к ответственности за несколько команд, недооценка коммуникаций. Рост менеджера — это переход на уровень структурирования работы, синхронизация между командами и настройка процессов. Рекомендации включают обучение софт-скиллам, делегированию и созданию видения для каждой команды.
🧃 Team‑building как инструмент ретроспективы
Большой гайд от команды Weeek (они вообще молодцы в контенте). А что если представить ретроспективу как тимбилдинг‑механизм со своими ролевыми упражнениями и визуализацией задач? Начинаем с анализа боли команды, чтобы сформулировать цель встречи. Затем — меняем формат, чтобы удерживать внимание и выявить глубинные проблемы. Роль ПМа - что-то вроде фасилитатора‑режиссёра: он создаёт атмосферу доверия, вовлекает всех участников и формирует почву для принятия решений.
Про эмпатию, которая позволяет строить глубокое доверие, удерживать таланты и улучшать мотивацию. PM с эмпатией слышит реальные проблемы, слышит эмоции, поддерживает психологическую безопасность и повышает вовлечённость. Такой стиль помогает формировать культуру, в которой люди остаются, радуются походу на работу, а не только выполняют задачи.
А тут в тему - 5 реальных кейсов, где проблемы не в багах, а в «тишине, обиде и недоверии» в команде. Без эмпатии и мягких навыков никакие таск‑трекеры не спасут проект. Менеджер/лидер — прежде всего коммуникатор, который задаёт тон доверия и обеспечивает безопасность диалогов. И конечно, в каждом кейсе софт-скиллы превратились в инструмент решения — будь то 1:1, фасилитация или построение атмосферы (нет, не душной).
Тимлид, берущий на себя всё, убивает инициативу и рост команды.Отсюда - важно документировать процессы, вводить формальную оценку рисков и распределять ответственность.
Три практики для проджекта: говори кратко, не говори «невозможно», а начни с сути. Особенно важно привлекать внимание слушателя с первых слов . Так PM переводит разговор в конструктив: вместо формулировки проблемы — запрос ресурсов, вместо «мы не успеем» — «нам нужен аналитик до понедельника». Этот стиль ускоряет принятие решений и делает коммуникацию продуктивной.
Avito рассказывает о переходе от личному вкладу к командному, делясь болями начинающих тимлидов. Главные ошибки: попытка контролировать всё, неподготовленность к ответственности за несколько команд, недооценка коммуникаций. Рост менеджера — это переход на уровень структурирования работы, синхронизация между командами и настройка процессов. Рекомендации включают обучение софт-скиллам, делегированию и созданию видения для каждой команды.
Большой гайд от команды Weeek (они вообще молодцы в контенте). А что если представить ретроспективу как тимбилдинг‑механизм со своими ролевыми упражнениями и визуализацией задач? Начинаем с анализа боли команды, чтобы сформулировать цель встречи. Затем — меняем формат, чтобы удерживать внимание и выявить глубинные проблемы. Роль ПМа - что-то вроде фасилитатора‑режиссёра: он создаёт атмосферу доверия, вовлекает всех участников и формирует почву для принятия решений.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤5👏2💘2👍1
🔥 Самые интересные материалы по управлению проектами за 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‑командами, анализ нормативных требований и адаптацию планов к регуляторным изменениям.
😱 Модель Кано: как отличить “Вау!” от обязательного
Про модель Кано и как классифицировать фичи на Must‑Be, Performance и Attractive. Это даёт проджектам инструмент определения приоритетов: обязательное («must») vs дифференцирующее. Важно правильно интерпретировать ответы пользователей, чтобы не тратить ресурсы на ненужные «
Наглядное сравнение Lean Startup, Scrum, Shape Up, Design Thinking и других методологий — с их контекстом применения, плюсами и ограничениями. При этом выбор методологии зависит от стадии продукта: например, Lean Startup эффективен на ранней стадии запуска, а Scrum — при регулярном обновлении зрелого продукта. А еще можно комбинировать подходы (ура! эклектика!).
Узнали? Согласны? Реальный кейс, где отсутствие проектной документации удорожило итерацию в пять раз (и это еще мало). Автор делает вывод: даже минимальное ТЗ + прототип экономят время и деньги. PM должен использовать документирование как инвестицию, а не ненужную формальность, а для этого делать ТЗ/доку легкой, понятной и согласованной.. Эффект: меньше рисков, меньше повторных правок, более точного попадания в потребности заказчика.
Автор описывает ранние признаки техдолга: задержки с оценками, длительные итерации, падение качества, длительный онбординг, недовольство тестировщиков. Предлагается диагностировать и категоризовать техдолг (технический, процессный, человеческий) для целенаправленного плана его снятия. Можно привлекать внешних аудиторов, чтобы выявить «захваченные» зоны и слепые пятна.
Про дилемму между долгосрочным планированием и гибкостью Agile. Он предлагает использовать квартальное планирование как мост между стратегией (годовая дорожная карта) и оперативной работой (спринты). Ключевая идея: квартал — достаточно долг для значимых итераций, но не столь жесток, чтобы терять адаптивность. При этом важно избегать бюрократии и формалистичных процедур под видом гибкости.
Автор показывает, что качественно подготовленное техническое задание минимизирует стоимость, время и количество уточнений при старте проекта. Готовить ТЗ надо, даже если клиент этого не сделал — и обязательно согласовывать его. Хорошее ТЗ — это документ, защищающий от расползания скоупа и резервирующий бюджет под экстра‑вопросы.Ну и важно обновлять ТЗ при изменениях — а не оставлять устаревшие версии.
Материал на VC.ru показывает, как Agile‑подходы помогли наладить коммуникацию с регуляторами — через прозрачность и итеративность, регулярные встречи с compliance‑командами, анализ нормативных требований и адаптацию планов к регуляторным изменениям.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥3❤1👍1🌚1💘1
🚰 В основе этого “проектного мировоззрения” понятие “потока”. Это поставка ценности заказчикам, над которой работает команда. Не диаграмма Ганта, не декомпозиция и бэклог, а непрерывный поток. Задача компании - дать потоку дорогу, не задерживать и не мешать превращаться в итоговый результат.
Незавершенка. Точнее, “мультипроектность”, много одновременно взятых командой и специалистом незавершенных проектов и задач. Многозадачность и мультизагруженность - зло. Идеал - это одна задача / один проект, на которых нужно держать фокус. Но как минимум, провести "триаж" - приоритезацию проектов и задач с результатом в виде полной (!) заморозки тех, которые менее критичны. Контролировать кол-во задач и проектов в работе (WIP-лимит). Не запускать сразу много, а запустить один-два, но зато с полной подготовкой.
☑️ Полная подготовка (full-kit) - вторая ключевая идея книги. Увы, мы принимаем как данное то, что в проектах много неопределенности, и позволяем себе не до конца собирать требования и нужную информацию. А зря. Неполнота данных, выросшая из поверхностной подготовки, - путь к 1) переделкам (“ой, а тут еще такое пожелание выявилось”) и 2) накоплению препятствий для потока.
Please open Telegram to view this post
VIEW IN TELEGRAM
3❤8👍5🔥3💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
🎄 Основы, гайды, инструменты (ч.1)
😾 Какие бывают риски проекта: полный список с примерами
Отличная детальная классификация рисков: внутренние (кадровые, процессы, даже служебные романы), внешние (экономика, регуляторные) и позитивные (возможности), - это помогает расширить понимание риск-менеджмента и распознавать риск не только как угрозу, но и как шанс, если правильно среагировать. Рекомендуется вести реестр, кодировать статус риска через цветовую шкалу (зелёный/жёлтый/красный - а какую еще вы ждали…) и назначать ответственных. А сам процесс управления рисками должен пройти через этапы: идентификация, анализ, планирование, мониторинг и эскалацию. В идеале еще и визуализированные в канбане.
🤩 Как оценивать сроки задач не «навскидку», а точно: инструмент и практики от Kaiten
Статья описывает методику оценки сроков не интуитивно, а через метрики: распределение нагрузки, исторические данные, буфер, учёт неопределённостей. Рекомендуется применять подход аналогии и параметрической оценки, умножая идеальную полученную оценку на коэффициенты с учётом отвлечений. Получается более точная прогнозируемость, снижение выгорания, повышение доверия внутри команды и со стороны заказчика.
😋 Управление изменениями в проекте с помощью service desk
Как новые требования возникает внезапно и могут сорвать сроки и бюджет, если их не сопровождать структурными процессами. А таким процессом и может стать сервис-деск, - как единая точка входа для запросов на изменения: формы, статусы, согласования и отслеживание, механизм объективного учёта изменений. Хаоса меньше, трассировка больше и больше связи с дорожной картой проекта (если она, конечно, у вас есть).
👊 Когда фидбек может уничтожить продукт
Автор предупреждает о риске слепо следовать каждому пользовательскому комментарию, идее, так как часто они не репрезентативны. Менеджер должен отбирать обратную связь, фокусируясь на её частоте, профиле пользователя и влиянии на продукт. Без фильтрации и структурирования фидбэк приводит к «лоскутному» интерфейсу и невнятной логике. Или просто пользователи не будут пользоваться тем, что долго и упорно просили… (знакомо?)
🤩 Что такое пайплайн (Pipeline) в разработке, продажах и проектах
Пайплайн - это последовательность шагов от идеи до релиза, визуализированная для прозрачности и контроля потока задач. Что-то вроде конвейера управления: каждый этап — от подготовки до QA — отслеживается и оптимизируется. Всё это вместе позволяет обнаружить “узкие места” и управлять потоком задач в реальном времени.
🐕 Были тысячи способов управлять проектами, но наши тимлиды выбрали эти
YouGile описывает планирование релизов через диаграмму Гантта и Miro: в результате имеем, “обратное планирование”, цели и ретро-проекции. Miro задействуем как стратегическую карту, а Гантт помогает увидеть сдвиги и задержки. И конечно же, канбан - доски поддерживают текущий поток работы, не перегружая сотрудников.
Отличная детальная классификация рисков: внутренние (кадровые, процессы, даже служебные романы), внешние (экономика, регуляторные) и позитивные (возможности), - это помогает расширить понимание риск-менеджмента и распознавать риск не только как угрозу, но и как шанс, если правильно среагировать. Рекомендуется вести реестр, кодировать статус риска через цветовую шкалу (зелёный/жёлтый/красный - а какую еще вы ждали…) и назначать ответственных. А сам процесс управления рисками должен пройти через этапы: идентификация, анализ, планирование, мониторинг и эскалацию. В идеале еще и визуализированные в канбане.
Статья описывает методику оценки сроков не интуитивно, а через метрики: распределение нагрузки, исторические данные, буфер, учёт неопределённостей. Рекомендуется применять подход аналогии и параметрической оценки, умножая идеальную полученную оценку на коэффициенты с учётом отвлечений. Получается более точная прогнозируемость, снижение выгорания, повышение доверия внутри команды и со стороны заказчика.
Как новые требования возникает внезапно и могут сорвать сроки и бюджет, если их не сопровождать структурными процессами. А таким процессом и может стать сервис-деск, - как единая точка входа для запросов на изменения: формы, статусы, согласования и отслеживание, механизм объективного учёта изменений. Хаоса меньше, трассировка больше и больше связи с дорожной картой проекта (если она, конечно, у вас есть).
Автор предупреждает о риске слепо следовать каждому пользовательскому комментарию, идее, так как часто они не репрезентативны. Менеджер должен отбирать обратную связь, фокусируясь на её частоте, профиле пользователя и влиянии на продукт. Без фильтрации и структурирования фидбэк приводит к «лоскутному» интерфейсу и невнятной логике. Или просто пользователи не будут пользоваться тем, что долго и упорно просили… (знакомо?)
Пайплайн - это последовательность шагов от идеи до релиза, визуализированная для прозрачности и контроля потока задач. Что-то вроде конвейера управления: каждый этап — от подготовки до QA — отслеживается и оптимизируется. Всё это вместе позволяет обнаружить “узкие места” и управлять потоком задач в реальном времени.
YouGile описывает планирование релизов через диаграмму Гантта и Miro: в результате имеем, “обратное планирование”, цели и ретро-проекции. Miro задействуем как стратегическую карту, а Гантт помогает увидеть сдвиги и задержки. И конечно же, канбан - доски поддерживают текущий поток работы, не перегружая сотрудников.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥4⚡1👍1😁1💘1
🔥 Самые интересные материалы по управлению проектами за 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. Стратегия для такого масштаба — разделение работы на этапы: выявление скрытых зависимостей, оценка рисков, пилотные миграции. Особое внимание уделялось изменениям среды, мониторингу производительности и четкой дорожной карте будущего проекта. И конечно, важна коммуникация: регулярные встречи на всех уровнях — от технарей до заказчиков, с визуализацией прогресса. Ну и всё получилось)
👀 Когнитивные искажения в принятии решений
Пересказ легендарной книги “Думать медленно - решать быстро” (знаю, что среди подписчиков есть те, кто еще не читал). В том числе - эффект ложной срочности, Зейгарник и другие — и как они мешают продуктивности. Отдельное спасибо - за акценты на искажения в управлении проектами и командами.
🐾Лучшие Канбан‑доски 2025: обзор для команд до 50‑ти
Обзор доступных российских канбан‑систем для команд до 50 человек (YouGile, Strive, Shtab, TEAMLY и другие, даже Б24), - авторы смотрят на скорость запуска, гибкость регулирования доступа и наличие бесплатных тарифов, лёгкость внедрения, возможность пригласить подрядчиков как гостей и наличие простых автоматизаций. Отдельно выделяются функции персонального планировщика, диаграммы Гантта и автоматических «сводок» — отчётов по задачам.
О ловушке постоянного добавления фич без фокуса и бизнес‑цели и вводе своего рода KPI для фичей: уменьшение оттока, увеличение конверсии, снижение барьеров. Иначе, если бэклог растёт быстрее исполнения, команда теряет способность доводить релизы до конца, специалисты тонут в задачах, интерфейс распухает как зефир, а пользователи почти не замечают изменений.
Автор предлагает “карту влияний” как ментальный каркас проекта на старте. Формат: Зачем (цель), Кто (роли или сегменты), Как (действия), Что (функции). Менеджер вместе с заказчиком проговаривает SMART‑цель, строит связи с функциональностью и фильтрует лишние задачи. Это помогает сократить объем задач, улучшить бюджетную предсказуемость и четкость видения. Карта становится контролем: решение принимать фичу или отказаться от неё сразу видно по влиянию на цель.
Метод Example Mapping помогает структурировать чистку бэклога на основе User Story, бизнес‑правил, примеров и вопросов, оформленных визуально на стикерах (!). Менеджер проводит сессии с представителями бизнеса, разработчиками и QA: записываются правила (синие), примеры (зелёные), вопросы (красные). Процесс длится до 25 минут на единицу бэклога.
Авторы собрали 10 проверенных книг по управлению проектами, к которым руководители команд возвращаются на разных этапах: от старта до масштабирования. На этапе изучения основ рекомендуются «PMBOK», «Scrum» и «Канбан» — они формируют базовое понимание методологий и подходов. Для найма и построения эффективной команды полезны «Кто» (про системный подход к подбору людей), «Пять пороков команды» (о причинах провалов в коммуникации) и «Радикальная прямота» (о честной, но бережной обратной связи). На этапе постановки целей предлагаются «OKR» и «Lean Analytics» (как задать измеримые ориентиры и работать с данными). Когда дело доходит до внедрения изменений, пригодится «Переключайтесь» с моделью Всадника, Слона и Тропы. Для роста — «Масштабированный скрам», помогающий сохранить гибкость в крупных командах.
Magnit Tech описывает кейс трансформации монолитной ERP-платформы на новую инфраструктуру — ответ на проблему устаревших систем и препятствий для time‑to‑market. Стратегия для такого масштаба — разделение работы на этапы: выявление скрытых зависимостей, оценка рисков, пилотные миграции. Особое внимание уделялось изменениям среды, мониторингу производительности и четкой дорожной карте будущего проекта. И конечно, важна коммуникация: регулярные встречи на всех уровнях — от технарей до заказчиков, с визуализацией прогресса. Ну и всё получилось)
Пересказ легендарной книги “Думать медленно - решать быстро” (знаю, что среди подписчиков есть те, кто еще не читал). В том числе - эффект ложной срочности, Зейгарник и другие — и как они мешают продуктивности. Отдельное спасибо - за акценты на искажения в управлении проектами и командами.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤4👍2💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
💃 Менеджер проекта - карьера и навыки
😱 Сторителлинг на пресейлах
Везде этот сторителлинг… И даже в пресейле. Авторы используют структуру: проблема, решение, выгода, - для первых касаний с клиентом и для установления доверия норм, снижается вероятность отказа и повышается конверсия лидов. Заказчику (лиду) инструмент помогает структурировать информацию и избегать хаоса в общении.
😁 Токсики, конфликты, демотивация: коммуникации решают проект
Про два реальных проекта: в одном — процессы были хорошо выстроены, но отсутствие эмоциональной обратной связи привело к увольнениям; в другом — чрезмерное общение всё спасло. Коммуникация — это инструмент, а не балласт: она должна быть эффективной и своевременной, тогда и “токсики” на деле окажутся очень полезными (знаем по себе, да). Менеджер должен не только планировать встречи, но и чувствовать эмоциональный климат команды, проводить «нытинговые» сессии, вовремя реагируя на напряжение.
😂 «Синдром менеджера» или как тревожность влияет на управление проектами
Про особый феномен — менеджерскую тревожность, вызванную высокой ответственностью, неопределённостью, многозадачностью и синдромом самозванца. Тревога снижает концентрацию, ослабляет принятие решений и разрушает восприятие команды. Автор предлагает фиксировать зоны неизвестности, разбирать их и создавать планы действия, чтобы снизить эмоциональную нагрузку. Также важно структурировать день, пересмотреть график и убрать лишние активности.
🤨 Делегирование, все всё знают, но не делают. Почему?
О двух (!) типа делегирования: исполнение (учебный формат) и управление (передача полномочий). Одно дело - давать подробные инструкции, другое - предоставлять свободу и ответственность квалифицированному сотруднику. Алгоритм делегирования включает выбор задачи, объяснение целей, согласование этапов и итоговый разбор результата. Такой подход позволяет выстраивать зрелую инфраструктуру лидерства, где сотрудники становятся наставниками, а менеджеру освобождается время для стратегии (эх, мечты…).
🤔 Когда проект не хочет сдаваться
Как этап сдачи проекта превратился в долгую боль из-за отсутствия ясных критериев приемки и методики испытаний (ПМИ). Без заранее прописанных ПМИ, команды не смогли согласовать работу, что привело к конфликтам между подрядчиками и заказчиком. И как же решили? ПМ организовал верификацию: каждый сценарий тестирования занесли в таблицу с шагами и результатами, отмечали статус «зашло»/«не зашло», и только после этого закрывали задачу. Появились ежедневные синхронки и прозрачные тикеты для критичных багов.
😎 Как стать идеальным менеджером и не выгореть: советы из практики
Автор из Avito делится адаптированным разбором книги Джули Чжо, бывшего руководителя продукта Facebook, и показывает, как стать эффективным менеджером, не теряя себя в роли лидера. Управление — это не о личных достижениях, а об успехе команды, где ключевые аспекты — люди, процессы и продукт.
💃 Трансформация руководителя из «подавителя» в лидера
Портрет руководителя «Кирилла» (гм…), который подавляет инициативу подчинённых, раздувая контроль и страх в команде. Цикл такой: использование эксперта, подавление при проявлении инициативы, слив сотрудника. И это аукается - команда разрушается. Рекомендации - переходить от устрашающего контроля — к влиянию через доверие и признание, т.е. помощь другим, а не подавление.
😔 Аналитик как скрытый руководитель проекта
Неожиданно (нет) аналитик часто невидимо выполняет функции ПМа, особенно в проектах без формального менеджера. Он участвует во всех фазах проекта: сбор требований, визуализация процессов, приоритизация задач и коммуникации между командой и заказчиком. Это позволяет ускорить решение вопросов, уменьшить количество ошибок и повысить прозрачность исполнения. Автор даёт рекомендации: внедрять универсальную визуализацию (BPMN, диаграммы, макеты), одностраничную документацию и таск-трекеры.
Везде этот сторителлинг… И даже в пресейле. Авторы используют структуру: проблема, решение, выгода, - для первых касаний с клиентом и для установления доверия норм, снижается вероятность отказа и повышается конверсия лидов. Заказчику (лиду) инструмент помогает структурировать информацию и избегать хаоса в общении.
Про два реальных проекта: в одном — процессы были хорошо выстроены, но отсутствие эмоциональной обратной связи привело к увольнениям; в другом — чрезмерное общение всё спасло. Коммуникация — это инструмент, а не балласт: она должна быть эффективной и своевременной, тогда и “токсики” на деле окажутся очень полезными (знаем по себе, да). Менеджер должен не только планировать встречи, но и чувствовать эмоциональный климат команды, проводить «нытинговые» сессии, вовремя реагируя на напряжение.
Про особый феномен — менеджерскую тревожность, вызванную высокой ответственностью, неопределённостью, многозадачностью и синдромом самозванца. Тревога снижает концентрацию, ослабляет принятие решений и разрушает восприятие команды. Автор предлагает фиксировать зоны неизвестности, разбирать их и создавать планы действия, чтобы снизить эмоциональную нагрузку. Также важно структурировать день, пересмотреть график и убрать лишние активности.
О двух (!) типа делегирования: исполнение (учебный формат) и управление (передача полномочий). Одно дело - давать подробные инструкции, другое - предоставлять свободу и ответственность квалифицированному сотруднику. Алгоритм делегирования включает выбор задачи, объяснение целей, согласование этапов и итоговый разбор результата. Такой подход позволяет выстраивать зрелую инфраструктуру лидерства, где сотрудники становятся наставниками, а менеджеру освобождается время для стратегии (эх, мечты…).
Как этап сдачи проекта превратился в долгую боль из-за отсутствия ясных критериев приемки и методики испытаний (ПМИ). Без заранее прописанных ПМИ, команды не смогли согласовать работу, что привело к конфликтам между подрядчиками и заказчиком. И как же решили? ПМ организовал верификацию: каждый сценарий тестирования занесли в таблицу с шагами и результатами, отмечали статус «зашло»/«не зашло», и только после этого закрывали задачу. Появились ежедневные синхронки и прозрачные тикеты для критичных багов.
Автор из Avito делится адаптированным разбором книги Джули Чжо, бывшего руководителя продукта Facebook, и показывает, как стать эффективным менеджером, не теряя себя в роли лидера. Управление — это не о личных достижениях, а об успехе команды, где ключевые аспекты — люди, процессы и продукт.
Портрет руководителя «Кирилла» (гм…), который подавляет инициативу подчинённых, раздувая контроль и страх в команде. Цикл такой: использование эксперта, подавление при проявлении инициативы, слив сотрудника. И это аукается - команда разрушается. Рекомендации - переходить от устрашающего контроля — к влиянию через доверие и признание, т.е. помощь другим, а не подавление.
Неожиданно (нет) аналитик часто невидимо выполняет функции ПМа, особенно в проектах без формального менеджера. Он участвует во всех фазах проекта: сбор требований, визуализация процессов, приоритизация задач и коммуникации между командой и заказчиком. Это позволяет ускорить решение вопросов, уменьшить количество ошибок и повысить прозрачность исполнения. Автор даёт рекомендации: внедрять универсальную визуализацию (BPMN, диаграммы, макеты), одностраничную документацию и таск-трекеры.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2🔥2😁2💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😱 Менеджер проекта (ч.1)
😀Как я перевёл команду в таск-трекер, а в итоге меня решили уволить
Да, вот такой кейс - перевод команды в таск-трекер завершился не успехом, а увольнением. И не потому, что хорошо внедрили и менеджер стал не нужен (не мечтайте). Причина в другом - в отсутствии чёткой цели: внедрение велось «в надежде на порядок», но без измеримых показателей. Менеджер выбрал слишком сложную систему, которая требовала обучения и не подходила команде, и в итоге задачи продолжали обсуждаться в чатиках, а трекер остался формальностью. Потом внедрили другой, правильный трекер, и наступил хеппи-енд.
😆Как сдать на РМР в 2025 году, если ты из России
Да, у героини материала получилось заиметь международный сертификат PMP, находясь в России. Несмотря на ограничения, экзамен доступен и подтверждён — на него можно подать заявку и сдавать на русском языке. Она прошла курс, использовала симуляторы, получала поддержку от преподавателей и коллег. Ну и еще важно заранее подготовиться к логистике и поддерживать мотивацию.
🙂Когда руководитель не руководитель. Синдром «Самого умного»
Автор рассматривает проблему менеджеров, которые остаются исполнителями и считают, что они «самые умные». Из-за этого такие руководители подбирают менее компетентную команду, принимают решения в одиночку и в итоге перегружаются. Ошибки остаются незаметными, потому что признать их — значит потерять своё превосходство. Это рушит доверие и мотивацию в коллективе. (Кстати, поделюсь своим любимым правилом - “если в команде я самый умный, значит мне пора ее покидать”, - и надеюсь, что мне еще не пора).
🥹Служить и защищать: тимлид на страже команды
Опыт роли тимлида как президента своей команды: важно не управлять и контролировать, а заботиться и защищать. Такой “президент” автоматизирует рутину — отчёты, задачи, интеграции, чтобы освободить разработчиков для созидательной работы. Кроме того, тимлид защищает команду от чрезмерного вмешательства менеджеров и заказчиков, избавляя от излишней отчётности. Короче, лидерство как служение.
🙃От табличек и звонков к онлайн-бронированию: кейс автоматизации в Ситидрайве
Прикольный кейс перевода сервиса бронирования из ручного процесса (таблицы, звонки) в онлайн-формат. Сделали MVP, столкнулись с проблемой масштабирования, затем внедрили автоматизированную систему: онлайн-заявки заменили ручную обработку, интеграция с приложением ускорила работу. Как результат - процесс остался стабильным, а команда освободилась от рутинных задач.
😌Как подготовиться к переходу на роль тимлида и как вернуться, если не вывезли
Аня из Avito описывает путь от сеньора к тимлиду, даёт советы, как переходить осознанно и что делать, если не справляешься. Вопросики себе: действительно ли готов быть руководителем, готов ли тратить время на митинги, “человекоугодничество”. Про сам переход, когда в первые месяцы наибольшее внимание уделяется обучению, установке границ ответственности и наставничеству. Ну и никто не запрещает выкатиться обратно - тут тоже много рекомендаций.
😀Как я перевёл команду в таск-трекер, а в итоге меня решили уволить
Да, вот такой кейс - перевод команды в таск-трекер завершился не успехом, а увольнением. И не потому, что хорошо внедрили и менеджер стал не нужен (не мечтайте). Причина в другом - в отсутствии чёткой цели: внедрение велось «в надежде на порядок», но без измеримых показателей. Менеджер выбрал слишком сложную систему, которая требовала обучения и не подходила команде, и в итоге задачи продолжали обсуждаться в чатиках, а трекер остался формальностью. Потом внедрили другой, правильный трекер, и наступил хеппи-енд.
😆Как сдать на РМР в 2025 году, если ты из России
Да, у героини материала получилось заиметь международный сертификат PMP, находясь в России. Несмотря на ограничения, экзамен доступен и подтверждён — на него можно подать заявку и сдавать на русском языке. Она прошла курс, использовала симуляторы, получала поддержку от преподавателей и коллег. Ну и еще важно заранее подготовиться к логистике и поддерживать мотивацию.
🙂Когда руководитель не руководитель. Синдром «Самого умного»
Автор рассматривает проблему менеджеров, которые остаются исполнителями и считают, что они «самые умные». Из-за этого такие руководители подбирают менее компетентную команду, принимают решения в одиночку и в итоге перегружаются. Ошибки остаются незаметными, потому что признать их — значит потерять своё превосходство. Это рушит доверие и мотивацию в коллективе. (Кстати, поделюсь своим любимым правилом - “если в команде я самый умный, значит мне пора ее покидать”, - и надеюсь, что мне еще не пора).
🥹Служить и защищать: тимлид на страже команды
Опыт роли тимлида как президента своей команды: важно не управлять и контролировать, а заботиться и защищать. Такой “президент” автоматизирует рутину — отчёты, задачи, интеграции, чтобы освободить разработчиков для созидательной работы. Кроме того, тимлид защищает команду от чрезмерного вмешательства менеджеров и заказчиков, избавляя от излишней отчётности. Короче, лидерство как служение.
🙃От табличек и звонков к онлайн-бронированию: кейс автоматизации в Ситидрайве
Прикольный кейс перевода сервиса бронирования из ручного процесса (таблицы, звонки) в онлайн-формат. Сделали MVP, столкнулись с проблемой масштабирования, затем внедрили автоматизированную систему: онлайн-заявки заменили ручную обработку, интеграция с приложением ускорила работу. Как результат - процесс остался стабильным, а команда освободилась от рутинных задач.
😌Как подготовиться к переходу на роль тимлида и как вернуться, если не вывезли
Аня из Avito описывает путь от сеньора к тимлиду, даёт советы, как переходить осознанно и что делать, если не справляешься. Вопросики себе: действительно ли готов быть руководителем, готов ли тратить время на митинги, “человекоугодничество”. Про сам переход, когда в первые месяцы наибольшее внимание уделяется обучению, установке границ ответственности и наставничеству. Ну и никто не запрещает выкатиться обратно - тут тоже много рекомендаций.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍5❤2⚡1🔥1💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
😱 Менеджер проекта (ч.2)
😐 Памятка менеджеру: Запрещённые фразы в IT
Интересный список типичных фраз, которые резко снижают эффективность общения с командой и заказчиками. Самая опасная — “какого, простите, х…” ”этого нет в ТЗ”: она обостряет конфликты и убивает коммуникацию, даже если вы правы. Такие фразы создают атмосферу отчуждения и непрофессионализма. Вместо этого автор предлагает быть помощником, а не критиком, и помогать клиенту, а не доказывать свою правоту.
🚑 Вас наняли спасать проект — вот что пойдёт не так
Часто компании нанимают "спасателя" проектов, которому дают карт-бланш (ура!) и хаос (не ура…). Но увы, без чёткой цели, полномочий и поддержки сверху он обречён. Чаще всего такие менеджеры тушат пожары (и совсем не всегда успешно) - и теряют силу. И если вас берут на такую роль, лучше заранее проверить на собеседовании, действительно ли организация готова к изменениям. А еще статья предлагает три инструмента для запуска перемен, если всё-таки вы решились спасать мир.
📝 Сеньор знает лучше? Как управлять очень опытными разработчиками
Как руководить разработчиками, которые технически сильнее тимлида. Признание их экспертизы — первый шаг: надо включать их в принятие решений, задавая нужные вопросы. В то же время, лидер остаётся ответственным за результат, а значит важно установить ясные границы: когда слушать, а когда принимать решение самому. Такой подход укрепляет доверие команды и вообще бустит решение проблем и задач.
😏 Как расти в карьере и не сгореть: руководство для тех, кто хочет всё успеть и всему научиться
Не будет открытием, что большинство IT-шников выгорают не из-за денег, а из-за неправильного подхода. И советы автор статьи дает весьма несложные: вместо героических трудов — микрообучение по 20 минут в день, а само деление задач должно быть по энергии, а не по времени. Работайте в пиковые часы, отдыхайте каждые 90 минут, автоматизируйте рутинные задачи. Цели должны быть достижимыми, причем шаг за шагом, а не какими-то героическими усилиями (от которых потом долго отходишь).
👀 7 актуальных метанавыков, чтобы вести за собой команды
Блог Хабра представил семь “метанавыков” (записываем словечко), которые, по мнению авторов, отличают эффективного лидера. Среди них — осознанность, умение быстро вникать в новое, слушание и спокойное реагирование на кризис, способность замечать детали. Еще сегодня важны гибкость и эмоциональный интеллект. Метанавыки помогают адаптироваться и вести команду в условиях изменений.
😡 Как управлять джуном, мидлом и сеньором одновременно: применяем модель Херси — Бланшара
Модель Херси — Бланшара — это управленческая модель, которая помогает выбирать стиль руководства в зависимости от зрелости сотрудника по конкретной задаче. Она основывается на двух ключевых параметрах: компетентности (навыках) человека и его мотивации (готовности работать над задачей). Автор применяет модель для команды разработки с разной зрелостью: джун доверяешь меньше, сеньору — больше. По мере роста компетентности и мотивации меняется стиль руководства — от прямых указаний до делегирования. Ну и рассказывает, как определить текущий уровень сотрудника и адаптировать подход, чтобы избежать выгорания лидера и сохранить мотивацию команды.
Интересный список типичных фраз, которые резко снижают эффективность общения с командой и заказчиками. Самая опасная — “какого, простите, х…” ”этого нет в ТЗ”: она обостряет конфликты и убивает коммуникацию, даже если вы правы. Такие фразы создают атмосферу отчуждения и непрофессионализма. Вместо этого автор предлагает быть помощником, а не критиком, и помогать клиенту, а не доказывать свою правоту.
Часто компании нанимают "спасателя" проектов, которому дают карт-бланш (ура!) и хаос (не ура…). Но увы, без чёткой цели, полномочий и поддержки сверху он обречён. Чаще всего такие менеджеры тушат пожары (и совсем не всегда успешно) - и теряют силу. И если вас берут на такую роль, лучше заранее проверить на собеседовании, действительно ли организация готова к изменениям. А еще статья предлагает три инструмента для запуска перемен, если всё-таки вы решились спасать мир.
Как руководить разработчиками, которые технически сильнее тимлида. Признание их экспертизы — первый шаг: надо включать их в принятие решений, задавая нужные вопросы. В то же время, лидер остаётся ответственным за результат, а значит важно установить ясные границы: когда слушать, а когда принимать решение самому. Такой подход укрепляет доверие команды и вообще бустит решение проблем и задач.
Не будет открытием, что большинство IT-шников выгорают не из-за денег, а из-за неправильного подхода. И советы автор статьи дает весьма несложные: вместо героических трудов — микрообучение по 20 минут в день, а само деление задач должно быть по энергии, а не по времени. Работайте в пиковые часы, отдыхайте каждые 90 минут, автоматизируйте рутинные задачи. Цели должны быть достижимыми, причем шаг за шагом, а не какими-то героическими усилиями (от которых потом долго отходишь).
Блог Хабра представил семь “метанавыков” (записываем словечко), которые, по мнению авторов, отличают эффективного лидера. Среди них — осознанность, умение быстро вникать в новое, слушание и спокойное реагирование на кризис, способность замечать детали. Еще сегодня важны гибкость и эмоциональный интеллект. Метанавыки помогают адаптироваться и вести команду в условиях изменений.
Модель Херси — Бланшара — это управленческая модель, которая помогает выбирать стиль руководства в зависимости от зрелости сотрудника по конкретной задаче. Она основывается на двух ключевых параметрах: компетентности (навыках) человека и его мотивации (готовности работать над задачей). Автор применяет модель для команды разработки с разной зрелостью: джун доверяешь меньше, сеньору — больше. По мере роста компетентности и мотивации меняется стиль руководства — от прямых указаний до делегирования. Ну и рассказывает, как определить текущий уровень сотрудника и адаптировать подход, чтобы избежать выгорания лидера и сохранить мотивацию команды.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍5❤2 2 2💘1
🔥 Самые интересные материалы по управлению проектами за 2 недели
👯 Команда проекта
😭 Почему ваш новый "гениальный" флоу вызывает у команды панику? Разбираем психологию сопротивления изменениям
Автор объясняет, что сопротивление изменениям — не признак вредности, а врождённая реакция мозга, стремящегося к экономии энергии и устойчивости. При внедрении новшеств появляется ощущение потери контроля и угрозы статусу экспертов, что блокирует команду. Изменение без подготовки вызывает стресс и влияет на самооценку. Хочешь успешную трансформацию - объясняй причины, вовлекай команду в процесс, выделяй время и ресурсы на адаптацию и будь готов к переговорам. Насильственные методы уничтожают доверие и создают технический и эмоциональный долг.
🤫 "Со мной что-то не так": психологическая работа с виной и агрессией у IT-специалистов
Статья погружает в эмоциональные запросы IT-специалистов, которые страдают от синдрома самозванца и ощущают внутреннюювино вину и агрессию. Надо работать не только с ситуацией, но и с внутренними установками: выявлять глубинные причины, бережно их прорабатывать. Важно научить выпускать агрессию конструктивно, направляя её на достижение целей, а не на самоуничтожение. Короче, не конфликт, а диалог (везде бы так).
😐 Должен ли аналитик уметь всё?
Полина, SA с десятилетним опытом, разбирает, насколько реалистично и эффективно требовать от аналитика владения всеми методами и подходами. Автор рассматривает ключевые инструменты: CustDev (интервью с пользователем), декомпозиция гипотез, анализ данных и создание брифов — и разбивает их по месту в процессе. Якобы подобный арсенал помогает не блуждать в догадках, а понимать реальные нужды бизнеса. А системному аналитику важно знать свои сильные стороны и работать в тандеме с другими специалистами, чтобы не превращаться в "универсала", теряющего глубину экспертизы...
🚶♀️ Секреты сильной команды
Психолог и руководитель делится секретом (?): команда — внезапно не просто группа сотрудников, а живой организм (я/мы), который достигает результатов благодаря синергии и взаимному росту. Оптимальный размер команды — 5–9 человек, иначе возникают проблемы взаимодействия и ответственности. Фишки сильной команды — договорённости, прозрачные отношения, личная ответственность и баланс лидерства: нужны и "тот, кто ведёт к результату", и "тот, кто создает атмосферу". А в идеальном мире можно еще и внедрить внутренний манифест, чтобы прям как отдельная республика)
😌 Пересечения и различия между бизнес-аналитиком в ИТ и бизнес-психологом
Сравнение роли бизнес-аналитика и бизнес-психолога: оба стремятся глубоко разобраться в проблемах и помочь организации, но работают с разными объектами. Аналитик меняет процессы, технологии и документацию, используя методики анализа и визуализации. Психолог — с людьми, групповой динамикой и коммуникациями. Вместе такие специалисты могут значительно повысить результативность изменений, преодолев сопротивление и сбои в взаимодействии. Так что если пользователи плачут вам в жилетку - это нормально)
🤣 Я тимлид, я так вижу! Когнитивные искажения и где они обитают
Как когнитивные искажения влияют на решения и работу команды. Например, эффект ложного консенсуса, регрессия к среднему, искажение при оценке решений по результату, а не по условиям. Осознание этих особенностей мышления помогает тимлиду принимать более взвешенные решения и понимать, почему логичные шаги не всегда приводят к ожидаемому результату. Ну и рекомендация — давать время для осмысления, привлекать мнение команды и различать эффект времени от прогресса.
👯 Команда проекта
Автор объясняет, что сопротивление изменениям — не признак вредности, а врождённая реакция мозга, стремящегося к экономии энергии и устойчивости. При внедрении новшеств появляется ощущение потери контроля и угрозы статусу экспертов, что блокирует команду. Изменение без подготовки вызывает стресс и влияет на самооценку. Хочешь успешную трансформацию - объясняй причины, вовлекай команду в процесс, выделяй время и ресурсы на адаптацию и будь готов к переговорам. Насильственные методы уничтожают доверие и создают технический и эмоциональный долг.
Статья погружает в эмоциональные запросы IT-специалистов, которые страдают от синдрома самозванца и ощущают внутреннюю
Полина, SA с десятилетним опытом, разбирает, насколько реалистично и эффективно требовать от аналитика владения всеми методами и подходами. Автор рассматривает ключевые инструменты: CustDev (интервью с пользователем), декомпозиция гипотез, анализ данных и создание брифов — и разбивает их по месту в процессе. Якобы подобный арсенал помогает не блуждать в догадках, а понимать реальные нужды бизнеса. А системному аналитику важно знать свои сильные стороны и работать в тандеме с другими специалистами, чтобы не превращаться в "универсала", теряющего глубину экспертизы...
Психолог и руководитель делится секретом (?): команда — внезапно не просто группа сотрудников, а живой организм (я/мы), который достигает результатов благодаря синергии и взаимному росту. Оптимальный размер команды — 5–9 человек, иначе возникают проблемы взаимодействия и ответственности. Фишки сильной команды — договорённости, прозрачные отношения, личная ответственность и баланс лидерства: нужны и "тот, кто ведёт к результату", и "тот, кто создает атмосферу". А в идеальном мире можно еще и внедрить внутренний манифест, чтобы прям как отдельная республика)
Сравнение роли бизнес-аналитика и бизнес-психолога: оба стремятся глубоко разобраться в проблемах и помочь организации, но работают с разными объектами. Аналитик меняет процессы, технологии и документацию, используя методики анализа и визуализации. Психолог — с людьми, групповой динамикой и коммуникациями. Вместе такие специалисты могут значительно повысить результативность изменений, преодолев сопротивление и сбои в взаимодействии. Так что если пользователи плачут вам в жилетку - это нормально)
Как когнитивные искажения влияют на решения и работу команды. Например, эффект ложного консенсуса, регрессия к среднему, искажение при оценке решений по результату, а не по условиям. Осознание этих особенностей мышления помогает тимлиду принимать более взвешенные решения и понимать, почему логичные шаги не всегда приводят к ожидаемому результату. Ну и рекомендация — давать время для осмысления, привлекать мнение команды и различать эффект времени от прогресса.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1🔥1👏1💘1 1 1
🔥 Самые интересные материалы по управлению проектами за 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 и другие), которые помогают управлять проектами и предотвращать ошибки. Примерчики, когда диаграммы спасали от кризисов, находили узкие места, распределяли ответственность и прогнозировали риски.
Основы, гайды, кейсы
🤩 Agile! — паразит поедающий до костей
Автор
Команда Kaiten собрала практический опыт применения Agile и Канбан вне ИТ — в маркетинге, HR и юридических отделах. Кратко - методики помогают строить итерации, тестировать гипотезы, ускорять коммуникацию и повышать эффективность. Юристы, например, использовали комбинацию спринтов и канбан-досок, чтобы закрывать стратегические задачи и текучку одновременно, повысив результативность с 15% до 60%. В маркетинге Agile помог интерактивно планировать кампании и синхронизироваться с другими функциями.
Автор показывает, что ИТ часто остаётся "обслуживающей" функцией, а не стратегическим партнёром бизнеса: бизнес-задачи задают с акцентом на "новую фичу", а не на стабильность продуктов. Такое восприятие провоцирует отложенные доработки, рост тикетов и конфликтную эскалацию. Решение “простое” - сменить мышление: ИТ должно стать ядром бизнес-процессов через прозрачность, сервисное мышление и интеграцию. А еще внедрять гибридный режим работы, укреплять доверие, менять KPI с бестолкового "среднее время закрытия тикета" на "устойчивость ключевых сценариев".
Авторский инструмент - контекстная диаграмма, которая позволит на старте проекта визуально обозначить границы взаимодействия систем и ключевых участников. Это простая схема, которую удобно рисовать в любой форме (хоть мышкой в пейнте) — важно, чтобы её понимали все заинтересованные лица. Такой подход предотвращает дискоммуникацию, снижает количество уточняющих уточнений, улучшает оценку сроков и снижает технический долг. Рекомендуется использовать эту схему в качестве опоры на ранних этапах проектирования и обсуждения архитектуры.
Что-то вроде фундаментальной модели бизнес-анализа: 1) изменение в контексте вызывает потребность, которая 2) формируется в требование, далее — 3) решение, которое приносит ценность заинтересованным сторонам. После реализации решение становится 4) частью нового контекста и запускает последующий цикл анализа. Есть практический чеклист для инициатора задачи (выяснить контекст, потребность, добиться понимания ценности, выявить заинтересованных и оценить реальные решения). Подход помогает структурировать работу аналитика, избегая поверхностности и неопределённости.
Коллеги из КОРУСа объясняют, как важен документ SLA (соглашение об уровне услуг) в проектах внедрения 1С. SLA задаёт правила игры: фиксирует обязанности и сроки обеих сторон, избавляя от неоднозначностей и конфликтов. В примерах показано, как задержки с доступом или данными могут сорвать сроки, если их не прописать заранее. Рекомендуется включить в SLA ресурсы, ответственных, форму данных и оплату, а также проводить регулярный мониторинг и корректировки.
Целых 11 визуальных инструментов (WBS, PERT, диаграмма Исикавы, RAID-log, VSM и другие), которые помогают управлять проектами и предотвращать ошибки. Примерчики, когда диаграммы спасали от кризисов, находили узкие места, распределяли ответственность и прогнозировали риски.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2 2💘1 1