🔥 Самые интересные материалы по управлению проектами за 2 недели
😏 Основы, гайды, инструменты
🎇 13 лучших аналогов Confluence в России в 2026 году
Собран обзор российских wiki и баз знаний (от корпоративных платформ до «лёгких» редакторов) с ключевыми критериями выбора: права и роли, совместное редактирование, версии/история, поиск по вложениям, интеграции и он-прем. Есть краткие профили каждого сервиса, ориентировочная стоимость, а также советы по миграции (экспорт/импорт, карты переноса, проверка ссылок и прав после переезда).
🥰 Как управлять знаниями командам разного формата. Что, если не Confluence
Разбор сценариев KM для продуктовых, проектных и сервисных команд: когда хватит «документации-как-кода» (Mermaid/Markdown), когда нужна полнофункциональная база знаний с правами, шаблонами и связью с задачами, и как организовать навигацию/обновление контента, чтобы страницы не превращались в «кладбище». Есть примеры структур и ритуалов поддержки актуальности.
🎄 От дашбордов к дофамину: как мозг измеряет эффективность поведения
Немного офтопа, который может быть полезен. Текст популярно рассказывает о нейромеханике «вознаграждения» и том, как метрики/дашборды влияют на мотивацию: почему частая и мелкая обратная связь лучше редкой большой, как избегать ложных стимулов (ванитные показатели - как вам новое словечко?), зачем привязывать цели к наблюдаемому поведению и как выстраивать циклы действия-сигнал-обучение, чтобы команда действительно улучшала процесс, а не рисовала цифры.
🍬 Лучшие таск-трекеры для управления проектами и задачами в 2026 году: обзор 19 российских сервисов
А теперь еще одно сравнение, на этот раз трекеров и того, как в них реализованы ключевые инструменты, методологии и фичи - канбан/скрам, иерархии задач, шаблоны проектов, диаграмма Ганта, автоматизации/роботы, мобильные клиенты, он-прем/облако, импорт из Jira/Trello. Есть ориентиры по ценам. Отдельно отмечены тренды — встроенная аналитика потока, базовые AI-фичи (резюме переписок, автопостановки и прочееуже надоевшее).
☕ Как выбрать систему управления проектами за 7 шагов: подробное руководство и обзор ИСУП
Пошаговый фреймворк по выбору (если вы внезапно еще не определились). Кратко - собрать требования (процессы, доступы, отчёты), определить критерии оценки и веса, провести скрининг вендоров, запросить и увидеть демо, провести пилот на живых кейсах, рассчитать ROI и начать поэтапный запуск. Отдельно — типичные риски: сверхкастомизация, недооценка миграции данных и обучения, а также чек-листы для сравнения кандидатов.
🎅 Как быстро построить метрики для измерения эффективности разработчиков: готовое решение
Автор делится практикой быстрого старта: какие события и поля собирать из трекера, как строить базовые метрики потока (скрытый WIP, цикл-тайм, доля прерванных задач), и почему такие панели нельзя использовать как KPI для сравнения людей, но можно как инструмент улучшений процесса и командной нагрузки.
✴️ Как управлять проектами в форс-мажорной ситуации: хакерская атака и ежедневные потери в миллионы рублей
Кейс антикризисного управления по сабжу. Из инструментов - отдельный боевой канал и роли (командир инцидента - коммуникации - техлиды), жёсткий приоритет на критический бизнес-контур (все остальное побоку), короткие сроки решений, прозрачная информация для стейкхолдеров и постмортем без поиска виноватых. Итог — всё хорошо (с), восстановление инфраструктуры, затем плановая санация и укрепление периметра.
🎊 Жизненный цикл ERP-систем
Бесхитростный, но полезный текст - от выбора и внедрения до эксплуатации, развития и вывода из эксплуатации: что учитывать по этапам (управление изменениями, миграции данных, регламенты и роли), как планировать волны запуска, почему устойчивость определяется согласованностью процессов и ролей вокруг ERP, а не кодом…
Собран обзор российских wiki и баз знаний (от корпоративных платформ до «лёгких» редакторов) с ключевыми критериями выбора: права и роли, совместное редактирование, версии/история, поиск по вложениям, интеграции и он-прем. Есть краткие профили каждого сервиса, ориентировочная стоимость, а также советы по миграции (экспорт/импорт, карты переноса, проверка ссылок и прав после переезда).
Разбор сценариев KM для продуктовых, проектных и сервисных команд: когда хватит «документации-как-кода» (Mermaid/Markdown), когда нужна полнофункциональная база знаний с правами, шаблонами и связью с задачами, и как организовать навигацию/обновление контента, чтобы страницы не превращались в «кладбище». Есть примеры структур и ритуалов поддержки актуальности.
Немного офтопа, который может быть полезен. Текст популярно рассказывает о нейромеханике «вознаграждения» и том, как метрики/дашборды влияют на мотивацию: почему частая и мелкая обратная связь лучше редкой большой, как избегать ложных стимулов (ванитные показатели - как вам новое словечко?), зачем привязывать цели к наблюдаемому поведению и как выстраивать циклы действия-сигнал-обучение, чтобы команда действительно улучшала процесс, а не рисовала цифры.
А теперь еще одно сравнение, на этот раз трекеров и того, как в них реализованы ключевые инструменты, методологии и фичи - канбан/скрам, иерархии задач, шаблоны проектов, диаграмма Ганта, автоматизации/роботы, мобильные клиенты, он-прем/облако, импорт из Jira/Trello. Есть ориентиры по ценам. Отдельно отмечены тренды — встроенная аналитика потока, базовые AI-фичи (резюме переписок, автопостановки и прочее
Пошаговый фреймворк по выбору (если вы внезапно еще не определились). Кратко - собрать требования (процессы, доступы, отчёты), определить критерии оценки и веса, провести скрининг вендоров, запросить и увидеть демо, провести пилот на живых кейсах, рассчитать ROI и начать поэтапный запуск. Отдельно — типичные риски: сверхкастомизация, недооценка миграции данных и обучения, а также чек-листы для сравнения кандидатов.
Автор делится практикой быстрого старта: какие события и поля собирать из трекера, как строить базовые метрики потока (скрытый WIP, цикл-тайм, доля прерванных задач), и почему такие панели нельзя использовать как KPI для сравнения людей, но можно как инструмент улучшений процесса и командной нагрузки.
Кейс антикризисного управления по сабжу. Из инструментов - отдельный боевой канал и роли (командир инцидента - коммуникации - техлиды), жёсткий приоритет на критический бизнес-контур (все остальное побоку), короткие сроки решений, прозрачная информация для стейкхолдеров и постмортем без поиска виноватых. Итог — всё хорошо (с), восстановление инфраструктуры, затем плановая санация и укрепление периметра.
Бесхитростный, но полезный текст - от выбора и внедрения до эксплуатации, развития и вывода из эксплуатации: что учитывать по этапам (управление изменениями, миграции данных, регламенты и роли), как планировать волны запуска, почему устойчивость определяется согласованностью процессов и ролей вокруг ERP, а не кодом…
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🔥2
🔥 Самые интересные материалы по управлению проектами за 2 недели
2⃣ Основы, гайды, инструменты (2)
❄ Ваши ставки, господа…
Тем, кто помешан на теме оценок и прогнозов. Популярный разбор того, как люди и бизнес искажают вероятности: чем отличаются «коэффициенты» и вероятность, зачем нужны калиброванные прогнозы и как переносить это мышление в продуктовые решения и аналитику (работа с базовыми частотами, диапазоны, сценарии, обновление оценок по данным).
🎅 Как организовать работу с внезапной сложной задачей и не уронить результат
Вкратце: «заморозить хаос» (собрать факты и ограничения), определить минимально ценный результат и временные рамки, нарезать работы на параллелящиеся куски с явными владельцами, выставить частые точки синка и/или демо, «защитить» фокус команды. Ну и как результат — оформить знания и встроить их в штатный процесс.
🍪 Что, если вы уже решаете не ту проблему?
Через сказку про Винни-Пуха автор показывает типичную ловушку того, как мы лечим симптом, а не причину. Команда наваливает фичи, но игнорирует неверную постановку задачи. Это видно по расползающемуся скоупу, вечным костылям, отсутствию роста метрик. Способ решения, в целом, понятный - перестать гнаться за фичами ради фич, сформулировать эффект, который мы ждем, проверить гипотезу на коротком эксперименте и только потом детализировать решение.
🍊 Как перестать ставить нереалистичные планы?
В Avito решилисобрать еще за что-то денег с пользователей делать планирование в соответствии с подходом «коротких горизонтов» Брайана Морана: цели на 12 недель (ничего себе короткие…), фокус на главных метриках, недельные обязательства и регулярный пересмотр приоритетов. Это снижает эффект “годовой мечты на слайдах”, делает выполнение наблюдаемым: меньше общих обещаний, больше конкретных шагов и результатов.
🎄 Возраст задачи: почему «залежавшаяся» задача убивает поток
Автор считает, что одна из главных метрик — возраст задачи. Чем дольше карточка висит, тем выше вероятность возвратов и потерь качества. Советы: следить за возрастом WIP, ставить лимиты на пребывание карточки задачи «в работе», выделять классы обслуживания и разгружать «стариков» (речь про задачи) раньше, чем они превращаются в «компост» бэклога.
🏠 Полезные хлопоты: кодекс сегментации проекта
Принципы «как съесть слона», т.е. проект: сегментировать задачи по ценности и риску, уменьшать связность между кусками, фиксировать интерфейсы заранее, держать маленькие, проверяемые результаты. Сегментация — это страховка от идеальных планов, которая упрощает координацию и ускоряет обратную связь.
🌟 Начать за здравие: как оформить спецификацию на разработку и ускорить процесс создания ПО
Коллеги из IBS предлагают шаблон спецификаций: цель и контекст, границы, роли и источники данных, сценарии и исключения, НФ-требования, критерии готовности и трассировка к задачам. Общий шаблон снижает разночтения между десятками аналитиков и ускоряет согласование без «свободного стиля» в документах.
🎄 Делайте хорошо и не делайте плохо. Амбивалентность требований в реальных проектах и как с ней бороться
Двусмысленные требования множат конфликты и доработки: одно слово — а на него три трактовки. Авторы пишут, что им помогло, в частности, пример и антипример для каждого пункта требований, словарик терминов, явные ограничения и исключения, согласованные сценарии ошибок.
🐴 Есть ли шанс правильно оценить трудозатраты?
Кратко - точной оценки не бывает, но можно приблизиться. Из инструментов - диапазоны вместо одной цифры, референсы(сравнение с прошлым), буфер на риски, контроль факта по вехам. И в целом, оценка живёт только в связке с пересмотром приоритетов и управлением ограничениями.
Тем, кто помешан на теме оценок и прогнозов. Популярный разбор того, как люди и бизнес искажают вероятности: чем отличаются «коэффициенты» и вероятность, зачем нужны калиброванные прогнозы и как переносить это мышление в продуктовые решения и аналитику (работа с базовыми частотами, диапазоны, сценарии, обновление оценок по данным).
Вкратце: «заморозить хаос» (собрать факты и ограничения), определить минимально ценный результат и временные рамки, нарезать работы на параллелящиеся куски с явными владельцами, выставить частые точки синка и/или демо, «защитить» фокус команды. Ну и как результат — оформить знания и встроить их в штатный процесс.
Через сказку про Винни-Пуха автор показывает типичную ловушку того, как мы лечим симптом, а не причину. Команда наваливает фичи, но игнорирует неверную постановку задачи. Это видно по расползающемуся скоупу, вечным костылям, отсутствию роста метрик. Способ решения, в целом, понятный - перестать гнаться за фичами ради фич, сформулировать эффект, который мы ждем, проверить гипотезу на коротком эксперименте и только потом детализировать решение.
В Avito решили
Автор считает, что одна из главных метрик — возраст задачи. Чем дольше карточка висит, тем выше вероятность возвратов и потерь качества. Советы: следить за возрастом WIP, ставить лимиты на пребывание карточки задачи «в работе», выделять классы обслуживания и разгружать «стариков» (речь про задачи) раньше, чем они превращаются в «компост» бэклога.
Принципы «как съесть слона», т.е. проект: сегментировать задачи по ценности и риску, уменьшать связность между кусками, фиксировать интерфейсы заранее, держать маленькие, проверяемые результаты. Сегментация — это страховка от идеальных планов, которая упрощает координацию и ускоряет обратную связь.
Коллеги из IBS предлагают шаблон спецификаций: цель и контекст, границы, роли и источники данных, сценарии и исключения, НФ-требования, критерии готовности и трассировка к задачам. Общий шаблон снижает разночтения между десятками аналитиков и ускоряет согласование без «свободного стиля» в документах.
Двусмысленные требования множат конфликты и доработки: одно слово — а на него три трактовки. Авторы пишут, что им помогло, в частности, пример и антипример для каждого пункта требований, словарик терминов, явные ограничения и исключения, согласованные сценарии ошибок.
Кратко - точной оценки не бывает, но можно приблизиться. Из инструментов - диапазоны вместо одной цифры, референсы(сравнение с прошлым), буфер на риски, контроль факта по вехам. И в целом, оценка живёт только в связке с пересмотром приоритетов и управлением ограничениями.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥2
🔥 Самые интересные материалы по управлению проектами за 2 недели
🕺 Менеджер проекта
🐱 От хаоса к фокусу: создаем ценность, не теряя себя
Эссе о том, как переключить внимание с бесконечного реагирования на ценность. Нужно фиксировать цель, урезать входящий поток сообщений, переводить обещания в наблюдаемые результаты, держать короткие петли обратной связи.
😭 Как мы перевели склад с «бумаги на цифру» силами руководителя проекта и одного разработчика
Кейс решения большой задачи малой кровью: обследование процессов, минимальный рабочий контур (приёмка, отгрузка, остатки), простая ТСД-форма вместо идеальной ERP, обучение на сменах и быстрые итерации по обратной связи. Результат — нормальный учёт и снижение ошибок без многолетней стройки.
🙂 Особенности совещаний на проектах внедрения ERP-систем
Коллеги рекомендуют разделять рабочие и статусные встречи, заранее фиксировать повестку и артефакты (решение, владелец и срок), заводить единый журнал открытых вопросов, держать в курсе заказчика. Ну и куда без типовых ошибок (например, «много людей без права решать» и «протоколы, которые никуда не попадают»).
😍 Как я научился без скандалов выходить из зомби-проектов систем автоматизации
Алгоритм мягкого выхода из конфликтов с заказчиками у автора такой: фактами показать несоответствие целей и ресурсов, предложить минимально безопасную остановку (например, передача каких-то артефактов), согласовать коммуникационный план и не ломать мосты — часто через год-два бизнес возвращается, но уже с более трезвыми ожиданиями.
☕️ PM vs PM в IT: двойной внутренний конфликт
Конфликт в том, что сверху — сроки и стейкхолдеры, а снизу — реальность команды и потока. Выживает тот, кто переводит требования в контролируемые планы, торгуется за бэклог и ресурсы, защищает фокус команды и регулярно пересобирает приоритеты по данным.
🐰 Спринты для отчётов, канбан для работы: как мы настроили Scrumban, чтобы угодить всем (и себе)
Команда оставила «наружный» Scrum для предсказуемых релизов (версии и даты), а внутри работает по Kanban. Схема подразумевает единую очередь по приоритету, жёсткое правило «берём верхнюю задачу», прозрачные политики входа и выхода. Итог — понятные обещания вовне и плавный поток внутри без разрывов на искусственные спринты.
Эссе о том, как переключить внимание с бесконечного реагирования на ценность. Нужно фиксировать цель, урезать входящий поток сообщений, переводить обещания в наблюдаемые результаты, держать короткие петли обратной связи.
Кейс решения большой задачи малой кровью: обследование процессов, минимальный рабочий контур (приёмка, отгрузка, остатки), простая ТСД-форма вместо идеальной ERP, обучение на сменах и быстрые итерации по обратной связи. Результат — нормальный учёт и снижение ошибок без многолетней стройки.
Коллеги рекомендуют разделять рабочие и статусные встречи, заранее фиксировать повестку и артефакты (решение, владелец и срок), заводить единый журнал открытых вопросов, держать в курсе заказчика. Ну и куда без типовых ошибок (например, «много людей без права решать» и «протоколы, которые никуда не попадают»).
Алгоритм мягкого выхода из конфликтов с заказчиками у автора такой: фактами показать несоответствие целей и ресурсов, предложить минимально безопасную остановку (например, передача каких-то артефактов), согласовать коммуникационный план и не ломать мосты — часто через год-два бизнес возвращается, но уже с более трезвыми ожиданиями.
Конфликт в том, что сверху — сроки и стейкхолдеры, а снизу — реальность команды и потока. Выживает тот, кто переводит требования в контролируемые планы, торгуется за бэклог и ресурсы, защищает фокус команды и регулярно пересобирает приоритеты по данным.
Команда оставила «наружный» Scrum для предсказуемых релизов (версии и даты), а внутри работает по Kanban. Схема подразумевает единую очередь по приоритету, жёсткое правило «берём верхнюю задачу», прозрачные политики входа и выхода. Итог — понятные обещания вовне и плавный поток внутри без разрывов на искусственные спринты.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
🔥 Самые интересные материалы по управлению проектами за 2 недели
🥰 Команда проекта
🚿 «Инструкция по выживанию», или как пережить отпуск старших коллег
Практичный гайд для тех, кто остался за старшего. Где быстро добыть контекст (задачи, почта, записи созвонов), у кого спросить, что зафиксировать в первый день (контакты со стороны заказчика, сроки, проблемы, приоритеты) и как держать ритм (типа проверять статусы в системе каждое утро, вести переписку в почте, не в мессенджерах, и опираться на артефакты).
🥺 Почему компетентные команды работают неэффективно
Разбираются скрытые причины того, почему мы “умные, но медленные”. Например, из-за переизбытка незакрытых задач, разрыва между ритуалами и реальными правилами, отсутствием общего источника правды и неявных ожидания. Рабочие противоядия — ограничение параллельной работы, явные политики процесса, регулярная ревизия договорённостей и метрики потока.
🐈 Командный вопрос: собираем направление разработки с нуля до полсотни человек
Опыт роста от «команда из одного» до 50+ разработчиков: как вводили уровни ответственности, стандарты и код-ревью, строили найм под продуктовую линейку и распределяли инициативы между несколькими продуктами. Акцент на том, что процессы вшиты в инструменты (проверки, соглашения), а роль лидов смещается от ручного контроля к настройке правил и среды.
🎮 Иллюзия сложности: как мы сами замедляем свои команды
Автор показывает, как сложность часто создаём мы сами, вводя лишние согласования, статусы, роли и запреты, которые превращают простой поток в болото.И авторы предлагают диету на минимально достаточные правила, сокращение точек ожидания и принятие решений ближе к работе.
😐 Поколение Z не ленивое, оно лингвистически чувствительное
Мысль простая, но интересная: зумеры не терпят небрежной речи, потому что живут в среде постоянной фиксации слов. Буквально одна двусмысленная формулировка в оффере или фидбэке может стоить сильного кандидата. Соотв., вывод - говорить точнее: объяснять критерии и ожидания, избегать скрытых угроз, использовать языки задач и фактов.
🌧 Практика масштабирования базы знаний: находи, документируй, делись
Как не похоронить базу знаний при росте: вводить роли (автор, рецензент и т.д.), настраивать жизненный цикл статьи, строить тематическую структуру вместо жёсткой иерархии отделов и держать метрики поиска.
😐 Распределённая agile-команда — испытание свободой в эпоху ИИ-лихорадки
О том, что дистант и ИИ усиливают перекосы: растёт ускоренное мышление, решения принимаются по ощущениям, а не по артефактам. В этой ситуации помогут жёстко оговорённые правила коммуникации, проверка предпосылок и короткие циклы обратной связи.
😈 Совы и жаворонки: кому на удалёнке жить хорошо?
Статья за планирование вокруг хронотипа, когда у вас в команде есть люди разных типов (а вы еще и сам(а) дятел). Рекомендации - дать команде больше асинхронности, фиксировать перекрытия для созвонов и не пытаться перешить биоритмы кожаных под единый график.
👿 Что раздражает коллег, но никто об этом не говорит: 8 вредных привычек в ИТ
Список некрупных, но бесящих и токсичных привычек. От «пингую в пять каналов» (да, я сам таким грешен) и «обещаю без ресурса» до «перебиваю на созвоне» и «не чиню свои поломки». Ну и рекомендации, как стать паинькой в команде, тоже есть.
Практичный гайд для тех, кто остался за старшего. Где быстро добыть контекст (задачи, почта, записи созвонов), у кого спросить, что зафиксировать в первый день (контакты со стороны заказчика, сроки, проблемы, приоритеты) и как держать ритм (типа проверять статусы в системе каждое утро, вести переписку в почте, не в мессенджерах, и опираться на артефакты).
Разбираются скрытые причины того, почему мы “умные, но медленные”. Например, из-за переизбытка незакрытых задач, разрыва между ритуалами и реальными правилами, отсутствием общего источника правды и неявных ожидания. Рабочие противоядия — ограничение параллельной работы, явные политики процесса, регулярная ревизия договорённостей и метрики потока.
Опыт роста от «команда из одного» до 50+ разработчиков: как вводили уровни ответственности, стандарты и код-ревью, строили найм под продуктовую линейку и распределяли инициативы между несколькими продуктами. Акцент на том, что процессы вшиты в инструменты (проверки, соглашения), а роль лидов смещается от ручного контроля к настройке правил и среды.
Автор показывает, как сложность часто создаём мы сами, вводя лишние согласования, статусы, роли и запреты, которые превращают простой поток в болото.И авторы предлагают диету на минимально достаточные правила, сокращение точек ожидания и принятие решений ближе к работе.
Мысль простая, но интересная: зумеры не терпят небрежной речи, потому что живут в среде постоянной фиксации слов. Буквально одна двусмысленная формулировка в оффере или фидбэке может стоить сильного кандидата. Соотв., вывод - говорить точнее: объяснять критерии и ожидания, избегать скрытых угроз, использовать языки задач и фактов.
Как не похоронить базу знаний при росте: вводить роли (автор, рецензент и т.д.), настраивать жизненный цикл статьи, строить тематическую структуру вместо жёсткой иерархии отделов и держать метрики поиска.
О том, что дистант и ИИ усиливают перекосы: растёт ускоренное мышление, решения принимаются по ощущениям, а не по артефактам. В этой ситуации помогут жёстко оговорённые правила коммуникации, проверка предпосылок и короткие циклы обратной связи.
Статья за планирование вокруг хронотипа, когда у вас в команде есть люди разных типов (а вы еще и сам(а) дятел). Рекомендации - дать команде больше асинхронности, фиксировать перекрытия для созвонов и не пытаться перешить биоритмы кожаных под единый график.
Список некрупных, но бесящих и токсичных привычек. От «пингую в пять каналов» (да, я сам таким грешен) и «обещаю без ресурса» до «перебиваю на созвоне» и «не чиню свои поломки». Ну и рекомендации, как стать паинькой в команде, тоже есть.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2🔥2
🔥 Самые интересные материалы по управлению проектами за 2 недели
🙏 Команда проекта
🌚 Новая норма ИТ-команд: недоговаривать
Автор описывает распространенную проблему «дефицита внимания» как, увы, скрытую норму рабочих отношений. Руководители недообъясняют, коллеги достраивают смысл сами, а команда тратит силы уже не на решение задачи, а на интерпретацию того, «что на самом деле имелось в виду». В итоге информационный вакуум быстро превращается в демотивацию, подозрения и токсик-вайб. Причем всё это особо не поменять - недосказанность в командах никуда не денется, поэтому сотруднику важно уметь распознавать этот вакуум.
🌞 Ричард Гельдрейх из Valve о работе в геймдеве и корпоративной культуре
Если вы, как и я, мечтали работать в компаниях а-ля Вальв, то вот можно почитать этот перевод откровенного текста Ричарда Гельдрейха о «самоорганизующихся» компаниях, где внешняя свобода и культ гениальности легко маскируют внутренние игры, манипуляции и неочевидные механизмы власти. Надо быть осторожнее с корпоративным маркетингом, не раскрывать работодателю лишнюю личную информацию и не путать красивый образ компании с качеством среды. Потому что за фасадом «плоской структуры» может скрываться не взрослая автономия, а довольно токсичная борьба без явных правил и ответственности.
🌞 «Прикинься шлангом и не высовывайся»: главное правило работы в системе
О столкновении молодого, инициативного сотрудника с системой, где старание, инициативность и желание делать лучше далеко не всегда ведут к признанию или росту. В жестко иерархичных структурах выживает не тот, кто работает сильнее, а тот, кто лучше понимает негласные правила и умеет не раздражать систему лишней заметностью.
🌚 Как за неделю собрать курс для отдела поддержки по базе знаний компании
У многих компаний уже есть всё нужное для быстрого обучения - статьи в базе знаний, рабочие инструкции, CRM или клиентская система, - но нет упакованного курса. Статья как раз о том, как превратить существующий контент в учебный контур без долгой методической стройки: взять готовые статьи, связать их в последовательность, добавить тесты, дедлайны, статусы прохождения и получить рабочий онбординг почти без переписывания материалов.
🌚 Почему Крош становится тимлидом, а Нюша выгорает: психология привязанности в ИТ-командах
(Специально для фанатов) Автор переносит теорию типов привязанности в профессиональную среду и показывает, как эмоциональная устойчивость, реакция на фидбек, отношение к дистанции и потребность в одобрении влияют на карьеру в ИТ едва ли не сильнее, чем техническая глубина. Надёжный тип легче выдерживает обратную связь, конфликты и рост ответственности, поэтому чаще естественно дорастает до лидских ролей; тревожный и избегающий типы по-разному уязвимы к перегрузке, неопределенности и выгоранию. Короче, не все проблемы сотрудников решаются советом «будь увереннее», потому что за их рабочим поведением часто стоит более глубокий эмоциональный паттерн.
👁 Как давление ожиданий ломает коммуникации в команде
О том, как высокие стандарты незаметно переходят в токсичную перфекционистскую культуру: люди перестают задавать вопросы, боятся озвучивать риски и смягчают формулировки до такой степени, что важная информация теряет остроту и смысл. У процесса несколько фаз - от культа безупречного результата до самоцензуры и страха ошибки. В итоге команда вроде бы остаётся профессиональной и собранной, но на деле всё больше молчит о проблемах, а значит, снижает собственную способность исправлять курс вовремя.
😔 Системный аналитик в эпоху ChatGPT: эволюция или революция
Одна из самых практичных статей в подборке: автор не спорит, заменит ли ИИ аналитика (гм…), а прямо показывает, что именно модели уже умеют делать хорошо - черновики требований, user stories, структурирование интервью, поиск противоречий, прототипы диаграмм и API-описаний. Но главный тезис не в автоматизации, а в смещении роли: аналитик всё меньше “писатель документов” и всё больше редактор, валидатор, синтезатор контекста и проектировщик процессов в команде.
Автор описывает распространенную проблему «дефицита внимания» как, увы, скрытую норму рабочих отношений. Руководители недообъясняют, коллеги достраивают смысл сами, а команда тратит силы уже не на решение задачи, а на интерпретацию того, «что на самом деле имелось в виду». В итоге информационный вакуум быстро превращается в демотивацию, подозрения и токсик-вайб. Причем всё это особо не поменять - недосказанность в командах никуда не денется, поэтому сотруднику важно уметь распознавать этот вакуум.
Если вы, как и я, мечтали работать в компаниях а-ля Вальв, то вот можно почитать этот перевод откровенного текста Ричарда Гельдрейха о «самоорганизующихся» компаниях, где внешняя свобода и культ гениальности легко маскируют внутренние игры, манипуляции и неочевидные механизмы власти. Надо быть осторожнее с корпоративным маркетингом, не раскрывать работодателю лишнюю личную информацию и не путать красивый образ компании с качеством среды. Потому что за фасадом «плоской структуры» может скрываться не взрослая автономия, а довольно токсичная борьба без явных правил и ответственности.
О столкновении молодого, инициативного сотрудника с системой, где старание, инициативность и желание делать лучше далеко не всегда ведут к признанию или росту. В жестко иерархичных структурах выживает не тот, кто работает сильнее, а тот, кто лучше понимает негласные правила и умеет не раздражать систему лишней заметностью.
У многих компаний уже есть всё нужное для быстрого обучения - статьи в базе знаний, рабочие инструкции, CRM или клиентская система, - но нет упакованного курса. Статья как раз о том, как превратить существующий контент в учебный контур без долгой методической стройки: взять готовые статьи, связать их в последовательность, добавить тесты, дедлайны, статусы прохождения и получить рабочий онбординг почти без переписывания материалов.
(Специально для фанатов) Автор переносит теорию типов привязанности в профессиональную среду и показывает, как эмоциональная устойчивость, реакция на фидбек, отношение к дистанции и потребность в одобрении влияют на карьеру в ИТ едва ли не сильнее, чем техническая глубина. Надёжный тип легче выдерживает обратную связь, конфликты и рост ответственности, поэтому чаще естественно дорастает до лидских ролей; тревожный и избегающий типы по-разному уязвимы к перегрузке, неопределенности и выгоранию. Короче, не все проблемы сотрудников решаются советом «будь увереннее», потому что за их рабочим поведением часто стоит более глубокий эмоциональный паттерн.
О том, как высокие стандарты незаметно переходят в токсичную перфекционистскую культуру: люди перестают задавать вопросы, боятся озвучивать риски и смягчают формулировки до такой степени, что важная информация теряет остроту и смысл. У процесса несколько фаз - от культа безупречного результата до самоцензуры и страха ошибки. В итоге команда вроде бы остаётся профессиональной и собранной, но на деле всё больше молчит о проблемах, а значит, снижает собственную способность исправлять курс вовремя.
Одна из самых практичных статей в подборке: автор не спорит, заменит ли ИИ аналитика (гм…), а прямо показывает, что именно модели уже умеют делать хорошо - черновики требований, user stories, структурирование интервью, поиск противоречий, прототипы диаграмм и API-описаний. Но главный тезис не в автоматизации, а в смещении роли: аналитик всё меньше “писатель документов” и всё больше редактор, валидатор, синтезатор контекста и проектировщик процессов в команде.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍2
🔥 Самые интересные материалы по управлению проектами за 2 недели
😐 Менеджер проекта - карьера и навыки
😛 Создатели, менеджеры и люди процесса. Кто на самом деле двигает продукт
Автор делит участников продуктовой организации на три группы: создатели делают продукт руками и головой, менеджеры растят и усиливают этих людей, а "люди процесса" отвечают за ритуалы, стандарты и фреймворки. Главная мысль в том, что процесс сам по себе не зло, но в больших компаниях он слишком легко превращается в самоцель и начинает жить отдельной жизнью, подменяя лидерство и ответственность формальными правилами.
🙌 ИИ не делает вас лучше как лидера. Зато сэкономит часы на рутине - опыт 4 руководителей
Kaiten собрал практические кейсы четырех руководителей и показывает интересную картину: ИИ сильнее всего помогает не в стратегии и лидерстве, а в рутине - отчетах, метриках, протоколах встреч, инструкциях, резюме интервью и предварительном анализе данных из таск-трекеров. Освобожденное время можно направить на управленческое мышление, но сами решения, приоритеты и интерпретации никто с человека не снимает.
✨ Почему жесткий тайм-менеджмент больше не работает
Текст критикует тотальный таймбоксинг, когда весь день нарезан на плотные слоты без воздуха и запаса, и объясняет, почему такой подход так соблазнителен: мозг любит иллюзию контроля и награждает нас уже на этапе красивого планирования. В статье это названо "дофаминовым авансом" - ощущением, будто работа уже сделана, хотя реально мы всего лишь аккуратно заполнили календарь. В итоге жесткий тайм-менеджмент нередко становится легализованной прокрастинацией: человек чувствует себя организованным, но при первом же отклонении реальности начинает сыпаться и терять не только план, но и ощущение управляемости.
🧐 Уволить 40% штата из-за ИИ: как плохой менеджмент прячут за красивыми технологиями
Статья разбирает "ИИ-камуфляж" - ситуацию, когда массовые сокращения оправдывают технологиями, хотя на деле речь идет о старом добром управленческом решении, упакованном в модную риторику. Автор не отрицает силу ИИ как инструмента, но настаивает: одно дело - использовать модели как помощников, и совсем другое - прикрывать ими увольнение значительной части штата, будто технология уже сама по себе оправдывает такие шаги.
🔫 Я следил, чтобы команда не выгорела. Выгорел сам
Выстраданный текст о том, как перфекционизм и привычка держать все под контролем не исчезают при переходе из разработки в менеджмент, а просто находят новую форму: процессы, коммуникации, онбординг, ретроспективы, формулировки задач, встречи 1-1. Хороший менеджер действительно должен заботиться о понятности, ритме и качестве работы команды, но если не понять, где можно ослабить контроль, эта забота начинает пожирать самого руководителя. в целом, менеджерское выгорание часто рождается не из безразличия, а как раз из гиперответственности и постоянной внутренней проверки, "достаточно ли хорошо все устроено".
😃 ИТ-лидер в финтехе: не менеджер, а "операционный центр" кросс-функциональной команды
Т1 описывает роль ИТ-лидера в финтехе как точку пересечения двух вертикалей - технологической и бизнесовой, где нужно одновременно удерживать сроки, качество и ресурсы. Те самые стримы и кросс-функциональные команды - это попытка совместить скорость продуктовой разработки, требования регулятора и высокую цену ошибок. Поэтому ИТ-лидер здесь не сводится ни к Scrum Master, ни к техлиду, ни к проектному менеджеру в чистом виде: его задача - превращать амбициозные бизнес-идеи в реалистичный поток поставки, не позволяя ни бизнесу "перегреть" команду, ни разработке уйти в бесконечный рефакторинг.
Автор делит участников продуктовой организации на три группы: создатели делают продукт руками и головой, менеджеры растят и усиливают этих людей, а "люди процесса" отвечают за ритуалы, стандарты и фреймворки. Главная мысль в том, что процесс сам по себе не зло, но в больших компаниях он слишком легко превращается в самоцель и начинает жить отдельной жизнью, подменяя лидерство и ответственность формальными правилами.
Kaiten собрал практические кейсы четырех руководителей и показывает интересную картину: ИИ сильнее всего помогает не в стратегии и лидерстве, а в рутине - отчетах, метриках, протоколах встреч, инструкциях, резюме интервью и предварительном анализе данных из таск-трекеров. Освобожденное время можно направить на управленческое мышление, но сами решения, приоритеты и интерпретации никто с человека не снимает.
Текст критикует тотальный таймбоксинг, когда весь день нарезан на плотные слоты без воздуха и запаса, и объясняет, почему такой подход так соблазнителен: мозг любит иллюзию контроля и награждает нас уже на этапе красивого планирования. В статье это названо "дофаминовым авансом" - ощущением, будто работа уже сделана, хотя реально мы всего лишь аккуратно заполнили календарь. В итоге жесткий тайм-менеджмент нередко становится легализованной прокрастинацией: человек чувствует себя организованным, но при первом же отклонении реальности начинает сыпаться и терять не только план, но и ощущение управляемости.
Статья разбирает "ИИ-камуфляж" - ситуацию, когда массовые сокращения оправдывают технологиями, хотя на деле речь идет о старом добром управленческом решении, упакованном в модную риторику. Автор не отрицает силу ИИ как инструмента, но настаивает: одно дело - использовать модели как помощников, и совсем другое - прикрывать ими увольнение значительной части штата, будто технология уже сама по себе оправдывает такие шаги.
Выстраданный текст о том, как перфекционизм и привычка держать все под контролем не исчезают при переходе из разработки в менеджмент, а просто находят новую форму: процессы, коммуникации, онбординг, ретроспективы, формулировки задач, встречи 1-1. Хороший менеджер действительно должен заботиться о понятности, ритме и качестве работы команды, но если не понять, где можно ослабить контроль, эта забота начинает пожирать самого руководителя. в целом, менеджерское выгорание часто рождается не из безразличия, а как раз из гиперответственности и постоянной внутренней проверки, "достаточно ли хорошо все устроено".
Т1 описывает роль ИТ-лидера в финтехе как точку пересечения двух вертикалей - технологической и бизнесовой, где нужно одновременно удерживать сроки, качество и ресурсы. Те самые стримы и кросс-функциональные команды - это попытка совместить скорость продуктовой разработки, требования регулятора и высокую цену ошибок. Поэтому ИТ-лидер здесь не сводится ни к Scrum Master, ни к техлиду, ни к проектному менеджеру в чистом виде: его задача - превращать амбициозные бизнес-идеи в реалистичный поток поставки, не позволяя ни бизнесу "перегреть" команду, ни разработке уйти в бесконечный рефакторинг.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2
🔥 Самые интересные материалы по управлению проектами за 2 недели
🤗 Основы, гайды, кейсы
🚬 PMBOK 8. Что изменилось?
Автор делает обзор ожидаемых изменений в PMBOK 8 и показывает, что развитие стандарта все дальше уходит от жестких "процессных списков" к более гибкому, принципиальному и контекстному взгляду на управление проектами. В центре внимания - не только артефакты и процедуры, но и адаптация подхода под среду, работу с ценностью, неопределенностью и реальными потребностями команды и организации.
🥺 Матрица Эйзенхауэра в корпоративной системе: почему не работает и что делать
О том, почему популярная личная техника приоритизации часто ломается в корпоративной среде. Кратко - потому что задачи в компании редко принадлежат одному человеку, срочность и важность зависят от контекста команды, а квадраты быстро начинают противоречить реальной системе зависимостей и обязательств. Тем не менее матрица - это тема, но надо опираться на более прозрачные правила приоритета, владельцев решений и наблюдаемые критерии.
👍 Системы управления ИТ-проектами: подборка российских решений 2026
Ииииии очередной обзор российского ландшафта систем управления проектами. В этот раз с упором на то, что выбирать инструмент нужно по зрелости процессов, требованиям к безопасности, гибкости настройки, интеграциям и масштабу команды. В главных ролях: SimpleOne SDLC, Битрикс24, ADVANTA, Kaiten, Weeek, YouGile и другие.
😎 Зачем командам разработки и QA концепция DoR и DoD, и как не превратить ее в бюрократию
Три аббревиатуры в названии - это про сущности, которые часто смешивают: критерии приемки отвечают на вопрос, что именно должно уметь решение, а DoR и DoD - в каком состоянии задача может войти в работу и считаться завершенной. Польза от DoR/DoD - синхронизации ожиданий между аналитиками, разработкой, тестированием и бизнесом.
🥺 Петля на шее: почему фидбек душит проект и как это остановить
О ситуации, когда обратная связь из полезного инструмента превращается в бесконечный тормоз (узнали? согласны?). Замечаний становится слишком много, а еще и поступают они слишком поздно, не имеют общего приоритета и фактически не помогают двигаться к результату. Ну и проект начинает задыхаться - команда все время что-то дорабатывает, но ощущение прогресса исчезает.
😰 Как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось
В целом-то понятно, как: размытые цели, постоянные переносы, скрытые проблемы, разрыв между формальным статусом и реальным положением дел, потеря доверия между участниками. Статья предлагает и антикризисную логику действий: быстро собрать факты, пересобрать картину рисков, вернуть прозрачную коммуникацию, сократить хаос в приоритетах и зафиксировать реалистичный маршрут выхода из провала.
🥰 Почему проваливаются проекты? 5 столпов, на которых держится успех
“Магнит” раскладывает успешный проект не на “магические качества сильного РП”, а на набор опор: понятная цель, работа с ожиданиями, прозрачная коммуникация, дисциплина исполнения и способность адаптироваться по мере изменений. Когда одна из этих опор проседает, проект еще может выглядеть живым, но начинает разрушаться изнутри - через конфликт интерпретаций, потерю доверия, накопление скрытых проблем и т.д.
🥺 Техническое задание – что это и для кого
Текст возвращает ТЗ к его базовой функции: это договоренность между участниками о том, что именно создается, в каких границах, с какими условиями и по каким критериям можно понять, что работа выполнена правильно. ТЗ нужно разным людям по-разному: заказчику - чтобы зафиксировать ожидания, исполнителю - чтобы понимать объем и ограничения, тестированию - чтобы проверять результат, а менеджменту - чтобы управлять сроками и рисками.
Автор делает обзор ожидаемых изменений в PMBOK 8 и показывает, что развитие стандарта все дальше уходит от жестких "процессных списков" к более гибкому, принципиальному и контекстному взгляду на управление проектами. В центре внимания - не только артефакты и процедуры, но и адаптация подхода под среду, работу с ценностью, неопределенностью и реальными потребностями команды и организации.
О том, почему популярная личная техника приоритизации часто ломается в корпоративной среде. Кратко - потому что задачи в компании редко принадлежат одному человеку, срочность и важность зависят от контекста команды, а квадраты быстро начинают противоречить реальной системе зависимостей и обязательств. Тем не менее матрица - это тема, но надо опираться на более прозрачные правила приоритета, владельцев решений и наблюдаемые критерии.
👍 Системы управления ИТ-проектами: подборка российских решений 2026
Ииииии очередной обзор российского ландшафта систем управления проектами. В этот раз с упором на то, что выбирать инструмент нужно по зрелости процессов, требованиям к безопасности, гибкости настройки, интеграциям и масштабу команды. В главных ролях: SimpleOne SDLC, Битрикс24, ADVANTA, Kaiten, Weeek, YouGile и другие.
Три аббревиатуры в названии - это про сущности, которые часто смешивают: критерии приемки отвечают на вопрос, что именно должно уметь решение, а DoR и DoD - в каком состоянии задача может войти в работу и считаться завершенной. Польза от DoR/DoD - синхронизации ожиданий между аналитиками, разработкой, тестированием и бизнесом.
О ситуации, когда обратная связь из полезного инструмента превращается в бесконечный тормоз (узнали? согласны?). Замечаний становится слишком много, а еще и поступают они слишком поздно, не имеют общего приоритета и фактически не помогают двигаться к результату. Ну и проект начинает задыхаться - команда все время что-то дорабатывает, но ощущение прогресса исчезает.
В целом-то понятно, как: размытые цели, постоянные переносы, скрытые проблемы, разрыв между формальным статусом и реальным положением дел, потеря доверия между участниками. Статья предлагает и антикризисную логику действий: быстро собрать факты, пересобрать картину рисков, вернуть прозрачную коммуникацию, сократить хаос в приоритетах и зафиксировать реалистичный маршрут выхода из провала.
“Магнит” раскладывает успешный проект не на “магические качества сильного РП”, а на набор опор: понятная цель, работа с ожиданиями, прозрачная коммуникация, дисциплина исполнения и способность адаптироваться по мере изменений. Когда одна из этих опор проседает, проект еще может выглядеть живым, но начинает разрушаться изнутри - через конфликт интерпретаций, потерю доверия, накопление скрытых проблем и т.д.
Текст возвращает ТЗ к его базовой функции: это договоренность между участниками о том, что именно создается, в каких границах, с какими условиями и по каким критериям можно понять, что работа выполнена правильно. ТЗ нужно разным людям по-разному: заказчику - чтобы зафиксировать ожидания, исполнителю - чтобы понимать объем и ограничения, тестированию - чтобы проверять результат, а менеджменту - чтобы управлять сроками и рисками.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
«Не усложняй! Управление проектами по методу P3.express» — коротко о книге
Открылся предзаказ на книгу Дмитрия и Валерии Ильенковых «Не усложняй! Управление проектами по методу P3.express». Мы прочитали ее и делимся впечатлениями.
✋ В двух словах, "Не усложняй" - книга про то, как навести порядок в проектах без методологического фанатизма. Сегодня многие команды живут между крайностями - либо никакой системы, лишь бы ехало, либо перегруженный ритуалами и отчетностью псевдопроцесс. P3.express позиционируется как минималистичная методологическая середина: 33 шага, разбитые на 7 этапов, минимум документации, широкая адаптируемость и опора на принципы.
✅ Коротко - книга отличная. Прекрасный пример того, как нужно писать для перегруженной концепциями и проблемами аудитории (да, это про РПшников).
✅ Сильная сторона книги - опора на здравый смысл и практичную эклектику, уложенную в повторяемый каркас. Вместо рассуждений о зрелости процессов нам предлагают понятную логику: сначала разобраться в принципах, потом пройти по шагам, затем адаптировать метод под свою среду, особенно если на тяжелый фреймворк или полугодовое обучение просто нет ресурсов.
✅ Сам фреймворк P3.express описан как система из 33 конкретных действий в рамках запуска проекта, планирования цикла, еженедельных и ежедневных действий, закрытия цикла, закрытия проекта и, что особенно ценно, работу "после проекта", где оцениваются полученные выгоды и генерируются новые идеи.
✅ При этом авторы не ограничиваются механикой шагов. Они вводят шесть принципов NUPP (Nearly Universal Principles of Project, “почти универсальные проектные принципы”) как "компас" для адаптации метода: выбирать результат и истину, а не привязанности; беречь энергию и ресурсы; быть проактивным; помнить о слабом звене; не делать ничего без цели; использовать воспроизводимые элементы. Без этих NUPP методология может превратиться в карго-культ.
✅ По инструментам.
🔹 Сама процессная рамка: понятный проектный ритм с ежемесячным, еженедельным и ежедневным уровнями управления. Такой ритм полезен в средах, где проекты идут “как получится”, а руководитель каждый день заново изобретает, что ему контролировать.
🔹 Опорный набор управленческих действий: описание проекта, фиксацию ожидаемых результатов, оценку рисков, решение “Go/No-Go”, стартовые встречи, регулярные ревью, приемку результатов, сбор уроков, передачу продукта, архивирование документации и оценку выгод.
🔹 Важность воспроизводимых элементов: чек-листов, шаблонов, повторяющихся циклов, документированных карточек задач и автоматизированных отчетов. По сути, это одно из самых прикладных ее посланий: никакого героизма - и побольше повторяемых нормальных управленческих практик.
🔹 Есть внедренческий контур: начинаем с пилота, потом делаем изменения заметными, опираемся на принципы и двигаемся постепенно. Потому что, увы, проект осуществляется в среде, а среда ему сопротивляется). И ещё авторы вынесли в отдельный раздел материалы для старта: шаблоны документов, выступления практиков и полезные ссылки.
✅ Отдельно отмечу доступность изложения - никакого академизма. Авторы явно понимают, что их читатель не всегда живет в терминологии PMI и не обязан получать удовольствие от многослойных методологических конструкций. Поэтому объяснение идет через бытовые и яркие аналогии: Lego, IKEA, стоматологию, походы, внутреннего отличника и т.д. Много личного опыта, признаний в собственных ошибках. В общем, всё дружелюбно и с минимальным входным барьером.
✅ Кому можно рекомендовать книгу?
Конечно, начинающим PM - здесь есть прочный фундамент и рабочая последовательность действий. Опытные менеджеры смогут найти здесь компактный каркас для будущей корпоративной методологии. Руководители и собственники смогут разобраться в проблемах проектов и найти общий язык с командами.
Меньше книга подойдет тем, кто ждет глубокого сравнительного анализа PMBOK, PRINCE2, Agile, Lean и гибридных моделей, а также тем, кому нужен готовый корпоративный регламент «под ключ» с детальными формами, ролями и матрицами ответственности прямо на страницах книги.
Открылся предзаказ на книгу Дмитрия и Валерии Ильенковых «Не усложняй! Управление проектами по методу P3.express». Мы прочитали ее и делимся впечатлениями.
Конечно, начинающим PM - здесь есть прочный фундамент и рабочая последовательность действий. Опытные менеджеры смогут найти здесь компактный каркас для будущей корпоративной методологии. Руководители и собственники смогут разобраться в проблемах проектов и найти общий язык с командами.
Меньше книга подойдет тем, кто ждет глубокого сравнительного анализа PMBOK, PRINCE2, Agile, Lean и гибридных моделей, а также тем, кому нужен готовый корпоративный регламент «под ключ» с детальными формами, ролями и матрицами ответственности прямо на страницах книги.
Please open Telegram to view this post
VIEW IN TELEGRAM
p3express.ru
Книга «Не усложняй! Управление проектами по методу P3․express»
Если вы уже перепробовали все методы, но дедлайны все равно горят, а команды выгорают — поздравляем. Вы нашли решение, которое навсегда закроет эту проблему.
👍7❤5🔥4
🔥 Самые интересные материалы по управлению проектами за 2 недели
😐 Основы, гайды и инструменты
😵 Простые хлопоты: когда проекту действительно нужно управление
Концептуальная статья о том, что управленческие действия в проектах слишком часто происходят по ритуалу, а не по реальной необходимости. Автор предлагает метафору «температуры» — уровня накопленной неопределённости, которая растёт по мере появления дефектов, задержек, искажений понимания и других скрытых потерь. Дальше строится упрощённая модель, в которой вмешательства менеджмента рассматриваются как способ «охлаждать» проект, когда неопределённость становится опасной.
😏 Что такое канбан на практике: изучаем доски, WIP-лимиты и метрики
Хороший базовый разбор канбана для тех, кто до сих пор считает, что канбан — это просто доска с колонками и карточками. А это прежде всего способ управлять потоком работы. В статье есть исторический заход от Toyota к адаптации подхода в разработке ПО, а затем разбор ключевых элементов: доска, карточки, колонки, сигналы проблем, ограничения WIP и метрики потока. Для опытных людей здесь вряд ли будет откровение, но как вводный и одновременно «отрезвляющий» материал — вполне удачно.
🦶 От стратегии до проектов: для чего бизнесу переходить к портфельному управлению
Про портфельное управление - оно нужно не потому, что звучит солидно, а потому, что инициатив становится слишком много, а денег и людей - слишком мало. Схема такая: собрать единый реестр инициатив, зафиксировать бюджеты, сроки, риски и владельцев, а потом принимать инвестиционные и приоритизационные решения на общей картине. Отдельно полезен блок о признаках, когда портфель у компании уже де-факто есть, просто он не управляется.
😨 Как я запилил свой Scrum Poker, потому что все остальные — отстой
Живой и немного хулиганский текст из серии «меня достали плохие инструменты, поэтому я собрал свой». Автор начинает с боли планинг-покера (лаги, тяжёлые решения, зависимость от Jira и отсутствие нужных функций), а затем показывает, каким сделал свой сервис. Из фич — удобное управление сессиями, автоматический расчёт среднего и архитектура с быстрым стартом и минимумом инфраструктурной возни.
😈 Как плохое ТЗ может удвоить стоимость проекта
Здесь тезис максимально прямой: длинное и подробное ТЗ не только не гарантирует успех, но часто создает ложное чувство определенности и толкает команду к избыточной разработке. Автор критикует привычку описывать заранее решение, а не пользовательскую проблему, и показывает, как это ведет к раздутому объему функциональности, сроков и бюджета. Предлагается более лёгкий подход: минимальный набор требований, фокус на потребностях пользователя, user story, критерии приёмки и постепенная детализация по ходу работы.
😢 Никого не повышают за простые решения
О перекосе, который знаком почти любой команде: сложные решения выглядят «впечатляюще», а простые — как будто слишком банальны, чтобы считать их достижением. Во многих компаниях сотрудники бессознательно получают больше признания за архитектурную навороченность, чем за элегантное решение, которое быстрее внедряется, легче поддерживается и лучше переживает будущее.
😔 Юридическая гигиена ИТ-проектов или как отстоять код, деньги и нервы
Для тех, кто привык считать договор чем-то вторичным по сравнению с требованиями и сроками. Разработка софта почти всегда требует смешанной договорной конструкции, потому что здесь переплетаются подряд, НИОКР и вопросы лицензирования или отчуждения прав. Дальше акцент смещается на ТЗ как часть договора.
🙂 Как правильно оформлять РИДы в ИТ-проектах, чтобы не создавать спорных ситуаций
Хороший разбор темы, которую в проектах часто упрощают до формулы «всё, что сделали, автоматически наше». На практике статья показывает, что с результатами интеллектуальной деятельности всё тоньше: нужно смотреть, где был реальный творческий вклад исполнителя, а где — просто использование готовых инструментов, библиотек, UI-китов или материалов по лицензии.
Концептуальная статья о том, что управленческие действия в проектах слишком часто происходят по ритуалу, а не по реальной необходимости. Автор предлагает метафору «температуры» — уровня накопленной неопределённости, которая растёт по мере появления дефектов, задержек, искажений понимания и других скрытых потерь. Дальше строится упрощённая модель, в которой вмешательства менеджмента рассматриваются как способ «охлаждать» проект, когда неопределённость становится опасной.
Хороший базовый разбор канбана для тех, кто до сих пор считает, что канбан — это просто доска с колонками и карточками. А это прежде всего способ управлять потоком работы. В статье есть исторический заход от Toyota к адаптации подхода в разработке ПО, а затем разбор ключевых элементов: доска, карточки, колонки, сигналы проблем, ограничения WIP и метрики потока. Для опытных людей здесь вряд ли будет откровение, но как вводный и одновременно «отрезвляющий» материал — вполне удачно.
Про портфельное управление - оно нужно не потому, что звучит солидно, а потому, что инициатив становится слишком много, а денег и людей - слишком мало. Схема такая: собрать единый реестр инициатив, зафиксировать бюджеты, сроки, риски и владельцев, а потом принимать инвестиционные и приоритизационные решения на общей картине. Отдельно полезен блок о признаках, когда портфель у компании уже де-факто есть, просто он не управляется.
Живой и немного хулиганский текст из серии «меня достали плохие инструменты, поэтому я собрал свой». Автор начинает с боли планинг-покера (лаги, тяжёлые решения, зависимость от Jira и отсутствие нужных функций), а затем показывает, каким сделал свой сервис. Из фич — удобное управление сессиями, автоматический расчёт среднего и архитектура с быстрым стартом и минимумом инфраструктурной возни.
Здесь тезис максимально прямой: длинное и подробное ТЗ не только не гарантирует успех, но часто создает ложное чувство определенности и толкает команду к избыточной разработке. Автор критикует привычку описывать заранее решение, а не пользовательскую проблему, и показывает, как это ведет к раздутому объему функциональности, сроков и бюджета. Предлагается более лёгкий подход: минимальный набор требований, фокус на потребностях пользователя, user story, критерии приёмки и постепенная детализация по ходу работы.
О перекосе, который знаком почти любой команде: сложные решения выглядят «впечатляюще», а простые — как будто слишком банальны, чтобы считать их достижением. Во многих компаниях сотрудники бессознательно получают больше признания за архитектурную навороченность, чем за элегантное решение, которое быстрее внедряется, легче поддерживается и лучше переживает будущее.
Для тех, кто привык считать договор чем-то вторичным по сравнению с требованиями и сроками. Разработка софта почти всегда требует смешанной договорной конструкции, потому что здесь переплетаются подряд, НИОКР и вопросы лицензирования или отчуждения прав. Дальше акцент смещается на ТЗ как часть договора.
Хороший разбор темы, которую в проектах часто упрощают до формулы «всё, что сделали, автоматически наше». На практике статья показывает, что с результатами интеллектуальной деятельности всё тоньше: нужно смотреть, где был реальный творческий вклад исполнителя, а где — просто использование готовых инструментов, библиотек, UI-китов или материалов по лицензии.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
🔥 Самые интересные материалы по управлению проектами за 2 недели
💻 Основы, гайды и инструменты
📢 У проекта шесть параметров и все важны. Проектный тетраэдр, а не треугольник
Попытка расширить классический проектный треугольник. Вместо трёх классических параметров (срок, бюджет, объём) автор предлагает смотреть сразу на шесть: добавляются качество, риски и ценность. В реальных проектах провал почти никогда не выглядит как «не уложились только в срок», потому что при давлении по срокам и деньгам почти всегда жертвуют качеством, полезностью результата и уровнем принимаемых рисков.
🏐 Документальное сопровождение создания ИТ-продуктов в рамках выполнения ИТ-проектов
Академично-практический текст про то, как вообще выстраивать комплект проектной документации при создании ИТ-продуктов. Автор исходит из того, что национальные стандарты задают рамку, но не жёстко диктуют единственный набор документов, поэтому состав проектной документации должен определяться контекстом, заинтересованными сторонами, стилем управления и ресурсами. Текст не сводит всё к культу ГОСТов, а пытается собрать более осмысленную структуру документального сопровождения, пригодную для реальной проектной практики.
🟢 Гибкость важнее функций: как за неделю мы адаптировали систему для Waterfall-проектов под Agile
Понятный и прикладной кейс про то, что главная проблема многих систем управления проектами — не отсутствие нужной галочки в чек-листе, а негибкость, из-за которой процессы приходится ломать под инструмент. Сначала покупают одну систему для классических проектов, потом вторую для Agile-команд, потом третью для ещё одного сценария — и в итоге получают лишние лицензии, ручное сведение данных и вечный рассинхрон. Авторы предлагают свой подход и продукт, позволяющий пересобрать текущую систему под новые процессы, вплоть до добавления сущности спринта, отдельных представлений и Scrum-доски.
➡️ От хаоса к гармонии: роль ИИ-ассистента в проектной трансформации
Как AI-ассистент может стать не просто игрушкой для генерации текста, а инструментом наведения порядка в проектной среде. В целом, это скорее туториал и кейс о применении ИИ в проектной трансформации,который показывает конкретную роль помощника в документообороте, коммуникациях, поиске знаний и снижении ручной рутины — именно там, где проектные процессы чаще всего расползаются в хаос.
🐈⬛ SAFe, платформенные команды и ИИ в разработке: как устроен IT в MANGO OFFICE
Хороший разбор организационного устройства крупной IT-функции через призму SAFe, платформенных команд и роли ИИ в разработке. Статья не ограничивается ритуальным «мы внедрили SAFe и стали счастливы», а прямо проговаривает, зачем он понадобился: водопад мешал быстро выпускать фичи и видеть реальный прогресс, а компании нужен был единый сквозной фреймворк. Плюс авторы не замалчивают шероховатости: роли Product Manager, Product Owner и системного архитектора на стыках действительно могут давать зазоры ответственности, где терялись задачи.
☁️ Как на самом деле запускаются изменения в компании
О том, что запуск изменений почти никогда не сводится к объявлению «с понедельника работаем по-новому». Сначала нужно сознательно поднять внимание к теме, потом не дать стартовой энергии раствориться в операционке, а затем перевести изменения в регулярный управленческий контур — через цели, метрики и повторяемые коммуникации. В общем, изменения состоялись не тогда, когда про них много говорят, а когда они перестают называться изменениями и становятся просто нормальным способом работы.
🔔 Зачем нужны нефункциональные требования к ПО и откуда их взять
Полезный базовый текст про ту часть требований, которую все признают важной, но регулярно оставляют на потом. ФТ отвечают на вопрос «что делает система», а НФТ — «как, когда, где и с какими качественными характеристиками она это делает», причем именно они во многом определяют архитектуру, эксплуатацию и размер будущих затрат. Если НФТ не записаны, они всё равно существуют, просто живут в головах нескольких людей и становятся источником потери знаний и будущих проблем.
Попытка расширить классический проектный треугольник. Вместо трёх классических параметров (срок, бюджет, объём) автор предлагает смотреть сразу на шесть: добавляются качество, риски и ценность. В реальных проектах провал почти никогда не выглядит как «не уложились только в срок», потому что при давлении по срокам и деньгам почти всегда жертвуют качеством, полезностью результата и уровнем принимаемых рисков.
Академично-практический текст про то, как вообще выстраивать комплект проектной документации при создании ИТ-продуктов. Автор исходит из того, что национальные стандарты задают рамку, но не жёстко диктуют единственный набор документов, поэтому состав проектной документации должен определяться контекстом, заинтересованными сторонами, стилем управления и ресурсами. Текст не сводит всё к культу ГОСТов, а пытается собрать более осмысленную структуру документального сопровождения, пригодную для реальной проектной практики.
Понятный и прикладной кейс про то, что главная проблема многих систем управления проектами — не отсутствие нужной галочки в чек-листе, а негибкость, из-за которой процессы приходится ломать под инструмент. Сначала покупают одну систему для классических проектов, потом вторую для Agile-команд, потом третью для ещё одного сценария — и в итоге получают лишние лицензии, ручное сведение данных и вечный рассинхрон. Авторы предлагают свой подход и продукт, позволяющий пересобрать текущую систему под новые процессы, вплоть до добавления сущности спринта, отдельных представлений и Scrum-доски.
Как AI-ассистент может стать не просто игрушкой для генерации текста, а инструментом наведения порядка в проектной среде. В целом, это скорее туториал и кейс о применении ИИ в проектной трансформации,который показывает конкретную роль помощника в документообороте, коммуникациях, поиске знаний и снижении ручной рутины — именно там, где проектные процессы чаще всего расползаются в хаос.
Хороший разбор организационного устройства крупной IT-функции через призму SAFe, платформенных команд и роли ИИ в разработке. Статья не ограничивается ритуальным «мы внедрили SAFe и стали счастливы», а прямо проговаривает, зачем он понадобился: водопад мешал быстро выпускать фичи и видеть реальный прогресс, а компании нужен был единый сквозной фреймворк. Плюс авторы не замалчивают шероховатости: роли Product Manager, Product Owner и системного архитектора на стыках действительно могут давать зазоры ответственности, где терялись задачи.
О том, что запуск изменений почти никогда не сводится к объявлению «с понедельника работаем по-новому». Сначала нужно сознательно поднять внимание к теме, потом не дать стартовой энергии раствориться в операционке, а затем перевести изменения в регулярный управленческий контур — через цели, метрики и повторяемые коммуникации. В общем, изменения состоялись не тогда, когда про них много говорят, а когда они перестают называться изменениями и становятся просто нормальным способом работы.
Полезный базовый текст про ту часть требований, которую все признают важной, но регулярно оставляют на потом. ФТ отвечают на вопрос «что делает система», а НФТ — «как, когда, где и с какими качественными характеристиками она это делает», причем именно они во многом определяют архитектуру, эксплуатацию и размер будущих затрат. Если НФТ не записаны, они всё равно существуют, просто живут в головах нескольких людей и становятся источником потери знаний и будущих проблем.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥 Самые интересные материалы по управлению проектами за 2 недели
🔤 Менеджер проекта - карьера и навыки
🔤 Как тимлиду давать обратную связь: 4 фреймворка, которые работают
Полезный прикладной текст для тимлидов, которые понимают, что обратную связь давать надо, но каждый раз внутренне надеются, что проблема как-нибудь рассосется сама. Обратная связь нужна не для формального менеджерского ритуала, а чтобы снижать тревожность, давать сотруднику понятный вектор улучшения и не оставлять команду жить в режиме догадок. Конкретно - это разбор фреймворков SBI и COIN, которые уводят разговор от оценок личности к фактам, последствиям и следующим шагам; плюс добавлена матрица радикальной откровенности как напоминание, что мягкость без честности тоже вредит.
🔤 Советы бывалого управленца — Борьба с текучкой персонала
Довольно едкая сатира на токсические способы «удержания» сотрудников. Уже в первых советах автор предлагает разрушать у людей чувство стабильности, затягивать выплаты и подвязывать их к компании через долговые механики. Поэтому воспринимать текст надо не как набор рекомендаций, а как язвительный памфлет о том, как выглядит менеджмент, когда людей считают не коллегами, а удерживаемым ресурсом.
🔤 Делегирование для тимлида: как перестать быть главным исполнителем и не скатиться в микроменеджмент
О той ломке роли, через которую почти неизбежно проходит новый лид: тебя повысили не для того, чтобы ты стал самым занятым разработчиком в комнате, а для того, чтобы результат команды перестал зависеть от твоего личного героизма. Инженерная привычка «я сам сделаю быстрее и надёжнее» плохо совместима с управленческой задачей выращивать самостоятельность других. Поэтому делегирование здесь показано не как ленивое сбрасывание задач, а как ключевой навык выживания лида и одновременно способ не скатиться в микроменеджмент.
🔤 В чем разница между героизмом и идиотизмом в управлении проектами
Очень здравая статья против романтизации проектного подвига. То, что в компаниях любят называть героизмом — переработки, ночные созвоны, постоянное ускорение и спасение дедлайна на надрыве, — чаще всего не признак силы команды, а симптом отсутствия нормальной системы управления. Проблема обычно не в том, что люди мало стараются, а в том, что никто не управляет изменениями, объем расползается, критерии готовности размыты, а хаос потом пытаются залить человеческим напряжением.
🔤 Лиды не люди
Текст с легкой самоиронией о специфическом положении лидов, которые в глазах системы часто превращаются в странных гибридов между человеком, ролью и сервисной функцией для всех остальных. По формату - живой разговор двух руководителей из 2ГИС, о перегрузке ожиданиями, раздвоении между людьми и процессами и той степени «не-людскости», которая возникает, когда на лиде сходятся интересы команды, бизнеса и проекта.
🔤 «Вечнозеленый» спор — Должен ли руководитель разработки (engineering manager) программировать наравне с командой?
Авторы формулируют обе позиции спора: с одной стороны, код помогает не терять авторитет и технический контакт с реальностью команды, с другой — у этого самого engineering manager есть вполне полноценная отдельная работа по развитию людей, синхронизации и удержанию системы в равновесии. Поэтому главный вопрос - это что именно сейчас важнее для конкретной роли, команды и масштаба задач.
Полезный прикладной текст для тимлидов, которые понимают, что обратную связь давать надо, но каждый раз внутренне надеются, что проблема как-нибудь рассосется сама. Обратная связь нужна не для формального менеджерского ритуала, а чтобы снижать тревожность, давать сотруднику понятный вектор улучшения и не оставлять команду жить в режиме догадок. Конкретно - это разбор фреймворков SBI и COIN, которые уводят разговор от оценок личности к фактам, последствиям и следующим шагам; плюс добавлена матрица радикальной откровенности как напоминание, что мягкость без честности тоже вредит.
Довольно едкая сатира на токсические способы «удержания» сотрудников. Уже в первых советах автор предлагает разрушать у людей чувство стабильности, затягивать выплаты и подвязывать их к компании через долговые механики. Поэтому воспринимать текст надо не как набор рекомендаций, а как язвительный памфлет о том, как выглядит менеджмент, когда людей считают не коллегами, а удерживаемым ресурсом.
О той ломке роли, через которую почти неизбежно проходит новый лид: тебя повысили не для того, чтобы ты стал самым занятым разработчиком в комнате, а для того, чтобы результат команды перестал зависеть от твоего личного героизма. Инженерная привычка «я сам сделаю быстрее и надёжнее» плохо совместима с управленческой задачей выращивать самостоятельность других. Поэтому делегирование здесь показано не как ленивое сбрасывание задач, а как ключевой навык выживания лида и одновременно способ не скатиться в микроменеджмент.
Очень здравая статья против романтизации проектного подвига. То, что в компаниях любят называть героизмом — переработки, ночные созвоны, постоянное ускорение и спасение дедлайна на надрыве, — чаще всего не признак силы команды, а симптом отсутствия нормальной системы управления. Проблема обычно не в том, что люди мало стараются, а в том, что никто не управляет изменениями, объем расползается, критерии готовности размыты, а хаос потом пытаются залить человеческим напряжением.
Текст с легкой самоиронией о специфическом положении лидов, которые в глазах системы часто превращаются в странных гибридов между человеком, ролью и сервисной функцией для всех остальных. По формату - живой разговор двух руководителей из 2ГИС, о перегрузке ожиданиями, раздвоении между людьми и процессами и той степени «не-людскости», которая возникает, когда на лиде сходятся интересы команды, бизнеса и проекта.
Авторы формулируют обе позиции спора: с одной стороны, код помогает не терять авторитет и технический контакт с реальностью команды, с другой — у этого самого engineering manager есть вполне полноценная отдельная работа по развитию людей, синхронизации и удержанию системы в равновесии. Поэтому главный вопрос - это что именно сейчас важнее для конкретной роли, команды и масштаба задач.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤2💘2
🔥 Самые интересные материалы по управлению проектами за 2 недели
⚡️ Команда проекта
✅ Ты ответил правильно, но тебя не поняли
Небольшой, но полезный текст про рабочую коммуникацию. Автор показывает, что проблема чаще всего не в том, что собеседник «не способен понять», а в том, что в ответе не хватает контекста, причинно-следственной связки, отделения гипотез от фактов и правильного уровня детализации. Простая рабочая схема «было - потому что - сделал - стало» превращает правильный, но бесполезный ответ в объяснение, с которым уже можно что-то делать. Короткий гайд по снижению производственного шума.
⏳ Что прокачивать на каждом грейде: навыки джуна, мидла и синьора
Обзор карьерного роста, но без культа «стань синьором как можно быстрее». На каждом грейде важны не только харды, но и свой набор зрелости — у мидла это уже самостоятельность, оценка задач и понимание продукта, а ближе к тимлиду появляются управленческие навыки, работа с конфликтами, нагрузкой и ожиданиями стейкхолдеров.
☯️ Зачем и как избавляться от незаменимых сотрудников
Очень здравый текст против управленческого фетиша на «звезд», без которых якобы ничего не работает. Автор показывает, что незаменимость — это не достоинство системы, а ее уязвимость: она увеличивает “автобусный фактор” и превращает сильного сотрудника в бутылочное горлышко и ставит проект под риск при болезни, отпуске или увольнении. Противоядия - дублирование знаний, оцифровка через wiki и аналогичное, чтобы критическая экспертиза переставала жить в голове одного человека.
🔴 Команда — самолёт и это не просто метафора
Статья строится на метафоре: команда — это не «группа хороших людей», а собранная конструкция, которая может лететь - или не может. Главный тезис: если смотреть на проблемы только «по-человечески», кажется, что дело в конкретных людях, но при системном взгляде видно, что сбой может быть в самой сборке ролей, нагрузок и критических незакрытых участков.
❓ Как выстроить систему обучения проектной команды в IT: пошаговый алгоритм
Материал против привычки начинать обучение с выбора красивого курса. Автор предлагает более взрослую последовательность: сначала диагностировать, где именно команда регулярно ломается на последних проектах, а уже потом превращать эти повторяющиеся провалы в структурированный учебный план.
❤️ Контроль работы сотрудников: методы и организация контроля в компании
Авторы стараются развести нормальный контроль, надзор и микроменеджмент. Отслеживать стоит не клики и сидение за компьютером, а результат, сроки, качество и соблюдение договоренностей; при этом сам контроль должен давать команде ясность и автономию, а не ощущение постоянной слежки. Практическая часть: перечислены операционные методы вроде планерок, KPI/OKR, чек-листов, one-to-one и анонимных опросов, плюс отдельно обозначены правовые рамки мониторинга сотрудников в России. Текст заметно вендорский, но как вводный материал про «экологичный контроль без превращения в плохого босса» норм.
Небольшой, но полезный текст про рабочую коммуникацию. Автор показывает, что проблема чаще всего не в том, что собеседник «не способен понять», а в том, что в ответе не хватает контекста, причинно-следственной связки, отделения гипотез от фактов и правильного уровня детализации. Простая рабочая схема «было - потому что - сделал - стало» превращает правильный, но бесполезный ответ в объяснение, с которым уже можно что-то делать. Короткий гайд по снижению производственного шума.
Обзор карьерного роста, но без культа «стань синьором как можно быстрее». На каждом грейде важны не только харды, но и свой набор зрелости — у мидла это уже самостоятельность, оценка задач и понимание продукта, а ближе к тимлиду появляются управленческие навыки, работа с конфликтами, нагрузкой и ожиданиями стейкхолдеров.
Очень здравый текст против управленческого фетиша на «звезд», без которых якобы ничего не работает. Автор показывает, что незаменимость — это не достоинство системы, а ее уязвимость: она увеличивает “автобусный фактор” и превращает сильного сотрудника в бутылочное горлышко и ставит проект под риск при болезни, отпуске или увольнении. Противоядия - дублирование знаний, оцифровка через wiki и аналогичное, чтобы критическая экспертиза переставала жить в голове одного человека.
Статья строится на метафоре: команда — это не «группа хороших людей», а собранная конструкция, которая может лететь - или не может. Главный тезис: если смотреть на проблемы только «по-человечески», кажется, что дело в конкретных людях, но при системном взгляде видно, что сбой может быть в самой сборке ролей, нагрузок и критических незакрытых участков.
Материал против привычки начинать обучение с выбора красивого курса. Автор предлагает более взрослую последовательность: сначала диагностировать, где именно команда регулярно ломается на последних проектах, а уже потом превращать эти повторяющиеся провалы в структурированный учебный план.
Авторы стараются развести нормальный контроль, надзор и микроменеджмент. Отслеживать стоит не клики и сидение за компьютером, а результат, сроки, качество и соблюдение договоренностей; при этом сам контроль должен давать команде ясность и автономию, а не ощущение постоянной слежки. Практическая часть: перечислены операционные методы вроде планерок, KPI/OKR, чек-листов, one-to-one и анонимных опросов, плюс отдельно обозначены правовые рамки мониторинга сотрудников в России. Текст заметно вендорский, но как вводный материал про «экологичный контроль без превращения в плохого босса» норм.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥 Самые интересные материалы по управлению проектами за 2 недели
🕶 Команда проекта
🙂 People management. Изменения, которые будут стоить 0 рублей. Спойлер: потому что вы уже за это платите
О том, что компании слишком часто пытаются лечить процессы новыми ролями, фреймворками и консультантами, хотя реальная проблема сидит в качестве управленческого поведения тех же самых людей, которые потом и будут жить в этих новых процессах. Вывод автора - процессы не меняются, пока не меняются игроки и их способность принимать решения, держать напряжение и спорить по делу.
🌜 Пользовательская инструкция как инструмент адаптации, а не формальность проекта
Прикладной материал про то, что пользовательские инструкции на внедрении обычно пишут "от системы", а не от задач человека, и именно поэтому ими почти никто не пользуется. Автор предлагает перестроить саму логику документа: сначала объяснить цель внедрения простым языком, затем показать, что изменится и что не изменится в работе, разделить зоны ответственности системы и человека, а уже потом переходить к сценариям по ролям, контрольным точкам, типовым ошибкам и нестандартным ситуациям.
💀 "У нас нет токсичных людей" - и при этом работать там невыносимо
Хороший текст про ту форму токсичности, которая вроде и не выглядит как открытая агрессия, но медленно разрушает среду изнутри. Команда может внешне быть вежливой и приличной, но при этом жить в режиме хронической неопределенности: несогласие воспринимается как опасность, проблемы не называют вслух, а обязательства становятся формой вежливости, а не реального договора.
☕️ Команда обещает больше, чем делает: где ломается планирование и как это исправить
Публикация против слишком удобного мифа, что перегруз возникает только из-за давления сверху. Оказывается, команды часто сами склонны брать на себя чуть больше, чем реально успеют, потому что в разработчиках много естественного оптимизма, веры в улучшение мира и желания дотянуться до лучшего сценария. А если команда и так обещает лишнее, любое дополнительное давление превращает планирование в машину по производству перегруза.
💔 Как ретроспектива меняет команды в ИТ, бизнесе и жизни
Автор помещает ретроспективу в большой контекст цифровой трансформации и масштабируемых Agile-фреймворков, где она нужна уже не как локальный ритуал команды, а как системный механизм роста и адаптации. Практика выводится не из моды на Agile, а из более старых оснований - цикла Деминга PDCA и идеи непрерывного улучшения Kaizen.
👻 "Лучше промолчу" - самая дорогая ошибка
Сильный текст про цену замалчивания в рабочих командах. Автор опирается на ряд исследований и показывает, что многие сотрудники годами не поднимают вслух проблемы вроде систематически слабой работы коллег, неуважения, нарушения договоренностей и размытой ответственности, хотя все это напрямую бьет по скорости и качеству работы. Молчание здесь показано не как нейтральность: вместо прямого разговора люди жалуются другим, компенсируют чужую работу и т.д. - проблема все равно живет, просто в разрушительной и неуправляемой форме.
О том, что компании слишком часто пытаются лечить процессы новыми ролями, фреймворками и консультантами, хотя реальная проблема сидит в качестве управленческого поведения тех же самых людей, которые потом и будут жить в этих новых процессах. Вывод автора - процессы не меняются, пока не меняются игроки и их способность принимать решения, держать напряжение и спорить по делу.
Прикладной материал про то, что пользовательские инструкции на внедрении обычно пишут "от системы", а не от задач человека, и именно поэтому ими почти никто не пользуется. Автор предлагает перестроить саму логику документа: сначала объяснить цель внедрения простым языком, затем показать, что изменится и что не изменится в работе, разделить зоны ответственности системы и человека, а уже потом переходить к сценариям по ролям, контрольным точкам, типовым ошибкам и нестандартным ситуациям.
Хороший текст про ту форму токсичности, которая вроде и не выглядит как открытая агрессия, но медленно разрушает среду изнутри. Команда может внешне быть вежливой и приличной, но при этом жить в режиме хронической неопределенности: несогласие воспринимается как опасность, проблемы не называют вслух, а обязательства становятся формой вежливости, а не реального договора.
Публикация против слишком удобного мифа, что перегруз возникает только из-за давления сверху. Оказывается, команды часто сами склонны брать на себя чуть больше, чем реально успеют, потому что в разработчиках много естественного оптимизма, веры в улучшение мира и желания дотянуться до лучшего сценария. А если команда и так обещает лишнее, любое дополнительное давление превращает планирование в машину по производству перегруза.
Автор помещает ретроспективу в большой контекст цифровой трансформации и масштабируемых Agile-фреймворков, где она нужна уже не как локальный ритуал команды, а как системный механизм роста и адаптации. Практика выводится не из моды на Agile, а из более старых оснований - цикла Деминга PDCA и идеи непрерывного улучшения Kaizen.
Сильный текст про цену замалчивания в рабочих командах. Автор опирается на ряд исследований и показывает, что многие сотрудники годами не поднимают вслух проблемы вроде систематически слабой работы коллег, неуважения, нарушения договоренностей и размытой ответственности, хотя все это напрямую бьет по скорости и качеству работы. Молчание здесь показано не как нейтральность: вместо прямого разговора люди жалуются другим, компенсируют чужую работу и т.д. - проблема все равно живет, просто в разрушительной и неуправляемой форме.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
🔥 Самые интересные материалы по управлению проектами за 2 недели
🤣 Менеджер проекта - карьера и навыки
😵💫 Я "нанял" AI-команду разработки и управлял ею через Kanban: опыт на реальном продукте
Очень любопытный и приземленный кейс про управление не "одним умным чатиком", а целым конвейером AI-агентов как проектной командой. Автор строит вокруг агентов полноценный пайплайн (бэклог, исследование задачи, спецификацию, реализацию, верификацию и тд). При этом с ростом доли AI ценность процесса не падает, а наоборот растет, потому что предоставленный себе агент очень быстро начинает производить хаос вместо результата.
🤢 Трудности перевода: как мы назначили контрибьютора тимлидом и чему это нас научило
Хороший ретроспективный текст о переходе от плоского управления к более структурированной модели, где внутри растущей команды приходится выделять тимлидов. Речь идет не про формальное повышение "самого сильного инженера", а про более тонкий и рискованный переход: когда у человека есть экспертность и влияние как контрибьютора, но роль тимлида требует уже другой логики - фокусировки, координации и управленческого перевода между уровнями системы..
🏠 50 оттенков порока: за что команды ненавидят тимлидов
О типовых лидерских грехах, которые команды считывают особенно остро: микроменеджмент, лицемерие, манипуляции, плохая обратная связь и ощущение непогрешимости руководителя. Статья строится вокруг реального разговора лидов о том, где заканчивается управление и начинается давление, чем манипуляция отличается от шантажа и почему даже хорошие намерения быстро портятся без саморефлексии.
⛔️ Манипуляции в жизни ИТ менеджера
В команде всегда есть отношения, а значит, всегда есть и попытки влиять друг на друга не только через формальные роли и рациональные аргументы. Автор не идеализирует рабочую среду и предлагает смотреть на управленческую жизнь без наивности: начальники могут давить, исполнители - молча соглашаться на невыполнимое, а вся система - производить выгорание под видом "надо собраться". Нужно распознавать подобные механики, не растворяться в них и сохранять рабочую эффективность и собственные границы.
👍 Управление тимлидами: не контроль, а системное лидерство
Управление несколькими тимлидами - это принципиально другая задача, чем управление отдельными разработчиками. И автор описывает типичный провал первого уровня: кажется, что опытные лиды "и так все знают", а на практике руководитель быстро превращается в бутылочное горлышко, на котором замыкаются решения, а вокруг начинает разрастаться микроменеджмент. Поэтому на уровне управления лидами нужно уже не операционно контролировать людей, а выстраивать систему лидерства, где работает распределение ответственности, зрелость решений и самостоятельность без потери общего направления.
😎 Кризис "переходного" возраста в управлении проектами: история преодоления
Рефлексивный текст о профессиональном кризисе, который приходит не от неуспеха, а как раз после внешне успешного достижения цели. Роль РП получена, ожидания общества и компании выполнены, а вместо удовлетворения приходит апатия, снижение энергии и потеря интереса к работе. Все потому, что управленческая роль может съедать смысл, если человек не успевает переосмыслить, зачем он вообще в ней находится. И текст как раз про внутреннюю цену карьерного перехода и необходимость заново собрать себя уже после достижения "правильной" цели.
Очень любопытный и приземленный кейс про управление не "одним умным чатиком", а целым конвейером AI-агентов как проектной командой. Автор строит вокруг агентов полноценный пайплайн (бэклог, исследование задачи, спецификацию, реализацию, верификацию и тд). При этом с ростом доли AI ценность процесса не падает, а наоборот растет, потому что предоставленный себе агент очень быстро начинает производить хаос вместо результата.
Хороший ретроспективный текст о переходе от плоского управления к более структурированной модели, где внутри растущей команды приходится выделять тимлидов. Речь идет не про формальное повышение "самого сильного инженера", а про более тонкий и рискованный переход: когда у человека есть экспертность и влияние как контрибьютора, но роль тимлида требует уже другой логики - фокусировки, координации и управленческого перевода между уровнями системы..
О типовых лидерских грехах, которые команды считывают особенно остро: микроменеджмент, лицемерие, манипуляции, плохая обратная связь и ощущение непогрешимости руководителя. Статья строится вокруг реального разговора лидов о том, где заканчивается управление и начинается давление, чем манипуляция отличается от шантажа и почему даже хорошие намерения быстро портятся без саморефлексии.
В команде всегда есть отношения, а значит, всегда есть и попытки влиять друг на друга не только через формальные роли и рациональные аргументы. Автор не идеализирует рабочую среду и предлагает смотреть на управленческую жизнь без наивности: начальники могут давить, исполнители - молча соглашаться на невыполнимое, а вся система - производить выгорание под видом "надо собраться". Нужно распознавать подобные механики, не растворяться в них и сохранять рабочую эффективность и собственные границы.
Управление несколькими тимлидами - это принципиально другая задача, чем управление отдельными разработчиками. И автор описывает типичный провал первого уровня: кажется, что опытные лиды "и так все знают", а на практике руководитель быстро превращается в бутылочное горлышко, на котором замыкаются решения, а вокруг начинает разрастаться микроменеджмент. Поэтому на уровне управления лидами нужно уже не операционно контролировать людей, а выстраивать систему лидерства, где работает распределение ответственности, зрелость решений и самостоятельность без потери общего направления.
Рефлексивный текст о профессиональном кризисе, который приходит не от неуспеха, а как раз после внешне успешного достижения цели. Роль РП получена, ожидания общества и компании выполнены, а вместо удовлетворения приходит апатия, снижение энергии и потеря интереса к работе. Все потому, что управленческая роль может съедать смысл, если человек не успевает переосмыслить, зачем он вообще в ней находится. И текст как раз про внутреннюю цену карьерного перехода и необходимость заново собрать себя уже после достижения "правильной" цели.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥3🙏3
🔥 Заждались?
С вами снова самые интересные материалы по управлению проектами за 2 недели
1/2
🔫 Великая иллюзия Agile: как индустрия променяла инженерную науку на средневековый эмпиризм
Тадам - и снова у нас радикальная критика Agile. Автор обвиняет индустрию в мнимой победе: классическая инженерия якобы вовсе не требовала двигаться строго по «водопаду» и давно использовала итерации. А вот проблемы аджайл принес - подменил системное проектирование короткими циклами, ритуалами, надеждой, что архитектура как-нибудь возникнет по дороге. В итоге получаем лоскутность. Текст местами сгущает краски, зато интересный.
🤨 От хаоса к системе: как мы выстроили процесс Discovery (часть 2)
Как превратить подготовку требований из "шаманства" отдельных аналитиков в воспроизводимый процесс. Задача проходит преданализ, оформление постановки по шаблону, рецензирование, согласование с бизнесом и техническим руководителем, проверку тестировщиком и только затем попадает на общее обсуждение команды. Главное (хоть и банально) - не жалейте время и деньги на предпроектную работу.
😱 Внедрили Scrum, но Agile так и не случился. Почему?
Эссе о том, почему установка доски, проведение ретроспектив и переименование совещаний не превращают компанию в гибкую. Коротко - из-за культуры. Там, где решения по-прежнему принимает начальник, а ошибка воспринимается как повод найти виноватого, самоорганизация обычно остаётся красивой витриной. Поэтому начинать внедрение стоит не с выбора модного фреймворка, а с диагностики управленческой среды и ее подходимости для нововведений.
😢 Как считать экономическую эффективность внедрения ИТ-решений. Переводим функционал в деньги
“А сколько мы на этом заработаем?” - страшный вопрос от бизнеса) Вот автор и предлагает двигаться от решения к конкретным изменениям бизнес-показателей (снижению простоев, затрат, аварийности или продолжительности операций), а затем переводить их в денежный эффект. Полезный материал для подготовки обоснований проектов перед собственником.
😔 IT-шная конфликтология или как заказчик всегда прав
О том, почему техническая правота сама по себе редко помогает выиграть спор с заказчиком. Кратко - бизнес оценивает сроки и риски не по сложности кода, а по тому, насколько понятно специалист объяснил последствия, ограничения и стоимость решения. Поэтому автор советует говорить на языке целей заказчика, фиксировать договоренности, заранее описывать неблагоприятные сценарии и привлекать коллег, когда собственных аргументов недостаточно.
😁 Книга среднего уровня — 2. Перфекционизм руководителя
Классный текст про отказ от желания, чтобы вся команда делала одновременно всё и идеально. То, что помогало хорошему специалисту выделяться, на управленческой должности превращается в источник задержек у подчиненных. Доведение вообще каждого результата до совершенства хорошо съедает ресурсы, хотя часто достаточно просто качественно выполненной работы в разумный срок.
😧 RICE, ICE, MoSCoW: когда фреймворк приоритизации вас топит
Про то, что все эти ваши фреймворки не панацея, а даже наоборот. RICE перемножает несколько субъективных оценок и выдаёт якобы убедительное число, ICE особенно легко ломается на разном понимании сложности, а в MoSCoW все интересанты быстро объявляют свои задачи обязательными - и всё, конец. Решение - да, надо использовать приоритезацию, но и включать голову при принятии решения. (И ответственность брать на себя, а не сваливать на инструмент)
😘 Мягкая сила в жестких дедлайнах: 7 принципов влияния для PM и тимлидов
Если слышали про принципы Роберта Чалдини про влияние в маркетинге, то вот они, но в проектах. Взаимность, последовательность, социальное доказательство, авторитет, симпатия, дефицит, единство и прочее. Что-то у автора выглядит здраво, а что-то уже на грани манипуляций (с) - например намеренно начинать переговоры с завышенного срока или формировать у сотрудника чувство долга. Но и это интересно почитать, чтобы в такое не вляпаться)
С вами снова самые интересные материалы по управлению проектами за 2 недели
1/2
Тадам - и снова у нас радикальная критика Agile. Автор обвиняет индустрию в мнимой победе: классическая инженерия якобы вовсе не требовала двигаться строго по «водопаду» и давно использовала итерации. А вот проблемы аджайл принес - подменил системное проектирование короткими циклами, ритуалами, надеждой, что архитектура как-нибудь возникнет по дороге. В итоге получаем лоскутность. Текст местами сгущает краски, зато интересный.
Как превратить подготовку требований из "шаманства" отдельных аналитиков в воспроизводимый процесс. Задача проходит преданализ, оформление постановки по шаблону, рецензирование, согласование с бизнесом и техническим руководителем, проверку тестировщиком и только затем попадает на общее обсуждение команды. Главное (хоть и банально) - не жалейте время и деньги на предпроектную работу.
Эссе о том, почему установка доски, проведение ретроспектив и переименование совещаний не превращают компанию в гибкую. Коротко - из-за культуры. Там, где решения по-прежнему принимает начальник, а ошибка воспринимается как повод найти виноватого, самоорганизация обычно остаётся красивой витриной. Поэтому начинать внедрение стоит не с выбора модного фреймворка, а с диагностики управленческой среды и ее подходимости для нововведений.
“А сколько мы на этом заработаем?” - страшный вопрос от бизнеса) Вот автор и предлагает двигаться от решения к конкретным изменениям бизнес-показателей (снижению простоев, затрат, аварийности или продолжительности операций), а затем переводить их в денежный эффект. Полезный материал для подготовки обоснований проектов перед собственником.
О том, почему техническая правота сама по себе редко помогает выиграть спор с заказчиком. Кратко - бизнес оценивает сроки и риски не по сложности кода, а по тому, насколько понятно специалист объяснил последствия, ограничения и стоимость решения. Поэтому автор советует говорить на языке целей заказчика, фиксировать договоренности, заранее описывать неблагоприятные сценарии и привлекать коллег, когда собственных аргументов недостаточно.
Классный текст про отказ от желания, чтобы вся команда делала одновременно всё и идеально. То, что помогало хорошему специалисту выделяться, на управленческой должности превращается в источник задержек у подчиненных. Доведение вообще каждого результата до совершенства хорошо съедает ресурсы, хотя часто достаточно просто качественно выполненной работы в разумный срок.
Про то, что все эти ваши фреймворки не панацея, а даже наоборот. RICE перемножает несколько субъективных оценок и выдаёт якобы убедительное число, ICE особенно легко ломается на разном понимании сложности, а в MoSCoW все интересанты быстро объявляют свои задачи обязательными - и всё, конец. Решение - да, надо использовать приоритезацию, но и включать голову при принятии решения. (И ответственность брать на себя, а не сваливать на инструмент)
Если слышали про принципы Роберта Чалдини про влияние в маркетинге, то вот они, но в проектах. Взаимность, последовательность, социальное доказательство, авторитет, симпатия, дефицит, единство и прочее. Что-то у автора выглядит здраво, а что-то уже на грани манипуляций (с) - например намеренно начинать переговоры с завышенного срока или формировать у сотрудника чувство долга. Но и это интересно почитать, чтобы в такое не вляпаться)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4💘3
2/2
Небольшая подборка управленческой литературы, составленная инженером, которому пришлось учиться руководить уже по ходу работы. О книгах Тома Демарко, Патрика Ленсиони и других - и как они помогли ему разобраться с конфликтами, доверием, ответственностью и постоянным режимом аврала, причем все на реальных ситуациях.
Предельно простая типология сотрудников, основанная всего на двух показателях: сколько человек обещает и сколько в итоге делает. В итоге четыре типа — от громкого имитатора деятельности до незаметного сотрудника, который систематически выдает больше обещанного. Модель интересна еще и тем, что диагностирует руководителя: например, почему сильный специалист предпочитает молчать о своей работе.
Обзор восьмой редакции PMBOK как отхода от представления об управлении проектами как о наборе обязательных процессов и шаблонов. Количество принципов сократилось, основное внимание сместилось к созданию ценности, адаптации подхода под конкретную ситуацию, ответственности руководителя за осмысленный выбор методов. Стандарт старается примирить все модели, не объявляя ни одну из них правильной по умолчанию.
Текст разделяет организационные процессы на (1) инструменты, которые меняют реальность, и (2) символические ритуалы, которые лишь создают ощущение контроля. Среди второго и постмортем, после которого никто не меняет настройки, приоритеты или правила работы. Его роль часто сводится совсем не к предотвращению следующей аварии, а к коллективному переживанию предыдущей. В общем, кроме поминок, нужно проследить, что именно стало иначе после выполнения процесса.
О том, почему недостаточно буквально выполнить написанное в техническом задании. Да потому что требования почти неизбежно содержат пробелы, неявные предположения и внутренние противоречия, а маленькая просьба “добавить кнопку” быстро обрастает много чем. Автор предлагает проверять, помимо формулировки задачи, еще и пользовательский сценарий, бизнес-цель, граничные случаи, последствия изменений и связь с остальной системой.
Типа кейс превращения ретроспективы из регулярной комнаты ярости в рабочий инструмент улучшения процессов. Сначала команда раз в две недели пыталась вспомнить всё, что её раздражало, выпускала пар и возвращалась к тем же проблемам. А потом… Ситуацию изменили единое пространство для фиксации наблюдений и обязательное превращение жалоб в конкретные действия. Жалобы важны, но польза и ценность появляются только тогда, когда за ними удаётся найти наблюдаемый факт и проверяемое изменение.
Провокационный прогноз о нашем (?) будущем в мире ИИ. Под угрозой - руководители-передатчики, которые распределяют задачи сверху вниз и собирают статусы снизу вверх. Теперь это автоматизируется, а небольшие команды специалистов, усиленных агентами, смогут выполнять без передастов. Но все не так мрачно - постановка целей, разрешение противоречий, принятие решений, развитие людей и ответственность за систему по-прежнему нужны.
Ликбез по закону - добавление людей в уже опаздывающий программный проект часто не ускоряет, а ещё сильнее задерживает его. Новичков нужно вводить в контекст, обучать и подключать к коммуникациям, соответственно, опытные начинают тратить на это время. Ну и не каждую задачу можно разделить между исполнителями. Это не значит, что расширять команды бессмысленно, но вот в момент кризиса найм часто служит психологически удобной заменой более трудным решениям.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥3
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🔥2