Управление проектами: дайджест публикаций #43
Как писать концепцию проекта, ставить задачи, адаптировать 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 вещей, если хочешь попасть на вилы к своим сотрудникам
“Вредные советы” — пять симптомов потери управляемости: каждый живет по своим правилам, заявки ходят кругами, списки и документы не обновляются, нет аналитики, инфраструктура не тянет новые процессы. Лечение — единый центр управления, общие правила, актуальные реестры и видимость потока работ.
Если орет шеф или заказчик (памятка менеджеру)
Что-то вроде памятки по деэскалации: нужно сохранять паузу, переводить разговор в факты, повторять своими словами, что услышали, и фиксировать договоренности письменно. Автор советует вынести обсуждение в спокойный формат и предложить объективные шаги — от критериев к срокам. Еще из важного — гигиена каналов: не спорить в общей переписке и не отвечать «сгоряча».
Интересно, сколько получают коллеги из топов? В тексте собраны (правда, не оч много) вилки по рынку с разрезом по ролям, грейдам и компаниям: разный «профиль» обязанностей дает заметный разброс компенсаций. Авторы отмечают влияние города/формата работы, бонусной части и испытательного срока на итоговую сумму.
20 навыков для управления проектами
Обзор ключевых компетенций проджекта: планирование, цели и метрики, риски, коммуникации, фасилитация, управление знаниями и инструментарием. Навыки делятся на «жесткие» и «мягкие», подчеркивается, что без вторых первые не работают в реальности. Есть рекомендации по прокачке и материалы, с которых удобно начать.
Команда проекта
Что такое выгорание и почему обычный отдых тут не поможет
Автор четко разводит усталость, стресс, депрессию, с одной стороны, и профессиональное выгорание, с другой: последнее — это не «просто устал(а)», а синдром со своими признаками (эмоциональное истощение, деперсонализация, падение эффективности). Причем даже отпуск не помогает — нужны системные изменения: перестройка режима, границы по работе, психотерапия, работа с источниками стресса и возврат смысла в деятельность.
Зумеры против труда: почему это поколение не хочет работать?
Хит недели (по числу комментов) — текст про то, откуда берется конфликт ожиданий между работодателями и «зумерами». Мотивация меняется: молодым важны автономия, развитие и понятные критерии успеха, а «жесткие ритуалы» и микроконтроль только отталкивают. Отсюда и новые рабочие меры — наставничество, короткие циклы обратной связи, внятные цели и гибкие форматы (онбординг, гибрид, проектные роли).
Про понятие Bus Factor: сколько людей должно исчезнуть из процесса, чтобы он встал — и внезапно в эксплуатации эта цифра часто равна 1. МТС делится практикой профилактики: нужна ревизия зон ответственности, назначение дублеров, актуализация документации, регулярная ротация и измерение фактических рисков. Плюс шкала «нормативов» и чек-лист запуска передачи знаний — от таблицы зон до плана снижения уязвимости.
Почему мы не даем инженерам делать «технические» задачи, и как это помогает бороться с техдолгом
Автор критикует разделение на «технические» и «бизнесовые» задачи: язык формирует мышление, и «техдолг ради техдолга» уводит от ценности для пользователя. Предложение — ранжировать работы по влиянию на метрики продукта/команды, а не по ярлыку, и защищать «технические» изменения понятными эффектами (надежность, скорость, стоимость владения). При таком подходе исчезают вечные споры приоритета и растет дисциплина в описании задач.
От техлида до IT-директора: как растут лидеры в корпорациях
Про стадии роста от техлида к CIO, как меняются зона ответственности, мышление и набор решений. Полезные ориентиры — «первые 100 дней» по Гартнеру, переход от управления задачами к управлению портфелем, рисками и людьми. Развивайте сетку контактов, учитесь договариваться с бизнесом и держать единый контур процессов, а не «героически тушить пожары».
Отвлекать разработчиков ПО намного вреднее, чем считает большинство менеджеров
Переводной текст про цену переключений: любое «пс» (с) разрывает контекст и съедает десятки минут производительности. Системные источники — бессодержательные встречи, чаты без правил, срочные пинги и многозадачность просто ради занятости. Как исправлять — договоренностями о «тихих окнах», асинхронные апдейтами, повестками и протоколами встреч, буфером для срочных инцидентов.
Онбординг нового сотрудника: пошаговое руководство для успешной адаптации
Хороший гайд с полным маршрутом: подготовка до выхода (аккаунты, доступы, наставник), план первой недели и месяца, чек-лист обучения и точки обратной связи. Авторы рассказывают про «карту роли» с границами ответственности и ожидаемыми результатами, а также матрица компетенций — как прозрачная траектория роста. Еще важны правила коммуникации и «витрина» знаний, чтобы не гоняться за ответами по чатам.
Как база знаний проектного офиса помогает в обучении сотрудников
Как ПМО превращает базу знаний из архива документов в среду обучения: глоссарий, шаблоны, уроки проектов, стандарты и инструкции типа «как мы решаем типовые кейсы». Особое значение — у роли владельцев разделов и регламент обновлений, иначе материалы быстро «застаиваются». Из метрик выделены востребованность статей, сокращение времени онбординга, число повторяющихся ошибок.
Автор: tmplts