Истории про Инжиниринг

Когда в обсуждении надежности сервиса появляется еще одна «девятка», это часто звучит как небольшое улучшение. Кажется, что речь идет о тонкой настройке. Было 99.9%, станет 99.99%. Визуально разница почти незаметна. На слайде это выглядит как один дополнительный символ после запятой. Для человека со стороны это вообще может восприниматься как косметическое усиление цели: ну да, хотим быть чуть надежнее, чуть аккуратнее, чуть качественнее. Но на практике это совсем не так. Разница между 99.9% и 99.99% доступности - не про «чуть лучше». Это про другой режим жизни системы и команд. Если перевести эти цифры в простой operational смысл, то 99...

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

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

Что именно тянет в разные стороны В реальной компании одновременно существуют три фокуса: Бизнес: квартальные цели по доходам и KPI; давление на оборот и маркетинговые кампании. Продукт: ценность для пользователя, эксперименты, дорожная карта на полгода/год. Технологии: долговременное здоровье платформы, возможность масштабирования, риск-инженерия, горизонты в годах. Каждый фокус сам по себе прав, но их метрики и горизонты различны. Это и создаёт конфликт. Скорость против надёжности Проблема. Продукт и бизнес хотят «быстрее», инженерия говорит «стоп» — боится багов и инцидентов...

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