Об ответственности разработчика: когда серверы падают, а виноватых нет

Вечер вторника. Я сижу за ноутбуком и чиню сервер. Планы были другие: написать пост, разобрать задачи на неделю, может даже прогуляться. Но коллега решил, что «делаем» значит «делаем прямо сейчас», произвёл часть работ на сервере и попросил меня проверить. Проверяю, а ничего не работает. Запрашиваю доработки, а в ответ: «Всё, я на сегодня закончил, остальное завтра». И вот я сижу один с неработающим функционалом, и ответственность за это почему-то на мне.

Как я вообще тут оказался? И ответственность эту я же взял на себя сам. Потому что не мог оставить сервер в нерабочем состоянии. Потому что «ну кто-то же должен». Знакомо?

Эта ситуация заставила меня серьёзно задуматься. А потом я прочитал пост Вани Замесина про радикальную ответственность, и мысли закрутились ещё сильнее. Из этих двух точек, из поломанного сервера и философского эссе, родился текст, который вы сейчас читаете. Эту мысль я продолжаю в статье карьерный путь.

Главное

Ответственность нельзя передать, если её не берут. Это не посылка, а осознанный выбор.

Радикальная ответственность «за всё» звучит красиво, но на практике приводит к выгоранию без полномочий.

Разделение ответственности в команде требует явных договорённостей, а не молчаливых ожиданий.

Принять ответственность за прошлые решения, это не про вину, а про точку, из которой двигаешься дальше.

Почему ответственность нельзя передать насильно?

Команды с чётко определёнными зонами ответственности показывают на 30% меньше незапланированных простоев, согласно отчёту DORA (State of DevOps Report, Google, 2023). Ответственность, это не задача в трекере, которую можно переназначить одним кликом. Это осознанный выбор, который человек делает сам.

В той ситуации с сервером я это прочувствовал буквально. Коллега не брал на себя ответственность за результат. Он сделал свою часть и ушёл. А я не мог уйти, потому что знал: если функционал не работает утром, это будет проблема. Моя проблема.

Но вот в чём штука. Никто не заставлял меня чинить этот сервер вечером. Я мог написать в чат «разберёмся завтра» и закрыть ноутбук. Но не смог. И это важное наблюдение: ответственность часто не назначается извне. Мы сами её подбираем, потому что не можем иначе.

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

Что такое «радикальная ответственность» и стоит ли в неё верить?

Согласно опросу Gallup (State of the Global Workplace, 2023), только 23% сотрудников по всему миру чувствуют вовлечённость в работу, что напрямую связано с ощущением контроля и ответственности за результат. Ваня Замесин продвигает идею: ты ответствен за всё, что с тобой происходит. Звучит мощно. Но я не уверен, что это работает буквально.

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

Я несколько лет работаю над тем, чтобы сменить фокус. Перестать обвинять обстоятельства и других людей. Перестать говорить «ну а что я мог сделать». И у меня есть реальные успехи в этом. Но радикальный подход выбил меня из колеи.

Потому что есть разница между «я отвечаю за свои решения» и «я отвечаю за всё». Первое помогает расти. Второе может раздавить. Особенно когда ты разработчик в команде, где решения принимаются коллективно, а последствия почему-то прилетают одному.

Где заканчивается моя ответственность и начинается чужая?

Исследование Harvard Business Review (The Overcommitted Organization, 2022) показало, что 73% руководителей команд отмечают проблемы с чётким разграничением зон ответственности. Это один из самых сложных вопросов в любой команде. И универсального рецепта не существует.

В разработке мы постоянно работаем на стыках. Бэкенд и фронтенд. Разработка и эксплуатация. Код и бизнес-процесс. Кто отвечает за то, что пользователь не может оформить заказ? Разработчик, который написал код? Аналитик, который поставил задачу? Менеджер, который не проверил? Или тестировщик, который пропустил баг?

Правильный ответ, конечно, «все вместе». Но «все вместе» на практике часто означает «никто конкретно». И тогда ответственность подбирает тот, кому не всё равно. Тот самый разработчик, который сидит вечером и чинит сервер.

Проблема молчаливых договорённостей

В той истории с сервером мы не договорились о конкретном времени. «Делаем?» - «Делаем». Без привязки ко времени, без распределения ролей, без плана отката. И когда что-то пошло не так, оказалось, что у каждого своё понимание «делаем».

По данным исследования Project Management Institute (Pulse of the Profession, 2023), 37% проектов проваливаются из-за нечётко определённых целей и ролей. В масштабе проектов это звучит как статистика. В масштабе одного вечера, это мой потерянный вечер. Подробнее об этом писал в статье первый сложный проект.

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

Ответственность и вина, это одно и то же?

Нет. И это, пожалуй, самая важная мысль в этом тексте. Согласно мета-анализу в журнале Psychological Bulletin (Guilt and Shame Proneness, Tangney et al., 2007), склонность к чувству вины коррелирует с конструктивным поведением, а склонность к стыду, наоборот, с избеганием ответственности.

Когда я сижу вечером и чиню сервер, я не виноват. Я сделал выбор. Можно было не делать, и тогда утром была бы проблема. Но я выбрал починить. Это ответственность без вины.

А вот когда разработчик допустил ошибку в проде и начинает себя грызть, это уже вина. И она не помогает. Она парализует. Ты не можешь нормально думать, когда внутренний голос говорит «ты облажался».

Замесин прав в одном: сожаление о прошлом не меняет настоящего. Но полностью выключить эмоции тоже не получится. Мы не роботы. И мне кажется, что здоровый путь, это не радикальная ответственность и не полное избегание. Это принятие. Принять, что ты находишься в этой точке. Что твои решения привели тебя сюда. И что отсюда можно двигаться дальше.

Принятие себя как основа ответственности

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

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

Как выглядит здоровая ответственность в IT-команде?

По данным отчёта Atlassian (The State of Teams, 2023), команды с явно описанными ролями и зонами ответственности на 25% продуктивнее тех, где роли размыты. Здоровая ответственность, это не героизм одиночки. Это система, в которой каждый знает свой участок.

Вот что, на мой взгляд, работает:

Явные договорённости вместо «ну ты же понимаешь». Если не проговорили, значит, не договорились.
Право на ошибку. Если команда наказывает за ошибки, люди начинают прятать проблемы вместо того, чтобы их решать.
Полномочия вместе с ответственностью. Нет смысла отвечать за результат, если ты не можешь влиять на процесс.
Ретроспективы без обвинений. Разбор ситуации «что пошло не так и как это предотвратить», а не «кто виноват».

На своём опыте я видел обе крайности. Команды, где никто ни за что не отвечал, и ничего не двигалось. И команды, где один человек тащил всё на себе и в итоге выгорал. Ни то, ни другое не работает.

Эту мысль я продолжаю в статье критическое мышление.

Можно ли научиться ответственности?

По результатам исследования Center for Creative Leadership (Leadership Development, 2022), 85% управленческих навыков, включая принятие ответственности, формируются через практический опыт, а не через теорию. Ответственность, это мышца. Она тренируется через действия, не через книги.

Я несколько лет осознанно работаю над этим. Начинал с простого: перестал говорить «мне не повезло» и начал говорить «я выбрал». Перестал обвинять обстоятельства. Но это не линейный процесс. Бывают откаты. Бывают моменты, когда хочется сказать «ну это же не я».

Вот несколько вещей, которые мне помогли:

Задавать себе вопрос «Что я мог сделать иначе?» после каждой неудачи. Не чтобы себя наказать, а чтобы найти точку роста.
Отделять зону контроля от зоны влияния. Я не могу контролировать поведение коллег. Но могу влиять на процесс коммуникации.
Прощать себя за ошибки. Серьёзно. Без этого ответственность превращается в самобичевание.
Фиксировать договорённости письменно. Это не бюрократия, а забота о будущем себе.

А что, если бы в той ситуации с сервером я не починил его? Утром была бы проблема, разбор полётов, может даже конфликт. Но, возможно, это привело бы к более чёткому разделению ответственности в будущем. Иногда не подбирать чужую ответственность, это тоже ответственный выбор.

Ответственность за пределами работы

Согласно исследованию American Psychological Association (Stress in America, 2023), 76% работников в IT-сфере испытывают стресс, связанный с размытыми границами между работой и личной жизнью. Тема ответственности шире, чем просто код и серверы. Она про то, как ты строишь свою жизнь в целом.

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

И это одновременно прекрасно и пугающе. Прекрасно, потому что ты сам формируешь свой день. Пугающе, потому что если что-то идёт не так, обвинить некого. Нет начальника, который поставил нереалистичный дедлайн. Нет компании, которая не дала ресурсов. Есть только ты и твои решения.

Пожалуй, в этом и заключается настоящая ответственность разработчика. Не в том, чтобы чинить серверы по вечерам. И не в радикальном принятии вины за всё на свете. А в честном признании: я здесь, потому что я так выбрал. И отсюда я могу выбрать, куда двигаться дальше.

Часто задаваемые вопросы

Как не брать на себя чужую ответственность в IT?

Главное правило: если нет явной договорённости, нет и обязательства. По данным PMI (2023), 37% проектов проваливаются из-за нечёткого распределения ролей. Фиксируйте договорённости письменно, проговаривайте зоны ответственности до начала работ и учитесь говорить «нет» без чувства вины.

Чем ответственность отличается от вины?

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

Как развивать культуру ответственности в команде?

Начните с безопасности. Команда берёт ответственность, когда знает, что за ошибку не накажут. Atlassian (2023) зафиксировал, что команды с явными ролями на 25% продуктивнее. Проводите ретроспективы без обвинений и убедитесь, что полномочия соответствуют обязанностям.

Работает ли концепция радикальной ответственности?

Частично. Идея «ты отвечаешь за всё, что с тобой происходит» помогает перестать обвинять внешние обстоятельства. Но в буквальном виде она может привести к выгоранию. Здоровый подход, это разделять зону контроля и зону влияния и нести ответственность только за то, на что можешь воздействовать.

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

Я не знаю идеальных ответов. Но знаю одно: тот вечер с сервером научил меня большему, чем любая статья про ownership и accountability. Иногда нужно прожить ситуацию, чтобы понять, какая ответственность твоя, а какую ты просто подобрал с пола, потому что больше некому. Если хочется больше практики, посмотри статью наставничество.