Перевод статьи Никиты Соболева «Building blameless working environment».
Однажды мне случилось работать в одной компании, которая занималась разработкой софта. Это была обычная компания: ничего плохого, но и ничего особо примечательного. Проблемы в ней были те же, что и в других подобных компаниях:
- код низкого качества,
- пропуск дедлайнов,
- превышение бюджета.
И в итоге – недовольные клиенты.
Конечно, все менеджеры хотели бы знать, что (или кто) является причиной такой ситуации. В этой компании было обычным делом услышать что-то вроде «Этот проект провалился, потому что ты написал некачественный код. И теперь клиент от нас ушел».
Это помогало улучшить ситуацию? Нет. Там было приятно работать? Нет. Поэтому однажды я проснулся и решил, что больше не хочу работать в этой компании.
Но хуже всего было то, что я был основателем этой компании.
Давайте просто все договоримся, что обвинение кого-то в ошибках не работает?
Прежде чем пойти дальше и рассказать, как мы сумели изменить наше рабочее окружение и как это на нас повлияло, я хотел бы сказать прямо: возложение вины за что угодно и на кого бы то ни было не работает. Почему?
- Ошибки и проблемы указывают на несовершенные или сломанные процедуры в рабочем процессе компании. Но вместо того чтобы их исправить, люди просто показывают пальцами друг на друга и стараются скрыть проблему. Таким образом она никогда не будет решена.
- Обвинение демотивирует людей. Из-за этого можно потерять лучших инженеров, ведь есть компании, где люди ведут себя по-другому, а мы, инженеры, можем выбирать место работы.
Что мы можем сделать вместо того чтобы обвинять друг друга? Мы можем выстроить наши процедуры иначе!
Не обвиняйте кого-то, а улучшайте свой проект
Представьте ситуацию, когда что-то пошло не так. Например, продакшен перестал работать из-за несоответствия версии зависимости. Или из-за глупой опечатки в вашей переменной string.
Такое случается довольно часто, это не сюрприз.
Поэтому мы должны быть готовы справляться с такими проблемами. Нам нужно создать работающий набор правил и практик, чтобы обходить возможные ошибки и обрабатывать те, которые мы не смогли обнаружить раньше.
Но как?
Маленькие задачи и понятные объемы работы
Большие задачи, занимающие дни или недели, тяжело определять. Объем работ в задачах такого рода неясен, а кроме того, нет четких критериев, по которым определяется, что работа сделана.
Вот как раз в таких случаях и может все пойти не так. Двое разных людей поймут подобную задачу по-разному, и причина этого – ее большой масштаб. Эти люди будут по-разному разбивать проблему на части, а этим частям будут давать разные приоритеты. А в конце будет легко сказать: «Ты плохо работал, ты не выполнил задачу».
Больше того, в подобных случаях сложно делать ревью и контролировать качество кода. Все мы знаем, как тяжело просматривать отрывки кода по тысяче строк и больше.
Я настаиваю на том, что задачи должны быть маленькими (выполнение которых занимает не больше 4 часов) и иметь понятный объем. Лучше иметь пять маленьких понятных задач, чем одну большую.
Такой подход уменьшает возможность недопониманий и позволяет обеим сторонам легко отслеживать прогресс, контролировать дедлайны и чувствовать пульс проекта.
Сделайте вашу непрерывную интеграцию как можно более строгой
Чем быстрее вы найдете ошибки в своем коде, тем лучше для проекта. Этот график показывает, насколько дорого (и по деньгам, и по времени) позволять багам проникать в продакшен.
Плохой код не должен попадать в ветку master и даже к ревьюеру. И ведь это можно автоматизировать! Есть статический анализ, линтинг, различные тесты и показатели соответствия, которые можно применить, прежде чем передавать код дальше. Если что-то не так, то ваш код просто не попадет в ветку master, а коллега не будет делать ревью, пока код не пройдет все проверки успешно.
Таким образом создаются понятные и прозрачные правила относительно качества, которые становятся законом.
Приветствуйте все баги
Но ошибки по-прежнему случаются! Это печальная реальность. Но только от вас зависит, как вы их воспринимаете. Вы можете сердиться или впадать в депрессию из-за этих ошибок, а можете учиться на них.
Я предпочитаю учиться как на своих ошибках, так и на чужих. Как это возможно?
Что бы ни случилось в продакшене плохого, вам нужно отследить, как оно прошло через все ваши кордоны обеспечения качества. Что пропущено?
После того как ваша команда найдет ответ, нужно автоматизировать эту проверку, чтобы подобные случаи не повторялись. Создайте правило линтинга или напишите регрессионный тест. Вот несколько реальных примеров, как это происходит у нас.
Когда в нашем проекте (python/django) случается нечто непредвиденное, мы добавляем новое правило в процесс непрерывной интеграции или пишем новое правило для нашего корпоративного линтера. Таким образом мы можем гарантировать, что подобная ошибка больше не повторится.
То же самое хорошо работает для наших фронтенд-проектов (javascript/vue).
Сделайте вашего клиента частью процесса
Бывают случаи, когда вы теряете клиента не потому что у вас код плохой, а потому что вы не выстроили понятного канала коммуникации с вашим клиентом. А уж потом вас обвинят во всем, что случилось плохого.
У нас раньше было множество проблем с этим. Длительные итерации и длинные циклы обратной связи просто убивали нас. Мы не могли достаточно быстро реагировать на баги и новые требования.
Решение этой проблемы довольно простое:
- Сделайте вашего клиента частью вашего процесса разработки.
- Делайте итерации настолько маленькими, насколько это возможно.
- Как можно чаще демонстрируйте свой прогресс.
Все эти цели у нас достигаются благодаря нескольким полезным подходам:
- Мы приглашаем наших клиентов в репозиторий с первого же дня.
- Микрозадачи дают нам возможность делать по несколько итераций в один день.
- Gitlab и K8S позволяют нам при необходимости сделать демо каждой отдельной фичи.
Мы получаем обратную связь от клиента настолько быстро, насколько это возможно. Клиент всегда понимает, что происходит с проектом: что сделано, а что еще в работе.
При таком подходе обвинять кого-то в неудачах и сложно, и бессмысленно. Сотрудничество позволяет создавать прекрасные продукты, а ведь именно это и является нашей целью.
Заключение
«Не обвинять, а исправлять» – такой подход кардинально изменил нашу работу в лучшую сторону. С тех пор, как мы стали его применять, мы еще не провалили ни одного проекта и не потеряли ни одного инженера из-за конфликтов.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]