Представьте, что ваше веб-приложение падает посреди ночи. Сейчас 2 часа ночи, но ваш бизнес глобальный. У вас есть пользователи в всех часовых поясах. Они злы. Они не могут покупать вещи на вашем веб-сайте или отменяют свои подписки. Деньги теряются каждую минуту, когда ваше веб-приложение не работает.
Внезапно один из ваших разработчиков оказался в деле! Этот разработчик немного беспокоится и много ругается (в конце концов, сейчас 2 часа ночи), но в конце концов проблемы решаются. Приложение снова работает, и деньги текут в ваш бизнес. Несмотря на то, что подобные ситуации случаются время от времени, вы утешаетесь, зная, что у вас всегда есть этот разработчик, чтобы спасти положение. Этот разработчик — ваш герой.
Однако никто в этой ситуации не должен чувствовать себя комфортно. Это чрезвычайно рискованная позиция для компании. Это негативно влияет на всех, кто работает в этой компании. И, несмотря на огромное чувство важности, это вредит и разработчику героя.
Начнем с проблем компании. Если существуют известные проблемы со стабильностью при работающем приложении, их следует устранить. Антикризисное управление почти никогда не решает глубинные проблемы. Антикризисное управление заключается в том, чтобы пережить еще один день. «Исправления» временные. Существует еще реальная проблема, которая должна быть исправлена.
Если вас утешает присутствие героя на вызове, эти реальные проблемы кажутся менее важными, чем они есть на самом деле. Существует сильное искушение отложить решение этих проблем в пользу работы над новыми видами деятельности, приносящими доход.
Но антикризисное управление — это не то же самое, что предотвращение кризисов.
Приложение, которое часто выходит из строя, зарабатывает плохую репутацию среди пользователей. Это затрудняет удержание и, в конечном итоге, затрудняет привлечение новых пользователей. Существует также возможность, когда герой недоступен. Это может произойти разными способами. А если они заболеют? Или родственник заболел? Или они едут в отпуск? Или они просто решили, что устали, и ушли?
Во всех этих случаях ваше приложение теперь не работает гораздо дольше (часы вместо минут или дни вместо часов). Вы можете возразить, что кто-то еще в команде может взять на себя мантию героя. Это приводит нас к проблемам для всех остальных в команде.
Что бы вы сделали, если бы на вашей работе случился кризис, и вы ничего не могли бы с этим поделать?
У тех, кто в этой ситуации, может возникнуть чувство беспомощности. Это может подорвать доверие человека, что часто влияет на производительность труда. Люди также могут попросить героя научить их решать проблемы, но почему компания должна отдавать приоритет этому обучению, если она не ставит во главу угла решение реальных проблем?
Что еще более важно, люди также могут положиться на героя. Они решают, что их бункер — это их собственная работа, а герой — это тот, кто справляется с кризисами. Им не нужно учиться помогать.
Это опасное отношение для разработчиков. Лучший способ предотвратить кризисы или, по крайней мере, сделать их более управляемыми — создать программное обеспечение, которое упрощает предотвращение кризисов или управление ими. Как разработчик может знать, как правильно учитывать кризис, если он не был в нем?
Они не могут.
Даже если герой объяснит технические детали после разрешения кризиса, важные детали будут упущены. Самый важный из них — эмоциональное состояние, в котором находился герой после пробуждения в 2 часа ночи в ответ на кризис.
Разработчики ежедневно принимают десятки крошечных решений в своем коде. Многие из этих решений могут сэкономить драгоценные минуты, если не часы, в условиях кризиса. Тот, кто просто слышит о чем-то, что поможет в кризисной ситуации, не будет по-настоящему понимать его важность, как тот, кто испытывает на себе последствия плохого решения во время кризиса.
Например: многие разработчики, которые не сталкивались с кризисом, будут писать плохие сообщения об ошибках. Их код изобилует сообщениями вроде «Произошла ошибка». Где произошла ошибка? Для кого это произошло? Даже такая мелочь, как «Произошла ошибка для пользователя 123 по адресу /home», имеет огромное значение. Но тот, кому никогда не приходилось решать критические проблемы, не поймет, насколько это важно. Они бы никогда не ощутили эмоционального воздействия этих, казалось бы, небольших изменений в своем коде.
Написание кода, который хорошо справляется с кризисом, является важным навыком для разработчиков. Когда разработчики полагаются на героя для разрешения кризисов, они лишают себя возможности развить навыки написания лучшего кода. Это повлияет на компанию в краткосрочной перспективе и на карьеру разработчиков в долгосрочной.
Наконец, есть вопросы к герою. Наличие навыков, позволяющих спасти положение, делает героя в некотором роде ценным. Но при переходе от кризиса к кризису герой будет развивать только умение разрешать кризисы. Герой не будет развивать свою способность предотвращать кризисы. Если компания не может сделать предотвращение кризисов приоритетом, у героя не будет времени заниматься предотвращением кризисов. Это влияет на карьеру героя, потому что их ценность привязана к одной компании. Они имеют меньшую ценность для другой компании, что влияет на их способность двигаться дальше, если они обнаружат, что недовольны.
И они будут недовольны.
Быть героем имеет ряд проблем с качеством жизни. Хотите взять отпуск? Конечно, но всегда держите наготове дежурный телефон и будьте готовы достать ноутбук в любой момент. Хотите построить что-то новое и интересное? Конечно, но делайте это в промежутках между кризисами. Хотите составить планы ужина с друзьями или пойти на свидание? Конечно, но будьте готовы отменить. На всякий случай.
Я был и героем, и разработчиком, который полагался на героя, чтобы спасти положение. Я могу честно сказать, что хуже быть героем. Похвала и адреналин поначалу могут быть приятными, но это не длится долго. В конце концов, есть только истощение, покорность и гнев.
"Как это могло снова сломаться?!"
Разрешение кризисов без предотвращения кризисов имеет убывающую отдачу от роста как разработчика. В конце концов, вы просто раз за разом решаете один и тот же кризис. В этом нет никакого обучения. Я также оказался в ситуации, когда мне нуждался кризис, хотя я его ненавидел. Я так привык их решать, что не знал, как действовать, когда не было кризиса. Как можно работать без перерыва? Так странно!
Итак, как мы можем избавиться от культуры разработчиков героев?
Идея проста, хотя реализовать ее может быть непросто. Относитесь к мысли о герое так же серьезно, как к кризису. Когда случится кризис, разрешите его. Но также сделайте хотя бы один шаг, чтобы предотвратить повторение чего-то подобного. Это не гарантия предотвращения, но медленный прогресс — это все же прогресс. В конце концов вы доберетесь туда.
Также уделите первостепенное внимание обучению остальных членов команды. Вовлекайте в каждый кризис несколько человек. Может быть, это просто исследование вопроса параллельно с героем. Может быть, это прямое соединение с героем. Но привлекать их. Все лучше учатся, делая. Это может показаться потраченным впустую временем, поскольку герой может делать все быстрее, но наличие нескольких человек, способных разрешать будущие кризисы, стоит этих затрат.
Ни один из этих шагов не является легким. Когда у вас чрезвычайная ситуация, никогда не бывает легко думать о долгосрочной перспективе. Но по всем причинам, изложенным выше, это важные шаги, которые необходимо предпринять, потому что они предотвращают порочный круг, когда только один герой решает кризисы, потому что герой — единственный, кто когда-либо разрешал кризис. Это стоит затрат.
Первоначально опубликовано на https://blog.professorbeekums.com.
