Началось все с устройства на новую работу. Новый проект казался интересным, коллеги – доброжелательными, так что я с радостью принял оффер. Первое время я только погружался в проект, разбирался с его особенностями и особо ничего не критиковал. Все-таки я тут новичок, ещё не в курсе всей ситуации, и вообще, в чужой монастырь со своим уставом не лезут.
Однако по окончании испытательного срока я уже понял, что в команде я остаюсь, а значит было бы неплохо влиять на будущее проекта и активнее выражать свое мнение, даже если оно кажется непопулярным. Проект уже разрабатывался долгое время, в нем накопилось немало технического долга, который меня сильно расстраивал. Я пытался его постепенно разбирать, работая по скаутскому принципу – оставлять поляну (в данном случае код) чище, чем она была до моего прихода. Однако, этого было мало, нужно было склонить к этому и остальных коллег тоже, чтобы пока я улучшал в одном месте, они не накапливали долг в другом.
Я начал активно бороться за чистоту кода на код-ревью. Я регулярно смотрел что делают коллеги и предлагал улучшения. Коллеги не всегда с ними соглашались, однако я не сдавался и настаивал на изменениях, потому что был на сто процентов уверен, что для проекта так будет лучше. Порой споры принимали ожесточенный характер, но мне это тоже казалось нормальным, ведь именно в споре рождается истина.
Также я регулярно поднимал эту тему на ретроспективах и планированиях спринтов. Мне казалось очень важным обратить внимание коллег на эту ситуацию, и я сильно удивлялся апатии с их стороны. Ситуация дошла до крайней точки, когда на очередной 1-на-1 встрече со своим руководителем я рассказал ему, что сомневаюсь в профессиональных качествах коллег, что они не замечают очевидных вещей и так продолжаться дальше не может. Руководитель согласился, что надо что-то менять, но только совсем в другую сторону. Оказывается, это я своим токсичным поведением вношу разлад в команду и блокирую работу других. Если так будет продолжаться и дальше, то им придется со мной расстаться.
Такой поворот событий был огромным шоком для меня. Первой мыслью было: "ну если вам не нравятся мои старания, то и загнивайте с своем болоте дальше!" Однако, в целом моя работа мне нравилась, поэтому так просто сдаваться не хотелось. И я решил разобраться в ситуации.
Анализ
Я попросил своего руководителя привести мне конкретные примеры токсичности в моем поведении. Тут надо отдать должное руководителю, к вопросу он подошёл серьезно и через некоторое время привел мне пару примеров: на митингах я тянул одеяло на себя, не давая другим высказаться нормально, показывал что есть лишь два мнения – моё и неправильное. На код-ревью были ожесточенные дискуссии по тривиальным поводам, и т.д. В общем, со стороны казалось, что со мной абсолютно невозможно ни о чём договориться.
Характерный пример произошел во время командного обсуждения будущих планов. Почти все время митинга я занял рассказом, что у нас в проекте творится бардак и мы ничего не добьемся, пока этот бардак не исправим. Разговор на том митинге зашел в тупик. После этого руководитель меня спросил, зачем было нужно об этом говорить так долго. Я попытался объяснить ещё раз, что состояние проекта никуда не годится. На что руководитель заметил: "Бардак? А я не вижу никакого бардака, задачи доставляются, остальные коллеги довольны, в чем проблема?". Он предложил мне спокойно в текстовом виде расписать, что именно идет не так и показать цифрами и примерами, почему исправление этого должно стать нашим приоритетом. Такое конструктивное предложение мотивировало меня. Я сел за написание документа – сейчас я им всем покажу! – но в итоге так и не смог привести внятного и весомого аргумента. При переводе в текстовый вид все проблемы оказались маленькими трудностями. Тут-то до меня и дошло – смысла поднимать эту тему на митинге не было вообще никакого, потому что обсуждавшиеся там планы лишь слегка пересекались с нашим техдолгом и мое внимание к ним просто зря потратило время всех участников.
В том конкретном случае я признал свою неправоту, но руководитель показал мне ещё примеры. Там было про код-ревью. Я настаивал на своей точке зрения, и никак не соглашался принять другую, потому что там был совсем не поддерживаемый код, как мне казалось. При более детальном рассмотрении оказалось, что предложенная мной оптимизация была преждевременной, по прошествии полугода так и не понадобилась, вся борьба была зря.
К этому моменту я осознал, что лезть на рожон лучше не стоит, даже при наличии благой цели. Иногда стоит и притормозить.
Что было дальше
Тут стало понятно, что нужно как-то выбираться из сложившейся ситуации, только вот неясно, как именно. В этом мне помог счастливый случай. Однажды на очередном код-ревью я заметил, что код можно переписать более оптимально, но помня про прошлые ситуации, у меня не было никакого желания ввязываться в затяжную дискуссию. Поэтому я оставил комментарий: "тут можно было сделать и по-другому, более оптимально, но в целом мне без разницы, могу заапрувить и так". Каково же было мое удивление, когда коллега без лишних пререканий взял и переделал на мою версию!
Я решил попробовать оставлять комментарии в таком же опциональном стиле ещё несколько раз. Это сработало! Оказывается, если не настаивать на своем мнении, то у коллеги не включается чувство противоречия, при котором он защищает свою точку зрения не потому что она лучше, а в качестве естественной защитной реакции.
Таким образом сложилась стратегия более конструктивных код-ревью. Если текущая версия не содержит каких-то фатальных багов, от которых развалится продакшен, то настаивать на своих комментариях не нужно. Автор кода сам разберется с нужными советами. Если же комментарий всё-таки критичный, то нужно явно показать, что именно сломается если этого не сделать. И пусть автор кода сам разбирается со своими рисками.
С культурой дискуссий на встречах тоже разобрались. Перевод дискуссии с эмоциональной в письменную форму позволил найти конкретные недостатки и путь их исправления. Здесь очень важную роль играет скорость восприятия. Не все люди могут сразу разобраться в ситуации, о которой они узнали 5 минут назад. Текстовый документ со ссылками позволит им погрузиться в контекст ситуации и предложить свои решения. Главное здесь не давить и не требовать немедленного ответа. Из-за давления так же есть шанс получить режим противоречия.
Выводы
История эта произошла несколько лет назад, и с текущей позиции кажется, что она закончилась хорошо. Перевод дискуссий в конструктивный режим и подавление желания высказывать импульсивную реакцию положительно сказались на продуктивности. Вопреки популярному здесь в сообществе мнению "работу работать нужно, а не тратить время на эти бесполезные вежливые расшаркивания", избавление от токсичности делает командную разработку однозначно лучше. Токсичность в команде можно сравнить с техническим долгом – его не видно на поверхности, но его наличие значительно замедляет прогресс, и с ним нужно бороться.
Автор: Boris Serdiuk
