Пятница, 23:40, прод лежит. Дежурный поднимает сервис за сорок минут: перезапустил контейнер, всё заработало. Инцидент закрыт, MTTR красивый, все спать.

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

$180 на Cursor за три дня. Три монитора. Пакет орешков. Ноль тестов. Бизнес в восторге. Команда в ужасе. Угадайте, кто победил.

Данные перенесены, workflow настроен, всех обучили. А через неделю — саботаж, снова задачи в Excel и бунтующий разработчик, у которого «вообще-то в Jira все нормально было»

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

Закупка — в 1С, инвентарный номер — в Excel, заявки на ремонт — в почте, списание — в бухгалтерии. Данные есть, но они не связаны. Разбираем 6 этапов жизненного цикла ИТ-актива, показываем, где чаще всего рвётся цепочка, и даём пошаговый план — как замкнуть цикл за квартал.

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

1000 устройств, 5 офисов, 1 Excel. Разбираем, где ломается учёт оборудования при росте компании и как перестать терять технику между филиалами.

Слово «вайбкодинг» в ИТ-среде вызывает неоднозначную реакцию: разработчики морщатся, бизнес интересуется, а все остальные делают вид, что давно разобрались. Ни лагерь хейтеров, ни лагерь евангелистов не дают честного ответа. Разбираемся: почему разработчики правы в своих опасениях, почему бизнес всё равно идёт в эту сторону — и что со всем этим делать.

Полгода поиска. Сотня отказов. И в итоге — либо берёте «почти подходящего», либо проект стартует без нужного человека. Знакомо? Проблема в том, что вы ищете одного человека там, где нужна комбинация навыков. В 2026 году роль «Senior Backend» больше не описывает реальную работу — она описывает несбыточную мечту работодателя. Пора собирать команды иначе.

Открываете список задач перед планированием спринта. Прокручиваете. Прокручиваете ещё. Где-то на третьем экране перестаёте понимать, что тут вообще происходит. Половина задач без автора, часть не трогали с прошлого года, несколько штук явно дублируют друг друга — но удалить страшно, вдруг важное. Разбираемся почему так происходит и что с этим делать.

Петров уволился, ноутбук исчез. На складе соседнего офиса нашли 12 нераспакованных ноутбуков. При инвентаризации обнаружили сервер, о котором никто не знал. Знакомо? Разбираем, почему Excel и 1С не справляются с учётом оборудования при росте компании и как выглядит нормальный процесс — с пошаговым планом перехода.

Проблема большинства команд не в том, что они работают медленно. Проблема в том, что они толком не понимают, где именно теряют время, сколько стоит каждая ошибка и насколько тяжёлым стал сам процесс поставки изменений. Именно здесь и полезны DORA-метрики. Разберём, что они измеряют, где их чаще всего трактуют неправильно и как применять их без KPI-магии. 

Ещё три года назад ИИ в ITSM представлялся как просто чат-бот на входе, который пытается угадать категорию тикета. Сегодня уже другой разговор: ведущие платформы встраивают AI не как надстройку над тикет-системой, а как архитектурный слой, который участвует в маршрутизации, предсказывает инциденты до их возникновения, автономно закрывает типовые обращения и генерирует постмортемы. Рынок уже видит пользу — по данным Forrester, компании, внедрившие предиктивные ITSM-практики, восстанавливаются после инцидентов вдвое быстрее тех, кто полагается на ручную обработку.

Рынок ITSM на это отреагировал по-разному — теперь при выборе инструментов фокус может быть не на том, какие ИИ-фичи есть у вендора, а насколько эта AI-инфраструктура управляема. В этом материале обозреваем мировых ITSM вендоров и их подходов к реализации ИИ.

Представьте: команда из 80 человек несколько лет живёт в Jira. Доски, спринты, кастомные поля, автоматизации на Groovy, сотни вложений, тысячи ссылок, разлетевшихся по корпоративным вики и письмам. 

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

Сможет ли российский продукт стать полноценной заменой Jira для команд разработки? Обсуждают команды SimpleOne и iiii-tech.

В поддержке запрос бизнеса очень прикладной: быстрее отвечать, делать меньше ошибок, выполнять SLA, выдерживать рост обращений при расширении каналов — почта, порталы, телефония. Компаниям нужно масштабировать сервис, сохраняя при этом стабильное качество. В статье о том, как они это делают.

Три пары функций. В каждой одна написана человеком, другая — ИИ. Сможете отличить? Мы не смогли. И наш ИИ-ревьюер тоже. Разбираем, почему синтетика проверяет синтетику — и что с этим делать.

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

Тимлид был искренне удивлён: «Я не видел никаких признаков!». А было ли тимлиду, где на них посмотреть?

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

О том, как одна базовая задумка – сделать разработку управляемой, пережила эпоху тяжелых каскадных проектов, DevOps, CI/CD, и подошла к 2026 году уже в совсем зрелом виде.