惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
P
Proofpoint News Feed
L
Lohrmann on Cybersecurity
S
Secure Thoughts
Attack and Defense Labs
Attack and Defense Labs
人人都是产品经理
人人都是产品经理
Stack Overflow Blog
Stack Overflow Blog
W
WeLiveSecurity
O
OpenAI News
SecWiki News
SecWiki News
博客园 - Franky
NISL@THU
NISL@THU
Microsoft Azure Blog
Microsoft Azure Blog
T
Tor Project blog
Microsoft Security Blog
Microsoft Security Blog
aimingoo的专栏
aimingoo的专栏
Security Latest
Security Latest
H
Hacker News: Front Page
Google Online Security Blog
Google Online Security Blog
P
Privacy & Cybersecurity Law Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
D
Darknet – Hacking Tools, Hacker News & Cyber Security
月光博客
月光博客
李成银的技术随笔
Spread Privacy
Spread Privacy
F
Full Disclosure
F
Fortinet All Blogs
T
The Exploit Database - CXSecurity.com
Vercel News
Vercel News
AWS News Blog
AWS News Blog
WordPress大学
WordPress大学
IntelliJ IDEA : IntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin | The JetBrains Blog
IntelliJ IDEA : IntelliJ IDEA – the Leading IDE for Professional Development in Java and Kotlin | The JetBrains Blog
V
Visual Studio Blog
J
Java Code Geeks
博客园 - 三生石上(FineUI控件)
G
Google Developers Blog
云风的 BLOG
云风的 BLOG
博客园 - 司徒正美
Engineering at Meta
Engineering at Meta
Last Week in AI
Last Week in AI
P
Palo Alto Networks Blog
宝玉的分享
宝玉的分享
T
True Tiger Recordings
N
News and Events Feed by Topic
酷 壳 – CoolShell
酷 壳 – CoolShell
Cisco Talos Blog
Cisco Talos Blog
N
News | PayPal Newsroom
S
SegmentFault 最新的问题
Jina AI
Jina AI

Все публикации подряд на Хабре

Иду в топ ниши строительных калькуляторов. Три месяца спустя HPSC: процессоры NASA, которые сделают космические аппараты по-настоящему умными Архитектура монорепозитория для параллельного исполнения торговых стратегий Чтобы не выглядело как пет-проект»: как я в одиночку сделал премиальный интерфейс кино-сервиса (с кодом) Вам продают ИИ. Покупать нужно не его Матрица компетенций джедая: как снизить Bus Factor на проекте Production начинается там, где заканчивается вайбкодинг От фич и каскадов к генеративной модели: как мы переосмыслили рекомендации с помощью ARGUS Отвечай, как топовый специалист: как службе поддержки решать настоящие, а не озвученные проблемы клиентов Новые IT-специалисты эпохи AI: как зарубежные и российские компании относятся к vibe-coders, low-coders и zerocoders Локальная система проверки персонала: как мы автоматизировали скрининг соискателей без передачи ПДн наружу Разрабатывали решение для автоматизации, а получили универсальный продукт «Мультиплексор для Лабораторных измерений» Подготовка и сдача экзамена PMP в мае 2026 года Время закрывать доски. Ваш SaaS таск-трекер — это просто слой лака над базой данных Как мы проектировали multi-agent feedback для обучения рисованию Что такое Gemma 4: обзор новой LLM от Google CyBOK. Глава 3. Законы и регуляторные нормы. Часть 8 LLM-инференс на фотонах? Препарируем передовые технологии, представленные в апреле Агенты выходят на работу (часть 3) Нехватка CUDA-памяти при обучении с GRPO: как перестать гадать и начать считать Окей, Lamoda, что надеть на вечеринку? Как обучить LLM навыкам ИИ-стилиста ArchiMate 4: Отказ от слоёв и унификация метамодели Дальнейшая судьба SFP-Master Игровой ПК или PlayStation 5: что выгоднее в 2026 году Flipper One — нам нужна ваша помощь Как мы построили корпоративную LLM-платформу: архитектура, грабли и выводы Устранить нельзя оставить — разбираем ситуацию с уязвимостями в российской виртуализации Bitrix и Laravel: веб-хуки, ERP и все-все-все (часть 5) Поиск секрета популярности лучших репозиториев GitHub за всё время существования платформы Сэкономили на облаке под 1С: ДО — заложили бюджет на штраф. Разбираем 152-ФЗ при работе с 1С Компьютерное зрение: что получается, когда у вас не идеальная лаборатория, а дождь, снег и подвижный манипулятор Параметризация в JUnit 5 и Allure Report Мне 15, и я собираю AI-стартап для недвижки: как я победил GPU, баги PyTorch и очередь в визовый центр Стратегия «Голубого океана»: как системный аналитик влияет на продукт Проектируем с нуля калькулятор на FPGA. Часть 3: Практические численные методы От видимости сети до кибербезопасности: главный миф о сетевой телеметрии, который мешает раскрыть потенциал NetFlow Как интегрировать ТСД с любой конфигурацией «1С: Предприятия»? Человеческие головы, сандалии и лягушки: стегоконтейнеры за тысячи лет до первого компьютера GigaIDE Pro для разработки на Django Как добиться непостоянного момента? Книга: «Kubernetes. Полное руководство по развертыванию и управлению Kubernetes в облачных и локальных средах. 2-е изд.» Почему IT-специалисты остаются: что работает на удержание в 2026 году Соединение деталей 3D-печатных изделий… Простое ли дело? Yamaha RGX121Z RM — современный суперстрат с японским вайбом второй половины 1980-х Как я написал плагин для WooCommerce под Yandex YCP или как купить в 1 клик из Алисы Креативное программирование: визуализация звука Сложно читать IT литературу на кривом русском? Есть решение — книжный ревью (рефакторинг) История о том, как человечество наняло очень странного сотрудника Как мы в отделе документации создали LLM агента для автоматизированного перевода с английского на другие языки Почему e-ink до сих пор не убил LCD, хотя должен был Как оплачивать нейросети и остальное недоступное в РФ в 2026: 9 способов с ценами и рисками, где можно влететь Решение проблем в управлении: почему мидл-менеджеры справляются с кризисами эффективнее топов Сколько телефонов и планшетов продали партнёры: единое хранилище данных для бренда электроники Google Fellow, студент Нанкина и создатель TikTok: кто сделал Seedream и Seedance. Досье SpeShu.AI В прорывном эксперименте из первых в мире полностью искусственных яиц вылупились птенцы Разворачиваем облачный ТОиР на заводе за две недели Vivaldi 8.0 — Унифицированная свобода выбора Как мы с нуля реализовали двустороннее доверие «лес–лес» с Microsoft Active Directory Хакер спас мир и сел в тюрьму: Невероятная история Маркуса Хатчинса и червя WannaCry Построение корпоративной архитектуры в ИТ-проектах, используя методологию TOGAF Пайплайн не должен хранить секрет: безопасное хранение и доставка секретов для CI/CD с Deckhouse Code и Stronghold ОГЭ информатика. 16 задание на Python Asus, MSI и Gigabyte урезают производство материнских плат. Что происходит на рынке Claudex: как я подружил Claude Code с ChatGPT/Codex OAuth без OpenAI API key Как измерить скорость интернета? Почему выгорают не слабые, а ваши Версионирование таблиц репозитория метаданных Sigla Vision Графическая утилита PostgreSQL mini Profiler (в помощь экспертам по технологическим вопросам 1С и не только им) Шахматные программы IV. Термины и методы Почему Я.Директ не приводит премиальных клиентов и что с этим делать – продали элитных туров на 600 млн Реестр отечественного ПО: как бизнесу выбрать решение среди 30 000 записей и не ошибиться Глаза не видят, а код пишется: как я настраиваю и программирую 100+ модулей в умном доме Архитектура AI-сервисов: почему монолит убивает latency и GPU Процессы: чего до сих пор не хватало обычным BPM (Часть 2) Книжный салон — дополнительные книги от издательства «БХВ». Предзаказ Как продакту довести фичу до прода без PMBOK и PRINCE2 Оргмодель, процессы и агенты (Часть 1) Probe-сеть из 10 регионов: что я не учёл про AS-разнесённость Как автоматизировать повторную обработку сообщений из архива в DATAREON Platform Arguments to Config — простая и мощная библиотека для парсинга аргументов в CLI-приложении на C# Как я обучил GPT с нуля на русском языке — и что из этого получилось Миллион алых нод: о выборе баз данных для хранения больших объёмов Билеты, баги и БДСМ: хроники тревел-стартапа От vSphere к VCD: как мы построили хранилище образов и нативный CSI для Kubernetes Фолдинг белка на ноутбуке. De novo дизайн KRAS G12D (Switch II) ингибитора. Докинг, валидация в AlfaFold Server и PyMOL Тебя уволят, и ничего не сломается. Возможно, станет даже лучше ИИ от Anthropic вскрыл банки G20, Цукерберг уволил 8000 человек за один день, а мы это пропустили Один за всех: как я в одиночку тащу фуллстек-проект, который незаметно разросся до соцсети Реакционная лженаука. Как СССР осудил кибернетику — и чем это аукнулось для ИИ Лёгкий мониторинг Proxmox-кластера: Pulse вместо большого Zabbix-стека RAG для тех, кто разочаровался: почему retrieval ломается и как это починить Три уровня субъективной реальности: почему непонимание в командах заложено биологически Дирижёр вместо конвейера: как AI ломает классический pipeline разработки Dart 3.12 — что нового в Dart? Четыре реакции — четыре тела. Можно ли измерить тип личности по сердцебиению? Flutter 3.44 — Что нового во Flutter? Найм инженеров в 2026: ботлнек — это не рынок, это вы Тонкие контроллеры и модели. Использование паттернов проектирования в Rails-приложении Тезис о расширенном разуме Сумасшедшая история Т9: Стартапы, дельфины и буддизм
Ваша трансформация обречена на провал. Восемь причин, почему
PMLogix · 2026-05-21 · via Все публикации подряд на Хабре

Более пятнадцати лет я занимаюсь управлением изменениями – внедряю проектное управления и запускаю трансформации. И вот неутешительный вывод: 70% трансформаций, на которые компании тратят годы и миллионы, заканчиваются ничем. Это не мои данные, их регулярно подтверждают многочисленные исследования, включая самое свежее – от компании BCG. Семь из десяти. На каждые три истории успеха приходится семь, о которых стыдливо умалчивают.

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

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

1. Первое лицо не верит – и врет об этом всем, включая себя.

Причина номер один.

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

Потому что он не верит в успех. Что трансформация окупится и принесет нужный результат. Поэтому он саботирует программу, оставаясь ее формальным заказчиком.

Что делать? Перестать врать самому себе. Нет веры – не запускайте большое. Сделайте пилот за два-три месяца. Сработает – масштабируйте. Не сработает – вы сэкономили компании годы и репутацию.

2. У трансформации нет цели. У нее есть лозунг.

«Повысить управляемость». «Развить проектную культуру». «Стать клиентоориентированной компанией». Это не цели, а красивые и пустые фразы. 

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

Что делать. Запретить себе слова «повысить», «улучшить», «развить», «оптимизировать», если нет конкретики. Описывать только конкретную новую реальность – что конкретно должно измениться? Если люди начинает яростно спорить – поздравляю, вы впервые говорите о реальных изменениях.

3. Двадцать инициатив, потому что «все важное».

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

По подсчетам BCG, 80 % ценности создают 20 % инициатив. Остальные 80 % – это не «дополнительная польза», а прямая конкуренция за внимание тех же людей. Запуская «все и сразу», вы добиваетесь того, что не будет сделано ничего.

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

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

4. У трансформации нет хозяина. Есть «руководитель программы».

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

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

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

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

5. В программу трансформации не заложены быстрые победы.

В плане указано: первый год – проектирование, второй – пилотный запуск, третий – масштабирование. Звучит солидно, но… это убивает программу.

У любой трансформации есть невидимый счетчик терпения. Он начинает отсчитывать время с момента запуска и заканчивается через 9–12 месяцев. Если за это время нет видимых результатов, программа умирает. Не потому, что она плохая. А потому, что закончилась вера в нее.

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

Что делать. Продумывайте программу не только от образа результата, но и на первые сто дней – что реально изменится за 3,5 месяца? Если вы не знаете, какой результат покажете через 90 дней, не начинайте.

6. Среднее звено узнает о трансформации из приказа.

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

Дальше – корпоративная классика. Никто открыто не возражает. Все ходят на совещания, заполняют формы. Но поведение не меняется ни на йоту. Потому что меняется поведение тех, кто чувствует себя соавтором, а не объектом.

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

Что делать. Считать привлечение ключевых людей не «потерей времени», а ключевой инвестицией. 

7. Ресурсы рассчитаны на старт, а не на дистанцию.

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

Дальше – классика. Через девять месяцев финансовый директор приходит с выражением лица, не предвещающим ничего хорошего, и говорит: «Рынок просел, надо оптимизировать расходы». И первое, что попадает под нож, – ваша программа. Операционную деятельность сокращать нельзя – это выручка. Трансформацию можно – это «инвестиции в будущее», то есть, говоря языком квартальной отчетности, ничего конкретного.

Дальше – медленное удушение. Бюджет урезали на 30%. Двух ключевых сотрудников вернули в функциональные подразделения. Контрольные точки – раз в квартал. Формально программа жива. На самом деле ее больше нет. Через полгода ее закроют с формулировкой «достигла плановых результатов на текущем этапе» – корпоративный эвфемизм, означающий «деньги закончились, а признать неудачу стыдно».

Любимая отговорка финансового блока: «Мы не могли предвидеть изменение рыночной конъюнктуры». Могли. Трансформация всегда обходится дороже, чем казалось, и требует больше времени. Это не «непредвиденные обстоятельства», а базовое правило. Если ваш финансовый директор не закладывает запас на полтора-два года вперед, то это не финансовый директор, а бухгалтер на высокой должности.

Что делать. Рассчитывайте бюджет на полную дистанцию – минимум на полтора-два года с запасом в 30–40 %. Иначе вы либо обманываете себя, либо новичок. И задайте себе честный вопрос: если через полгода понадобится дополнительный бюджет, программа это переживет? Если нет, не запускайте. Лучше отложить еще на полгода и собрать нормальный ресурс, чем красиво запустить и красиво похоронить.

8. «Решения приняты, пути назад нет».

Звучит как проявление силы и принципиальности. На деле же эта фраза чаще других приводит к провалу трансформаций.

Через полгода после запуска выясняется, что одна из ключевых гипотез не подтвердилась. Рынок изменился. ИТ-система оказалась хуже, чем обещал поставщик. Технология устарела. Нужно остановиться и пересмотреть подход.

Только пересматривать неудобно. Уже вложились. Уже отчитались. Уже сказали команде: «Обратной дороги нет». Признавать, что год назад было принято не самое идеальное решение… как-то неудобно.

И команда героически реализует то, что давно утратило смысл. Бюджет освоен, отчеты сданы, результата нет. Все знали, что план нереалистичен, но никто не сказал об этом вслух.

Что делать. Регулярно проводить честный пересмотр программы. Не просто обновлять статус «все по плану», а вести взрослые разговоры: что усилить, что остановить, что добавить. Право на пересмотр должно быть закреплено с самого начала – иначе в сложный момент его никто не поднимет.

И главное.

Если вы прочитали и узнали свою компанию по некоторым пунктам, это не приговор. Это диагноз. А диагноз – это половина решения.

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

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

Коллеги, подписывайтесь на мой Телеграм канал Андрей Малахов | От проектов к масштабу. Там я делюсь проверенными работающими инструментами управления, клиентскими кейсами и мыслями о менеджменте, современном бизнесе. Также публикую подкасты с топовыми экспертами России в области управления проектами и изменениями и делюсь своим подходом к созданию системы управления, выработанной за 20+ лет опыта.