Привет, Хабр! В данной статье я хочу поделиться своим опытом токсичного общения с коллегами, начиная с первой встречи с HR-менеджером и заканчивая работой внутри команды. Такое поведение, на мой взгляд, серьезно подрывает мотивацию и нормальное взаимодействие в команде при решении возникающих проблем. Оно также заставляет задуматься о целесообразности работы в такой атмосфере. Ведь зачем оставаться на месте, где отношения между коллегами вызывают столько дискомфорта?
Первоначальное знакомство очень важно
Первое и самое важное знакомство начинается с HR-менеджером компании и в зависимости от его поведения у вас формируется первоначальное мнение о компании. И у меня периодически возникали проблемы при взаимодействии с ними.
Была компания в которую мне очень хотелось попасть, но разговоры с HR-менеджером постепенно и по-этапно отталкивали меня от этого решения. Все начинается с достаточно долгих ответов на вопросы с зазором от нескольких часов, до нескольких дней и тут возникает вообще мысль, а нужен ли я им как работник при отсутствии какого-то интереса к себе?
HR-менеджер держал меня в некотором эмоциональном напряжении и не поддерживал со мной связь. Например, мы договорились обсудить компанию и вакансию, но потом он исчез на несколько дней, а затем внезапно вернулся и назначил собеседование. После собеседования обещалась некоторая обратная связь, но через 3 дня никто не связался со мной. На этом моменте я начал сомневаться, думая, что это просто плохая организация, и что я потратил время впустую. Однако спустя 1.5 недели менеджер снова появился из ниоткуда и предложил мне оффер, включая проверку безопасности, после чего снова исчез на неделю.
Моё мнение о компании уже сформировано, и я потерял доверие из-за первоначального опыта взаимодействия. Возникают сомнения: что если я приму их предложение, уволюсь, а затем они снова исчезнут, и я окажусь без работы? Ведь HR-менеджер - это лицо компании, и от его поведения зависит, как я буду воспринимать эту компанию.
Будь внимателен на код-ревью, ведь нужно разнести код своего коллеги
Код-ревью для разработчиков - это особый вид удовольствия. По моему мнению, код-ревью должно включать в себя поддержку единого стиля кода, обмен знаниями, поиск ошибок и совместную работу. Однако бывают ситуации, когда обычный мердж-реквест превращается в некий тред на дваче, где каждый хочет высказать свои личные предпочтения и видение проекта.
Однажды я работал над разработкой общей библиотеки для всего цеха разработки и внёс небольшие изменения в логирование для улучшения производительности. Когда я создал мердж-реквест, начался сущий кошмар. От трех человек я получил более 70 замечаний, причем не только по моим изменениям, но и по тем, что они увидели в проекте, а также по своим пожеланиям относительно стиля кода.
Пришлось каждому отвечать, что данное замечание не относиться к задаче, а их некоторые пожелания не совпадают с единым стилем кода принятым в цехе разработки. Они соглашались, что их замечания не по делу и когда я начинал собирать апрувы, они старались искать все новые и новые замечания, так-как их предыдущее не получило одобрение. Самое интересное, что они начинали ругаться и с другими людьми, которые указывали замечания.
В итоге ушло несколько дней на то, чтобы разобраться с каждым и отвечать на все их замечания, а также исправить лишь несколько из 70 предложенных изменений. По моему мнению, такое поведение также является проявлением некоторой токсичности, поскольку цель не в том, чтобы помочь улучшить код, а просто засыпать человека замечаниями и тратить дни на поиски проблемы там, где ее может и не быть.
Будь почтителен со своими родителями, родственниками и с менеджером Иваном из своей компании
Если ты работаешь, но ещё не сталкивался с токсичными менеджерами, то, вероятно, ты очень удачливый человек или только начинаешь свой профессиональный путь. В моем опыте периодически возникали такие ситуации и приходилось придумывать, как давать отпор таким людям. Такую ситуацию и хочу описать.
Пришла ко мне очередная бизнес-задача, уже с подготовленной документацией и согласованным архитектурным решением от менеджеров. Казалось бы, просто взял, реализовал, протестировал и выпустил в релиз, но менеджер Иван решил продемонстрировать свою важность, и релиз затянулся на неопределенный срок.
Всё началось с согласования мердж-реквеста в релизную ветку. На просьбы посмотреть и согласовать изначально был игнор, потому что Иван был очень занят согласованием других мердж-реквестов. После того как он, наконец, согласился взглянуть на наш, и решил выполнить просьбу жалкого червя (автора), начались мелкие придирки и постоянные вопросы к реализации. При получении адекватных ответов он снова исчезал на несколько дней.
Заказчики уже ожидают функционала на продакшене, а я все еще не могу получить согласование от нашего менеджера. Это заставляет меня поднять вопрос на ретроспективе: почему этот менеджер взял на себя обязанности по согласованию всех задач в релизе и не может выполнять свою работу вовремя? Возможно, он вообще лишнее звено в этой бюрократической цепи. Другие разработчики тоже сообщают о таких проблемах, и наш тимлид решает провести разговор с Иваном и ускорить процесс.
Результатом данного разговора стало то, что Иван отказывается согласовывать данные доработки, аргументируя тем, что ему не устраивает архитектурное решение, хотя ранее он уже его согласовывал. Он указывает мне, что я должен посмотреть его расписание в календаре и назначить встречу с моим тимлидом и аналитиком, причем я не упоминаюсь в этой встрече. И разговор проходит в тоне, как-будто я секретарша, а он мой начальник, хотя в юридической структуре мой руководитель, мой тимлид.
Я решаю передать данную информацию своему тимлиду и дальше он уже отправляется разбираться с нашим менеджером. Как итог данного действия отложенный релиз на 2 месяца и множество созвонов и встреч, но функционал отправился в релиз в том виде в котором был разработан изначально.
И тут возникает вопрос: зачем всё это нужно? Почему, когда некоторые становятся столпами бюрократии, они начинают не решать проблемы, а создавать новые? Мне кажется, всё это происходит потому, что нужно демонстрировать руководству, как сильно ты зависишь от этого и как много ты работаешь, даже если эта работа не имеет реального значения.
Заключение
Токсичное поведение никогда не заставит других людей работать лучше и не принесет ничего хорошего, кроме временного самоудовлетворения. Важно работать вместе и помогать друг другу решать проблемы, а не создавать их на пустом месте. Хорошая атмосфера в команде так же важна, как и другие показатели.
А те кто сталкивается с токсиками хочу сказать "Не нужно это терпеть".
Спасибо за внимание!
Для тех кому понравилось
Поэтому если интересно получать анонсы новых статей, технические истории работяги или выбрать тему следующей статьи, присоединяйся к моему Телеграмм каналу.
Комментарии (35)
Gusotron
25.04.2024 10:44+15Закидают меня нежные наши писаки, чую, но не сказать глупо.
Чем больше общаюсь с разработчиками тем больше убеждаюсь, что это самые нежные и тонко организованные люди в твоем, username, офисе.
и упаси тебя господь вместо трех звонков и десяти часов обсуждения сказать разработчику «это ерунда, ты не прав, так делать мы не будем, точка».
ребят, иногда нужно работать, а не искать токсичность во всех несогласных. Ну так, вдруг забыли.
ItwithMisha Автор
25.04.2024 10:44+2Бывают же ситуации, когда тебе именно и не дают просто работать.
nguseff
25.04.2024 10:44+1В этом и проблема, что "просто работать" не получается. А проблемы менеджмент скидывает на исполнителей.
В примере, который привёл автор статьи, к разработчику обычно ещё приходит менеджер и говорит, что разработчик (pr'ы которого не принимаются и даже не смотрятся) не справляется. Никто не будет искать проблемы в управлении, если можно просто уволить разработчика, а начальству рассказать, что провел оптимизацию.
Pardych
25.04.2024 10:44+5Как человек самой тонкой и трепетной душевной организации могу передать только короткий трехсимвольный сигнал с координатами по которым можно отправиться менеджеру влезающему в чужую предметную область и лакирующего все соусом "просто сделай как я сказал, просто надо работать". Следом пойдет чувак, который придумал что в его компании менеджеру это можно, или, упаси господь, нужно. Если ты нанял инженера - он инженерит, а не ты. Не можете договориться - привлеки других инженеров, ака "архитектурная сессия" и они либо тебе мозги поставят на место, либо ему. В зависимости от того кто не прав. И вот это вот и называется - просто работать.
Thomas_Hanniball
25.04.2024 10:44+1А какая разница, сколько времени функционал добирается до релиза? Ты свою работу сделал, merge request создал, сиди и расслабляйся, пока бюрократия там сама себе работает и сама себя задерживает.
Организационные проблемы в компании должны решать менеджеры\тимлиды и прочие люди, наделённые властью, а не новички.
ItwithMisha Автор
25.04.2024 10:44+1Тут мне кажется зависит от компании и где-то могут сказать твоя задаче и должен довести до конца решая все сопутствующие моменты. А так да лучше вопросы бюрократии перепасовать заинтересованным лицам)
Markscheider
25.04.2024 10:44+12зависит от компании и где-то могут сказать твоя задаче и должен довести до конца решая все сопутствующие моменты
Невыстроенные процессы Йода видит тут.
Это вроде того, как саппорту первой линии говорят: "ну, запроси базу у пользователя, расковыряй ее скулем, найди места, имеющие отношения к ошибке, залейся в дев, протестируй, найди сходное поведение и вот тогда создавай тикет на вторую линию".
Каждый должен делать свое дело.
l4rover
25.04.2024 10:44+3Технари, одна из самых токсичных сред, у нас на учебе были взаимные проверки и попадались такие душнилы, которые любое малейшее двусмысленную формулировку в задании трактовали не в твою пользу. При этом никакого профита с обнаружения "ошибки" они не имели. Устроить трехчасовую проверку JsonParser-а? Да пожалуйста, попутно спросим все что можно о языке, памяти, командах процессора, стандартах и версиях среды разработки. Ну в целом вы это видите на собеседованиях.
Не то, чтобы гуманитарии много добрее, мне кажется это в целом проблема СНГ, а не программистов, очень низкая симпатия и доверие друг к другу вот и результат.
Yuriy_75
25.04.2024 10:44+1На позицию ревьюера просто противопоказано ставить кого попало. Обязательно должен быть человек с развитыми софт-скиллами. И конечно, ревьюер по задаче должен быть один.
Если ревьюер толковый и тактичный - то и взаимодействовать с таким нет проблем. Иногда даже есть за что спасибо сказать.
Ревьюер, который еще не прошел через период подросткового самоутверждения - беда для всех.
Pardych
25.04.2024 10:44+1Да не сказал бы. Все как везде, такие же люди. Причем в разработке это еще на собесе видно - кому просто работать надо, а кому мозги сношать.
Free_ze
25.04.2024 10:44+3цель не в том, чтобы помочь улучшить код, а просто засыпать человека замечаниями и тратить дни на поиски проблемы там, где ее может и не быть.
начались мелкие придирки и постоянные вопросы к реализации.
Под ревью должно закладываться время на полировку решения и обсуждения возможных слабых мест. Вопросы и уточнения - это нормальное явление, систематические ревью без единого коммента - это скорее признак формального отношения ревьюеров. Все, разумеется, должно быть в пределах разумного, если никто нигде серьезно не облажался.
Затягивания другими людьми согласований и прочих подготовительных процедур, необходимых для дальнейшей работы - это повод вкопаться, заблокировав задачу (уведомив ответственных, конечно). А молчаливое выполнения по сырым требованиям - это уже
ССЗБразделение ответственности с тормозящим звеном. Тут и начинается выяснение, кто больше неправ.Но бывает и обратная ситуация, если там на самом деле в ревью косяк на косяке и такие конфликтные ситуации систематически происходят с разными людьми, то токсиком запросто может оказаться сам рассказчик, который пытается втулить своё любыми правдами и неправдами, обесценивая труд ревьюеров и апеллируя ко времени.
ItwithMisha Автор
25.04.2024 10:44+1Если под каждое ревью закладывать полировку решение и обсуждение возможных слабых мест, то на это будет уходить значительно больше времени и основная суть ревью будет теряться. Тогда можно сразу начинать с парного программирования и сидеть в вдвоем согласованный код писать.
Есть согласованный стандарт и стиль кода команды, если тебе не нравиться, какая-то вкусовщина, то создавай встречу или выноси на обсуждение в чате или ретроспективе. Есть какие-то слабые места не относящиеся к задаче, заводи задачу на доработку. Просто так можно бесконечно сидеть и полировать под желание каждого человекаFree_ze
25.04.2024 10:44+2Если не доводить до абсурда, то практика код-ревью отлично работает. А если реквесты просто подмахивают не глядя, то это бесполезная процедура, тормозящая мержи.
Есть согласованный стандарт и стиль кода команды
А если нет? Имеющаяся кодобаза может быть разного качества. Новый код может привносить как новые здравые изменения, так и чепуху.
какая-то вкусовщина
Самое растяжимое понятие здесь - эта самая вкусовщина. В идеале достаточно обменяться аргументами и некто обличенный властью должен принимать решение. Это должно происходить достаточно оперативно, без растекания мыслью по древу.
MP23
25.04.2024 10:44+1Перестал читать после "не относиться к задаче"
ItwithMisha Автор
25.04.2024 10:44Ревью производиться по коду к задаче, а не по любому коду к проекта.
diakin
25.04.2024 10:44+4Видимо комментатор имеет в виду лишний мягкий знак в слове "относиться". (И "производиться" тоже. ;)
MP23
25.04.2024 10:44+1Именно! Когда человек не знает когда писать тся и ться, но учит манерам .
pl_baliashvili
25.04.2024 10:44+1Манеры и правописание это разные вещи, странно, что тебе это невдомек
ogukuu
25.04.2024 10:44Именно! Когда человек не знает когда писать тся и ться, но учит манерам .
Ещё один человек зацикленный на бесполезных правилах)
exTvr
25.04.2024 10:44Ещё один человек зацикленный на бесполезных правилах)
Казнить нельзя помиловать.
Да, нафиг эти знаки препинания - от лукавого они.
ogukuu
25.04.2024 10:44Казнить нельзя помиловать.
Да, нафиг эти знаки препинания - от лукавого они.
К знакам препинания тоже есть вопросы. Но тут было про одно конкретное правило, и к знакам препинания оно не относится.
Filiber
25.04.2024 10:44+8Мы когда-то боролись с пассивной агрессией в команде и поэтому в конце фраз стали добавлять: “п.дор”, благодаря чему это переходило в активную агрессию, а с ней у нас проблем не было. :)
gun_dose
25.04.2024 10:44+2некоторые пожелания не совпадают с единым стилем кода принятым в цехе разработки
По-хорошему, стиль кода должен автоматически проверяться на пре-коммит хуке, а потом повторно уже пайпланом в репозитории, чтобы не проскочили любители опции -n.
Blurr_30
25.04.2024 10:44+2Я триггернулась на картинку, а про сбор средст на всякие др и праздники на работе, а ничего про это не было. А я так хотела пожаловаться, как с нас сдерали по 3к на подарки мужчинам на 23 февраля (((
Vadziku
25.04.2024 10:44+3То есть автор собачился с коллегами, собачился с менеджментом, но виноват в этом не автор, а все окружающие? :-)
nameisBegemot
25.04.2024 10:44Очередной крик души про токсичность в айти. И все вроде как понимают, поддерживают. Но вон кто-то сказал, что джава популярнее питона (не лучше, а просто популярнее) - я пошли дизлайки.
Я как-то написал здесь, что книга по кодингу в 700 страниц за 3к дорого. Так кто-то обиделся и на это.
А так да, все против токсичности
exTvr
Фу, какая токсичная статья./s