Фича может уехать в прод за 30 минут, а может застрять на месяц из-за согласований, созвонов и чужих слотов в календаре. Именно этот разрыв и описал главный эксперт ОТП Банка Михаил, сравнив два полюса, между которыми живут процессы в разработке: рабочую вакханалию без правил и аккуратную корпоративную машину, где почти все правильно, но слишком медленно.
В заметке на Habr / Карьера Михаил, Java/Kotlin-разработчик и главный эксперт ОТП Банка, разбирает личный маршрут от команд без базовой организации к банку с выстроенной дисциплиной. Для русскоязычной IT-аудитории это не очередной спор про Agile против Waterfall и не банальное нытье про митинги. Это практический вопрос: где заканчивается полезная предсказуемость и начинается процесс ради процесса, который съедает скорость, внимание команды и смысл изменений.
До перехода в банк автор, по его словам, работал в командах, где нормой были нереальные сроки, отсутствие груминга, планирования и внятного тайм-менеджмента. Задачи прилетали в режиме «нужно было вчера», переработки считались почти обязательными, а отказ от них мог обернуться давлением со стороны окружения. Иногда описание задачи сводилось к картинке процесса, нарисованной на бумаге. В такой среде цикл от появления задачи до прода занимал те самые 30 минут, но плата за скорость была очевидной: падающее качество кода, растущее число багов, выгорание команды и постоянное тушение пожаров.
На этом фоне переход в банк выглядел как выигрышный апгрейд карьеры. Четкие границы спринта, заранее подготовленные задачи, отсутствие внезапных ночных авралов и предсказуемый рабочий день для многих разработчиков звучат не как бюрократия, а как роскошь. После команд, где нельзя спокойно пообедать без экстренного звонка, сама возможность планировать день и не ждать очередного «срочно» воспринимается почти подозрительно. В этом месте статья цепляет точным наблюдением: хаос утомляет не только переработками, но и тем, что он постепенно сбивает внутренние настройки. Когда все вокруг постоянно горит, нормальная организация сначала кажется не нормой, а странностью.
Когда порядок начинает тормозить
Проблема, по версии автора, начинается позже, когда восторг от предсказуемости сменяется бытовой арифметикой процессов. То, что в неформальной команде решалось за пять минут, в крупной структуре растягивается на дни, недели, а иногда и месяцы. Изменение одного поля может потребовать согласования с архитектором. Исправить найденный баг сходу нельзя: нужна отдельная задача, а задача должна пройти свой маршрут одобрения. Если речь идет об интеграции с другой командой, то добавление одного поля, его тестирование и выкатка уже легко занимают месяц. Формально все логично: контроль, прозрачность, зависимость от соседних контуров. Практически это выглядит так, будто компания защищается не только от ошибок, но и от любой лишней скорости.
Отдельная линия критики касается встреч. Михаил пишет, что часть грумингов и созвонов превращается в обязательный ритуал, где не все участники действительно нужны. В отдельных случаях рабочий день может уходить на 4-6 часов звонков, в которых разработчик в основном молчит, пока собственная работа стоит на паузе. Чтобы просто обсудить вопрос по задаче, нужно собрать несколько участников, найти общий слот, а если разговор уходит в архитектуру или детали, встречу переносят до появления нужного человека. Так у каждого вопроса появляется свой «владелец», которого еще надо поймать. Для инженера это означает не просто потерю времени, а распад контекста: пока ждешь следующего обсуждения, внимание уже переключилось на другие задачи.
В этом наблюдении нет ничего экзотического. Чем крупнее компания, тем дороже обходится ошибка на проде, тем сильнее тяга к формализации. Банки, телекомы, интеграторы и крупные платформы годами отстраивают защитные слои вокруг изменений: планирование, согласование, контроль архитектуры, тестовые контуры, межкомандные синки. Такая система действительно снижает вероятность хаотических релизов и делает нагрузку на людей более предсказуемой. Но вместе с этим она нередко производит побочный эффект, знакомый почти любой зрелой продуктовой или корпоративной разработке: решение уже понятно, но команда еще долго оформляет право его реализовать.
Самый полезный тезис статьи в том, что процессы в разработке нельзя обсуждать как моральную категорию, где есть «хорошие» и «плохие» команды. Автор честно показывает компромисс. В хаосе есть свобода, скорость и адреналин, но там же живут переработки, выгорание и разваливающийся код. В жестко выстроенной среде есть нормальный сон, выходные и понятный ритм, но вместе с ними появляются бесконечные согласования, лишние встречи и ощущение, что простое действие стало тяжелой процедурой. Это важный сигнал и для разработчиков, и для менеджеров: сами по себе процессы в разработке не делают организацию зрелой. Зрелость начинается там, где процесс помогает двигать задачу, а не доказывает собственную необходимость.
Для бизнеса отсюда следует довольно неприятный, но полезный вывод. Компания может искренне считать, что инвестирует в качество и устойчивость, а на деле незаметно накапливать операционное трение. Его трудно увидеть в отчетах, зато его быстро чувствуют команды: баг исправляется дольше, чем живет пользовательская боль; решение обсуждают повторно, потому что к моменту реализации участники уже забыли исходный контекст; релиз формально безопасен, но стоимость этой безопасности начинает съедать продуктовую скорость. В условиях, где рынку нужны быстрые проверки гипотез, такой перекос бьет не только по настроению инженеров, но и по темпу бизнеса.
У статьи нет попытки вынести окончательный приговор одной из сторон, и в этом ее сильная сторона. Автор не романтизирует ни ночные дедлайны, ни корпоративную правильность. Его вывод проще и взрослее: хаос может бодрить, но долго на нем не живут; порядок может спасать, но в избытке он превращается в тормоз. Для рынка разработки главный вопрос теперь даже не в том, нужны ли процессы в разработке, а в том, кто в компании умеет вовремя остановиться и не превратить полезную систему в еще один способ отложить работу на потом.