Почему это иногда работает, и где этим стоит пользоваться.

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

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

Тут, на Habr, в том числе, пролетало не мало статей, где был отсыл к пирамиде потребностей Маслоу – да, увы, она тоже работает. Говорить о внутренней мотивации можно только тогда, когда базовые потребности закрыты… но иногда и она не работает, т.е. мотивация не всегда работает, даже при удовлетворенных базовых потребностях. Нужно что-то большее и правильно поставленные цели - может быть двигателем в развитии…

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

Но давайте прыгнем немного в очень даже реальную историю

Когда-то, ужа давно, когда и я был молодым, и трава была зеленее, довелось работать в консалтинге (я в общем-то и сейчас в нем, но в другом и в другом амплуа).

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

Компании часто сталкиваются с необходимостью переливать данные между системами. Но нередко это превращается в настоящий квест: форматы данных могут различаться, для интеграции инструментов может не быть готовых коннекторов, самостоятельно гарантировать консистентность данных в целевой системе может быть сложно или невозможно. Поэтому подобные задачи редко обходятся без применения CDC (Change Data Capture).

Меня зовут Андрей Капустин. Я менеджер продукта Tarantool CDC в компании VK Tech. В этой статье я расскажу о Tarantool CDC и о том, как инструмент помогает консолидировать данные из разрозненных хранилищ, в том числе проприетарных СУБД, обеспечивая прозрачность, высокую консистентность и скорость.

Обзор сетей и инструментов для Вайб кодинга на 1С. Очередная порция сетей: Claude 4, Grok, Qwen3, Llama4, GPT o3 и 4.1. MCP серверы для Cursor для 1С. Плагин EDT для вайб кодинга на 1С.

­­­Какие предметы вам нравились в школе? Я очень любила математику.  Меня завораживали цифры, формулы и логические рассуждения. А самое главное, даже если решать задачу несколькими разными способами – единственно верный ответ всегда будет один. И проверив его, можно быть уверенным, что задача решена правильно.

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

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

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

Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста Podlodka и автор Роадмапа Тимлида. Веду телеграм-канал Teamlead Good Reads, где каждый день делюсь идеями о работе с командами. Публикую перевод статьи Гранта Слаттона, инженера и основателя компании Row Zero, в прошлом старшего инженера в AWS S3.

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

Выбор архитектуры данных — это не просто техническое решение, а стратегический шаг, от которого зависит эффективность работы с данными во всей компании. Data Warehouse, Data Lake, Lakehouse или Data Mesh — у каждого подхода есть свои сильные и слабые стороны, и не существует универсального ответа. В этой статье — прагматичный разбор современных архитектур с точки зрения дата-инженера с акцентом на реальные кейсы. Если вы стоите перед выбором или хотите убедиться, что двигаетесь в правильном направлении — разложим всё по полочкам.

Шесть букв, которые могут изменить ваш B2B-маркетинг — аутрич. Или cold outreach, если говорить по-научному. Метод, который помогает выйти напрямую на ЛПРа (лицо, принимающее решение) в компании. Но есть нюанс: слишком часто его путают со спамом. А это — как путать вино с уксусом.

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

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

В статье — разбор причин, ловушек, типовых сценариев из практики и рекомендации, что делать, если проект уже идет, а менеджера все еще нет.

Мне стало интересно: насколько глубоко системный аналитик уровня Senior должен разбираться в программном коде? Где проходит грань между бизнес-фокусом и технической вовлечённостью?

Чтобы ответить на этот вопрос, я провёл исследование и опросил почти 200 системных аналитиков. Мы выяснили, какие технические навыки сегодня считаются must-have, а какие по-прежнему остаются "по желанию".

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

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

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

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

Что такое цифровая зрелость и зачем её измерять?

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

Сейчас в сети много инструкций по установке GUI-панелей, таких как Marzban, 3x-ui или новая RemnaWave. Однако, все они избыточны для домашнего использования, так как предназначены для крупных проектов и отличаются высокой сложностью настройки.

Мануал, который необходимо пройти до получения первого рабочего конфига, занимает более 10 страниц. Кроме того, подходящий конфиг для Xray нужно ещё поискать и правильно настроить — с этим отлично справляется Bash-скрипт autoXRAY.

Без GUI и базы данных Xray потребляет меньше ресурсов сервера и отлично подходит для запуска на слабых VPS-конфигурациях!

При каждом запуске autoXRAY генерирует новые UUID, ключи и пароли для защиты пользователей, а также выбирает случайные SNI из списка для маскировки.

Cold Email Outreach — это метод привлечения клиентов, при котором вы отправляете электронные письма потенциальным клиентам, с которыми раньше не было контакта, с целью установить деловое общение, назначить встречу или продать продукт/услугу. - Примерно так звучит определение от ChatGPT. 

Простыми словами, это когда шлете емайлы людям и компаниям, с которыми ранее никогда не общались, предлагаете свои услуги и товары, начинаете диалог.

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

В статье поделюсь своим опытом применения методики Cold Email Outreach для b2b с высоким средним чеком.

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

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

Диагностика хаоса - первый шаг. Но сама по себе она ничего не меняет. Это лишь осознание проблемы. Настоящая работа начинается на этапе структурирования требований.

Это тот момент, когда вы берёте множество разрозненных данных, противоречий, записей в Telegram, Excel-таблиц, каких-то старых писем и превращаете всё это в рабочий артефакт: чёткий, пригодный к реализации, контролируемый и понятный всем участникам.

Структурирование - это не про красивые документы. Это про построение системы управления требованиями, которая будет жить и развиваться вместе с продуктом. Именно здесь начинается настоящий системный анализ.

Поводом к написанию этого текста стал анализ кастдевов с пользователями Tangl, где снова появилась тема поддержки стандарта IDS в Tangl control. Я решила разобраться с перспективами и ограничениями спецификации IDS для автоматической проверки BIM-моделей на основе правил.

В статье мои выводы о том, в каких BIM-сценариях применение IDS даёт эффект, а для каких BIM-процессов он не особо полезен.

Введение: Архитектурное дежавю

Вы когда-нибудь замечали, как цифровой мир движется по спирали? В 2018 году я, размахивая Dockerfile и Helm-чартами, внедрял микросервисы на C# с RabbitMQ — всё ради священной цели «низкой связанности». А через три года, переключившись на Angular, с ужасом осознал: фронтенд-компоненты общались через цепочки Input/Output, словно это 2005-й, а мы пишем WinForms.

Это как собрать космический корабль, но управлять им через телеграф. На бэкенде мы гордо декларируем event-driven architecture, а на фронтенде компоненты перешёптываются через пропсы, будто подростки на школьной дискотеке. Ирония? Чем сложнее становились наши системы, тем больше они напоминали те самые монолиты, от которых мы бежали в мире backend.

Группа экспертов GitHub провела анализ популярных open-source AI проектов, созданных за последние 99 дней. В статье вы узнаете об этих проектах и почему они важны для индустрии AI.