В России прогнозируют новую волну блокировок VPN в конце лета или начале осени.

Текущая ситуация с VPN
Сергей Щербаков, технический директор компании «Стахановец», считает, что стабилизация работы VPN — лишь временная пауза. Весной и в начале лета системы анализа трафика грубо подавляли VPN: вырезали пакеты по цифровым отпечаткам протоколов OpenVPN и WireGuard. Из‑за этого возникали массовые обрывы соединений — оборудование операторов не справлялось с ложными срабатываниями.

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

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

Чего ждать в будущем
Щербаков прогнозирует такие изменения:
- вместо полных обрывов — искусственное снижение скорости в пиковые моменты;
- задержки при открытии страниц;
- проблемы с передачей больших файлов;
- усиленный анализ временных интервалов между пакетами — этот этап сложнее обойти.

Источник

✨ ЕЖЕНЕДЕЛЬНЫЙ ДАЙДЖЕСТ «ШКОЛЫ МЕНЕДЖЕРА ОРГАНИЗАЦИИ»

Новое за прошлую неделю — для руководителей, менеджеров, HR и всех, кто работает с людьми, процессами и изменениями.

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

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

🎯 «Ещё чуть-чуть доработаю»

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

Я тогда не очень понимал, что происходит. Сейчас — примерно понимаю.

Перфекционизм вообще странная штука. Его же на собеседованиях подают как достоинство, да? «Я очень требователен к себе». Все кивают, записывают в плюс. А по факту он чаще работает против. Вот, например, опрос участников «Лидеров России» (публиковали в июне 2026) — там выяснилось, что перфекционизм коррелирует с худшими результатами команд. Не с лучшими, заметьте. А с худшими. Наравне с избеганием конфликтов. Забавно, что «злопамятность» в том же исследовании оказалась полезной чертой — ну, жизнь вообще полна иронии.

Дальше интереснее. Перфекционизм и прокрастинация — это не противоположности, как кажется. Это буквально близнецы.

Механика такая: ставишь планку очень высоко → мозг понимает, что до неё далеко → боится → откладывает → начинает в последний момент → аврал → либо пересдача, либо срыв. Forbes разбирал «ошибку планирования» — когда человек систематически недооценивает время на задачу. Перфекционист недооценивает вдвойне, потому что закладывает «идеальное» время, а не реальное с учётом всех доработок «для себя».

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

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

И тайм-бокс. «Трать на это не больше четырёх часов, потом показывай». Жёсткий лимит не даёт уйти в бесконечное улучшательство. Ну и на ретроспективе смотреть на расхождения: если задача, оценённая в 8 часов, заняла 24 — это не «сложная задача», а перфекционизм или ошибка планирования.

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

В проектном мире «сделать достаточно хорошо и вовремя» почти всегда ценнее, чем «сделать идеально, но после релиза». Умение отпустить — это навык. Не самый простой, кстати.

🔗 Если интересно покопаться:
• РБК — черты характера и эффективность команд («Лидеры России», 2026)
• Forbes Life — ошибка планирования и срыв дедлайнов

#софт_скиллы #менеджмент #перфекционизм #проектная_команда #выгорание

4 дисциплины исполнения: порядок или удобная иллюзия?

Стратегия может провалиться тихо. Никто не отменяет решения и не спорит с целями. Просто в понедельник появляется срочный отчёт, во вторник недовольный клиент, в среду меняются сроки проекта. К пятнице на важную инициативу снова нет времени. Люди заняты, совещания идут. Только задуманное не происходит.

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

Начать хотя бы с требования выбрать одну цель. В теории это концентрация усилий. На практике подразделение редко занимается одним направлением. Проектной команде приходится соблюдать сроки, удерживать бюджет, обеспечивать качество и сохранять отношения с заказчиком. Если один показатель объявить главным, остальные не исчезнут. Сотрудники быстро понимают, за какую цифру их спрашивают, и улучшают именно её. Иногда за счёт того, что осталось вне табло.

Не бесспорна и ставка на опережающие показатели. Авторы предлагают управлять не прибылью как итогом, а действиями, которые должны её обеспечить: количеством встреч, предложений или коммерческих часов. Но причинная связь не всегда надёжна. Десять встреч могут не дать сделки. Высокая загрузка способна увеличить выручку, но ухудшить качество. Значит, действие не становится правильным только потому, что его можно посчитать.

Еженедельная встреча ответственности тоже полезна лишь до определённого момента. Она помогает не забывать о цели, но при слабом управлении превращается в контроль. Люди берут безопасные обязательства, которые точно выполнят. Табло становится красивым, показатели зелёными, а изменения нет. Формально дисциплина соблюдается. По существу команда обслуживает систему отчётности.

Есть и более неприятный вопрос. Почему стратегическая задача проигрывает повседневной работе? Возможно, дело не в дисциплине. Причиной могут быть противоречивые указания, нехватка людей, неясные полномочия или цель, в которую никто не верит. Еженедельные обещания этого не устранят. Они лишь сделают проблему заметнее. Но заметить препятствие и убрать его — разные действия.

Отказываться от четырёх дисциплин из-за этих ограничений всё же не стоит. Система даёт команде ритм и помогает увидеть отставание раньше итогового отчёта. Она полезна там, где цели теряются в текущих делах. Но считать её готовым механизмом исполнения рискованно. Табло не заменяет анализа причин, а регулярность не исправляет ошибочное направление.

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

Ответы могут оказаться неточными. Их придётся пересматривать. Поэтому дисциплина исполнения — не строгая технология успеха, а рабочая гипотеза, которую нужно постоянно проверять на реальности.

🗣 ТЗ заказчика — не приговор. Как переписать требования, не поссорившись

Заказчик принёс ТЗ. Вы читаете — и волосы дыбом. Не потому что написано коряво (хотя и это бывает). А потому что ТЗ чаще всего бывает неполным. Или неконкретным. Или неясным — то есть в принципе написанным, но так, что понять, что именно нужно сделать, невозможно. Иногда там просто нет половины нужного. А иногда описанное решение через полгода положит систему, а через год её придётся переписывать. И вот вы сидите, смотрите в этот документ и понимаете: надо как-то сказать. Но не так, чтобы человека обидеть.

Потому что первая реакция на «у вас тут проблема» — защита. Это не про эго заказчика, это про нормальную человеческую реакцию. Он вложил в это ТЗ время, может, неделю с командой вылизывал, а вы приходите и говорите «не пойдёт». Даже если правы — вы проиграли этот разговор ещё до его начала.

Парадокс в том, что заказчик чаще всего не глупый. Он просто говорит на другом языке. Он описывает решение, потому что ему кажется, что он знает, что нужно. А реальная задача — где-то под слоем этого решения, и до неё надо докопаться.

Честно говоря, у меня ушло года три, чтобы это понять. Раньше я сразу лез с «вот тут неправильно, давайте я объясню». Сейчас пытаюсь иначе.

Первый приём — не критиковать, а задавать вопросы. Процессы, а не решение.

Вместо «зачем вам эта кнопка?» — «расскажите, как у вас сейчас выстроен этот процесс». Пока человек описывает процесс, он часто сам начинает видеть, что предложенное в ТЗ решение не закрывает половину шагов. Это работает почти безотказно. Вы не нападаете — вы расследуете вместе.

Второй — переводить «хочу» в «для чего».

Заказчик: «Нужна выгрузка в Excel из каждого документа». Банальный пример, но показательный. Можно молча сделать — и потом неделю разгребать «а почему тут так долго», «а почему данные разъезжаются». А можно спросить: «Для чего вам эта выгрузка? Что вы с ней делаете дальше?». И часто оказывается, что выгружают, чтобы свести в один отчет. Который можно собрать прямо в системе за пять минут. Без Excel, без боли, без «а у вас версия не та».

Третий — показывать последствия, а не указывать на ошибки.

Не «это архитектурно неверно». А «если сделать так, то при росте объёмов вот эта операция начнёт занимать минуту вместо секунды. Хотите посмотреть альтернативу?». Заказчику всё равно, что там «архитектурно». Ему важно, что через год будет больно. Это он понимает.

И четвёртый, наверное, главный — отдавать решение заказчику.

Не «давайте перепишем ТЗ вот так». А «я вижу вот такие риски. Если их оставить — вот последствия. Как поступим?». Люди соглашаются на изменения охотнее, когда это их решение, а не ваше требование. Даже если вы подвели их к этому ответу за полчаса.

Знаете, что самое странное во всём этом? Большинство конфликтов вокруг ТЗ — вообще не про ТЗ. Они про то, что аналитик или РП не умеет вести этот разговор. Технически он может быть гением, но если на встрече звучит «ваше ТЗ — фигня» (даже завуалированно) — проект начинает срываться ещё до старта.

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

#софт_скиллы #аналитика #ТЗ #переговоры #РП #практика

Почему после оценки 360° ищут виноватых

Обратная связь 360° часто начинается как полезная управленческая практика, а заканчивается вопросом: «И кто это про меня написал?»

Проблема обычно не в людях. Просто им выдали анкету с вопросами вроде «насколько сотрудник проявляет лидерство» — и предложили поставить оценку от одного до пяти. Один ставит тройку, потому что всё нормально. Другой — потому что всё плохо. Получается таблица с цифрами, а смысла в ней немного.

Собирать обратную связь лучше у тех, кто действительно видел человека в работе: руководителя, нескольких коллег, подчинённых и внутренних заказчиков. Не нужно приглашать половину компании. Обычно достаточно 8–12 человек, причём из разных рабочих кругов. Иначе получится не обзор, а опрос популярности.

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

Самое тонкое начинается после получения результатов. Нельзя просто отправить человеку отчёт на сорока страницах и пожелать успехов. Сначала показывают общие закономерности: где оценки совпали, где заметно расходятся, какие примеры повторяются. Отдельные резкие комментарии без подтверждения — ещё не диагноз.

А дальше выбирают не десять недостатков, а одну-две привычки на ближайшие три месяца. Например, заранее формулировать ожидаемый результат задачи или раз в неделю запрашивать обратную связь у команды.

Хорошая 360° не выносит приговор. Она слегка поворачивает зеркало. И желательно так, чтобы человеку после этого хотелось что-то изменить, а не найти автора комментария.

🔥 РП, который не горит: как перестать быть пожарным

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

Честно говоря, большинство из нас начинают как пожарные. Мне кажется, это даже в какой-то степени нарабатывается как доблесть. «Я спас проект», «мы вытянули релиз за выходные», «без меня всё бы рухнуло». Звучит героически, окружение кивает, руководство ценит. А потом ты оглядываешься и понимаешь: ты не управляешь проектом. Ты управляешь пожарами. И если убрать твои ночные подвиги — ничего не работает, потому что системы нет.

Парадокс в том, что хороший РП — это скучный РП. У него редко что-то «горит», потому что он выстроил привычки, которые не доводят до пожара. Горящий срок — это не свойство профессии, это симптом. Сигнал, что где-то не сработало раннее обнаружение.

Давайте про привычки. Не про Jira и не про диаграммы Ганта — это инструменты, они вторичны. Про то, как мыслить.

Первая привычка — ловить отклонения рано.

Не когда задача уже просрочена на неделю, а в первый день, когда она начала буксовать. Разница между «мы уже отстали» и «мы только начали отставать» — это разница между авралом и корректировкой. Для этого нужен регулярный, честный статус по задачам. Не «всё нормально, работаем», а «вот тут застряли, вот тут ждем, вот тут рискованно». Многие РП боятся поднимать тревогу заранее — кажется, что это признак слабости. Наоборот. Молчание до последнего — это слабость.

Вторая — держать буфер.

И в сроках, и в ресурсах, и в своих собственных силах. План, в котором каждый час расписан и нет ни одного свободного дня — это не план, это катастрофа с отложенным запуском. Что-то всегда идёт не так: кто-то заболел, заказчик не дал данные, интеграция не взлетела с первого раза. Если буфера нет — первый сбой превращается в пожар. Если есть — в рабочую ситуацию.

Третья — отдельный тайм-бокс на «непредвиденное».

Грустная правда: непредвиденное предвидеть нельзя по определению. Но можно зарезервировать под него время. Час в день на разбор полётов, ответы на срочное, штормовые вопросы команды. Если этот слот не заложен — «срочное» начинает съедать плановые задачи, и вот ты уже не РП, а диспетчер, который мечется от одного вызова к другому.

Четвёртая — регулярные точки сверски, даже когда «всё хорошо».

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

И пятая, наверное, самая неудобная — уметь отказывать.

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

Знаете, что самое трудное во всём этом? Изменить собственную самооценку. Перестать ассоциировать себя с тем, кто «всегда спасает». Хороший РП часто выглядит так, будто у него мало работы. Потому что пожаров нет. А когда нет пожаров — кажется, что и толку от него мало. Это ловушка, в которую попадают и сами РП, и их руководители.

Цените тех, у кого скучно. Скорее всего, именно они и делают так, чтобы всё работало.

#менеджмент #РП #проектная_команда #практика #управление_проектами

📖 «Я вас услышал» и ещё 13 фраз, которые значат вообще не то, что вы думаете

Воскресный вечер. Завтра понедельник. Самое время улыбнуться. Я тут собрал небольшой словарь фраз, которые мы все произносим на статусах, в переписках и на встречах с заказчиком. С расшифровкой. Поехали.

«Я это починил»
= Я что-то поменял, и теперь ошибка исчезла. Почему — не знаю. Трогать больше не буду. Если спросите, как починил, — придётся импровизировать.

«Это известная проблема»
= Я о ней услышал пять минут назад от тебя, но уже нагуглил тред на форуме 2019 года. Значит, мы не одни такие. Уже легче.

«У нас тут есть небольшие риски»
= У нас тут катастрофа. Но если сказать «катастрофа», все запаникуют, включая меня. Поэтому «небольшие риски». Идеально для статуса наверх.

«Давайте обсудим это офлайн»
= Давайте не будем позориться в общем чате на двадцать человек. Я не согласен, но публично спорить не хочу, ты тоже не хочешь. Поговорим вдвоём, как взрослые люди.

«Задача в работе»
= Я открыл её в таск-трекере три дня назад, посмотрел, закрыл. С тех пор думаю. Думаю продуктивно, между прочим.

«Подрядчик затягивает»
= Мы сами сорвали сроки, но виноватых искать надо снаружи. Это универсальная фраза, работает с поставщиками, интеграторами и облачными сервисами.

«Нужно дополнительно согласовать с заказчиком»
= Заказчик опять передумал. Но «передумал» звучит как обвинение, а «дополнительно согласовать» — как процесс. Так все довольны.

«Это фича, а не баг»
= Я не знаю, почему так работает. Но откатывать страшно. Поэтому теперь это задумано.

«Дедлайн сдвигается в сторону оптимизации»
= Дедлайна нет. Есть новая дата. Старую дату забудьте. Оптимизация — это когда мы делаем вид, что всё по плану, просто план обновился.

«У нас agile»
= У нас водопад, но с доской в Jira.

«Я занесу это в бэклог»
= Я занесу это в бэклог, и мы больше никогда к этому не вернёмся.

«Команда перешла в режим повышенной интенсивности»
= Команда перерабатывает. Но «перерабатывает» — это про выгорание, а «повышенная интенсивность» — это про героизм. Так в отчёте красивее.

«Давайте вернёмся к этому позже»
= Никогда. В проектной лексике «позже» — это вежливое «никогда». Если мы действительно хотим вернуться, говорят «завтра» или «в следующем спринте».

«Я вас услышал»
= Я вас услышал. Это всё, что я могу вам сейчас обещать.

Знаете, что самое смешное? Мы все понимаем, что это значит. И заказчик понимает. И команда понимает. И тем не менее каждый день произносим эти фразы с умным видом. Потому что в проектном мире прямая речь — это роскошь, а дипломатия — это инструмент выживания.

Если узнали себя хотя бы в трёх пунктах — мы с вами из одного мира. Добро пожаловать. Тут переводы не нужны.

#воскресное #юмор #проектная_команда #переговоры #РП #практика

✨ ЕЖЕНЕДЕЛЬНЫЙ ДАЙДЖЕСТ «ШКОЛЫ ПРОЕКТНОГО СПЕЦИАЛИСТА»

Новые тексты за прошлую неделю — для PM, аналитиков, архитекторов и всех, кто живёт в проектах, дедлайнах и мессенджерах.

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

Все мы привыкли думать, что бизнес — это про стабильность. Ну, или хотя бы про предсказуемость. Взял планку, выполнил, получил профит. А теперь посмотри, что делают продавцы на WB. Карточка: «Покупай, пока не сторело».

Продавец ловко вплетает в рекламу то, что сейчас у всех на слуху — эти удары БПЛА по складам, эту тревогу, эту атмосферу неопределённости. И превращает это в триггер. Просто искусно сыграно на общем фоне.

Раньше я думал, что адаптация в бизнесе — это когда ты серьезно и продуманно перенастраиваешь рекламную политику. А сейчас приходит понимание, что адаптация — это умение поймать общий нерв и завернуть его в оффер. Чтобы человек, пролистывая ленту, увидел знакомую боль, улыбнулся или напрягся — и купил. Не потому что ему нужна вещь, а потому что он проникся моментом.

В IT мы часто грешим тем, что пытаемся быть слишком правильными, слишком логичными. Клиенту — красивые презентации, партнёрам — дорожные карты, в соцсетях — экспертный контент. А эти ребята с маркетплейса просто берут происшествие, о котором все говорят, и вешают его на свой товар. Прямо. Без цензуры. Даже если это страшновато. Они переупаковывают страх в скидку и продают.

И вот в этом, если честно, огромный урок для всех нас в IT. Мало уметь делать качественный продукт. Нужно ещё уметь вписать его в контекст дня. Чтобы он звучал не как «очередная разработка», а как ответ на то, что у людей прямо сейчас болит.

Продавцы на WB это делают на интуиции. Схватили инфоповод — переложили на ценник — запустили. Мы же можем сделать то же самое, только словами, кейсами, постами, предложениями.

И если ты можешь обыграть всё так, чтобы клиент увидел в твоём предложении спасение от хаоса — ты выиграл. Неважно, продаёшь ты коробки с товаром или IT проект. Главное — попасть в резонанс. Сделать так, чтобы у человека в голове щёлкнуло: «Ага, это про меня. Это про сейчас».

Мы в IT, если честно, часто забываем про эту человеческую часть. А зря. Потому что технологии — это просто инструмент. А продаёт всегда история. И сейчас самое время учиться плести эти истории из того, что происходит за окном. Даже если за окном — дым.

✨ ЕЖЕНЕДЕЛЬНЫЙ ДАЙДЖЕСТ НА КАНАЛЕ «ШКОЛА МЕНЕДЖЕРА ОРГАНИЗАЦИИ»

За последнюю неделю на канале вышли сильные материалы про планирование, приоритеты, RACI, Agile, лидерство и управленческие ошибки.

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

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

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

Техники? Честность, конкретные сроки и предложение альтернатив — вот база.

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

Баланс — это не роскошь, а необходимость, иначе выгорание обеспечено.

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

Claude собрал шутер за полдня: а скоро вашу 1С тоже напишет нейросеть?

Недавно в интернетах наткнулся на историю, которая зацепила. Один человек (Мэтт Шумер) дал Claude Opus 5 один большой запрос — создать современный браузерный шутер, подключить субагентов и улучшать результат. тот взял и собрал браузерный шутер. 55 тысяч строк кода, и никаких готовых картинок, всё из головы — вернее, из кода, процедурно генерируется на лету.

Это ж как если бы у нас в 1С запрос сгенерировал не просто отчёт, а целую подсистему с интерфейсом, формами и обменом данными . Конечно, до оригинального продукта этому Call of Duty от Claude далеко, критики поставили 5 из 10 . Но! Раньше, чтобы сделать такой прототип, нужна была небольшая студия разработчиков. А тут один человек запустил целую команду виртуальных помощников одним запросом .

Выводы напрашиваются сами собой. Очень скоро нас, возможно, захлестнёт волна типовых конфигураций, решённых за выходные, или даже целых ERP-систем, собранных по запросу "Сделай мне как в SAP у Газпрома". Спрос на рутинное переписывание типовых отчётов упадёт, а вот ценность архитектора, который сможет грамотно сформулировать задачу для нейросети, поставить "техническое задание", правильно разделить работу между агентами и проверить их результат — возрастёт в разы.

Если вы вдруг получаете зарплату за то, что переводите требования бизнеса на язык кода и находите нестандартные решения, то вы определённо на верном пути. Ваша работа становится всё более ценной, а инструменты — сложнее и интереснее. Стоит непременно продолжать, осваивать новые подходы и не бояться задавать этим нейросетям сложные вопросы.

Кстати промпт и исходный код лежат на GitHub (https://github.com/mshumer/Claude-of-Duty)

💣 Архитектор и его тень: почему «я один знаю, как тут всё устроено» — бомба

В почти каждом проекте есть такой человек. Тот, без которого всё остановится. Он знает, почему интеграция с складом работает именно так, а не иначе. Он помнит, почему вот этот регистр в 2019 году переписали задом наперёд. Он один понимает, как связаны эти три подсистемы, которые официально «независимы». Все это знают. Все этого боятся. И никто с этим ничего не делает.

Его называют по-разному: «наш гений», «человек-система», «тот, кто держит всё на себе». Звучит как комплимент. На самом деле — это диагноз проекта. И бомба.

Честно говоря, когда я впервые столкнулся с этой темой, я думал, что проблема в людях — дескать, не хотят делиться знаниями, берегут экспертизу как сокровище. Сейчас думаю иначе. Проблема почти никогда не в человеке. Проблема в системе, которая позволяет знанию жить только в одной голове. И в культуре, которая это поощряет.

Потому что давайте честно: носитель уникального знания — это удобно. К нему подошёл, спросил, получил ответ, пошёл дальше. Никакой документации, никаких вики, никаких онбордингов. Быстро, точно, по делу. Пока он есть. А потом его нет — и оказывается, что проект держался на одном человеке. И не важно, ушёл он в отпуск, заболел, сменил работу или просто выгорел. Результат один: знание исчезло.

Это называется bus factor — «фактор автобуса». Грубо: сколько человек в команде должно попасть под автобус, чтобы проект обрушился? В здоровой команде ответ — «много, мы друг друга подстрахуем». В нездоровой — «один». И вы знаете, о ком речь.

Как распознать бомбу заранее

Тревожные звоночки достаточно универсальны. Если вы замечаете за своим проектом что-то из этого — пора что-то менять.

• Любой нестандартный вопрос идёт к одному и тому же человеку. Неважно, формально ли он архитектор — фактически он держит контекст.
• Документация есть, но она устарела на пару лет. Или написана, но «не для людей» — разобраться без автора невозможно.
• Он сам жалуется, что «некому передать», но при этом не передаёт. Кажется, что времени нет. На самом деле — нет привычки и нет системы.
• Новые сотрудники приходят и месяцами не могут войти в тему, потому что «всё в голове у Иванова».
• Когда он в отпуске, половина решений откладывается. Когда возвращается — навёрстывается авралом.

Что с этим делать (и почему «просто задокументируй» не работает)

Самая частая рекомендация — «надо всё описать». И это не работает. Потому что носитель знания знает в тысячу раз больше, чем способен рассказать. А записанное без контекста — мертво. Документация, написанная «вообще», никем не читается и быстро устаревает.

Поэтому работают другие подходы. Не «опиши всё», а «сделай так, чтобы знание не концентрировалось».

Парное программирование и парные ревью. Не «Иванов делает архитектуру, остальные смотрят», а «Иванов делает архитектуру вместе с кем-то, кто будет её потом поддерживать». Знание передаётся в процессе работы, а не через документ.

Ротация. Если один человек годами ведёт один и тот же блок — это сигнал. Ротация зон ответственности заставляет объяснять, структурировать, передавать. Больно, но эффективно.

ADR — Architecture Decision Records. Короткие записи: какое решение принято, почему, какие альтернативы рассматривали. Не «вся документация», а именно решения с обоснованием — тот контекст, который теряется первым.

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

Знаете, что самое сложное во всём этом? Не техническая часть. Технически всё понятно. Сложнее всего — признать, что герой-одиночка — это не ценность, а риск. И что культура «мы держимся на Иванове» — это не повод для гордости, а повод для тревоги.

Хорошая новость: bus factor можно снизить. Это не дар, это практика. И чем раньше начать — тем дешевле обойдётся. Пока автобус ещё не подъехал.

#архитектура #bus_factor #проектная_команда #риски #практика #управление_знаниями

🎤 Демо для заказчика, после которого не стыдно

Знаете, какой самый обидный способ потерять проект? Сделать всё правильно, а потом показать это так, что заказчик разочаровался. Не потому что плохо сделано. А потому что показано непонятно. Это случается гораздо чаще, чем кажется. И каждый раз обидно до скрежета в зубах, потому что проблема не в работе, а в подаче.

Давайте разберёмся, почему так происходит. Потому что большинство из нас показывают демо так, как интересно им самим. Смотрите, какую сложную интеграцию мы сделали. Смотрите, тут архитектура какая красивая. Заказчик кивает, улыбается, а про себя думает: «Ну молодцы, а мне-то что?». Для него ваша сложность — это ваша проблема.

Главное правило: демо — это не показ разработки. Это продажа результата.

Заказчик пришёл понять, стало ли ему лучше. Эффективнее ли работает бизнес. Меньше ли рутины. Быстрее ли закрывается период. Вот это его язык. И если вы на нём не говорите — техническое совершенство останется невидимым.

Знаете, что самое несправедливое? Часто тот, кто сделал хуже, но лучше показал — получает больше признания. Грустно, но это правда рынка.

Готовьтесь к демо, а не надейтесь на импровизацию

Самая частая ошибка — думать, что раз вы всё сделали, то и рассказать сможете с ходу. Не сможете. Демо без подготовки обычно выглядит так: вы открываете систему, тыкаете куда-то, объясняете что-то себе под нос, потом спохватываетесь и начинаете показывать хаотично. Заказчик теряется. Вы нервничаете. Финал предсказуем.

Хорошее демо — это сценарий. Вы заранее знаете, что покажете первым, что вторым, на чём сделаете паузу, где предложите «давайте попробуете сами». Не импровизация, а выстроенный путь.

Показывайте путь пользователя, а не структуру системы

Вот типичное плохое демо: «А вот у нас раздел «Справочники», тут «Документы», тут «Отчёты». Давайте я покажу, как всё устроено». Заказчику плевать, как всё устроено. Ему интересно, как он будет работать.

Хорошее демо идёт по реальному процессу. «Вот ваша заявка поступает. Вот проходит согласование. Вот попадает в отчёт руководителю». Заказчик видит себя в системе. Это работает в сто раз сильнее, чем демонстрация меню.

Говорите на языке ценности, а не функционала

Плохо: «Мы реализовали автоматическое заполнение табличной части документа на основании данных из связанного регистра».

Хорошо: «Раньше на это тратили двадцать минут вручную. Теперь система делает это за секунду. Сто документов в день? Это тридцать часов в месяц, которые возвращаются в работу».

Одно и то же решение. Одна подача говорит про технологию. Другая — про деньги и время.

Не прячьте проблемы — но подавайте их правильно

Соблазн показать только гладкое и работающее огромен. Но заказчик не наивен. Если на демо всё идеально, он начинает подозревать: либо мы что-то скрываем, либо показываем не то, что реально есть.

Честнее — открыто сказать: «Вот этот кусок пока в доработке, вот это планируем закрыть к следующему этапу». Но подавать как план, а не как извинение. Это вызывает доверие. Гораздо больше, чем фальшивый идеал.

И последнее — репетируйте вслух

Прогнать демо в голове — не репетиция. Репетиция — это сказать вслух, в идеале перед коллегой, который сыграет «глупого заказчика» и задаст неудобные вопросы. Пять раз проговорить сценарий вслух — и на встрече вы будете звучать в десять раз увереннее.

Демо — это навык. Ему можно научиться. И именно он часто решает, увидят вашу работу или нет. Обидно делать классную вещь и не суметь её показать. Ещё обиднее — видеть, как кто-то делает хуже, но показывает лучше. Давайте это исправлять.

#софт_скиллы #демо #переговоры #РП #аналитика #практика

🔄 Retrospective, которую не ненавидят

Знаете, какой звук вызывает у проектной команды тихую тоску? «Коллеги, в пятницу в 17:00 ретро». Кто-то закатывает глаза. Кто-то пишет «ок» и думает, как быстрее свалить. Кто-то готовится честно ответить «всё нормально», чтобы поскорее разойтись.
Знакомая картина? Ретроспектива — самый формализованный и самый испорченный ритуал в управлении проектами. По идее — рабочий инструмент улучшения. На практике — пустой обряд, на котором боятся сказать правду. Давайте разберёмся, почему так, и что с этим делать.

Почему ретро превращается в пустой ритуал

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

Вторая — отсутствие последствий. Сколько раз вы обсуждали на ретро одну и ту же проблему? Спринт за спринтом — «опять сорвали оценку», «опять заказчик поздно дал данные», «опять тестирование в конце». Обсудили, разошлись, в следующем спринте — то же самое. Когда команда видит, что ретро ни на что не влияет, она перестаёт вкладываться. Правильно делает.

Третья — формат ради формата. «Давайте напишем стикеры: что хорошо, что плохо, что улучшить». Звучит методически грамотно. Но если за этим нет реального разговора, стикеры — это просто бумажки на доске, которые потом никто не читает.

Как сделать ретро, которое работает
Не буду писать, что есть один правильный формат — это враньё. Работает не формат, работает культура и несколько принципов. Вот они.

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

Фокус на системе, а не на людях. Хороший вопрос — не «кто накосячил», а «как устроена наша работа так, что косяк стал возможен». Разница колоссальная. Первый вопрос ищет виноватого. Второй — слабое место в процессе. И ответы получаются совершенно разные.

Мало проблем, много решений. 
Главная ошибка начинающих фасилитаторов — увлечься сбором проблем. В итоге за час набирается двадцать пунктов, и времени на решения не хватает. Правило: половина ретро — на проблемы, половина — на конкретные действия. Причём действий должно быть мало, но они должны быть с владельцем и сроком. Три сделанных улучшения лучше двадцати обещанных.

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

Меняйте формат, когда он умер. 
Формат «что хорошо/плохо/улучшить» — отличный, но приедается. Если команда отвечает на автомате — меняйте. Иногда берём одну тему и разбираем глубоко. Иногда — «что бы я сказал себе в начале спринта». Главное — чтобы людям было интересно думать, а не заполнять ритуальную таблицу.

И главное — про действия, а не про чувства
Часто ретро путают с групповой терапией. «Давайте поделимся, что чувствуем». Я не против чувств, но если вы обсудили эмоции, но не выработали ни одного изменения — ретро не состоялось. Эмоции — это сигнал, не результат. «Я расстроен, потому что снова переделывали в последний момент» — повод решить проблему поздних правок, а не повод всех обнять.
Ретроспектива — не про прошлое. Про то, что вы сделаете по-другому в будущем. Если из ретро не вышло ни одного конкретного изменения — оно было бесполезно. Точка.

#менеджмент #agile #ретроспектива #проектная_команда #РП #практика

чтобы все наконец осознали, что это уже не юмор

✨ ЕЖЕНЕДЕЛЬНЫЙ ДАЙДЖЕСТ «ШКОЛЫ ПРОЕКТНОГО СПЕЦИАЛИСТА»

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

🔄 Retrospective, которую не ненавидят
Почему классическое ретро превращается в пустой ритуал и как сделать его рабочим инструментом улучшения, а не формальной «галочкой».
ЧИТАТЬ
🎤 Демо для заказчика, после которого не стыдно
Статья показывает, как презентовать результат так, чтобы заказчик увидел пользу для бизнеса, а не только сложность архитектуры и интеграций.
ЧИТАТЬ
💣 Архитектор и его тень: почему «я один знаю, как тут всё устроено» — бомба
Текст о рисках, когда критическое знание живёт в одной голове, и проект зависит от одного «человека‑системы».
ЧИТАТЬ
📉 Срыв сроков как честный диагноз проектной системы
Статья о том, почему дедлайн «срывается не в день сдачи», а задолго до него, и как сроки выдают системные проблемы в управлении проектом.
ЧИТАТЬ
🔥 РП, который не горит: как перестать быть пожарным
В статье сравнивается «героического пожарного» РП с системным руководителем и показывает, как выйти из режима вечных авралов.
ЧИТАТЬ

Еженедельный дайджест «Школы менеджера организации»
Неделя 24–30 июля 2026

🔥 Миф о «плоских структурах»: почему без иерархии наступает хаос
Сокращение управленцев и переход к «автономии» часто подают как прогрессивную реформу, но без зрелых команд и новых правил принятия решений это превращается в скрытую иерархию и размывает ответственность.
ЧИТАТЬ
🌀 Адаптивный менеджмент: когда классический план больше не работает
Классические трёхлетние стратегии устаревают раньше, чем запускаются, и статья разбирает, чем адаптивный менеджмент отличается от хаоса и как использовать скользящее планирование и сценарный подход без модного словоблудия.
ЧИТАТЬ
📑 Бюрократия обходится дороже, чем принято считать
Регулирование нужно для безопасности, но сложность норм создаёт скрытые издержки: поиск требований, отслеживание изменений и устранение противоречий занимают время, которое не добавляет ценности продукту.
ЧИТАТЬ
🧵 Сложность как валюта: бизнес усложняет собственную работу
Каждое согласование и отчёт появлялись как разумное решение, но со временем корпоративная сложность начинает обслуживаться ради самой себя, а не ради клиента
ЧИТАТЬ
🚀 5 ошибок начинающих предпринимателей — и как их избежать
Влюблённость в идею, путаница выручки с прибылью, попытка делать всё самому и другие типичные ошибки старта бизнеса разобраны простым языком с практичными альтернативами.
ЧИТАТЬ

🧱 Карьерный тупик senior: ты всё умеешь, но некуда расти

Знакомое состояние? Лет в тридцать-тридцать пять ты оглядываешься и понимаешь: технически ты на вершине. Сложные задачи решаешь на автомате. Младших обучаешь. Тебя зовут на самые тяжёлые куски проекта. Все вокруг считают тебя экспертом. И при этом — странное ощущение. Расти больше некуда. Не вверх, не вглубь. Вроде бы всё хорошо, а внутри глухое «и это всё?».
Это не выгорание. Это не лень. Это карьерный тупик senior. И в него попадает почти каждый, кто дошёл до этой ступени. Давайте честно разберёмся, что с этим делать. Без банальностей «просто стань руководителем».

Почему это происходит
Карьера в ИТ: первые лет пять ты растёшь вертикально. Джун, мидл, senior — каждый переход ощущается как прыжок. А потом рост замедляется. Не потому что ты стал хуже. А потому что senior — почти потолок технической вертикали. Дальше редкие позиции архитектора, тимлида, техдира. Мест мало, и не каждому это нужно.
Ты продолжаешь работать, делать хорошо, получать зарплату. Но ощущения движения нет. Задачи повторяются. Появляется вопрос, на который страшно отвечать: а что дальше?

Главный миф: «идти в менеджмент»
Первый совет, который слышишь: «иди в руководители». Но менеджмент — другая профессия, не «следующая ступень после senior». Руководить — меньше делать своими руками и больше через людей. Для кого-то кайф, для кого-то пытка. Если идти в менеджмент только потому, что «по-другому расти некуда», получится несчастный руководитель и потерянный специалист. Оставим это как один из вариантов, но не единственный.

Расти вглубь, но в новый домен
Senior в одной области — ещё не факт, что ты разобрался в смежной. Разработчик может стать архитектором, аналитик — методологом, РП — куратором нескольких проектов. Это не вертикальный рост, а горизонтальный: расширение экспертизы в сопредельные области.
Это называется T-shaped развитие. Вертикальная черта буквы T — твоя глубокая экспертиза. Горизонтальная — широта в смежных областях. Senior с T-shaped профилем ценится выше узкого специалиста: он связывает кусочки, которые другие не видят.

Менторство и передача знаний
Парадокс: делясь знаниями, ты сам растёшь. Менторство заставляет структурировать то, что знаешь интуитивно. Объясняя младшему, видишь пробелы в собственном понимании.
Плюс — вклад в будущее. Если ты единственный, кто умеет делать X, ты не ценный специалист, ты заложник. Обучая других, освобождаешь себя от рутины и систему от зависимости от одного человека.

Смена домена или отрасли
Иногда тупик — не про уровень, а про место. Ты senior в банковской автоматизации, и скучно. Но перейдя в производство, логистику, медицину — снова джун. Новая предметка, новые процессы. Тяжело для эго, но даёт ощущение роста, которого давно не было.

И вариант, который редко обсуждают: не расти
Самая неудобная мысль для амбициозного человека. Но честная. Не каждому нужно расти бесконечно. Иногда правильно сказать: «я хороший senior, мне нравится моя работа, я не хочу становиться руководителем». Это не поражение. Это осознанный выбор.
Проблема в том, что корпоративная культура часто не оставляет места для такого выбора. Не растёшь — «застоялся». На самом деле не так с человеком, а с культурой, которая считает движение единственной нормой. Хороший senior, который делает свою работу и не горит желанием прыгать выше, — это ценность, а не проблема.

Что в итоге
Карьерный тупик senior — это развилка. Выбор: расти в ширину через новые домены, стать ментором, сменить нишу, пойти в менеджмент (если твоё), или остановиться и признать, что тебе хорошо. Все варианты рабочие. Нерабочий один — застрять и молча вариться годами, обвиняя себя.
Если узнал себя — это нормально. Вы не одни. Выход есть, просто не там, где обещали.

#карьера #senior #менторство #саморазвитие #практика