Петров уволился, ноутбук исчез. На складе соседнего офиса нашли 12 нераспакованных ноутбуков. При инвентаризации обнаружили сервер, о котором никто не знал. Знакомо? Разбираем, почему Excel и 1С не справляются с учётом оборудования при росте компании и как выглядит нормальный процесс — с пошаговым планом перехода.
Проблема большинства команд не в том, что они работают медленно. Проблема в том, что они толком не понимают, где именно теряют время, сколько стоит каждая ошибка и насколько тяжёлым стал сам процесс поставки изменений. Именно здесь и полезны DORA-метрики. Разберём, что они измеряют, где их чаще всего трактуют неправильно и как применять их без KPI-магии.
Ещё три года назад ИИ в ITSM представлялся как просто чат-бот на входе, который пытается угадать категорию тикета. Сегодня уже другой разговор: ведущие платформы встраивают AI не как надстройку над тикет-системой, а как архитектурный слой, который участвует в маршрутизации, предсказывает инциденты до их возникновения, автономно закрывает типовые обращения и генерирует постмортемы. Рынок уже видит пользу — по данным Forrester, компании, внедрившие предиктивные ITSM-практики, восстанавливаются после инцидентов вдвое быстрее тех, кто полагается на ручную обработку.
Рынок ITSM на это отреагировал по-разному — теперь при выборе инструментов фокус может быть не на том, какие ИИ-фичи есть у вендора, а насколько эта AI-инфраструктура управляема. В этом материале обозреваем мировых ITSM вендоров и их подходов к реализации ИИ.
Представьте: команда из 80 человек несколько лет живёт в Jira. Доски, спринты, кастомные поля, автоматизации на Groovy, сотни вложений, тысячи ссылок, разлетевшихся по корпоративным вики и письмам.
И вот в один прекрасный день приходит задача: «Переезжаем». Дедлайн — три месяца. При этом на старте никто не знает, что в системе накопилось за годы: десятки автоматизаций, половина из которых создавалась под задачи, которых уже нет.
Сможет ли российский продукт стать полноценной заменой Jira для команд разработки? Обсуждают команды SimpleOne и iiii-tech.
В поддержке запрос бизнеса очень прикладной: быстрее отвечать, делать меньше ошибок, выполнять SLA, выдерживать рост обращений при расширении каналов — почта, порталы, телефония. Компаниям нужно масштабировать сервис, сохраняя при этом стабильное качество. В статье о том, как они это делают.
Три пары функций. В каждой одна написана человеком, другая — ИИ. Сможете отличить? Мы не смогли. И наш ИИ-ревьюер тоже. Разбираем, почему синтетика проверяет синтетику — и что с этим делать.
Антон проработал в компании три года — хороший разработчик, знал кодовую базу лучше всех, онбордил новичков, вкладывал душу. В пятницу он написал в личку тимлиду: «Нам надо поговорить», а в понедельник уже с заявлением.
Тимлид был искренне удивлён: «Я не видел никаких признаков!». А было ли тимлиду, где на них посмотреть?
Задачи закрываются, метрики зелёные. Потом приходит момент, когда нужно тронуть модуль, который написал ИИ три месяца назад — и выясняется, что никто не понимает, что там происходит. Разбираем, почему ИИ-долг опаснее обычного техдолга и что с этим делать.
О том, как одна базовая задумка – сделать разработку управляемой, пережила эпоху тяжелых каскадных проектов, DevOps, CI/CD, и подошла к 2026 году уже в совсем зрелом виде.
Разработчик приходит к руководству и говорит: «Нам нужен рефакторинг». Руководство слышит: «Мы хотим потратить деньги и ничего не выпустить». Дальше — тишина, новый спринт с новыми фичами и ещё один слой технического долга сверху.
ИТ-директор знает, что сервер загружен на 90% и скоро встанет. Бухгалтер знает, что этот же сервер уже три года как самортизирован и формально не существует. Закупщик знает, что на прошлой неделе купил сорок новых ноутбуков — и понятия не имеет, что на складе лежат ещё два десятка. Все трое работают в одной компании, но живут в разных реальностях.
Цена этого разрыва — потерянное оборудование, раздутые бюджеты и простои, которых можно было избежать.
Представьте: у компании 300 подразделений по всей стране или пять производственных площадок от Москвы до Дальнего Востока. Как узнать, сколько реально ноутбуков в омском филиале, где они находятся и в каком статусе принтер, купленный два года назад: используется, неисправен, в ремонте или уже подлежит списанию? Если данные приходят через мессенджеры или эксельные файлы, присланные раз в квартал — вы уже в зоне риска.
Однажды утром вы открываете задачу и понимаете: единственный человек, который знал, как это работает, вчера уволился. Знания ушли вместе с ним.
Разберем, почему попытки оцифровать интеллект через нормо-часы и коммиты ведут к деградации продукта, и как на самом деле устроена невидимая зона создания ИТ-решений, где ценность рождается из исследования и анализа, а не из скорости стука по клавишам.
Внедрили таск-трекер для ускорения — а команда стала тратить 40 минут в день на костыли. Рассказываю, как за полтора года у нас накопилось 11 обходных путей, почему онбординг новичков растянулся до трёх недель и что мы с этим сделали. Внутри — чек-лист «тормозит ли вас ваш инструмент» и пошаговый план действий.
Как бесконтрольное использование ИИ для генерации кода превращает сеньоров в уборщиков чужого кода: разбираем метрики, которые выявляют проблему, и три практики, позволяющие встроить управление ИИ-долгом в процесс разработки.
Недавно мы с командой проанализировали инфополе Хабра и обнаружили, что эйфория от внедрения ИИ в разработку сменяется разочарованием, senior-разработчики тонут в ревью некачественного кода, а техдолг растет как снежный ком. Мы сами проходим через этот путь, внедряя GenAI в SimpleOne, и прекрасно понимаем вашу боль.
Всем привет, я Артем Герасимов, владелец продукта SimpleOne SDLC. В этой статье я расскажу о реальных проблемах ИИ-генерации кода и о том, какие механизмы помогают нам с ними справляться.
SimpleGen — новый продукт для генерации решений на платформе SimpleOne с помощью AI. В этой статье рассмотрим, как начать работу с SimpleGen: что поставить на рабочую машину, как подготовить репозиторий, настроить доступ к SimpleOne, а также выполнить свою первую задачу.
Всем привет, я Артем Герасимов, владелец продукта SimpleOne SDLC. Чуть больше года назад я пришел в компанию в момент, когда продукт только прошел стадию MVP, которую мы делали быстро, чтобы проверить гипотезу. Гипотеза подтвердилась, появились клиенты, но вместе с ними пришел беспорядок: запросы терялись между почтой и чатами, сроки срывались, процессы перестали работать.
В этой статье расскажу, как мы за год превратили стартап-проект в управляемый продукт — с конкретными решениями, ошибками и чек-листом действий, которые можно применить в любой команде разработки.