Blameless environment или почему нельзя винить людей за плохую работу

Никита Соболев, технический директор wemake.services, назвал свой подход к управлению Blameless environment. Это значит, что он никогда ни в чём не винит людей. Никита уверен: если баг попал в ваш проект, это проблема проекта. Этот баг должен быть поправлен так, чтобы он больше никогда не случился.

О принципах Blameless environment Никита рассказал на одной из конференций Онтико. Такой подход позволяет его компании делать качественный продукт для своих клиентов и не отвлекаться на танцы с HR-бубнами (долгий найм, мотивация, профилактика выгорания, вот это вот всё).

В компании wemake.services полная свобода действий: хочешь — работаешь, не хочешь — не работаешь. Чтобы уйти в отпуск или устроить себе выходной, не нужно ничего согласовывать и составлять графики. Человек просто нажимает кнопку «не работаю» и не работает. Конечно, заработать деньги можно только выполняя задачи, которые раздаёт бот.

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

Часто общение мешает работе. Мы все общаемся с коллегами на нерабочие темы (обсуждаем сериалы и пр.), потому что мы — люди. Этот недостаток, к счастью, исправим. Для того чтобы понять, насколько на самом деле общение губительно для нас, можно посмотреть на разные примеры.

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

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

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

Чтобы структурировать общение, достаточно сделать два шага:

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

В wemake.services выбрали общение через GitLab. Если возник вопрос, задай его в GitLab. Если хочешь задать какой-нибудь странный вопрос, задай его там. Если поймёшь, что нет места, где можно задать такой вопрос, возможно, его и не надо задавать.

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

Структурированное общение делает разных людей одинаковыми. У GitLab даже аватарки все примерно одинаковые — у одного буква K, у другого C. А кто там скрывается за этими буквами для рабочего процесса не важно.

Если есть кто-то самый главный, то получится не свобода, а ерунда. Поэтому в wemake.services есть бот, чтобы править всеми. Он распределяет задачи между разработчиками и «пинает» тех, кто не завершает задачу в срок. Бот выложен в open source, любой желающий может использовать его в своём проекте или компании.

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

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

Задачи должны быть короткие. Не в плане описания, как «поправить баг на проде», но короткие по своей сути. Короткие, маленькие задачи удобно делать. Они понятны любому: новичку, среднему, опытному разработчику. Каждый может понять такую задачу и сделать, например, за половину рабочего дня.

Задачи должны быть упорядоченные. Когда ставят задачи, часто не думают, в каком порядке их нужно сделать. Но задачи могут блокировать друг друга, параллелиться или добавлять дополнительную сложность другим задачам, если выполнены вперед, и т.д. Про упорядоченность задач говорят очень мало: заносят их в Jira или Trello, а потом берут оттуда. Но немногие задумываются, а в каком порядке, почему и зачем порядок именно такой.

Все задачи должны быть индивидуальными. Что это значит? Задачи – это сущности, которые существуют в рамках проекта и всегда кому-то принадлежат. Иногда прямо в описании задачи можно встретить: «Сергей, Маша, пожалуйста, поправьте это. Вы знаете, как это сделать». Так делать нельзя, нужно дать весь контекст, чтобы эта задача стала индивидуальной внутри себя, чтобы любой человек, который её прочитал, мог её выполнить. Чтобы не было никаких разрозненных знаний, разбросанных по проекту, и не было никаких скрытых смыслов в рамках этой задачи.

В целом такой подход называется Domain-Driven Design и успешно применяется на протяжении многих лет. Задача оказалась очень непростой, и Никита до сих пор работает над её решением. Но он выработал простую формулу.

Требования. С них все начинается, заказчик изъявляет свою волю разработчикам, в виде требований. Клиент условно говорит: «Требую, чтобы страница логина работала». Начинается осознание, расписывание в виде таблиц, списков, графиков и т.д. Требования остаются как самая главная часть проекта. Это то, что ты делаешь на самом высоком уровне.

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

Документация и требования – это близнецы-братья, это двуединство. Требования – это ЧТО нужно сделать, а документация – КАК это делать. Когда Никита понял, что из требований можно генерировать документацию, это стало важной частью бизнес-процесса в его компании. Требования стали записываться в специальном формате и сразу формироваться в документацию.

Тесты. Следующий логичный шаг — проверить, что это работает. В wemake.services стали тестировать требования, чтобы убедиться, что делают действительно то, что нужно.

Когда работаешь с разработчиками — пишешь требования как код, документацию как код, всё как код — понимаешь, что всё код. Так можно сделать очень и очень многое, потому что код можно проверять, тестировать, отслеживать его изменения во времени и т.д. Код един!

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

Как только в wemake.services объединили разработчиков и заказчика, удалось добиться очень важного: разработчики наконец-то стали делать то, что нужно бизнесу. Они перестали внедрять что-то просто так, потому что видели требования и понимали их, понимали, что нужно сделать.

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

Естественно, любое действие в проекте проверяется. Разработчик создал тикет или провел код-ревью, дальше идёт проверка — насколько хорошо он это сделал. Всё проверяется для того, чтобы люди давали качественный результат.

В разработке есть такое понятие — CI, Continuous Integration — если коротко, то это workflow, куда стягиваются куски кода от разработчиков для автоматической проверки. Если что-то не так, система оповестит об этом всех заинтересованных лиц.

В «wemake.services» CI и тесты максимально строги к тому, что делают разработчики. Это должен быть ультимативный суд — инструмент, который ответит на вопрос, хороший код или плохой. Такой CI, естественно, должен быть неотвратим. Неотвратимый и строгий CI дает несколько классных возможностей. Это возможность развиваться, потому что теперь есть базовая планка, от которой можно отталкиваться: каждый следующий кусочек кода лучше предыдущего. Каждый следующий кусочек кода повышает ценность проекта и улучшает CI. Каждый следующий кусочек кода — шаг в сторону развития.

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

Что можно с этим сделать? Можно вернуться к обычной тактике и говорить: «Ты сделал ошибку, исправь ее. Ты написал плохой код — иди научись писать код». Это плохой путь, который не ведет к развитию.

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

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

В wemake.services самым главным даром считаются баги. В каждом продукте есть баги. Но почему-то в нашей данности баг – это плохо. Человек, который сообщил о баге, если он не тестировщик, слышит: «Что ты делаешь? Ты срываешь сроки. Мы же фичи должны делать, а ты какие-то баги находишь». Предъявлять баг — значит говорить, что что-то не работает, что-то плохо. Но на самом деле все наоборот.

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

В wemake.services не платят зарплаты. Но это не значит, что компания не платит разработчикам в принципе. Да, есть люди, которые работали с wemake.services и ничего не заработали, потому что ничего не сделали, не выдали результат.

В wemake.services платят только за результат. Так как задачки маленькие, понятные, то каждой из них можно определить цену. Человек выполняет задачу и получает за это деньги. Причём, платят не только за написание кода, но за тикеты и ревью. Потому что это тоже большая работа: вникнуть, посмотреть, что сделано, рассказать другому, в чем он не прав.

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

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

Эту систему можно исправить, и сделать это несложно. Вы можете взять все те же инструменты, поставить их и работать. Они все в open source, поэтому вы легко можете начать делать так же.