PM под градусом…дедлайнов

Удивительно, как часто под словом Канбан скрывается просто отсутствие структуры. «Без спринтов, без планирования, без ритуалов - у нас Канбан». Нет, у вас не Канбан, а просто хаос в колонке In Progress. Канбан не отменяет сроки, он просто заменяет искусственные итерации на непрерывный поток. Вместо спринта у тебя есть Lead Time - сколько задач проходит путь от Committed до Done. Если этот срок нестабилен, то система нездорова. Канбан не против планирования, он просто делает его на основании фактов, а не обещаний...

Если тебе кажется, что команда работает, а прогресса нет, то открой CFD. Эта диаграмма покажет, что происходит на самом деле, без лишних слов. CFD - это такая штука, где три линии рассказывают историю твоего проекта: ✈️ Arrival Line - сколько задач прилетает в ToDo. 🛬 Departure Line - сколько реально уходит в Done. А между ними - все то, что зависло в работе (WIP), тот самый лимб, где задачи живут неделями, пока кто-то «допиливает мелочь». Если линии расходятся, беда. Задач прилетает больше, чем команда успевает закрывать...

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

Мы привыкли считать, что в проектах не хватает времени. Но чаще даже не времени, а внимания. Мессенджер пикает, чаты кипят, кто-то зовет “на минутку”, потом “помоги посмотреть билд”, потом “всё пропало”. К вечеру вроде весь день был в работе, а ничего не сдвинулось. Внутри команды внимание - настоящая валюта. Каждый хочет кусочек, и чем выше ты в иерархии, тем дороже твой фокус. PM думает, что управляет временем, но на самом деле управляет вниманием - своим и команды. Если внимание размазано, даже идеальный процесс превращается в шум...

В каждом проекте есть тьма невидимых задач: они не в Jira, их никто не оценивает, но именно они высасывают капасити команды. Ты открываешь доску - все зеленое, спринт сбалансирован, velocity норм. А потом «бац» и сроки съехали, команда выжата, и никто не понимает, почему. А все просто: половина недели ушла на «мелочи». На уточнение дизайна «пока все тут». На ревью, которое «пять минут». На звонок «давайте быстро обсудим». На тест, который упал, но «я сейчас перезапущу». Каждый раз вроде ничего страшного, а потом день сгорел, и ни одна таска не закрыта...

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

В финансах есть теория опционов: право купить или продать актив позже, когда информации станет больше. В проектах этот прием работает так же. PM часто гордится тем, что «все быстро решил». Но в реальности скорость - не всегда сила. Раннее решение может оказаться тупиком, из которого потом дорого выбираться. Real Options - это умение оставлять дверь открытой. Решение принимается не сразу, а в тот момент, когда цена ожидания еще низкая, а информации уже больше. Как это выглядит в проектах: • Вместо того чтобы утвердить стек навсегда - запускаешь прототипы и смотришь, что взлетает...

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

Узкое место в проекте - это не метка в Gantt-диаграмме. Это живая, подвижная точка, где прямо сейчас теряется результат. Именно сейчас, потому что вчера это могло быть совсем другое место. Теория ограничений учит нас: производительность ограничена самым слабым звеном. Но в проектах слабое звено не закреплено. Оно перемещается, а иногда и внутри дня. Это и есть динамический bottleneck: не постоянный дефект, а подвижная зона перегрузки. Где он проявляется: - Функция, которую раньше тянул один человек...

Многие PM-ы мыслят так: «Сейчас все продумаем, запланируем, согласуем и поедем как по шпалам». Но в реальных проектах дорога редко бывает прямой. То бизнес поменяет приоритет, то архитектура упадет, то выяснится, что фича вообще не нужна. И ты оказываешься с жестким планом, который ведет не туда, а пересобрать его уже некогда. Что делает Option Thinking Он не заставляет угадывать правильный путь заранее. Он предлагает готовиться к тому, что путь точно изменится. И ты не паникуешь - потому что у тебя есть варианты...

Когда у тебя четыре команды, пять заказчиков, куча взаимных блокеров и все «на вчера» - ты быстро понимаешь: это не удержать просто регулярными митингами и табличкой с дедлайнами. Именно про это говорит закон Эшби из кибернетики: Чтобы управлять сложной системой, твоя система управления должна быть не менее сложной. Проще: нельзя рулить хаосом с помощью линейки и таймера. Что это значит для PM-а? Если проект живет в турбулентности: меняются приоритеты, появляются новые стейкхолдеры, команда частично...

В проектах редко случаются уникальные катастрофы. Чаще всего это одни и те же сценарии, которые просто меняют маску. Системное мышление называет их archetypes - типовые паттерны, по которым система сама себя загоняет в тупик. Вот несколько, которые в IT встречаются чаще всего: 1. Лечение симптомов вместо причины. Прод падает из-за архитектуры → команда заливает хотфиксы. Качество кода падает → берут больше тестировщиков. Сроки горят → кидают еще людей. Симптом лечат, но корень остается, и проблема возвращается сильнее...