Есть такой опасный момент в инфраструктуре: когда все вроде бы работает, но трогать это лишний раз не хочется. Не потому что идеально. А потому что есть ощущение — если полезешь, станет хуже. В какой-то момент мы поймали себя на этом с MinIO.
Последние годы в IT‑командах регулярно встречаю один и тот же паттерн — у техлидов и различных руководителей самого среднего звена.
Назову его Геннадий. Техлид. В команде за глаза зовут «Ещё Подумаем». Восьмой год в роли. Выбор фреймворка — две недели. Приоритеты спринта — три встречи. Даже «куда идём обедать командой» превращается в опрос в чате.
Геннадий — человек, который всегда знал, как надо. Уверенный. С позицией. Решал сам — это было его.
Перестало работать.
HR считает его выгоревшим, отправляет в отпуск. Он возвращается посвежевшим — ничего не меняется. Вопросы продолжают висеть.
Выгорания нет. Анализы чистые, сон нормальный, отпуск освежил. Он не устал — он просто больше не принимает решения. Ни он сам, ни его руководитель, ни HR не знают, как это называть. В их словаре такого слова нет.
Слово есть — в нейробиологии.
Говорят: “выстраивать процессы”. А откуда они берутся, как это обычно происходит, и вообще, зачем это всё?
Что такое процесс? Это то, как организована повторяющаяся работа, взаимодействие между участниками, ради какого-то общего результата.
Процесс никогда не должен быть самоцелью. И нет никакого универсального процесса на все случаи жизни.
Мы хотим достичь какой-то большой и сложной цели, или регулярно достигать какие то цели похожего типа. И чтобы делать это хорошо, эффективно, нам нужно структурировать взаимодействие разных участников. И мы это делаем в какой-то нашей конкретной ситуации: жизненной, рабочей, глобальной и т.д.
Сегодня мы с вами поговорим о вещи, на первый взгляд, простой до банальности: почему важно хвалить сотрудников и проявлять к ним внимание. Тема, кажется, даже не заслуживает отдельного разговора - ну кто же не знает, что доброе слово приятно? Но вот парадокс: по моим личным наблюдениям (статистику я, конечно, не публикую, все взято из моей головы), компании редко хвалят коллег за сделанную работу. Я не о том, чтобы каждые две-три недели гладить человека по головке за сам факт его существования - разумеется, нет. Речь о другом - о простом, почти забытом искусстве замечать усилия.
Конечно, любой человек скажет: прибавка к зарплате лучше любых слов. И с деньгами не поспоришь. Но давайте смотреть правде в глаза: путь до реального повышения оклада часто занимает года, и внутри одной компании нужно пройти немалый путь. А бывает, что у бизнеса прямо сейчас нет финансовой возможности подкинуть сотруднику сверху - кризис, низкий сезон, сложный период. И вот тут открывается минимальный, но невероятно мощный инструмент - дать человеку понять, что он для компании важен. Не кошельком, а вниманием.
За месяц в одиночку написал production-систему анализа цен и продуктов конкурентов с Claude Code. До этого пятнадцать лет управлял командами и бизнесами, код руками открывал раз в три года. Главный вывод: Claude Code это инициативный junior с памятью золотой рыбки. 5 правил контроля, без которых он разваливает любую систему сложнее MVP за две сессии.
В Agile и Scrum есть почти священная заповедь: команда должна быть стабильной, долгоживущей. Люди притираются друг к другу, учатся работать вместе, растёт доверие и предсказуемость.
Но вообще, люди уходят, приходят новые, компания растёт, появляются новые продукты, кто-то выгорает, кто-то засиделся и перестал развиваться.
Хайди Хелфанд, автор книги "Dynamic Reteaming: The Art and Wisdom of Changing Teams", проработавшая в AppFolio, ExpertCity и других компаниях, утверждает: изменение состава команды - это не проблема, а нормальный и правильный процесс, которым можно управлять. Она собрала реальные кейсы и показала, что пересборка команд даёт результаты, которых не может дать стабильная команда.
Почему громкие обещания, касающиеся роста продуктивности труда, чаще всего не дают ожидаемых результатов? Может, что-то сильно не в порядке с теми программными продуктами, применение которых должно приводить к улучшениям? А может — сами числа скрывают какую-то тайну?
В условиях глобальной неопределенности финансовое планирование и бюджетирование перестает быть ритуалом подготовки отчетов – сегодня это живой процесс, который определяет жизнеспособность компании, развивая базовые подходы в комплексную систему интегрированного планирования.
Бюджетирование – очень важная, интересная и нетривиальная задача, которую в современном мире принято решать при помощи автоматизации. Если еще 5 лет назад в системе бюджетирования видели инструмент консолидации и план-факт анализа, то сегодня это комплексная высокотехнологична модель бизнеса.
В этой статье мы поговорим о том, как сама природа процесса бюджетирования влияет на задачи автоматизации и критерии подбора ИТ-системы для решения этих задач.
Выбирая LLM для своего первого пет-проекта, я случайно создал бенчмарк для LLM "Испытание Дали" по трем параметрам: качество, скорость и стоимость. Этот бенчмарк позволил мне найти оптимальную LLM для встраивания в продукты моей компании Флаг Софт. Возможно, вас тоже заинтересуют его результаты.
Когда ко мне обратился клиент, он сформулировал проблему примерно так: «Вся информация есть, но связана только у меня в голове».
Он технический директор в сфере силовой электроники. Рабочий день — проекты, схемы, переписки, документация. Всё это жило в разных местах, и только он сам знал, где что лежит и как одно связано с другим.
Про Developer Experience любят говорить, проводя параллели со счастьем. Счастливый разработчик пишет хороший код, остаётся в компании, приводит друзей. Звучит хорошо, продаётся хорошо. Только когда я спрашиваю на интервью «а сколько это счастье стоит и что оно приносит бизнесу», в ответ обычно начинается мычание. Потому что счастье — это маркетинговая обёртка, в которую упаковали DX, чтобы продать его людям с бюджетами. Обёртка свою работу сделала, про DX начали говорить. Но если вы строите стратегию вокруг счастья, то вы почему-то начинаете покупать в офис кресла и фрукты, а пайплайн как собирался 40 минут, так и собирается.
Замечаю, что часто люди подстраиваются под инструменты для работы, а не наоборот
Подумаем в статье почему так происходит и что с этим делать
Многие из нас идут на работу, полные энтузиазма, что ИИ сделает самую нудную и сложную часть работы. Claude, Cursor, Gemini и десятки агентов — обещают освободить нас от рутины и превратить обычный день в поток гениальных идей. Но вместо лёгкости вы вдруг ловите себя на том, что мозг гудит, как перегретый сервер. Мысли путаются, решения даются медленнее, и вы тупите, будто после бессонной ночи. Добро пожаловать в эпоху «AI brain fry» (перегрев мозга от ИИ).
Именно так называется феномен, который подробно разбирают авторы статьи в Harvard Business Review (март 2026 года) — команда экспертов из BCG и Университета Калифорнии в Риверсайде. Они провели опрос среди 1488 американских сотрудников крупных компаний и выяснили, что ИИ не всегда друг. Иногда он становится тихим вором ваших когнитивных ресурсов.
Еще два-три столетия назад «взять и обучить» клерка мог только сам банк. Однако и сегодня, когда подготовкой специалистов занимаются топовые вузы, банки не пренебрегают корпоративным образованием. Рассказываем, как и чему банки учили сотрудников — 400 лет назад, в начале XX века и сейчас — и почему многие современные компании (включая МКБ) в этих вопросах делают ставку на ИИ.
Третья неделя в новой компании. меня спрашивают кто в соседней команде отвечает за конфиги админки и где лежит контракт по realtime-интеграции с витринами партнёров. отвечаю без открытия браузера.
Я ж не гений. просто всё это уже в одном каталоге и достаётся одной командой в терминале.
Представьте ситуацию: к 30 годам человек добился всего. Желал быть тимлидом и стал им. На работе сплошь успехи. Полностью соответствует всем ожиданиям, которые на него возлагают общество, коллеги, друзья и близкие. Но счастливым себя не чувствует: вместо этого энергии становится меньше, все чаще ощущается апатия, теряется интерес к работе. В общем, тот самый «кризис переходного возраста» во всей красе, только в профессиональном плане. Я провел в этом состоянии больше полутора лет, и я до сих пор в процессе.
Привет! Меня зовут Саша Шиндин, я руководитель группы проектного управления мобильных решений в «Лаборатории Касперского», а эта статья про то, как подобный кризис проживать. Не претендую тут на роль эксперта — просто хочу поделиться своим опытом переосмысления карьеры и не только ее.
«Калугатрансмаш» уже закрылся — на его месте строят жилой комплекс. Следующие, судя по всему, — мы. Так говорит руководство «Кубаньжелдормаша» — завода, которому в августе исполнится 93 года, который пережил немецкую оккупацию и 90-е, но может не пережить систему госзакупок. Разбираю конкретный конкурс, в котором единственный производитель проиграл перекупщику — и почему это касается не только заводов, но и всего IT-сектора.
Это не про политику. Это про продуктовый сигнал, который считывают все — кроме тех, кто его посылает.
Есть старый принцип в разработке: eat your own dog food — пользуйся тем, что создаёшь. Microsoft внедрила его в 1988-м, когда менеджер написал вирусное письмо коллегам: «Ты ешь свой собственный корм для собак?» Смысл прост — если вы не пользуетесь собственным продуктом, у вас нет мотивации его улучшать. Пользователи это видят. Рынок это чувствует.
У нас есть три живых кейса, которые демонстрируют, что происходит, когда принцип нарушается систематически, публично и в промышленных масштабах.
Всем привет. Меня зовут Данил, я учредитель агентства WallMates. Никогда раньше не писал на Хабр, потому что здесь принято обсуждать архитектуру высоконагруженных систем, а не колеровку RAL. Но этот кейс заставил меня сесть за клавиатуру по двум причинам.
Во-первых, я чуть не завалил проект из-за банальной колориметрии. Во-вторых, наблюдая за командой заказчика после сдачи объекта, я понял, что офис — это такой же интерфейс для сотрудника, как IDE для разработчика. И если UX в помещении кривой, продуктивность падает, даже если у вас MacBook Pro и кресло Herman Miller.
В какой-то момент я заметил, что сам учет финансов в Obsidian меня полностью устраивает, а вот сбор исходных данных для него каждый раз отнимает лишнее время.
Схема была простой и довольно утомительной: открыть несколько банков, посмотреть остатки по счетам и картам, потом перенести эти цифры в свои заметки. По отдельности это мелочь, но в регулярной рутине такие действия быстро начинают раздражать.
Я решил автоматизировать именно этот участок. Мне был нужен локальный и понятный способ собирать данные из интернет-банков, а уже потом использовать их в своей системе заметок.
В этой части речь пойдет именно про сбор данных: как я сделал небольшой bridge-слой между банками и Obsidian. Во второй части можно будет уже перейти к тому, как эти данные встраиваются в vault.