Канбан на практике, гайд по проектным метрикам, портфельное управление, хорошее и плохое ТЗ, обзор книги по 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, асинхронные апдейты, “одно окно” между командами и более четкие зоны ответственности. 

Как организовать работу удалённых сотрудников

Большой практичный материал про удаленку без лишней романтизации. Удаленка дает свободу и расширяет возможности найма, но одновременно приносит риски потери контроля, размытия границ между работой и жизнью, перегруза созвонами и выгорания. Как сделать правильно: продумать формат, обеспечить людей всем необходимым, настроить самостоятельность и прозрачность процессов, собрать базу знаний для онбординга и повседневной работы, а также следить за реальной загрузкой сотрудников, а не надеяться, что «они сами как-нибудь распределятся».