Программисту: как правильно косячить

“Брать ответственность” не то же самое, что “брать на себя вину”.

В разработке взять ответственность за результат значит:

• сделать задачу
• помочь исправить последствия, если что-то пошло не так
• сделать так, чтобы проблема больше не повторялась

Ответственность и Вина

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

Клиент в ярости. Требует разобраться.

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

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

Если в проектной команде менеджер ищет крайнего, то разрабочики начинают обсуждение плана с предъяв:

• к аналитикам — “в требованиях ничего не было сказано про счета не в рублях. Это работа аналитиков предусматривать такое”
• к QA — “тестировщики должны были проверить на данных из продакшена"
• к проектному менеджеру — “как это менеджер не в курсе бизнес планов клиента?”
• к клиенту — “а чё это он нас не предупредил?”
• к техподдержке — “ну как они могли не заметить проблемы? Они же проверяют систему после доставки”
• сразу на всех кроме себя — “я же говорил! Я так и знал!”

Пока ищут крайнего брокер теряет клиентов и репутацию — проблема-то не исправляется. Поиск виноватого не дает никакой пользы кроме самоутверждения.

В слаженных командах обсуждение проблемы начинается с принятия ответственности:

• “это обычный рабочий момент. Неприятно, но мы спокойно найдем решение, исправим последствия, поймем, как избегать подобных проблем в будущем”:
• “а у нас есть бэкап? он старый. Тогда со стороны разработки мы можем попробовать по логам восстановить данные. Риски такие, займет вот столько”
• Когда счета трейдеров восстановлены: “Со стороны разработки, мы могли бы избегать последствий, если бы у нас была информация о переменах в бизнесе брокера. Как мы можем получать такие обновления?
  Пока мы можем добавить данные в мониторинг и заранее узнавать о некоторых изменениях.”

Зачем вообще брать на себя ответственность?

• То, за что ты отвечаешь — это и есть карьерный рост.

Например, для junior разработчика нормально отвечать за качество только своего кода. Если этот код сломает продакшн, то последствия будут исправлять более опытные разработчики.

Тимлид исправляет последствия всех проблем от решений команды, делает так чтобы проблемы больше не повторялись.

• Участие в решении проблем дает возможность сделать комфортные условия работы под себя.

Если от аналитиков приходят непонятные задачи, то можно взять на себя ответственность за контроль описания задач и предложить структуру, которая тебе удобна.

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

Значит вообще за все нужно брать ответственность?

Нет. Только за то, что ты можешь исправить, улучшить, сделать достаточно хорошо.

Точно не стоит указывать коллегам как им работать, если вы не их руководитель. Иначе все скатывается к поиску виноватого.

Лучше смотреть именно на свой участок работы и ответить на вопрос “что именно мы можем сделать чтобы улучшить качество работы?”.