Канбан на практике, гайд по проектным метрикам, портфельное управление, хорошее и плохое ТЗ, обзор книги по P3. Express и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Расширенные дайджесты, новости, обзоры книг и курсов для РП и аналитиков — в моем канале «Проектный дайджест», а теперь ещё и в удобной базе знаний, где я собрал уже почти 2000 статей по управлению проектами — с резюме, тегами и даже pdf‑ками.
Основы, гайды и инструменты
Как не стоит писать функциональные требования для Технического Задания
Античек-лист для всех, кто пишет ТЗ в режиме «быстро накидаем, а там разберёмся». Автор проходит по типовым ошибкам (попытка сделать документ за один присест, смешивание требований с решениями, переписывание бессвязных пожеланий заказчика и тд). Главная мысль: хорошие требования рождаются не из спешки и копипаста, а из обследования, декомпозиции и нормальной аналитической работы. И отсюда компактный чек-лист качества: кто, что, когда, как проверяется, нет ли двусмысленности и не подменено ли «что нужно» на «как это сделать».
Простые хлопоты: когда проекту действительно нужно управление
Концептуальная статья о том, что управленческие действия в проектах слишком часто происходят по ритуалу, а не по реальной необходимости. Автор предлагает метафору «температуры» — уровня накопленной неопределённости, которая растёт по мере появления дефектов, задержек, искажений понимания и других скрытых потерь. Дальше строится упрощённая модель, в которой вмешательства менеджмента рассматриваются как способ «охлаждать» проект, когда неопределённость становится опасной.
Что такое канбан на практике: изучаем доски, WIP-лимиты и метрики
Хороший базовый разбор канбана для тех, кто до сих пор считает, что канбан — это просто доска с колонками и карточками. А это прежде всего способ управлять потоком работы. В статье есть исторический заход от Toyota к адаптации подхода в разработке ПО, а затем разбор ключевых элементов: доска, карточки, колонки, сигналы проблем, ограничения WIP и метрики потока. Для опытных людей здесь вряд ли будет откровение, но как вводный и одновременно «отрезвляющий» материал — вполне удачно.
От стратегии до проектов: для чего бизнесу переходить к портфельному управлению
Про портфельное управление - оно нужно не потому, что звучит солидно, а потому, что инициатив становится слишком много, а денег и людей - слишком мало. Схема такая: собрать единый реестр инициатив, зафиксировать бюджеты, сроки, риски и владельцев, а потом принимать инвестиционные и приоритизационные решения на общей картине. Отдельно полезен блок о признаках, когда портфель у компании уже де-факто есть, просто он не управляется.
Как я запилил свой Scrum Poker, потому что все остальные — отстой
Живой и немного хулиганский текст из серии «меня достали плохие инструменты, поэтому я собрал свой». Автор начинает с боли планинг-покера (лаги, тяжёлые решения, зависимость от Jira и отсутствие нужных функций), а затем показывает, каким сделал свой сервис. Из фич — удобное управление сессиями, автоматический расчёт среднего и архитектура с быстрым стартом и минимумом инфраструктурной возни.
Как плохое ТЗ может удвоить стоимость проекта
Здесь тезис максимально прямой: длинное и подробное ТЗ не только не гарантирует успех, но часто создает ложное чувство определенности и толкает команду к избыточной разработке. Автор критикует привычку описывать заранее решение, а не пользовательскую проблему, и показывает, как это ведет к раздутому объему функциональности, сроков и бюджета. В качестве контраста предлагается более лёгкий подход: минимальный набор требований, фокус на потребностях пользователя, user story, критерии приёмки и постепенная детализация по ходу работы.
Сократили срок выхода задач в продакшен почти вдвое: что реально сработало
Хороший практический кейс без лишней героики: команда показывает, какие изменения реально повлияли на скорость доставки (цикл выхода задачи сократился с 23 до 11 дней). Среди сработавших мер: публичные кросскомандные демо, более детализированные этапы жизненного цикла задачи, чтобы увидеть реальные узкие места, более контекстное описание задач и автоматизация мелких коммуникаций через триггеры и уведомления. При этом ускорение получилось из комбинации всех инструментов.
«Не усложняй! Управление проектами по методу P3.express» — коротко о книге
А это мой небольшой обзор классной книги о P3.express как о методологии для тех, кто устал от крайностей — либо полного управленческого бардака, либо ритуализированного процессного цирка. Главный образ книги: минималистичная середина — 33 шага, 7 этапов, минимум документации и акцент на принципах.
Переезд 1С: быстро, дёшево, трезвые грузчики
Практичный текст про специфический сценарий перехода с одной системы 1С на другую. Автор жёстко разводит два проектных концепта: полноценное внедрение с обследованием, переосмыслением процессов и дорогой аналитикой — и «переезд», где главное сохранить работоспособность бизнеса, минимизировать доработки и не тащить в проект лишние мечты. По сути это текст против проектного романтизма: если бизнес не хочет трансформации, а хочет выжить при смене платформы, не надо продавать ему космический корабль вместо грузчиков.
Собрать организационные и ИТ-проекты воедино: опыт группы компаний «Нацпроектстрой»
Корпоративный кейс про внедрение ИСУП. В компании сформировали проектный офис, описали около 90 требований к системе, сравнили решения и выбрали платформу, где были важны портфельное управление, календарно-сетевое планирование, учёт ресурсов, совместная работа и бюджетный контроль. После внедрения появилась целостная картина по портфелю, проектный офис стал видеть статусы, риски и отклонения без ручного сбора информации и получил возможность перераспределять ресурсы на уровне ��сей группы компаний. Текст, конечно, слегка вендорский, но как иллюстрация того, зачем крупной структуре вообще нужна единая проектная система, он вполне рабочий.
Никого не повышают за простые решения
О перекосе, который знаком почти любой команде: сложные решения выглядят «впечатляюще», а простые — как будто слишком банальны, чтобы считать их достижением. Во многих компаниях сотрудники бессознательно получают больше признания за архитектурную навороченность, чем за элегантное решение, которое быстрее внедряется, легче поддерживается и лучше переживает будущее.
Юридическая гигиена ИТ-проектов или как отстоять код, деньги и нервы
Для тех, кто привык считать договор чем-то вторичным по сравнению с требованиями и сроками. Разработка софта почти всегда требует смешанной договорной конструкции, потому что здесь переплетаются подряд, НИОКР и вопросы лицензирования или отчуждения прав. Дальше акцент смещается на ТЗ как часть договора. Дополнительно разбираются вопросы цены, налоговых изменений и общие юридические риски, которые в ИТ-проектах слишком часто обнаруживаются уже после конфликта.
PMBoK 7 vs PMBoK 8: что изменилось и зачем это знать креативному PM в геймдеве
Интересный обзор изменений в PMBOK, написанный через призму геймдева и арт-аутсорса. Автор показывает, что восьмая версия стала заметно менее догматичной: вместо набора правил акцент смещен на ценности, встроенное качество, адаптацию под контекст и право выбирать подход в зависимости от ситуации. Теперь адаптация — не личная импровизация ПМа за пределами стандарта, а встроенная часть самого подхода. Есть и любопытный блок про AI: стандарт уже поднимает тему автоматизации, ассистирования и правовых вопросов вокруг сгенерированного контента.
Как правильно оформлять РИДы в ИТ-проектах, чтобы не создавать спорных ситуаций
Хороший разбор темы, которую в проектах часто упрощают до формулы «всё, что сделали, автоматически наше». На практике статья показывает, что с результатами интеллектуальной деятельности всё тоньше: нужно смотреть, где был реальный творческий вклад исполнителя, а где — просто использование готовых инструментов, библиотек, UI-китов или материалов по лицензии. Дизайн может быть РИДом за счёт самостоятельной структуры и визуальной логики, код — за счёт оригинальной бизнес-логики и алгоритмов, тексты — за счёт способа выражения, а не самих идей.
Спринт в методологии Scrum: что это и как работать по спринтам
Базовый учебный разбор спринтов в Scrum без особых откровений, но и без лишней путаницы. Спринт здесь не сводится к «нарезке задач по неделям», а связывается с работой в условиях неопределенности и идеей поставки рабочей, тестируемой ценности на каждом витке. А собственно спринт объяснен короткий цикл длиной от одной до четырех недель, в рамках которого команда делает ограниченный объем работы, получает обратную связь и при необходимости корректирует дальнейшее движение.
Менеджер проекта - карьера и навыки
Head of Product или проджект на стероидах? Учимся читать вакансии между строк
Слегка язвительная заметка о том, как под красивой вывеской Head of Product часто прячут роль человека, который будет тащить на себе операционку, аналитику, синхронизации и контроль разработки (знакомо, да, коллеги?). Автор разбирает конкретные формулировки из вакансии и показывает, что требования вроде «работать руками», «нести полную ответственность», «управлять командами разработки» и при этом отвечать за продуктовые метрики часто указывают не на стратегическую продуктовую роль, а на смесь delivery, project и product в одном измученном человеке.
Дисциплина не работает. И это лучшая новость для всех, кто устал от самоистязания
О том, что людям чаще всего не нужна «жесткая дисциплина» сама по себе — им нужна система, которая помогает двигаться к цели без ощущения постоянного внутреннего насилия. Держится всё не на силе воли, а на приятности и простоте самого процесса. И бросают полезные инструменты не из-за лени, а потому что система начинает раздражать, стыдить и давить. Поэтому статья - про дизайн поведенческих систем: мягкий ритм, низкий порог входа и отсутствие самобичевания работают лучше культа «соберись, тряпка».
Компания без менеджеров — бред или следующая реальность?
Главный тезис тут не в том, что менеджеры исчезнут, а в том, что начинает умирать их старая функция как передаточного звена между «наверху решили» и «внизу исполнили». Автор приводит примеры очень компактных компаний с аномально высокой выручкой на сотрудника и связывает это с сокращением слоев согласования и “менеджеров среднего звена”, но не сваливается в лозунг «менеджеры больше не нужны». Самая сильная часть текста — попытка показать, что автоматизация сама по себе не решает управленческую проблему: по приведённой модели лучший эффект дает не просто замена рутины AI, а сочетание автоматизации, развития людей и одновременной перестройки бизнес-модели.
Парадоксы AI продуктивности. Почему мы работаем быстрее, но устаём больше
Про обратную сторону AI-ускорения: вроде бы инструменты экономят время, но субъективно работа от этого не становится легче. Часть рутины действительно исчезает, но освобожденное время мгновенно заполняется новыми ожиданиями, новыми задачами и постоянной когнитивной перестройкой под очередной инструмент. В итоге мы не столько «меньше работаем», сколько быстрее вращаемся в том же барабане, только теперь с AI-помощником..
Руководство WEEEK для менеджеров. Мини-курс
Большой гайд по самому сервису WEEEK, цель которого - быстро помочь разобраться в рабочем пространстве, создать задачи, пригласить команду и понять, как устроены базовые механики сервиса. Также много про роли пользователей, уровни полномочий, индивидуальные доступы к модулям и общей логике настройки пространства.
Команда проекта
Почему джуны на сложных проектах — это нормально
Текст против мифа о том, что крупные и живые проекты — территория только для мидлов и сеньоров. Автор на собственном опыте младшего аналитика показывает, что джун — это не «наблюдатель на экскурсии», а вполне рабочая единица: он участвует в демонстрациях, уточняет требования через прототипирование, готовит постановки, тестирует, разбирает инциденты и берёт на себя заметный пласт прикладных задач.И вообще, польза джуна возникает не вопреки его уровню, а благодаря нормально устроенной команде, где есть база знаний, понятная эскалация вопросов и живая поддержка старших коллег.
Сколько стоит ваш созвон: считаем временные потери и чиним процесс в инженерной команде
Созвоны — это внезапно вполне осязаемые потери команды, которые можно посчитать и уменьшить. Автор описывает, как в инженерной команде посмотрели на календари и увидели довольно такую картину: 12–16 встреч в неделю на человека, около 30% встреч без повестки, средняя длительность 45 минут и примерно каждая пятая встреча, которую можно было заменить письмом или обсуждением в чате. Отсюда рекомендации: нормальная повестка как промпт, сокращение числа участников и использование фасилитации как отдельной роли, которая удерживает встречу в рамках цели.
Что такое эффективная команда, почему 91% сотрудников работают вслепую и причем тут «эчпочмак»?
Любопытная попытка собрать модель эффективной команды из трёх углов: достижение бизнес-целей, психологическая и мотивационная устойчивость, а также предсказуемость потока. Автор называет эту конструкцию «эчпочмаком» — не только ради запоминаемости, но и чтобы подчеркнуть простую мысль: если один угол сломан, вся конструкция течёт. Главный тезис статьи — приоритет целей: можно иметь мотивированную команду и хорошие метрики, но если люди не понимают, куда и зачем движутся, они просто эффективно едут не туда.
Принцип управления командой «3D»
И тут тоже команда мыслится через три режима: демократия, делегирование и добровольчество. Это некая схема для выбора подхода по ситуации: где-то важно обсуждение и совместное решение, где-то — передача полномочий, а где-то — ставка на инициативу тех, кто готов взять ответственность на себя. Текст без академизма, но с нормальным чувством реальности.
Метрики здоровья команды: быстрая диагностика в период кризисов
Очень плотный и прикладной текст о состоянии команды через систему сигналов. Автор предлагает собрать единый индекс здоровья из четырёх групп метрик: доступность, скорость, качество и здоровье процесса, причем сразу с весами, источниками данных, целевыми значениями и логикой расчета итогового индекса. Текст местами тяжеловат и больше похож на инженерный гайд, чем на легкую статью, но подход интересный, рекомендуем глянуть.
Коммуникации в командах: где найти время на реальную работу?
Про действительно болезненную тему - коммуникации всё чаще вытесняют саму работу. Значительная часть рабочего времени уходит на встречи, чаты, согласования и отчёты, и автор подкрепляет это статистикой про часы, уходящие на митинги, и массовую усталость от видеовстреч. Рекомендации: блоки глубокой работы в календаре, правило 80/20, асинхронные апдейты, “одно окно” между командами и более четкие зоны ответственности.
Как организовать работу удалённых сотрудников
Большой практичный материал про удаленку без лишней романтизации. Удаленка дает свободу и расширяет возможности найма, но одновременно приносит риски потери контроля, размытия границ между работой и жизнью, перегруза созвонами и выгорания. Как сделать правильно: продумать формат, обеспечить людей всем необходимым, настроить самостоятельность и прозрачность процессов, собрать базу знаний для онбординга и повседневной работы, а также следить за реальной загрузкой сотрудников, а не надеяться, что «они сами как-нибудь распределятся».
