Школа проектного специалиста

💣 Архитектор и его тень: почему «я один знаю, как тут всё устроено» — бомба В почти каждом проекте есть такой человек. Тот, без которого всё остановится. Он знает, почему интеграция с складом работает именно так, а не иначе. Он помнит, почему вот этот регистр в 2019 году переписали задом наперёд. Он один понимает, как связаны эти три подсистемы, которые официально «независимы». Все это знают. Все этого боятся. И никто с этим ничего не делает. Его называют по-разному: «наш гений», «человек-система», «тот, кто держит всё на себе». Звучит как комплимент. На самом деле — это диагноз проекта. И бомба. Честно говоря, когда я впервые столкнулся с этой темой, я думал, что проблема в людях — дескать, не хотят делиться знаниями, берегут экспертизу как сокровище. Сейчас думаю иначе. Проблема почти никогда не в человеке. Проблема в системе, которая позволяет знанию жить только в одной голове. И в культуре, которая это поощряет. Потому что давайте честно: носитель уникального знания — это удобно. К нему подошёл, спросил, получил ответ, пошёл дальше. Никакой документации, никаких вики, никаких онбордингов. Быстро, точно, по делу. Пока он есть. А потом его нет — и оказывается, что проект держался на одном человеке. И не важно, ушёл он в отпуск, заболел, сменил работу или просто выгорел. Результат один: знание исчезло. Это называется bus factor — «фактор автобуса». Грубо: сколько человек в команде должно попасть под автобус, чтобы проект обрушился? В здоровой команде ответ — «много, мы друг друга подстрахуем». В нездоровой — «один». И вы знаете, о ком речь. Как распознать бомбу заранее Тревожные звоночки достаточно универсальны. Если вы замечаете за своим проектом что-то из этого — пора что-то менять. • Любой нестандартный вопрос идёт к одному и тому же человеку. Неважно, формально ли он архитектор — фактически он держит контекст. • Документация есть, но она устарела на пару лет. Или написана, но «не для людей» — разобраться без автора невозможно. • Он сам жалуется, что «некому передать», но при этом не передаёт. Кажется, что времени нет. На самом деле — нет привычки и нет системы. • Новые сотрудники приходят и месяцами не могут войти в тему, потому что «всё в голове у Иванова». • Когда он в отпуске, половина решений откладывается. Когда возвращается — навёрстывается авралом. Что с этим делать (и почему «просто задокументируй» не работает) Самая частая рекомендация — «надо всё описать». И это не работает. Потому что носитель знания знает в тысячу раз больше, чем способен рассказать. А записанное без контекста — мертво. Документация, написанная «вообще», никем не читается и быстро устаревает. Поэтому работают другие подходы. Не «опиши всё», а «сделай так, чтобы знание не концентрировалось». Парное программирование и парные ревью. Не «Иванов делает архитектуру, остальные смотрят», а «Иванов делает архитектуру вместе с кем-то, кто будет её потом поддерживать». Знание передаётся в процессе работы, а не через документ. Ротация. Если один человек годами ведёт один и тот же блок — это сигнал. Ротация зон ответственности заставляет объяснять, структурировать, передавать. Больно, но эффективно. ADR — Architecture Decision Records. Короткие записи: какое решение принято, почему, какие альтернативы рассматривали. Не «вся документация», а именно решения с обоснованием — тот контекст, который теряется первым. Онбординг как тест. Если новичок за две недели не может разобраться в блоке без постоянных вопросов — знаний вне головы автора там нет. Это диагноз блоку, а не новичку. Знаете, что самое сложное во всём этом? Не техническая часть. Технически всё понятно. Сложнее всего — признать, что герой-одиночка — это не ценность, а риск. И что культура «мы держимся на Иванове» — это не повод для гордости, а повод для тревоги. Хорошая новость: bus factor можно снизить. Это не дар, это практика. И чем раньше начать — тем дешевле обойдётся. Пока автобус ещё не подъехал. #архитектура #bus_factor #проектная_команда #риски #практика #управление_знаниями

💣 Архитектор и его тень

Claude собрал шутер за полдня: а скоро вашу 1С тоже напишет нейросеть? Недавно в интернетах наткнулся на историю, которая зацепила. Один человек (Мэтт Шумер) дал Claude Opus 5 один большой запрос — создать современный браузерный шутер, подключить субагентов и улучшать результат. тот взял и собрал браузерный шутер. 55 тысяч строк кода, и никаких готовых картинок, всё из головы — вернее, из кода, процедурно генерируется на лету. Это ж как если бы у нас в 1С запрос сгенерировал не просто отчёт, а целую подсистему с интерфейсом, формами и обменом данными . Конечно, до оригинального продукта этому Call of Duty от Claude далеко, критики поставили 5 из 10 . Но! Раньше, чтобы сделать такой прототип, нужна была небольшая студия разработчиков. А тут один человек запустил целую команду виртуальных помощников одним запросом . Выводы напрашиваются сами собой. Очень скоро нас, возможно, захлестнёт волна типовых конфигураций, решённых за выходные, или даже целых ERP-систем, собранных по запросу "Сделай мне как в SAP у Газпрома". Спрос на рутинное переписывание типовых отчётов упадёт, а вот ценность архитектора, который сможет грамотно сформулировать задачу для нейросети, поставить "техническое задание", правильно разделить работу между агентами и проверить их результат — возрастёт в разы. Если вы вдруг получаете зарплату за то, что переводите требования бизнеса на язык кода и находите нестандартные решения, то вы определённо на верном пути. Ваша работа становится всё более ценной, а инструменты — сложнее и интереснее. Стоит непременно продолжать, осваивать новые подходы и не бояться задавать этим нейросетям сложные вопросы. Кстати промпт и исходный код лежат на GitHub (https://github.com/mshumer/Claude-of-Duty)

Вот как можно мягко, но уверенно отказать от переработок, не сгорая на работе: главное — говорить с начальством на языке выгод для компании, а не просто «не хочу». Например, «сейчас я на пределе, и качество пострадает, если буду тянуть ещё», звучит куда лучше, чем жалоба. Техники? Честность, конкретные сроки и предложение альтернатив — вот база. Личный опыт подсказывает: лучше сразу обозначить границы, чем потом жалеть. Баланс — это не роскошь, а необходимость, иначе выгорание обеспечено. Ну, в общем, пробуйте, адаптируйте под себя, ведь каждый босс — это отдельный случай.

✨ ЕЖЕНЕДЕЛЬНЫЙ ДАЙДЖЕСТ НА КАНАЛЕ «ШКОЛА МЕНЕДЖЕРА ОРГАНИЗАЦИИ» За последнюю неделю на канале вышли сильные материалы про планирование, приоритеты, RACI, Agile, лидерство и управленческие ошибки. 📌 Почему хорошие планы так часто остаются планами Почему даже разумные и хорошо подготовленные планы часто не дают результата? В статье разбирается, как выбрать главный приоритет, сделать прогресс заметным и поддерживать ритм ответственности. 🕒 Тайм-менеджмент для занятых: 5 техник, которые переживут обычный понедельник Практичные приёмы для тех, чей день постоянно съедают встречи, письма и срочные просьбы. Текст помогает не потерять главную задачу среди операционки. 🏚 Ваш бизнес может выглядеть идеально, но именно в этот момент он начинает разрушаться Материал про энтропию в организациях и то, почему система без притока энергии постепенно приходит в беспорядок, даже если внешне всё выглядит нормально. 🧩 RACI без бюрократии: четыре роли, которые должен понимать каждый сотрудник Статья о том, как матрица RACI помогает убрать размытость ролей и избежать ситуаций, когда ответственность оказывается ничьей. 📊 Матрица Эйзенхауэра для руководителя: как не утонуть в операционке Разбор приоритизации для руководителей: что делать, когда срочные вопросы вытесняют действительно важные. ⚙️ Как «Росатом», Сбер и государственные службы приручали Agile О том, как Agile работает в больших организациях, где гибкость приходится согласовывать почти так же, как бюджет или регламент. 🟡 Что означают статусы задач: “в работе”, “почти готово”, “на согласовании” Текст про управленческий язык статусов и о том, почему «в работе» далеко не всегда означает реальное движение задачи. 💼 Рынок управленцев: компаниям больше не нужен человек, который просто хорошо руководит Статья о том, как меняются ожидания компаний от руководителей: важны уже не красивые речи, а измеримый результат.

Все мы привыкли думать, что бизнес — это про стабильность. Ну, или хотя бы про предсказуемость. Взял планку, выполнил, получил профит. А теперь посмотри, что делают продавцы на WB. Карточка: «Покупай, пока не сторело». Продавец ловко вплетает в рекламу то, что сейчас у всех на слуху — эти удары БПЛА по складам, эту тревогу, эту атмосферу неопределённости. И превращает это в триггер. Просто искусно сыграно на общем фоне. Раньше я думал, что адаптация в бизнесе — это когда ты серьезно и продуманно перенастраиваешь рекламную политику. А сейчас приходит понимание, что адаптация — это умение поймать общий нерв и завернуть его в оффер. Чтобы человек, пролистывая ленту, увидел знакомую боль, улыбнулся или напрягся — и купил. Не потому что ему нужна вещь, а потому что он проникся моментом. В IT мы часто грешим тем, что пытаемся быть слишком правильными, слишком логичными. Клиенту — красивые презентации, партнёрам — дорожные карты, в соцсетях — экспертный контент. А эти ребята с маркетплейса просто берут происшествие, о котором все говорят, и вешают его на свой товар. Прямо. Без цензуры. Даже если это страшновато. Они переупаковывают страх в скидку и продают. И вот в этом, если честно, огромный урок для всех нас в IT. Мало уметь делать качественный продукт. Нужно ещё уметь вписать его в контекст дня. Чтобы он звучал не как «очередная разработка», а как ответ на то, что у людей прямо сейчас болит. Продавцы на WB это делают на интуиции. Схватили инфоповод — переложили на ценник — запустили. Мы же можем сделать то же самое, только словами, кейсами, постами, предложениями. И если ты можешь обыграть всё так, чтобы клиент увидел в твоём предложении спасение от хаоса — ты выиграл. Неважно, продаёшь ты коробки с товаром или IT проект. Главное — попасть в резонанс. Сделать так, чтобы у человека в голове щёлкнуло: «Ага, это про меня. Это про сейчас». Мы в IT, если честно, часто забываем про эту человеческую часть. А зря. Потому что технологии — это просто инструмент. А продаёт всегда история. И сейчас самое время учиться плести эти истории из того, что происходит за окном. Даже если за окном — дым.

✨ ЕЖЕНЕДЕЛЬНЫЙ ДАЙДЖЕСТ «ШКОЛЫ ПРОЕКТНОГО СПЕЦИАЛИСТА» Новые тексты за прошлую неделю — для PM, аналитиков, архитекторов и всех, кто живёт в проектах, дедлайнах и мессенджерах. 🔥 РП, который не горит: как перестать быть пожарным Противопоставление «героического пожарного» проектного менеджера и спокойного «хозяина проекта», у которого почти не бывает пожаров, потому что выстроены привычки и ранние сигналы. Текст хорошо подходит тем, кто устал жить в режиме постоянного аврала и хочет перейти от тушения к управлению. ЧИТАТЬ 📊 Project manager больше не управляет проектом. Он управляет тем, что проектом притворяется Планы переехали в бэклоги, релизы стали непрерывными, команды — кросс‑функциональными, и классический PM уже не описывает реальную работу. ЧИТАТЬ 🧭 Почему после оценки 360° ищут виноватых Обратная связь 360° часто превращается в охоту за тем, «кто это написал», потому что анкеты построены вокруг абстрактных оценок, а не наблюдаемого поведения. ЧИТАТЬ 🗣 ТЗ заказчика — не приговор. Как переписать требования, не поссорившись Заказчик приносит неполное или неконкретное ТЗ, а специалист видит риски, которые потом придётся разгребать. ЧИТАТЬ 📘 4 дисциплины исполнения: порядок или удобная иллюзия Книга предлагает фокус на одной цели, ведущие действия, табло и еженедельные обязательства, но в реальных проектах почти всегда больше одной критической метрики. В тексте разбирается, где этот подход помогает, а где превращается в красивую управленческую иллюзию. ЧИТАТЬ 🌐 В России прогнозируют новую волну блокировок VPN в конце лета или начале осени Технический директор «Стахановца» объясняет, что нынешняя «стабилизация» VPN — лишь пауза: системы анализа трафика собирают данные и калибруют алгоритмы. Пользователи уже привыкли к сбоям и переключаются между клиентами и протоколами, но это создаёт лишь иллюзию устойчивости. ЧИТАТЬ 🧩 Проекты без владельца: когда заказчик «где‑то рядом», а решения зависают неделями Проект может выглядеть живым, но ключевые решения неделями остаются в подвешенном состоянии, и никто не может назвать владельца вопроса. ЧИТАТЬ 🕒 Почему план загрузки команды не работает, даже если в нём учтены все задачи В календаре всё красиво, но один больничный или срочный запрос ломает весь план. Статья объясняет, что проблема часто в отсутствии норм времени: задачи планируют по датам, но не понимают, сколько часов реально займёт работа. ЧИТАТЬ

📖 «Я вас услышал» и ещё 13 фраз, которые значат вообще не то, что вы думаете Воскресный вечер. Завтра понедельник. Самое время улыбнуться. Я тут собрал небольшой словарь фраз, которые мы все произносим на статусах, в переписках и на встречах с заказчиком. С расшифровкой. Поехали. «Я это починил» = Я что-то поменял, и теперь ошибка исчезла. Почему — не знаю. Трогать больше не буду. Если спросите, как починил, — придётся импровизировать. «Это известная проблема» = Я о ней услышал пять минут назад от тебя, но уже нагуглил тред на форуме 2019 года. Значит, мы не одни такие. Уже легче. «У нас тут есть небольшие риски» = У нас тут катастрофа. Но если сказать «катастрофа», все запаникуют, включая меня. Поэтому «небольшие риски». Идеально для статуса наверх. «Давайте обсудим это офлайн» = Давайте не будем позориться в общем чате на двадцать человек. Я не согласен, но публично спорить не хочу, ты тоже не хочешь. Поговорим вдвоём, как взрослые люди. «Задача в работе» = Я открыл её в таск-трекере три дня назад, посмотрел, закрыл. С тех пор думаю. Думаю продуктивно, между прочим. «Подрядчик затягивает» = Мы сами сорвали сроки, но виноватых искать надо снаружи. Это универсальная фраза, работает с поставщиками, интеграторами и облачными сервисами. «Нужно дополнительно согласовать с заказчиком» = Заказчик опять передумал. Но «передумал» звучит как обвинение, а «дополнительно согласовать» — как процесс. Так все довольны. «Это фича, а не баг» = Я не знаю, почему так работает. Но откатывать страшно. Поэтому теперь это задумано. «Дедлайн сдвигается в сторону оптимизации» = Дедлайна нет. Есть новая дата. Старую дату забудьте. Оптимизация — это когда мы делаем вид, что всё по плану, просто план обновился. «У нас agile» = У нас водопад, но с доской в Jira. «Я занесу это в бэклог» = Я занесу это в бэклог, и мы больше никогда к этому не вернёмся. «Команда перешла в режим повышенной интенсивности» = Команда перерабатывает. Но «перерабатывает» — это про выгорание, а «повышенная интенсивность» — это про героизм. Так в отчёте красивее. «Давайте вернёмся к этому позже» = Никогда. В проектной лексике «позже» — это вежливое «никогда». Если мы действительно хотим вернуться, говорят «завтра» или «в следующем спринте». «Я вас услышал» = Я вас услышал. Это всё, что я могу вам сейчас обещать. Знаете, что самое смешное? Мы все понимаем, что это значит. И заказчик понимает. И команда понимает. И тем не менее каждый день произносим эти фразы с умным видом. Потому что в проектном мире прямая речь — это роскошь, а дипломатия — это инструмент выживания. Если узнали себя хотя бы в трёх пунктах — мы с вами из одного мира. Добро пожаловать. Тут переводы не нужны. #воскресное #юмор #проектная_команда #переговоры #РП #практика

🔥 РП, который не горит: как перестать быть пожарным Есть два типа руководителей проектов. Один утром открывает ноут и не знает, что его сегодня ждёт — какой факел вспыхнет, какой срыв подкрался, какой заказчик опять «всё передумал». Второй утром открывает ноут и примерно представляет, что будет — потому что сам это распланировал. Первого мы называем пожарным. Второго — хозяином проекта. Честно говоря, большинство из нас начинают как пожарные. Мне кажется, это даже в какой-то степени нарабатывается как доблесть. «Я спас проект», «мы вытянули релиз за выходные», «без меня всё бы рухнуло». Звучит героически, окружение кивает, руководство ценит. А потом ты оглядываешься и понимаешь: ты не управляешь проектом. Ты управляешь пожарами. И если убрать твои ночные подвиги — ничего не работает, потому что системы нет. Парадокс в том, что хороший РП — это скучный РП. У него редко что-то «горит», потому что он выстроил привычки, которые не доводят до пожара. Горящий срок — это не свойство профессии, это симптом. Сигнал, что где-то не сработало раннее обнаружение. Давайте про привычки. Не про Jira и не про диаграммы Ганта — это инструменты, они вторичны. Про то, как мыслить. Первая привычка — ловить отклонения рано. Не когда задача уже просрочена на неделю, а в первый день, когда она начала буксовать. Разница между «мы уже отстали» и «мы только начали отставать» — это разница между авралом и корректировкой. Для этого нужен регулярный, честный статус по задачам. Не «всё нормально, работаем», а «вот тут застряли, вот тут ждем, вот тут рискованно». Многие РП боятся поднимать тревогу заранее — кажется, что это признак слабости. Наоборот. Молчание до последнего — это слабость. Вторая — держать буфер. И в сроках, и в ресурсах, и в своих собственных силах. План, в котором каждый час расписан и нет ни одного свободного дня — это не план, это катастрофа с отложенным запуском. Что-то всегда идёт не так: кто-то заболел, заказчик не дал данные, интеграция не взлетела с первого раза. Если буфера нет — первый сбой превращается в пожар. Если есть — в рабочую ситуацию. Третья — отдельный тайм-бокс на «непредвиденное». Грустная правда: непредвиденное предвидеть нельзя по определению. Но можно зарезервировать под него время. Час в день на разбор полётов, ответы на срочное, штормовые вопросы команды. Если этот слот не заложен — «срочное» начинает съедать плановые задачи, и вот ты уже не РП, а диспетчер, который мечется от одного вызова к другому. Четвёртая — регулярные точки сверски, даже когда «всё хорошо». И особенно когда «всё хорошо». Команда часто молчит, когда всё нормально — и молчит до тех пор, пока что-то не сломается. Регулярный короткий статус, даже пустой по содержанию, держит связь. Ты узнаёшь о проблеме на этапе «что-то странно», а не «всё горит, помогите». И пятая, наверное, самая неудобная — уметь отказывать. Не каждый скоуп-крип растёт бесконечно. Не каждая просьба заказчика должна идти в текущий спринт. РП, который не умеет сказать «это пойдёт в следующий релиз, не сейчас» — это РП, у которого потом горят сроки. Отказывать — это не конфликтовать. Это защищать проект от перегрузки, которая всё равно вылезет боком. Знаете, что самое трудное во всём этом? Изменить собственную самооценку. Перестать ассоциировать себя с тем, кто «всегда спасает». Хороший РП часто выглядит так, будто у него мало работы. Потому что пожаров нет. А когда нет пожаров — кажется, что и толку от него мало. Это ловушка, в которую попадают и сами РП, и их руководители. Цените тех, у кого скучно. Скорее всего, именно они и делают так, чтобы всё работало. #менеджмент #РП #проектная_команда #практика #управление_проектами

Почему после оценки 360° ищут виноватых Обратная связь 360° часто начинается как полезная управленческая практика, а заканчивается вопросом: «И кто это про меня написал?» Проблема обычно не в людях. Просто им выдали анкету с вопросами вроде «насколько сотрудник проявляет лидерство» — и предложили поставить оценку от одного до пяти. Один ставит тройку, потому что всё нормально. Другой — потому что всё плохо. Получается таблица с цифрами, а смысла в ней немного. Собирать обратную связь лучше у тех, кто действительно видел человека в работе: руководителя, нескольких коллег, подчинённых и внутренних заказчиков. Не нужно приглашать половину компании. Обычно достаточно 8–12 человек, причём из разных рабочих кругов. Иначе получится не обзор, а опрос популярности. Вопросы тоже должны быть про наблюдаемое поведение. Не «умеет ли руководитель мотивировать», а «объясняет ли, почему задача важна». Не «хорошо ли общается», а «даёт ли договорить и уточняет ли позицию собеседника». Полезны и три открытых вопроса: что стоит продолжать, что мешает в работе, что изменить в первую очередь. Самое тонкое начинается после получения результатов. Нельзя просто отправить человеку отчёт на сорока страницах и пожелать успехов. Сначала показывают общие закономерности: где оценки совпали, где заметно расходятся, какие примеры повторяются. Отдельные резкие комментарии без подтверждения — ещё не диагноз. А дальше выбирают не десять недостатков, а одну-две привычки на ближайшие три месяца. Например, заранее формулировать ожидаемый результат задачи или раз в неделю запрашивать обратную связь у команды. Хорошая 360° не выносит приговор. Она слегка поворачивает зеркало. И желательно так, чтобы человеку после этого хотелось что-то изменить, а не найти автора комментария.

🗣 ТЗ заказчика — не приговор. Как переписать требования, не поссорившись Заказчик принёс ТЗ. Вы читаете — и волосы дыбом. Не потому что написано коряво (хотя и это бывает). А потому что ТЗ чаще всего бывает неполным. Или неконкретным. Или неясным — то есть в принципе написанным, но так, что понять, что именно нужно сделать, невозможно. Иногда там просто нет половины нужного. А иногда описанное решение через полгода положит систему, а через год её придётся переписывать. И вот вы сидите, смотрите в этот документ и понимаете: надо как-то сказать. Но не так, чтобы человека обидеть. Потому что первая реакция на «у вас тут проблема» — защита. Это не про ego заказчика, это про нормальную человеческую реакцию. Он вложил в это ТЗ время, может, неделю с командой вылизывал, а вы приходите и говорите «не пойдёт». Даже если правы — вы проиграли этот разговор ещё до его начала. Парадокс в том, что заказчик чаще всего не глупый. Он просто говорит на другом языке. Он описывает решение, потому что ему кажется, что он знает, что нужно. А реальная задача — где-то под слоем этого решения, и до неё надо докопаться. Честно говоря, у меня ушло года три, чтобы это понять. Раньше я сразу лез с «вот тут неправильно, давайте я объясню». Сейчас пытаюсь иначе. Первый приём — не критиковать, а задавать вопросы. Процессы, а не решение. Вместо «зачем вам эта кнопка?» — «расскажите, как у вас сейчас выстроен этот процесс». Пока человек описывает процесс, он часто сам начинает видеть, что предложенное в ТЗ решение не закрывает половину шагов. Это работает почти безотказно. Вы не нападаете — вы расследуете вместе. Второй — переводить «хочу» в «для чего». Заказчик: «Нужна выгрузка в Excel из каждого документа». Банальный пример, но показательный. Можно молча сделать — и потом неделю разгребать «а почему тут так долго», «а почему данные разъезжаются». А можно спросить: «Для чего вам эта выгрузка? Что вы с ней делаете дальше?». И часто оказывается, что выгружают, чтобы свести в один отчет. Который можно собрать прямо в системе за пять минут. Без Excel, без боли, без «а у вас версия не та». Третий — показывать последствия, а не указывать на ошибки. Не «это архитектурно неверно». А «если сделать так, то при росте объёмов вот эта операция начнёт занимать минуту вместо секунды. Хотите посмотреть альтернативу?». Заказчику всё равно, что там «архитектурно». Ему важно, что через год будет больно. Это он понимает. И четвёртый, наверное, главный — отдавать решение заказчику. Не «давайте перепишем ТЗ вот так». А «я вижу вот такие риски. Если их оставить — вот последствия. Как поступим?». Люди соглашаются на изменения охотнее, когда это их решение, а не ваше требование. Даже если вы подвели их к этому ответу за полчаса. Знаете, что самое странное во всём этом? Большинство конфликтов вокруг ТЗ — вообще не про ТЗ. Они про то, что аналитик или РП не умеет вести этот разговор. Технически он может быть гением, но если на встрече звучит «ваше ТЗ — фигня» (даже завуалированно) — проект начинает срываться ещё до старта. Этому не учат на технических специальностях. А жаль. Потому что умение провести заказчика через пересмотр требований, не потеряв его доверие — это, наверное, самый дорогой софт-скилл в нашей профессии. Дороже любого сертификата. #софт_скиллы #аналитика #ТЗ #переговоры #РП #практика

4 дисциплины исполнения: порядок или удобная иллюзия? Стратегия может провалиться тихо. Никто не отменяет решения и не спорит с целями. Просто в понедельник появляется срочный отчёт, во вторник недовольный клиент, в среду меняются сроки проекта. К пятнице на важную инициативу снова нет времени. Люди заняты, совещания идут. Только задуманное не происходит. Книга «4 дисциплины исполнения» предлагает понятный ответ. Нужно выбрать одну критически важную цель, определить ведущие к ней действия, завести табло и каждую неделю принимать обязательства. Подход выглядит здраво: команда переходит от намерений к проверяемым действиям. Однако простота схемы вызывает вопросы. Начать хотя бы с требования выбрать одну цель. В теории это концентрация усилий. На практике подразделение редко занимается одним направлением. Проектной команде приходится соблюдать сроки, удерживать бюджет, обеспечивать качество и сохранять отношения с заказчиком. Если один показатель объявить главным, остальные не исчезнут. Сотрудники быстро понимают, за какую цифру их спрашивают, и улучшают именно её. Иногда за счёт того, что осталось вне табло. Не бесспорна и ставка на опережающие показатели. Авторы предлагают управлять не прибылью как итогом, а действиями, которые должны её обеспечить: количеством встреч, предложений или коммерческих часов. Но причинная связь не всегда надёжна. Десять встреч могут не дать сделки. Высокая загрузка способна увеличить выручку, но ухудшить качество. Значит, действие не становится правильным только потому, что его можно посчитать. Еженедельная встреча ответственности тоже полезна лишь до определённого момента. Она помогает не забывать о цели, но при слабом управлении превращается в контроль. Люди берут безопасные обязательства, которые точно выполнят. Табло становится красивым, показатели зелёными, а изменения нет. Формально дисциплина соблюдается. По существу команда обслуживает систему отчётности. Есть и более неприятный вопрос. Почему стратегическая задача проигрывает повседневной работе? Возможно, дело не в дисциплине. Причиной могут быть противоречивые указания, нехватка людей, неясные полномочия или цель, в которую никто не верит. Еженедельные обещания этого не устранят. Они лишь сделают проблему заметнее. Но заметить препятствие и убрать его — разные действия. Отказываться от четырёх дисциплин из-за этих ограничений всё же не стоит. Система даёт команде ритм и помогает увидеть отставание раньше итогового отчёта. Она полезна там, где цели теряются в текущих делах. Но считать её готовым механизмом исполнения рискованно. Табло не заменяет анализа причин, а регулярность не исправляет ошибочное направление. Главная ценность подхода, вероятно, не в обещании гарантированного результата. Он вынуждает руководителя ответить на неудобные вопросы: что действительно важно, какие действия влияют на итог и что команда готова сделать на этой неделе. Ответы могут оказаться неточными. Их придётся пересматривать. Поэтому дисциплина исполнения — не строгая технология успеха, а рабочая гипотеза, которую нужно постоянно проверять на реальности.

🎯 «Ещё чуть-чуть доработаю» Завтра сдача результата этапа. Аналитики принесли отчёт для заказчика — вроде всё готово, цифры бьются, выводы на месте. И тут кто-то в команде запускает правки «последней мили»: переносит столбец, переписывает формулировку в шапке, потом ещё раз переписывает, потом возвращает как было. Отчёт-то рабочий. Но «ну нельзя же так показывать, тут ещё подшлифовать надо». Часов в одиннадцать вечера выясняется, что правки заехали криво и часть данных вообще не подтянулась. И вот уже не «подшлифовать», а «откатывать срочно». Утром — разгребать последствия с руководителем проекта заказчика. Я тогда не очень понимал, что происходит. Сейчас — примерно понимаю. Перфекционизм вообще странная штука. Его же на собеседованиях подают как достоинство, да? «Я очень требователен к себе». Все кивают, записывают в плюс. А по факту он чаще работает против. Вот, например, опрос участников «Лидеров России» (публиковали в июне 2026) — там выяснилось, что перфекционизм коррелирует с худшими результатами команд. Не с лучшими, заметьте. А с худшими. Наравне с избеганием конфликтов. Забавно, что «злопамятность» в том же исследовании оказалась полезной чертой — ну, жизнь вообще полна иронии. Дальше интереснее. Перфекционизм и прокрастинация — это не противоположности, как кажется. Это буквально близнецы. Механика такая: ставишь планку очень высоко → мозг понимает, что до неё далеко → боится → откладывает → начинает в последний момент → аврал → либо пересдача, либо срыв. Forbes разбирал «ошибку планирования» — когда человек систематически недооценивает время на задачу. Перфекционист недооценивает вдвойне, потому что закладывает «идеальное» время, а не реальное с учётом всех доработок «для себя». В проектной команде это бывает по-разному. Бесконечная полировка того, что уже работает. Или «сделаю сам, у других хуже» — и тимлид становится бутылочным горлышком. Или страх показать черновик: сидит человек, никому не показывает промежуточный результат, ждёт, пока доведёт до блеска, а потом выясняется, что двигался вообще не в ту сторону. И вся красота всплывает на релизе. Правило «достаточно хорошо»: договариваешься заранее о критерии приёмки. Выполнен — всё, готово, доработки идут в бэклог, а не в текущий спринт. Ещё — декомпозиция с точками сдачи: разбиваешь так, чтобы показать промежуточное через день-два. Страх оценки от этого сильно сдувается, потому что показать «недоделку» на раннем этапе — это норма, а не провал. И тайм-бокс. «Трать на это не больше четырёх часов, потом показывай». Жёсткий лимит не даёт уйти в бесконечное улучшательство. Ну и на ретроспективе смотреть на расхождения: если задача, оценённая в 8 часов, заняла 24 — это не «сложная задача», а перфекционизм или ошибка планирования. Пожалуй, главное, что я понял: перфекционизм — это вообще не про качество. Это про тревогу перед неидеальностью. Показать неидеальное страшно, а довести «ещё чуть-чуть» — безопасно. Безопасно ровно до того момента, пока не подкрадывается дедлайн. В проектном мире «сделать достаточно хорошо и вовремя» почти всегда ценнее, чем «сделать идеально, но после релиза». Умение отпустить — это навык. Не самый простой, кстати. 🔗 Если интересно покопаться: • РБК — черты характера и эффективность команд («Лидеры России», 2026) • Forbes Life — ошибка планирования и срыв дедлайнов #софт_скиллы #менеджмент #перфекционизм #проектная_команда #выгорание

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

✨ ЕЖЕНЕДЕЛЬНЫЙ ДАЙДЖЕСТ «ШКОЛЫ МЕНЕДЖЕРА ОРГАНИЗАЦИИ» Новое за прошлую неделю — для руководителей, менеджеров, HR и всех, кто работает с людьми, процессами и изменениями. 🌀 Как «Росатом», Сбер и госслужбы приручали Agile Agile отлично смотрится в небольшой IT‑команде, где заказчик сидит рядом, а решения принимаются за десять минут — но ломается, когда каждая гипотеза превращается в служебную записку и прогоняется через юристов, ИБ и бюджетный комитет. Статья показывает, как крупные организации пытаются совместить гибкость с тяжёлой бюрократией и что из этого реально работает, когда право на изменения нужно сначала согласовать. ЧИТАТЬ 📋 Что на самом деле значат статусы задач «в работе», «почти готово», «на согласовании» «В работе» — самый вместительный корпоративный статус: в нём задача может жить неделю, месяц и кусок квартала, формально «двигаясь», хотя на деле человек только открыл файл или записал слово «Цель». Текст помогает расшифровать привычные колонки на досках задач и увидеть, где управление превращается в самоуспокоение, а не в реальные сроки и результаты. ЧИТАТЬ 🧑‍💼 Рынок управленцев: компаниям больше не нужен человек, который просто хорошо руководит Вакансии всё меньше похожи на заказ «харизматичного стратега» и всё больше — на поиск человека, который реально изменит деньги, процессы и работу команды, а не только красиво расскажет о развитии бизнеса. Статья полезна тем, кто строит карьеру в управлении: она честно показывает, какие результаты ждут от руководителей и почему «уметь руководить» без измеримого эффекта рынку уже не хватает. ЧИТАТЬ 🔧 Управление изменениями по модели Коттера: восемь шагов, чтобы команда не делала вид, что всё по‑старому Приказ и презентация запускают изменения только формально: без фактов срочности, коалиции сторонников и понятного видения люди уходят в имитацию и аккуратно саботируют новые правила. Автор разбирает восемь шагов Коттера на живых примерах — от создания чувства необходимости до закрепления изменений в культуре, чтобы «новая система» не осталась презентацией. ЧИТАТЬ 🎛 Модель ситуационного лидерства Херси–Бланшара: стиль управления под зрелость сотрудника Проблема часто не в «лени» или «характере» человека, а в том, что руководитель выбрал стиль управления, к которому сотрудник пока не готов: где-то нужно больше директивности, где‑то — поддержки, а где‑то можно передавать ответственность. Статья даёт простой набор вопросов и четыре базовых стиля, чтобы подобрать поведение под конкретную задачу и уровень самостоятельности, а не пытаться «одним стилем» управлять всеми. ЧИТАТЬ 🏗 Иерархия больше не работает? Что показали Zappos и Haier Zappos экспериментирует с холакратией, Haier делит гигантскую компанию на тысячи микропредприятий — оба кейса показывают, что проблема не в начальниках как таковых, а в том, что большая организация со временем становится слишком медленной. Текст даёт редкую возможность посмотреть, что происходит, когда меняют реальные правила управления, а не только название должностей. ЧИТАТЬ 💬 Фразы, после которых подчинённые начинают обновлять резюме «Ты же понимаешь, что это срочно» или «ну это же базовый уровень» звучат как управленческая ясность, но для сотрудника превращаются в сигнал «спасайся, кто может». Автор даёт альтернативные формулировки, которые помогают проговаривать ожидания и сроки, не разрушая доверие и не разгоняя текучку. ЧИТАТЬ 📑 «У нас всё по регламенту» — пока не случился аврал Пока ничего не горит, схемы и инструкции создают иллюзию полноты порядка, но как только меняются вводные или возникает форс‑мажор, выясняется, что никто не знает, кто отвечает, где актуальный документ и кто должен принять решение. Статья полезна тем, кто строит процессную модель: она показывает, почему регламенты без реального распределения ответственности и живой практики не спасают от хаоса. ЧИТАТЬ 📚 Книжные клубы для управленцев: чтобы встреча не превратилась в ещё одно совещание В реальности книжный клуб часто собирает людей, которые часть встречи мысленно отвечают на письма, часть раздражается на «непрочитавших», а проблема организации маскируется под обсуждение «коммуникаций». Автор показывает, как использовать книги как безопасный повод говорить о сложных темах управления, а не для галочки «мы читаем бизнес‑литературу». ЧИТАТЬ

В России прогнозируют новую волну блокировок VPN в конце лета или начале осени. Текущая ситуация с VPN Сергей Щербаков, технический директор компании «Стахановец», считает, что стабилизация работы VPN — лишь временная пауза. Весной и в начале лета системы анализа трафика грубо подавляли VPN: вырезали пакеты по цифровым отпечаткам протоколов OpenVPN и WireGuard. Из‑за этого возникали массовые обрывы соединений — оборудование операторов не справлялось с ложными срабатываниями. Что происходит сейчас Сейчас инженеры собирают данные о поведении VPN: какие порты используют, как часто переподключаются, применяют ли маскировку. Алгоритмы калибрируют и пока не работают в полную силу. Как изменилась культура пользования Пользователи адаптировались: - устанавливают 2–3 VPN‑клиента; - вручную настраивают протоколы; - меняют порт (например, с 443 на 80) или включают режим обфускации при проблемах. Из‑за этого сбои перестали шокировать: если один протокол не работает, пользователь переключается на другой — и соединение восстанавливается. Это создаёт иллюзию стабильности. Чего ждать в будущем Щербаков прогнозирует такие изменения: - вместо полных обрывов — искусственное снижение скорости в пиковые моменты; - задержки при открытии страниц; - проблемы с передачей больших файлов; - усиленный анализ временных интервалов между пакетами — этот этап сложнее обойти. Источник

ЕЖЕНЕДЕЛЬНЫЙ ДАЙДЖЕСТ ПУБЛИКАЦИЙ «ШКОЛЫ ПРОЕКТНОГО СПЕЦИАЛИСТА» Новые тексты для PM, аналитиков, архитекторов и всех, кто живёт в проектах, дедлайнах и мессенджерах. За прошлую неделю вышло 7 материалов — от управленческого фольклора и невидимой работы до героического PM и цифрового FOMO. 💬 Управленческий фольклор: тревожные фразы Фразы «надо просто ускориться» и «давайте пока не будем эскалировать» звучат как управленческая уверенность, но на деле маскируют системные проблемы со сроками и ресурсами. Статья хорошо подходит как повод поговорить с командой о том, какие сигналы мы игнорируем в своих проектах. ЧИТАТЬ 👨‍💻 Карьера в IT с нуля в сегодняшней России Эпоха «курсы + модные технологии в резюме» закончилась: вакансий для джунов меньше, требований больше, а бизнесу нужны не любые разработчики, а люди, которые приносят реальную пользу. Автор по шагам разбирает путь от первой позиции до руководящей роли и показывает, как выстраивать развитие в новых условиях рынка. ЧИТАТЬ 💸 Теория двух факторов Герцберга: почему одной зарплатой вовлеченность не купить Зарплата, офис и стабильность — это «гигиенические факторы», они снимают недовольство, но не создают интерес к работе сами по себе. В тексте хорошо показано, почему попытка лечить выгорание только деньгами без смысла, роста и нормальной культуры почти всегда проваливается. ЧИТАТЬ 🤖 Искусственный интеллект как зеркало неэффективности AI быстро находит не только рутину, но и «исторически сложившиеся процессы», в которых один и тот же отчёт делают четыре человека и никто не понимает, почему. Нейросеть в этом тексте — не магическая кнопка, а инструмент, который заставляет пересмотреть организацию труда и ответственность за процессы. ЧИТАТЬ 🕰 Сколько стоит «невидимая работа»: согласования, правки, уточнения, ожидания Согласования, ожидание ответов, повторные обсуждения и исправление недопониманий не попадают в отчёты, но забирают огромную долю рабочего времени. Автор предлагает считать эту «невидимую работу» как отдельную статью затрат и честно смотреть, сколько ресурсов уходит на бег на месте. ЧИТАТЬ 😂 Анекдоты и дедлайны… Лёгкий текст про рабочий юмор: как анекдоты про «зайди на пару слов» и «нужно ещё вчера» помогают переживать бесконечные дедлайны, планёрки и согласования. Хорошая вставка для неформальной рассылки команде, чтобы чуть снизить градус тревоги вокруг сроков. ЧИТАТЬ 🧠 Нейросеть не думает: почему мы обманываем сами себя Объяснение нейросетей «по‑простому»: не магия и не «живой интеллект», а сложная конструкция из связей и примеров, которая учится подбирать правдоподобные ответы. Текст помогает трезво посмотреть на AI и перестать ждать от него человеческого мышления там, где оно в принципе невозможно. ЧИТАТЬ

Эмоциональный интеллект: почему это важно и как его прокачивать в работе Его принято считать чем-то приятным, но необязательным. Мол, главное — быть хорошим специалистом, выполнять задачи и не опаздывать на встречи. А уж разбираться в чужом настроении — дело психологов. Однако на работе проблемы чаще возникают не из-за таблиц, документов или программ. С ними обычно всё более-менее понятно. Сложности начинаются там, где один сказал резче, другой промолчал, третий додумал остальное и пошёл жаловаться начальнику. Эмоциональный интеллект — это не привычка всем улыбаться и быть удобным. И не умение подавлять раздражение, делая вид, что всё замечательно. Скорее, это способность вовремя заметить: сейчас говорит не здравый смысл, а обида, страх или желание доказать свою правоту. Вроде бы мелочь. Но именно из таких мелочей потом вырастают затяжные конфликты, сорванные сроки и совещания, после которых всем нужен ещё один выходной. Хорошая новость в том, что этот навык можно развивать. Для начала полезно хотя бы не отвечать сразу. Пауза в несколько секунд иногда спасает лучше длинного курса по коммуникациям. Ещё стоит учиться называть своё состояние обычными словами: не «все достали», а «есть раздражение, потому что договорённость снова нарушена». Формулировка меняется — и разговор уже получается другой. Помогает и простая привычка уточнять. Не угадывать, почему коллега недоволен, а спросить. Не считать молчание согласием. Не принимать сухое письмо за личное оскорбление. Люди вообще слишком часто ведут спор не с человеком, а со своей версией его мыслей. В итоге эмоциональный интеллект нужен не для душевных разговоров у кулера. Он помогает экономить силы, договариваться быстрее и не превращать обычную рабочую неприятность в драму на три отдела. А это, если честно, уже вполне деловой результат.

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