Влад Кузнецов | Project Management в IT

С чего я начинаю разбор проекта еще до разговоров с людьми

💬Первые пару дней на новом проекте я ни с кем стараюсь не разговаривать.

Каждый все равно расскажет свою версию и все они будут даже честными. У руководителя одна правда, у подрядчика другая (и ее он расскажет красивее всех).

На чтение трекеров и чатов раньше уходило 1-2 недели, сейчас хватает вечера – читаю-то уже не я.

🔍Рабочие чаты я обычно выгружаю целиком. В Telegram это экспорт истории в json (в др системах тоже есть варианты), 3-6 месяцев переписки весят немного.

Из выгрузки собираю карту связей: кто кому пишет, через кого идут вопросы между командами, про сами задачи и тд и тп.

На карте сразу видно человека, через которого проходит 50% связей.
В оргструктуре он обычно рядовой специалист, а весь проект почему-то едет с его скоростью…

🟢Трекер подключаю часто напрямую, у Atlassian есть официальный MCP для Claude (под серверные варианты есть куча утилит с аналогичным функционалом, ну и кэширование никто не отменял, в конце-то концов).
Первым делом смотрю, какие задачи висят дольше срока, за который команда обычно закрывает 85% своей работы. Это у нас кандидаты на разговор.

🟢Потом раскладываю входящие задачи за квартал на 2 кучки.
У Джона Седдона есть понятие failure demand – работа, которая появилась только потому, что что-то раньше сделали не так: доработки после приемки, баги прошлого релиза.
Команда искренне уверена, что ее заваливают новыми хотелками. А выясняется, что заметная часть потока – переделка своего же (и никакой найм тут не поможет).

🟢Дальше накладываю трекер на чаты.
Задача бодро числится «в работе», а в чате про нее 3 недели назад написали «пока стопорим». Решение принято, но до Jira так и не доехало.
По таким расхождениям и видно, как проект живет.

❗️

С людьми встречаюсь уже после этого, и не со всеми. 1х1 только с ключевыми лидами и топами, по 30 минут желательно.

Прихожу с гипотезами и прошу их опровергнуть. Сильные специалисты отвечают быстро и по делу, им это даже нравится. А разговоры «за жизнь» в попытке подружиться обрываю сразу – картину проекта они не расширяют никак, у нас задачи другие.

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

Оговорка про данные: переписки и задачи – чувствительная штука, прогонять их можно только там, где это разрешено политикой компании

Еще забавно, что часто тот самый человек-узел с карты почти всегда искренне удивляется, когда ему показываешь картинку 🙂

Изменение не успело сработать, а его уже отменили

В начале 60-х в MIT, в группе Джея Форрестера, придумали настольную игру про пиво 🍻

4 игрока: магазин, оптовик, дистрибьютор и пивоварня.

📋Каждый видит только свой склад и заказы от соседа, договариваться нельзя, а заказанное приезжает с задержкой в несколько ходов.

Спрос меняется ровно 1 раз и без всяких сюрпризов: покупатели брали 4 ящика в неделю, потом стали брать 8, и так до конца игры.

⚡️И почти в каждой партии начинается цирк.
Магазин видит дефицит и заказывает больше. Товар не приезжает (он в пути), заказывает еще. Оптовик видит рост заказов и берет с запасом…
Через десяток ходов склады завалены пивом, и заказы падают до нуля.

Джон Стерман в 1989-м разобрал результаты таких партий в статье для Management Science и нашел причину:

игроки системно забывают про то, что уже заказали и что сейчас едет.

Склад пустой – значит, надо заказать еще, хотя три прошлых заказа уже в дороге.
Издержки при этом выходили почти в 10 раз выше оптимальных.

В управлении командами происходит ровно то же самое, только ходы длиннее.

🟢Вот ввели новый процесс. Эффект появится месяца через 2-3, а через 3 недели на статусе уже спрашивают, почему ничего не поменялось.
Докручивают второе изменение, потом третье.
Когда первое наконец начинает работать, сверху лежат еще 2, и что из них что дало, разобрать уже невозможно.
Дальше обычно все откатывают, потому что «не работает» 🙂

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

У нас очень любят

«быстро делать выводы»

и

«оперативно реагировать»

.

В системе с задержкой это и есть самый надежный способ ее раскачать.

💡Урок пивной игры простой: прежде чем что-то добавлять, посчитайте, что уже едет.

Перед новым изменением выпишите, что вы поменяли за последние 3 месяца и что из этого еще не успело проявиться.

И у каждого изменения сразу фиксируйте дату, когда ждете результат и что именно должны увидеть. До этой даты в том же месте больше ничего не трогаете.

Звучит скучно и медленно. Зато это единственный способ понять, что вообще сработало…

Сижу сейчас над перепиской с одного проекта

Команда неделю готовила предложение руководству: перестроить работу с подрядчиками, придумать и ввести новый порядок приемок + бюджет на переход просчитать по всем направлениям…🥵
Отправили, через 2 дня ответ одним словом – «посмотрим».
Третий день все гадают, что это было, а работа по теме, естественно, стоит 🙂

А все просто:
Руководителю принесли большое решение, которое потом будет сложно откатить. Соглашаться страшно, а отказать вроде неудобно – люди ж старались как никак.
Вот и получается «посмотрим» (вполне рациональный ответ, хоть и бесит).

Так что переписываем предложение и просим меньше⬇️: месяц попробовать новую приемку с одним подрядчиком.
Не понравится – откатим как было.

Чем меньше шаг и чем дешевле ошибка, тем быстрее на него говорят «да» ⚡️

Закрутили контроль, а его стали обходить еще изобретательнее

Систему можно попробовать перенастроить.
Среди самых тупых консервативных представителей менеджмента обычно выглядит это так: давим на нужный показатель, а он через пару месяцев возвращается на место, будто ничего и не было…

У Донеллы Медоуз (на русском книга вышла как «Азбука системного мышления») для этого есть название – policy resistance, сопротивление системы вашим правилам.

🔍 В любой системе несколько участников, и у каждого своя цель.
Сдвинули систему в свою сторону – значит, оттащили ее от целей остальных и они начинают тянуть сильнее.

В итоге все пашут вдвое больше, а стоит все там же (и что забавно, не нравится это никому, но поддерживают все).

🔣Пример из жизни.

Комитет видит изменений меньше, чем до реформы, и радуется: дисциплина выросла 🤡
Хотя изменения никуда не делись, просто ушли с радаров.
Самое смешное, что на этих цифрах потом рисуют кейс для той же конференции.🔣

Рынок эту историю, кстати, давно поставил на поток:

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

📚Медоуз подчеркивает: назло тут никто не работает.

Каждый принимает вполне разумные решения из того куска системы, который видит.
Разработчик обходит комитет потому, что отвечает за срок – и спросите с него за этот срок вы же.

Поэтому перед тем как вводить правило, стоит прикинуть, чью работу оно ломает и что человеку придется делать, чтобы выжить.
Обычно это видно заранее, просто смотреть никто не хочет (на слайдах такое не рисуют).

Дальше у Медоуз совет, который она сама называет почти немыслимым для управленца:
перестать давить и поискать цель, которая устроит обе стороны.

С комитетом это значит развести мелкие правки и то, что реально двигает сроки и деньги. Мелочь пусть решают команды, а через комитет идет только серьезное.

P.S. Если вы полгода закручиваете гайки и удивляетесь, почему их откручивают все изобретательнее – поздравляю, вы в этой гонке полноправный участник.

Следующий пост – про задержку: почему система долго отвечает и как из-за этого управление превращается в раскачивание.

Система всегда выдает ровно тот результат, на который ее спроектировали

Есть фраза, которую почти везде подписывают именем Деминга:

любая система идеально спроектирована для получения тех результатов, которые она дает.

На самом деле автор другой – Пол Батальден, профессор медицины из Дартмута.
В 80-х он учился у Деминга, отсюда и путаница (раскопали это только в 2008-м).

Обычно фразу читают как упрек: результат плохой, значит сами виноваты.
Смысл в ней другой – она разворачивает внимание с людей на устройство самой работы.

И вот что важно:

система никогда не бывает сломанной.

❗️Она вообще не умеет работать неправильно.

Если у вас месяцами срываются сроки, никто не говорит про риски и все согласования идут по 3 недели – система в этот момент работает идеально.
Просто настроена она именно вот на такой результат.

🟢Самый базовый пример из поддержки
Команде ставят KPI: закрывать обращения за сутки.

Что происходит:
Через квартал сам показатель зеленый, а жалоб стало еще больше.
Тикеты закрывают, не дожидаясь решения, пользователь открывает новый и счетчик радостно засчитывает оба.

Система отработала безупречно: вы просили закрытые за сутки тикеты, вы их получили.

Про решенные проблемы речи нигде не было 🤌

Злого умысла тут тоже ни у кого нет, люди делают то, за что их хвалят.
Дальше обычно меняют людей (это же проще, чем признать свою ошибку и начать перепроектировать систему) или устраивают разнос, а через полгода новые закрывают тикеты точно так же 😕

Поэтому вместо «кто виноват» стоит спрашивать иначе: что в устройстве работы делает такое поведение выгодным?

⚠️Посмотрите, чем человек рискует, когда поступает «правильно».
В примере с поддержкой честно довести обращение до решения означает завалить свой KPI и остаться без премии.
Пока это так, разговоры про клиентоориентированность будут фоном.

🥴Возьмите поведение команды, которое раздражает вас сильнее всего, и представьте, что завтра всех заменили на новых людей.
Есть ощущение, что через полгода новые будут делать то же самое (а это так)? Значит, дело точно не в людях.

Дальше – про то, почему даже правильные изменения в такой системе норовят откатиться назад.

Начнем серию про «систему»

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

Тогда я еще думал, что это дело случая…ну не повезло, не сложилось, и вот сейчас то все точно встанет на правильные рельсы.

Менеджеров и не только там меняли регулярно.
Новые приходили и правда толковые, с опытом, и месяцев через 5-6 сидели в тех же авралах, что и их предшественники.

⚡️Постепенно до меня дошло, что дело вообще не в людях (ну или не только в них).

Человек попадает в устройство работы (системы), которое сложилось задолго до него, и довольно быстро начинает играть по его правилам:

согласовывать так же долго и молчать про риски там же, где молчали все до него.

📌Устройство это складывалось годами – из старых решений, привычек и страхов, из того, за что здесь хвалят и за что ругают.
Ни в одном регламенте этого, разумеется, нет 😕

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

Так что следующие несколько постов будут про систему – про то, почему она дает именно такой результат и почему любые изменения в ней норовят откатиться назад (и отдельно про то, как резкими движениями ее только раскачивают).

Доля сложных проектов, не достигших результата, выросла до 31%

CIO.com разбирает, почему IT-проекты продолжают проваливаться даже там, где IT и бизнес наконец договорились между собой.
📎База – свежий Pulse of the Profession от PMI: 31% сложных проектов не достигают полного объема заявленных выгод.

Для сравнения PMI приводит 12% из своей же работы 2024 года. Правда, это было другое исследование с другой выборкой, так что рост «более чем вдвое» стоит держать в голове как оценку, а не как замер.

Опрос серьезный: 2534 человека в 35 странах, из них 511 топ-менеджеров. 97% за год вели хотя бы один сложный проект, 81% говорят, что проекты усложнились.

Самое интересное в отчете – чем отличаются те, у кого сложные проекты идут лучше среднего.
🔢Согласование со спонсором на старте: 40% против 30% у отстающих.
🔢Поэтапное вовлечение стейкхолдеров: 50% против 42%.
🔢Работа с темпом команды: 42% против 33%.

Разрывы небольшие, а практики предельно обычные, ничего нового по сравнению с учебником десятилетней давности.

При этом 35% на последнем сложном проекте не использовали вообще никакого структурного подхода.

🔍CIO параллельно собрал у консультантов 12 причин провалов, и там та же картина: некому принимать решения, нет владельца со стороны бизнеса, спонсор ограничивается дашбордом, приоритизация не работает, часть стейкхолдеров забыли позвать.
Одна из историй в тексте – транснациональная компания, где целое подразделение узнало о внедрении новой технологии уже по факту.

Слово «сложность» тем и удобно, что звучит как внешнее обстоятельство и снимает вопрос, кто конкретно не согласовал спонсора на старте.

🔖Статья: cio.com/article/4215089/why-it-projects-still-fail-3.html
🔖Отчет: pmi.org/learning/thought-leadership/driving-success-in-complex-projects

Топы, которые кочуют по одной орбите

Компания, 1,5 года, реорганизация, уход по соглашению сторон.
Дальше следующая компания, и так по кругу.

Такое уже давно посчитали.
Heidrick & Struggles разобрали 20 000 своих поисков: 40% руководителей на топ-позициях уходят или проваливаются в первые 18 месяцев.
Медианный срок внешне нанятого топа – 2,8 года.

🔍Казалось бы, на такие позиции нанимают тщательно: кейсы, стратегические сессии, собеседования с советом директоров.

Только Center for Creative Leadership, который изучает крушения карьер не одно десятилетие, приходит к неудобному выводу: топы проваливаются почти никогда не из-за нехватки компетенций.

Ломается все на отношениях, политике и неверном понимании ситуации, в которую человек пришел.

Причем срываются чаще как раз те, кто на прошлом месте показывал отличные результаты.
Человек, который вытащил одну компанию, в другой садится в лужу – там другие люди, другая история и другие расклады. За час собеседования это никак не проверить…

❗️Хотя справедливости ради.

40% ранних уходов происходят потому, что роль урезали уже после найма:

компания развернулась, случилась очередная реорганизация, CEO переопределил зону ответственности.
Человек нанимался управлять направлением, а через полгода у него функция без бюджета.

💡Что же делают компании, которые перестали наступать на эти грабли.

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

🟢Там же договариваются о первых 90 днях: что кандидат должен успеть и по каким признакам обе стороны поймут, что вход прошел нормально.
Так хотя бы есть где разойтись по-человечески, не потратив год.

Выглядит как элементарная гигиена. И почти нигде не делается…🙂

«Надо синхронизироваться»

🔍Переводится это так: решение принимать некому, поэтому вместо решения будет встреча.

Синхронизация нужна, когда у сторон разная картина.

Но чаще картина одинаковая, просто нет человека, готового сказать «делаем так» и потом за это отвечать.
Встреча дает решению появиться как бы само, без автора.

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

Чем больше в календаре синхронизаций, тем меньше в компании людей с правом решать.

Стефан Вольперс: переход на «продуктовую модель» – часто просто ребрендинг

Автор: 20+ лет практики как product manager/product owner/agile-коуч, серт. тренер Scrum.org, автор гайда по антипаттернам Scrum.

🔢23 августа 2026
Опрос аудитории менеджеров из 48 компаний: среди компаний, заявивших о переходе на продуктовую модель работы, реальные решения о разработке изменились только в одной из 26 – в остальных это оказалось переименованием должностей без изменения сути.

Ироничный вывод: продакт-оунеры, можете расходиться – вывеску сменили, работаем по-старому 🙂

🔢Вторая часть – про AI: автор ссылается на исследование компании Faros AI (сама продает аналитику инженерных процессов, так что цифры не без интереса) на выборке 10 000+ разработчиков и 1255 команд – методология в статье не раскрыта, только итог: там, где активно внедряют AI, число смерженных pull request-ов выросло почти вдвое, но время на их проверку выросло почти настолько же, а сами PR стали заметно крупнее.

🟢Вывод: AI ускоряет написание кода, но не его проверку – узкое место просто сместилось.

🔖Первоисточник: https://age-of-product.com/product-owner-interview-questions/

Реорганизация как способ скрыть свои же грехи

Результатов нет, а объяснение всегда наготове: структура выстроена неправильно, легаси и железо тянут вниз, команды не той зрелости (виновато что угодно, кроме решений последних 1,5 лет).

И запускается очередная трансформация.

Причем это далеко не наша местная особенность.
По опросам McKinsey 82% руководителей проходили через оргредизайн в своей компании, у 70% он случился за последние 2 года.

Структуру перекраивают чаще, чем обновляют сайт.

Целей при этом достигают 23%, а 15% реорганизаций делают компании только хуже.

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

К тому же от нового топа ждут изменений.
Прийти и ничего не поменять означает признать, что до тебя было и так нормально…

💰Издержки платит организация, а заметность получает конкретный человек.
К моменту, когда станет ясно, что новая структура работает не лучше старой, он обычно уже в другой компании.

💡Отличить настоящую перестройку от ритуальной можно по одному признаку.
🟢В первом случае разговор начинается с проблемы: вот здесь работа встает, вот почему, вот как новая структура это чинит.
🟢Во втором – со схемы, а обоснование подтягивают уже потом.

Спросите у затевающих:

какую конкретную проблему решаем и как поймем, что решили.

Внятного ответа там обычно нет…

❗️А если такие вопросы решаете не вы – не бегите занимать освободившиеся позиции только потому, что они освободились.
Это лучший способ оказаться в роли, к которой вас никто не готовил.

Держитесь за то, что от схемы не зависит: рабочие договоренности и понимание, где на самом деле принимаются решения.

Квадратики поменяются, а работать вы будете с теми же людьми.

1 сентября, и про образование в менеджменте

Образование у меня финансовое, менеджмент шел внутри него – 4 семестра.
Из всей учебы мне запомнились ровно 2 предмета: менеджмент и маркетинг. Просто их вели действующие специалисты из крупных компаний, а не люди, пересказывающие методичку, написанную 30 лет назад.

📎Менеджмент – это дисциплина, и довольно старая.

🟢Первую бизнес-школу открыли в Париже в 1819 году.
🟢В 1881-м появился Уортон, первая университетская школа бизнеса в США, 13 студентов в первом наборе.
🟢В 1908-м Гарвард запустил первую программу MBA: 15 преподавателей, 33 студента, и там же придумали разбор кейсов, который теперь используют везде.
🟢В 1911-м Тейлор издает «Принципы научного менеджмента», и управление начинают изучать с измерениями и экспериментами.

200 лет отдельного образования и больше века исследований. Школы, которые между собой спорят, работы, которые проверяли десятилетиями.

Это не надстройка к профессии и уж точно не курс на 2 месяца с сертификатиком в конце.

❗️Тем не менее руководителем становится сильный инженер, ни дня не изучавший то, чем ему предстоит заниматься.
Никто не назначит главврачом лучшего электрика в больнице, а с управлением это норма: хорошо кодил – значит, разберется.

Разбирается он на живых людях, изобретая заново то, что разобрали до него полвека назад.

Через год у него уже есть «авторская» методология, выстраданная лично, и он охотно делится ей на конференциях.

Отсюда и фирменные решения…
Команда не успевает – наймем еще людей. У команд разные процессы – сделаем всем одинаковые. Быстро и уверенно.

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

🎓Дипломом это, к сожалению, не лечится.
Полно людей с профильным образованием, которые не могут нормально даже планерку провести.
Вопрос в привычке разбираться в своем предмете всерьез, как в любой другой профессии. Мы же не считаем нормальным, когда человек оперирует по видео с ютуба.

С Днем знаний, дорогие друзья!🎉
Хороший повод открыть что-нибудь по основной специальности – для руководителя она теперь называется менеджмент.

Проблема брейншторма не в том, что кто-то говорит громче

Брейншторм придумал рекламщик Алекс Осборн в конце 40-х.

Его идея звучала так: если собрать людей вместе и запретить критику, группа нагенерит больше, чем те же люди поодиночке.

Метод разошелся по всему миру и работает до сих пор.

❓Гипотезу проверяли десятилетиями, и она не подтвердилась.
В 1991 году Маллен с коллегами свел результаты воедино (тут можно почитать🥵): два десятка исследований, больше 800 команд.

Группы придумывают меньше идей, чем те же люди по отдельности, и качество идей тоже ниже.

🔍Причину обычно ищут в психологии: кто-то давит авторитетом, кто-то стесняется.
Главный механизм описали Диль и Штребе в 1987 году под названием production blocking.

Суть такая: пока говорит один, остальные слушают.

Слушая, человек не может параллельно разворачивать собственную мысль, потому что внимание занято.

К своей очереди он половину забыл, а оставшееся подстроилось под сказанное до него.
Даже давления никакого не нужно, механика работает и в самой доброжелательной команде.

💡Лечится это все порядком, который Делбек и Ван де Вен собрали в 70-х.
Встречу ведет фасилитатор, и она идет в четыре шага.

🟢Молчаливая генерация.
Ведущий формулирует вопрос, все 10 минут пишут идеи молча, каждый сам.

🟢Круг.
По очереди каждый зачитывает одну идею, ведущий выписывает ее на доску. Дальше следующий круг, пока идеи не кончатся. Обсуждать и оценивать на этом шаге запрещено.

🟢Разбор по списку.
Идут сверху вниз по доске, по каждой идее вопросы на понимание. Дубли объединяют, ничего не выбрасывают.

🟢Голосование.
Каждый молча расставляет приоритеты, ведущий считает голоса. Побеждает результат подсчета.

Разговор при таком порядке идет по списку, а не по тому, кто первым перехватил инициативу.
А решение принимает арифметика, так что переспорить всех уже недостаточно.

Формат тяжелый, на пару часов, и для еженедельной встречи команды он избыточен.

🙂P. S. Я уверен, что проблему брейншторма (до боли смешную) вы наблюдаете каждую неделю:
1,5 часа шума, а довольны в итоге 1-2 человека, которые громче всех говорили.
Обычно кто-то из C-level, заглянувший на огонек поделиться видением.

Он уходит с ощущением прекрасно проведенного мозгового штурма, а команда через день собирается снова – уже без него и уже чтобы действительно придумать, как это делать.

Вот эта вторая встреча и есть работа.
Первая была лицемерным ритуалом.

⚡️Готовлю для вас длинный и душный пост про брейншторминг и как с ним бороться…
💯 - если интересно

Мэтью Ходжсон предлагает ставить лимиты трат на AI-агентов

В выпуске подборки Food for Agile Thought Стефана Вольперса вышел текст Мэтью Ходжсона о разрыве между финансовым контуром компании и тем, как расходуют деньги агенты.

🔖Суть рассинхрона: бюджет согласуется раз в год, а агент тратит токены посекундно.
Компания планирует расходы в горизонте, который к такой скорости не приспособлен, и обнаруживает сумму постфактум.

Предложение Ходжсона – задавать лимиты трат на уровне самого агента, не дожидаясь следующего бюджетного цикла.

Текст авторский, количественных данных в нем нет, но мысль крайне интересная…