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

Есть карьерные разговоры, после которых человек уходит не просто расстроенным. Он уходит с ощущением, что правила игры стали непонятными. Представим ситуацию. Тимлид несколько лет хорошо делает свою работу. Команда стабильна. Delivery едет. Стейкхолдеры довольны. Конфликты не выносятся наверх без необходимости. Найм работает. Процессы становятся лучше. Команда не разваливается при первом же сложном периоде. Руководитель регулярно говорит, что всё хорошо. Постепенно человек начинает брать на себя больше. Помогает соседним командам. Участвует в кросс-командных инициативах. Работает не только с задачами своей команды, но и с более широким контекстом...

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

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

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

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