Как писать концепцию проекта, ставить задачи, адаптировать agile, почему метод персон и JTBD нерабочие, как починить сторипойнты, что делать, если менеджер - петух, и как тушить пожары, сколько зарабатывают ПМы в банках и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Расширенные дайджесты, новости, обзоры книг и курсов для РП и аналитиков — в моем канале «Проектный дайджест», а теперь ещё и в удобной базе знаний, где я собрал уже почти 1800 статей по управлению проектами — с резюме, тегами и даже pdf‑ками.

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

Что такое концепция проекта и как ее написать

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

Как ставить задачи разработчикам и укладываться в дедлайны

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

Метод Кано на практике: как мы перестали гадать и стали понимать пользователей лучше

Команда Контура классифицировала фичи по модели Кано через парные вопросы пользователям и расчет коэффициентов "наличие/отсутствие". Выяснилось, что используемость фичи ≠ ценность: эмоциональный отклик может быть выше у менее часто используемой функции. По итогам сегментного анализа составили рейтинг "обязательных", "важных" и "интересных" возможностей и скорректировали приоритеты. Главный урок - опираться на данные пользователей, а не на ощущения команды. Шах и мат, фичеисты!

Продукт, который спасал компанию, но умер из-за плохого управления

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

Почему гибкость важнее догмы в Agile и управлении проектами

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

Kubernetes на пальцах: самое простое объяснение, что это такое

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

Почему "метод персон" и JTBD - это неработающий инструмент

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

Хватит страдать в Telegram. Мы сделали мессенджер, в котором удобно работать

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

Организуем сквозное управление контрактной разработкой, используя Kanban

Руководитель контрактного производства описывает, как собрал прозрачную систему управления на Kanban (проекты → доски → статусы), без лимита вложенности и с чатами в задачах. Цель - единый поток от запроса до отгрузки, видимость загрузки и контроль сроков. А еще в комментах рекомендуют метод STATIK, чтобы еще упростить доски и по-взрослому работать с блокерами.

Почему ваш таск-трекер демотивирует и как это починить

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

Принятие решений как "проектный треугольник": что действительно можно контролировать

Статья сопоставляет принятие управленческих решений с треугольником "объем - сроки - ресурсы": обычно реально управляются лишь два угла, а третий диктует рамки качества. И задача менеджера/команды - определить, какой риск вы берете на себя: срезать объем, растягивать сроки или усиливать команду.

Story Points: как Авито выровняло понимание оценок в команде

О том, почему одинаковые "3 стори-пойнта" у разных людей в команде означали разное, и как они наводили общий смысл. Кратко - зафиксировали, что оценивают относительную сложность, а не часы; ввели эталоны задач и правила обсуждения рисков до оценки; переобучили команду на реальных примерах; уточнили критерии "готово" и перестали сравнивать спринты по голым суммам SP.

Переосмыслите свой Scrum: укрепляйте гибкость, а не ритуалы

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

Проектный офис: как собрать единую цифровую среду управления

Если проектов много, ручное сведение все инфо в Excel ломается - нужна общая среда с единым словарем, шаблонами и связью "инициатива + портфель + показатели". Статья как раз дает практическую рамку: структуру базы знаний, типовые документы, порядок ревизии и ответственность ролей, которые в своей совокупности приводят к прозрачности статусов и единым правилам приоритизации.

Грабли на проектах: инструменты снижения неизбежных рисков

Автор перечисляет типовые провалы проектов, от туманной цели до несогласованных интеграций, и предлагает рабочие меры предосторожности. А именно чек-листы стартовых условий, матрицы рисков, контрольные точки и понятная карта ответственности. Важный принцип - обнаруживать скрытые зависимости до реализации/кодинга, а не после.

"Дальше будешь": почему "модный Agile" не спасает без смысла процесса

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

Планирование ресурсов проекта: как ничего не потерять и не перегрузить людей

Материал объясняет, почему без единого хранилища данных о людях, навыках и загрузке планирование превращается в гадание. Статья предлагает вести "витрину" ресурсов: роли, компетенции, текущая занятость, отпускные окна, а также правила бронирования и перераспределения. Есть примеры отчетов и сигналов перегруза, позволяющих реагировать заранее. Итог - управляемая загрузка и более честные сроки.

Методология P3.express на стыке с Agile и Scrum: что брать, а что не тащить

Краткое введение в P3.express (пошаговая система из десятков регулярных действий) - как она сочетается с двухнедельными спринтами и ежедневными ритуалами. Главный посыл - адаптировать методологию под реальность, что приводит к понятным целям и большей вовлеченности.

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

Петух на проекте

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

Как переосмыслить управление на удаленке

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

Анатомия соционики: как проектному менеджеру найти подход к каждому в команде (и даже в IT)

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

Как тушить пожары с помощью коммуникаций: живой опыт и истории из жизни

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

О вредных коммуникациях

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

Переход от координирующей роли к лидерской управленческой роли

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

Делай эти 5 вещей, если хочешь попасть на вилы к своим сотрудникам

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

Если орет шеф или заказчик (памятка менеджеру)

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

Сколько зарабатывают Product и Project Manager? Реальные зарплаты в Яндекс, Авито, Т-Банк и других компаниях

Интересно, сколько получают коллеги из топов? В тексте собраны (правда, не оч много) вилки по рынку с разрезом по ролям, грейдам и компаниям: разный "профиль" обязанностей дает заметный разброс компенсаций. Авторы отмечают влияние города/формата работы, бонусной части и испытательного срока на итоговую сумму.

20 навыков для управления проектами

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

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

Что такое выгорание и почему обычный отдых тут не поможет

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

Зумеры против труда: почему это поколение не хочет работать?

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

"Один ушел - и все сломалось". Почему в ИТ-эксплуатации важно отслеживать Bus Factor и как это делаем мы

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

Почему мы не даем инженерам делать "технические" задачи, и как это помогает бороться с техдолгом

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

От техлида до IT-директора: как растут лидеры в корпорациях

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

Отвлекать разработчиков ПО намного вреднее, чем считает большинство менеджеров

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

Онбординг нового сотрудника: пошаговое руководство для успешной адаптации

Хороший гайд с полным маршрутом: подготовка до выхода (аккаунты, доступы, наставник), план первой недели и месяца, чек-лист обучения и точки обратной связи. Авторы рассказывают про "карту роли" с границами ответственности и ожидаемыми результатами, а также матрица компетенций - как прозрачная траектория роста. Еще важны правила коммуникации и "витрина" знаний, чтобы не гоняться за ответами по чатам.

Как база знаний проектного офиса помогает в обучении сотрудников

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

Управление проектами: дайджест публикаций #43