Дисклеймер: статья написана лично мной и затем отредактирована с помощью нейросети — для исправления ошибок и улучшения стиля.
Всем привет! Меня зовут Алексей Григорьев. Я работаю в ИТ больше 15 лет: разработка, фриланс, управление командой.
Я несколько раз оказывался в одной и той же ситуации. Я приходил в компанию или проект на позицию тимлида, где пахло жареным. Легаси, нестабильный прод, отсутствие документации, команда, работающая в режиме выживания. Казалось бы, моя задача как тимлида развивать систему, улучшать процессы, растить людей. Но реальность оказывалась иной, все силы уходили на то, чтобы система просто работала.
Попытка заняться развитием разбивалась об стену, чтобы строить новое, нужно стабилизировать старое. Как только начинаешь вносить изменения, система сопротивляется. Рефакторинг роняет прод, изменения в процессах вызывают сопротивление и саботаж, обновления инфраструктуры приносят новые проблемы. Возникает замкнутый круг: изменения порождают пожары, теперь их нужно тушить, а тушение выжигает все силы.
Раньше я считал это неудачей, с которой ничего не поделать. Но после рефлексии понял: это не ошибка управления, а естественный цикл жизни сложной системы. Я выявил цикл, который неосознанно применял много раз.
В основе лежат три этапа:
Стабилизация системы - старое должно работать и не порождать пожаров. Ресурсы конечны, и тратить их на все сразу невозможно.
Планирование и обучение - определяем, что хотим изменить, и готовим команду к этим изменениям.
Внедрение изменений - шаг развития, который снова вносит нестабильность и возвращает нас в начало цикла.
Хочу поделиться моим опытом, как обуздать хаос и превратить его в инструмент развития.
1. Стабилизация системы. Тушим пожары, возвращаем контроль.
Когда я прихожу в новую компанию или проект, моя первая задача не рефакторинг и не внедрение новых практик. Моя задача - стабилизировать систему настолько, чтобы у меня и команды появились ресурсы на развитие.
Ресурсы конечны. Невозможно развивать архитектуру, когда сервер падает три раза в день.
Доверие команды. Люди не могут работать в постоянном стрессе. Стабильность дает психологическую безопасность.
База для изменений. Любое изменение, внедренное в нестабильную среду, будет искажено хаосом. Сложно понять: это изменение не сработало или на него повлиял внешний фактор?
Работал я на одном проекте, личный кабинет на PHP (Битрикс), который выступал прокси между пользователем и API внутренней системы. Периодически сайт падал с ошибкой 502. Перезагрузка сервера помогала, но проблема возвращалась, то через день, то через неделю. Я начал копать и обнаружил, что на curl запросах к внутреннему API не установлены таймауты. Некоторые запросы зависали в бесконечности, занимая воркеры php-fpm. Когда все воркеры оказывались заняты, сервер переставал отвечать на новые запросы и отдавал 502. Я настроил таймауты на уровне curl.
curl_setopt($ch, CURLOPT_TIMEOUT, 30); curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10);
Зависшие запросы стали корректно обрываться. Падения прекратились.
Главное на этом этапе не пытаться сделать все и идеально. Нужно найти самое критичное узкое место, которое отнимает больше всего сил и устранить его. Это даст энергию для следующего шага.
2. Планирование и обучение. Готовим почву для изменений
Когда система стала стабильней, я перехожу к планированию. Этот этап для меня всегда состоит из двух вопросов:
Что меняем? (Процесс, инструмент, архитектура).
Что нужно, чтобы это изменение было успешно внедрено? (Ресурсы, навыки, инфраструктура, договорённости).
В команде работали джуны-фронтендеры, которые после онбординга оставались один на один с кодовой базой. Формального технического менторства не было и никто не сопровождал их на старте.
Что меня беспокоило:
Отсутствие поддержки: Новички были предоставлены сами себе. Документация была, но проверить, как они её усвоили, было некому.
Типовые ошибки: Джуны не переиспользовали существующий код, допускали ошибки в работе, застревали на сложных задачах.
Непривычный Git Flow: Наш процесс работы с ветками и мерджами требовал привыкания, а ошибиться было легко.
Дефицит времени старших разработчиков: Опытные разработчики были загружены своими задачами — их «не дождёшься» за советом.
Решение: использовать Code Review как инструмент обучения и поддержки. Все MR от джунов и новичков на онбординге проходили обязательное ревью у старших разработчиков. Я заранее обсудил что хочу внедрить ревью с командой и они идею поддержали, потому что сами формировали правила.
Как это работало:
Менторство: Разработчики не просто аппрувили MR, а советовали, помогали декомпозировать задачи, разбивали сложные фичи на подзадачи и передавали джунам посильные част��.
Инфраструктура: Совместно с командой написали инструкцию по ревью. Создали каналы в Mattermost для запросов. Добавляло оперативности.
Гибкость: Обязательный режим длился 3–6 месяцев, пока я и команда не видели, что человек вырос. Дальше ревью становилось опциональным, по запросу.
Главный принцип этого этапа: Обучение, это не трата времени, а инвестиция в успешное внедрение. Если команда понимает зачем и умеет как, даже сложное изменение приживается без саботажа.
3. Внедрение изменений. Изменение создает новые пожары
Когда команда готова и есть план, наступает самый сложный этап — внедрение. Казалось бы, все продумано, но именно здесь система начинает «сопротивляться». И это нормально. Я обсудил изменение с командой, они поддержали идею. А вот с менеджерами проектов я поговорил только после того, как мы начали применять ревью на практике. Это была моя ошибка.
Что пошло не так:
Когда задачи стали закрываться медленнее (потому что теперь нужно ждать аппрува), менеджеры начали задавать вопросы: «Почему срок сдвинулся?», «Зачем нам эта бесполезная бюрократия?».
Джуны, новички, которые только привыкали к процессу, оказались под двойным прессингом: нужно и ревью проходить, и объяснять менеджерам почему долго.
Что я сделал:
Признал ошибку. Я должен был обсудить это раньше с менеджерами.
Объяснил, что время на задачу выросло, но количество багов и возвратов на доработку снизилось.
Договорился о буфере. Мы согласовали, что на задачи, которые делают джуны и новички в период онбординга закладывается дополнительный коэффициент времени.
Главный принцип этого этапа: Любое изменение временно дестабилизирует систему. Моя задача не избежать этого, пытаясь предусмотреть все возможные сценарии (это невозможно), а быть готовым к новым пожарам и иметь ресурсы для их тушения.
Этот же цикл я неосознанно применял и для своего развития. Совсем недавно я получил диплом магистра менеджмента. Спустя время, когда я начал глубже погружаться в менеджмент, лидерство, Agile, разные методологии управления проектами, я узнал, что мой интуитивный цикл очень похож на цикл Деминга (PDCA). Также мои идеи перекликаются с идеями 6 сигм о снижении вариативности, практиками непрерывного обучения, управлением изменениями и принципами Delivery Management (ADKAR). Приятно было осознать, что мои изобретения уже работают в лучших мировых практиках.
Что я вынес для себя:
Если после внедрения изменений что-то начало ломаться — это нормально. Мы просто перешли на новый виток цикла.
Не нужно пытаться исправить все сразу. Один потушенный пожар даст больше энергии, чем десять планов по оптимизации.
Изменения не приживаются в вакууме. Обучение, договорённости и инфраструктура важнее самого изменения.
Человек тоже система. Если начинаешь «гореть», значит, пора на этап стабилизации, а не на новые достижения.
Порядок не бывает вечным. Любое изменение временно вносит хаос. Любая стабильность со временем деградирует. Это не повод опускать руки, а повод принять правила игры, что системы никогда не будут стабильными.
