Как страх ошибок убивает мотивацию разработчиков и что с этим делать

Страх ошибок превращает релизы в стресс, разработчики перепроверяют код по сто раз и боятся экспериментировать. Долгие циклы выпуска и культура поиска виноватых убивают инициативу и заставляют лучших сотрудников уходить. Алексей Флоринский, генеральный директор SimbirSoft,  предлагает четыре инструмента, которые возвращают командам спокойствие и скорость.

Представьте, что команда активно пишет код, но релизы выходят раз в месяц, а то и реже. Потому что все боятся что-то сломать. Каждый выход на продакшен (рабочая версия, которая доступна конечным пользователям) воспринимается как прыжок с парашютом. Разработчики перепроверяют код по сто раз, боятся экспериментировать и предлагать новое.

Когда я спрашиваю, почему так происходит, слышу одно: «А вдруг упадет?» или «А вдруг я что-то сломаю, и меня уволят?»

Страх — плохой мотиватор. Он убивает инициативу и желание что-то менять. Вместо развития получается паническое топтание на месте, постоянный стресс и нарастающая усталость. Именно под давлением таких ощущений лучшие сотрудники уходят в другие компании, где можно работать спокойно.

Как страх выглядит на практике

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

Все выдыхают: «Пронесло». Но вместо чувства победы приходит опустошенность. И это повторяется из релиза в релиз.

Через несколько таких циклов команда окончательно перестает верить в свои силы. Новые идеи не рождаются, да их даже и не предлагают. Зачем, если все равно не прокатит?

Ситуация усугубляется, когда в компании нет культуры работы с ошибками. Если после каждого инцидента ищут виноватого, а не разбирают причины, страх становится хроническим. Разработчик перестает рисковать, даже когда риск оправдан.

Почему страх возникает

Причин несколько.

Первая — опасение «положить продакшн». Ошибка может стоить денег, репутации и времени. В больших компаниях, где последствия могут быть катастрофическими, бояться начинают все — от джунов (начинающих специалистов) до архитекторов.

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

Третья — культура долгих релизов. Если выпускаете код раз в месяц, каждый релиз становится событием. Всех трясет: «А вдруг мы что-то не учли?» Страх накапливается, и выход на продакшен превращается в игру на выживание.

Что с этим делать: четыре инструмента

Изменить ситуацию можно. Для этого есть конкретные инструменты, которые работают на практике.

1. Feature flags (шлюзы функциональности)

Это способ включать новую функцию не для всех сразу, а постепенно. Код уже в продакшене, но функция скрыта за выключателем. Вы можете включить ее для 5% пользователей, посмотреть на результат, потом — для 20%, ну а потом — для всех. Если что-то пошло не так — мгновенно откатываете, не перевыпуская код.

Флаги позволяют снизить страх перед релизом: вы не боитесь, что новая функция упадет у всех сразу. Вы всегда можете откатить изменение за секунды, не дожидаясь следующего релиза.

2. Error Budget (бюджет ошибок)

Это договоренность между командой и бизнесом о том, сколько ошибок можно себе позволить. Например, система должна работать с доступностью 99,9% в месяц. Это значит, что 0,1% времени (около 43 минут) можно потратить на ошибки и восстановление.

Когда у вас есть такой бюджет, страх ошибок снижается. Вы знаете, что упасть можно, если не выходить за рамки бюджета. Этот подход помогает командам договариваться о допустимом уровне ошибок и не бояться каждого сбоя.

3. Blameless Post-Mortem (разбор ошибок без наказаний)

После любого инцидента команда разбирает, что произошло. Главное правило — искать слабые места в процессах, а не виноватых. Если ошибка случилась, значит, что-то в системе позволяет ей происходить.

Самый ценный результат здесь в том, что люди перестают скрывать ошибки. Они знают, что, если сообщат о проблеме, их не накажут. Это значит, что проблемы решаются быстрее.

4. Автоматизация проверок

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

В одном из проектов было 700 ручных проверок, которые занимали 30–32 часа. После автоматизации 75% из них время сократилось до 12 часов. Экономия времени сотрудников составила более 50%, скорость обнаружения дефектов выросла более чем в 2 раза. Автоматизация не просто ускорила процесс, она снизила риск системных ошибок, потому что рутинные проверки теперь выполняются программой, а не человеком, который может устать или отвлечься.

Пример из практики

Мы работали с командой, где релизы выходили раз в месяц. Каждый релиз был стрессом. Дедлайн переносился три-четыре раза. За день до релиза все сидели до ночи, правили баги, которые всплыли на финальном тестировании.

Перешли на еженедельные релизы. Сначала было страшно, но потом команда привыкла. Каждый релиз стал меньше по объему, ошибки было проще отслеживать. Если что-то падало — сразу видели, что именно, и быстро чинили.

Через три месяца страх ушел, команда стала работать быстрее, а дедлайны пришли в норму. Люди перестали бояться ошибиться, потому что каждая ошибка теперь из катастрофы превратилась просто в задачу, которую нужно починить в следующем релизе.

В заключение

Страх ошибок и долгие релизы — это звенья одной цепи. Изменить это можно, только работая над всей системой: культурой, процессами, отношением к ошибкам.

Бюджет ошибок, шлюзы функциональности и разбор ошибок без наказаний — это не пустая теория, это инструменты, которые работают на практике.