Чем выше человек поднимается в иерархии, тем увереннее начинает читать других. И тем чаще промахивается.

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

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

И тут, как в плохой калибровке, прибор сам себе ставит «норму». Ошибка не ощущается изнутри.

Для PR это тоже важный урок: не путать уверенность спикера с точностью его оценки. Иногда лучший вопрос на встрече — не «что вы думаете?», а «откуда вы это знаете?» 👀

Если коротко: статус не улучшает способность понимать людей. Он часто просто делает ошибки более убедительными.

В BI-проектах есть неприятный момент: дашборд можно сдать, а управление так и не поменять.

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

Через месяц руководители всё так же уточняют показатели в чатах, команды сверяются с Excel «для себя», а дашборд открывают в основном перед встречей — не чтобы управлять, а чтобы подтвердить уже выбранную версию. Удобно, конечно. Но это скорее ритуал, чем инструмент 🫠

Проблема обычно не в Power BI, DataLens или Tableau. И даже не в том, что аналитик «не дожал» визуализацию. Чаще BI существует отдельно от управленческого процесса: данные есть, а правил, кто и на что опирается при решении, нет.

И вот тут дашборд бессилен. Он не меняет культуру сам по себе. Он лишь подсвечивает, где компания пока ещё управляет не данными, а привычками.

Я давно заметил: идеальные процессы в команде — это не всегда про порядок и спасение от хаоса. Иногда это просто очень дорогая версия того же хаоса, только с созвонами, регламентами и согласованием согласования.

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

Не исчезают. Просто меняют форму.

Когда процессы выстроены слишком жестко, команда начинает тратить время не на продукт, а на обслуживание системы. 30 минут на задачу — и месяц на то, чтобы убедить всех, что эту задачу вообще можно делать. Звучит знакомо? 🙃

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

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

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

В арбитраже денег нет 💵

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

И тут начинается магия без магии: WebRTC, NAT, STUN, TURN, а потом еще LiveKit — чтобы все это не развалилось в продакшене. Звучит как набор аббревиатур, которые любят инженеры и терпят редакторы. Но именно на этом уровне решается, будет ли звонок плавным или «у вас тоже звук пропал?».

Для PR и медиа тут хороший урок: если вы рассказываете про сложный продукт, не пытайтесь сразу продавать «революцию с ИИ». Сначала объясните базу. Люди гораздо лучше понимают историю, когда видят, как у вас устроен самый низкий этаж 🧩

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

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

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

Три типичных примера из практики:
— импорт товаров из Excel: можно быстро собрать костыль, а можно сразу подумать, как жить с обновлениями, ошибками и объёмами;
— мобильное меню на MODX: код есть, но вопрос не в том, «как сделать», а в том, как не сломать остальную верстку;
— Schema.org-разметка: ИИ легко генерирует компонент, но если он не учитывает структуру сайта, пользы от него немного.

Мой вывод простой: сначала проверяю не код, а постановку задачи. ИИ — хороший исполнитель. Но архитектор из него пока так себе 😉

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

Вот, например, идея внедрить Doctrine ORM прямо в ядро WordPress — без просадки по производительности. Звучит как попытка подружить два мира, которые обычно смотрят друг на друга с лёгким подозрением: классический CMS-быт и более строгая архитектура из мира PHP-framework’ов.

Но именно такие кейсы и интересно читать в PR-коммуникациях: не “как мы сделали красиво”, а “как мы вообще не развалили систему по дороге”. Тут важны не лозунги, а конкретика — где был риск, как обошли оверхэд, что реально изменилось в работе с данными.

Для редактора это почти идеальный сюжет: есть конфликт, есть техническая интрига и есть повод для нормального разбора без магии и маркетингового тумана. А для питча это напоминание: если у вас не просто “мы внедрили”, а “мы внедрили, и вот что из этого получилось”, шансы на интерес заметно выше. 👀

Геймдев любит выглядеть как клуб для избранных: мол, туда берут только гениев с портфолио в 12 лет и дипломом из космоса. На практике всё прозаичнее — и интереснее.

Я бы смотрел на индустрию не как на одну профессию, а как на набор очень разных ролей. Кто-то делает арт, кто-то пишет код, кто-то тестирует, кто-то собирает продуктовую логику и следит, чтобы игрок не ушёл после третьего экрана. И да, это всё — геймдев 🎮

Миф про «низкие зарплаты» тоже давно устарел. В хороших студиях вилки уже давно живут в одной вселенной с другими IT-направлениями, а в некоторых специализациях — и выше. Но тут, как всегда, магии нет: платят за конкретный навык, а не за любовь к играм.

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

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

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

Рабочий порядок такой:
— заголовок: событие + конкретика, без «лидер рынка объявил»;
— лид: 2–3 предложения с сутью новости;
— контекст: почему это важно для рынка, аудитории или отрасли;
— детали: цифры, механика, география, участники, сроки без тумана;
— цитата: не тост руководителя, а позиция или объяснение;
— справка: кто вы такие, если редактор видит вас впервые;
— контакты: человек, который реально ответит.

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

Перед отправкой проверьте релиз одним вопросом: сможет ли человек пересказать новость в одном предложении после первого абзаца? Если нет — структура пока работает против вас.

Убийцы WordPress обычно появляются с очень уверенным лицом и обещают «всё будет проще, быстрее и без боли». Потом выясняется, что проще — только на презентации, а быстрее — если не считать годы разработки.

Я бы к таким анонсам относился спокойно: гибрид PHP-фреймворка и CMS звучит бодро, особенно когда в планах — взять лучшее от Symfony, упростить вход для новичков и ещё дать zero code для блогов и магазинов. Идея знакомая: хочется собрать инструмент, который одинаково устроит и разработчика, и человека, который просто хочет запустить сайт без танцев с Composer.

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

Мне в таких историях нравится не заголовок про убийцу WordPress, а сам эксперимент. Он честно показывает: рынок всё ещё ждёт удобный PHP-инструмент без лишней боли. И, возможно, именно поэтому за такими проектами стоит наблюдать. Даже если на выходе будет не революция, а просто очень честная попытка 🙂