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

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

⛔️ Проекты буксуют из-за коммуникации. Согласитесь, эти бесконечные уточнения в переписке, размытые технические задания, необоснованные уступки съедают не только время, но и экономическую эффективность работы. Мы запускаем интенсив «Деловые коммуникации для ИТ-специалиста» — практико-ориентированный курс, где за 2 недели и 4 живые встречи вы получите конкретные инструменты: → Техники активного слушания для выявления истинных потребностей заказчика → Презентации ИТ-продуктов на языке выгод по методике BOMBER-B → Переговоры по модели Томаса-Килмана → Автоматизация деловой переписки через ИИ-ассистентов с готовой библиотекой промптов ✅ Результат: паспорт компетенций, чек-листы, шаблоны и сокращение времени на рутину до 5–10 часов в неделю. 🧑‍💻 Для аналитиков, разработчиков, менеджеров по продажам, КАМов и администраторов проектов. 👉 Все подробности и заявка: на сайте #IT #softskills #деловыекоммуникации #обучение

🚀 Старт уже через 2 недели! Новый поток авторского курса «Школа руководителя проекта» с обновленной программой! Что вас ждёт: 🔹 2,5 месяца интенсивной практики по стандартам PMBOK 🔹 Разбор реальных IT-проектов, а не абстрактных теорий 🔹 Инструменты, которые можно внедрить с первого занятия 🔹 Обратная связь от преподавателей-практиков Этот курс для вас, если вы: ▫️ хотите систематизировать опыт в проектном управлении ▫️ чувствуете, что проекты «едут» не так, как планировалось ▫️ готовы выйти на новый уровень — от исполнителя до руководителя Места ограничены. Подробности и регистрация на сайте.

Запись вебинара про корректировки закупок и продаж до ввода остатков: -Значение корректных начальных данных для последующей работы ERP-системы и последствия некорректного начального баланса; -Алгоритм корректировок закупок до начала ведения учета в 1С:ERP; -Шаги по проведению корректировок продаж до начала учета в 1С:ERP; -Инструменты для проверки устранения расхождений и ошибок. Смотрим: https://vkvideo.ru/video-63402641_456240376 #1C #ERP #1CERP

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

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

Дайджест «Школы менеджера организации» за 3–9 августа На неделе говорили о сложных управленческих темах: как быть честным и не переходить границы, почему KPI иногда искажает реальность, зачем руководителю делегировать и откуда у топ-менеджеров берутся сомнения в себе. 💬 Где проходит граница между радикальной честностью и грубостью — читать 📊 Почему сотрудники начинают работать на цифры, а не на результат — читать 🎯 Почему привычка «сделаю сам» мешает руководителю развивать команду — читать 📈 Чем отличаются цель, KPI, показатель и метрика — читать 🎭 Почему синдром самозванца особенно часто проявляется у руководителей — читать Читайте, сохраняйте и делитесь с коллегами, которым интересны управление командами, развитие руководителей и эффективная организация работы.

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

✨ ЕЖЕНЕДЕЛЬНЫЙ ДАЙДЖЕСТ «ШКОЛЫ ПРОЕКТНОГО СПЕЦИАЛИСТА» За прошедшую неделю, 3–9 августа, вышли материалы о границах проекта, баге в пятницу, управленческой перегрузке, адаптации новичков, метриках и развитии senior‑специалистов. 🚧 Как договориться, что НЕ входит в проект Сроки часто срываются не из-за слабой команды, а из-за незаметного расширения состава работ: к первоначальному запросу постепенно добавляют новые задачи, но дедлайн остаётся прежним. Статья о том, как заранее фиксировать границы проекта и обсуждать изменения с заказчиком без конфликта. 🐛 Стадии принятия бага, который всплыл в пятницу вечером Ироничный текст о знакомом сценарии: критическая ошибка появляется в конце рабочей недели, а команда проходит путь от отрицания до кофе, коммита и долгожданного подтверждения от заказчика. 🎙 SADT и IDEF0: как устроена строгая логика процессов Выпуск о методологии функционального моделирования: как через блоки и дуги декомпозировать сложную систему, описывать входы, управление, механизмы и результаты процесса. 📵 Самая незаметная ошибка — быть всегда на связи Постоянные сообщения, звонки и согласования создают ощущение занятости, но вытесняют работу над действительно важными решениями. Автор объясняет, как доступность руководителя приучает команду передавать ему всё больше вопросов. 🌱 Новички в крупном проекте: как не убить проект и не сломать людей «Бросить в воду» — плохая стратегия для сложных проектов, где цена ошибки высока. Материал о том, почему новичкам нужны понятные задачи, контекст, регулярная обратная связь и безопасный способ задавать вопросы. 📊 Как правильные метрики заставляют компанию работать неправильно Люди начинают оптимизировать то, чем их измеряют: поддержка шлёт отписки ради скорости ответа, продажи делают звонки ради плана, а качество уходит на второй план. Текст — о риске подменить бизнес-результат красивыми цифрами. 🧱 Карьерный тупик senior: ты всё умеешь, но некуда расти После уровня senior технический рост становится менее очевидным: редкие позиции архитектора, тимлида или техдиректора подходят не всем. Статья разбирает, почему это не обязательно выгорание и какие траектории развития остаются у опытного специалиста.

🎬 Один проект — два фильма: заказчик и подрядчик Пятница, вечер. Самое время посмеяться над тем, что объединяет нас всех. Один и тот же проект глазами двух сторон — два совершенно разных киносюжета. На совещании Заказчик: «У нас простые процессы, внедрим за пару месяцев». Подрядчик: «У них там ад, но на совещании улыбаемся». В договоре Заказчик: читает одно. Подрядчик: написал другое. Оба: уверены, что договорились. На старте Заказчик: «Ну, начали! Когда первые результаты?». Подрядчик: «Мы ещё не получили доступы. И данные. И НСИ. Хотя бы НСИ». На середине Заказчик: «А можно ещё вот это добавить? Совсем чуть-чуть». Подрядчик: «Опять. Снова. Как всегда». За неделю до сдачи Заказчик: «Кажется, нам нужно пересмотреть подход». Подрядчик: «Мы это предсказывали на старте. В протоколе. На странице три». На сдаче Заказчик: «Ну, в целом похоже на то, что мы хотели». Подрядчик: «Это ровно то, что в спецификации. Которую вы согласовывали. Полгода». Через год Заказчик: «Хорошо, что всё-таки сделали. Хотя было сложно». Подрядчик: «Хорошо, что всё-таки сделали. Хотя было сложно». Знаете, что смешного? На финальной строчке они наконец согласны. Все хотят одного — чтобы проект закончился и заработал. Просто путь к этому каждый видит по-своему. Хорошей пятницы и удачных проектов. Чтобы кино было со счастливым концом. 🍿

SADT появилась ещё в конце 1960-х как способ разложить сложную систему на понятные действия. Без магии: берётся большая функция, например «управлять производством», и раскладывается на более мелкие — закупать, планировать, выпускать, контролировать. Позже подход лёг в основу IDEF0, который до сих пор используют при описании бизнес-процессов, проектировании информационных систем, автоматизации производства и внедрении ERP. Особенно полезно там, где все говорят о процессе разными словами и уже немного запутались. Сильная сторона SADT — она заставляет не просто рисовать квадратики. У каждого действия есть вход, результат, правила управления и ресурсы. Сразу видно: что приходит в процесс, что из него выходит и почему он вообще работает. Но есть и минус. Хорошая SADT-модель требует времени и дисциплины. Если увлечься детализацией, можно нарисовать такую иерархию, в которой потеряется даже автор. Поэтому это не универсальная замена всем схемам, а инструмент для ситуаций, когда сложность действительно надо разложить по полкам.

Разбираем ключевые различия между целью, параметром, метрикой, показателем и KPI. В статье показано, как путаница в терминах приводит к ошибочным решениям, суррогатным «ключевым» показателям и странной системе премирования. И как навести порядок в управленческом языке, связать KPI с критически важными результатами и перестать измерять всё подряд только потому, что это легко выгружается в Excel? Читать полностью: Цель, KPI или метрика: почему менеджеры называют одним словом разные вещи.

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

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

Телефонный спам победят за счёт бизнеса Телефонный спам, похоже, решили победить самым понятным для бизнеса способом — сделать каждый звонок платным и подписанным. Мобильные операторы начали блокировать массовые и автоматические вызовы, если компания не заключила договор на маркировку. В среднем такая маркировка стоит около 30 копеек за каждую попытку. Даже если человек не ответил. По прежним оценкам, общие расходы российского бизнеса могут превысить 20 млрд рублей. А количество звонков с признаками массовости, поступающих из сетей фиксированной связи, с начала 2026 года выросло на 155%. Такие данные приводит «Коммерсантъ». На первый взгляд, всё логично. Звонит компания — на экране должно быть понятно, кто именно. Не загадочный номер, не «служба безопасности чего-то», а нормальное название. Мошенникам сложнее, людям спокойнее. Но есть одна бытовая неприятность. Вместе со спамом под блокировку может попасть вполне нужный звонок: из клиники, службы доставки, банка, сервисного центра. Просто где-то не оформили договор, не передали данные или операторы не договорились между собой, как ими обмениваться. Получается занятная картина. Раньше компании платили за то, чтобы дозвониться. Теперь ещё и за право быть узнанными. Причём платить приходится даже за короткое «абонент не отвечает». Скорее всего, дешёвых обзвонов действительно станет меньше. Только доверие к звонкам одной подписью не возвращается. Если компания звонит пять раз за вечер, надпись с её названием делает раздражение не меньше, а просто более адресным. Возможно, главный итог маркировки именно в этом. Теперь хотя бы понятно, на кого злиться.

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

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

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

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