У вас случаются встречи, на которых 10 или более человек никак не могут договориться? Такое может быть и с архитектурными, и дизайн-решениями, и  процессами. В Dodo такое случалось. Это было мучительно больно и выматывающе, поэтому хочу поднять тему решительности или «куража», как это называется в экстремальном программировании.

Почему я? Когда-то давно, когда я ещё не была техлидом, я заметила, что у нас есть проблема с глобальными процессами. От этого страдали все, и я в том числе. В конце концов страдать мне надоело, поэтому я решилась изменить что-то хотя бы в собственной команде. И мне это удалось. Хочу поделиться опытом и рассказать о одном принципе, который помог мне тогда и помогает по сей день.

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

Кто делает, тот несёт ответственность

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

Расскажу историю. Давным-давно мы делали сайт. Архитектор придумал, как его делать, и попытался нам передать свою мысль. Мы поняли и пошли пилить. В итоге, несмотря на все объяснения архитектора, его задумка сильно разошлась с тем, что мы сделали.

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

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

Я считаю, что принятие решения кем-то другим — не тем, кто делает — это самообман! И эта мысль придаёт мне решительности.

Кто несёт ответственность, тот имеет право принимать решение

С кодом более-менее понятно. Вы пишете код, поэтому вы отвечаете за дизайн решения. Но есть истории посложнее. Как, например, эта история про саппорт.

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

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

Ребята подняли этот вопрос. И не просто подняли, а создали процесс SLA по багам. Очевидно, что мы не хотели, чтобы наш продукт свалился в «пропасть баганутости» так, чтобы им невозможно было бы пользоваться. Тогда давайте научимся оценивать баги и установим суммарный порог по количеству багам, за который мы не скатываемся! А в случае, если мы до него доходим, то останавливаем разработку. Потому что если продукт настолько «баганутый», то от добавления ещё одной фичи пользователям лучше не будет. Им бы лучше, чтобы продукт работал без глюков. Для принятия порога по багам на все команды достаточно команды саппорта плюс CPO или CTO в качестве верифицирующего органа. И не нужны совещания с миллионами апрувов.

Если сформулировать это кратко: я принимаю ответственность за то, что делаю, это даёт мне право на принятие решений.

Если хочу сказать «нет» — говорю

Алгоритм действий такой:

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

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

• Если и это не помогло, то возникает два вопроса. Какие последствия могут быть в случае факапа? Кто будет разгребать проблемы и насколько это будет болезненным?

  • Если последствия не велики или разгребать их будет, тот кто давит, тогда можно провернуть disagree and commitment: сделать так, как просят, но за результат целиком и полностью отвечает тот, кто настаивает. И обязательно проговорить или даже прописать, что разгребать последствия будет тот, чья идея.

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

Пример: приближаются новогодние праздники и продакт-оунер решает, что срочно нужно сделать и выкатить фичу, работы на 15 минут. Команда на PBR понимает, что фича не так проста, как кажется, и что её реально зарелизить только ближе к 30 декабря. Кроме того, зафичатоглить её полностью не получится. Команда принимает решение сказать продакту «нет». Аргументация звучит так: после релиза фичи на продакшене вполне могут всплыть баги или проблемы с нагрузкой, какой бы замечательный регресс мы не провели. Релизить что-то под занавес мы не будем: во-первых, в такое пиковое время можно получить кучу негатива от клиентов, а во-вторых, в новогодние праздники у всей команды не рабочее время и дожидаться исправлений пользователи будут долго. 

Да, работодатель или лидер могут быть не готовы отдавать принятие решений своим сотрудникам. В таком случае остаётся либо смириться с ситуацией, либо принять, что жизнь слишком коротка, чтобы отдуваться за промахи и косяки других людей. Победы тут тоже ощущаются не совсем своими, потому что за вас ключевые решения принимает кто-то другой. Решительность и смелость здесь будут в том, чтобы уйти. В возможности ощутить результат своим, плохой он или хороший, заключается огромная ценность. У каждого есть право на самореализацию через работу, на которой вы проводите 40 из 112 часов своего бодрствования в неделю.

В целом, у меня всё.

В этой статье остаётся нераскрытым:

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

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

• как принимать рискованные решения, когда это правда необходимо;

• решительность в условиях социального неодобрения.

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

Мысль «тот, кто делает, тот и решает», определённо сделала мою жизнь проще. Эта фраза хороша в своей краткости. Это принцип. Она легко всплывает в голове в нужный момент, и это влияет на то, что я делаю и говорю после того, как о ней вспомнила. 

Надеюсь, эти мысли и вашу жизнь сделают проще:

• Кто делает, тот и принимает решение.

• Принятие ответственности даёт право принимать решения.

• Если на вас давят, помните: вы можете сказать «нет».

• Бегите от гиперконтролирующих лидеров.