Что раздражает коллег, но никто об этом не говорит: 8 вредных привычек в IT

Автор: Иван Богданов, Технический писатель

Материалов про эффективную коммуникацию в командах — море. Про SMART-цели, agile-ретроспективы, feedback-сессии написано столько, что можно диссертацию защитить, да и не одну, но я хочу подойти к проблеме внутрикомандной коммуникации с другой стороны.

Вместо методик и best practices поговорим о том, что не надо делать в реальном общении внутри команд, особенно если это коллективы на полной или частичной удаленке. Обсудим конкретные косяки, которые можно регулярно наблюдать в рабочем процессе (и сам их иногда допускаю, чего уж там).

Почему это важно? Исследования рисуют невеселую картину. Анализ Stack Overflow показывает, что только 25% разработчиков довольны своей текущей работой. Разработчики тратят от 30 до 60 минут в день на поиск ответов на вопросы, при этом 75% регулярно отвечают на одни и те же вопросы повторно. Больше половины респондентов отмечают, что ожидание ответов нарушает их рабочий процесс. Исследование Google Project Aristotle выявило, что психологическая безопасность - самый важный фактор эффективности команды. При этом опрос GitLab обнаружил серьезный разрыв между тем, как руководители и разработчики воспринимают одни и те же проблемы - от рисков AI до качества обучения.

Получается, что мелочи в коммуникации — не такие уж мелочи. Они разрушают атмосферу, тормозят работу и раздражают коллег, часто незаметно для тех, кто их совершает. О каких конкретно мелочах речь? Дальше — набор наблюдений из практики, субъективных и неполных, но регулярно встречающихся. Многое может показаться очевидным или проговаривается при онбординге, однако почему-то те же самые промахи всплывают снова и снова — у новичков и сотрудников с большим опытом работы. Особенно эти наблюдения могут помочь тем, кто только начинает свой карьерный путь.

Может, само пройдет

Начну с самого сложного момента. Речь не о пропущенных дедлайнах или мелких багах, а о серьезных проблемах, которые влияют на прод, а новичку сложно сходу оценить степень влияния. Случайно удалил данные в базе или поменял конфигурацию, повесил теги на оборудование, влияние которых полностью не знаешь, и система начала чудить. Первое желание — попытаться исправить самому и надеяться, что никто не заметит (спойлер — заметят). Или еще хуже — начать искать, на кого можно свалить: «Это же не я менял конфигурацию последним», «Скрипт был кривой изначально», «Меня никто не предупредил об этом тикете».

Желание понятное, но оно только усугубит положение. Более опытные коллеги оценят ситуацию за минуты и предложат решение, на поиск которого новичок потратит часы мучений. Они знают подводные камни системы и могут предотвратить новые проблемы. А молчание о серьезной ошибке почти всегда заканчивается тем, что всё вылезает в самый неподходящий момент, когда чинить уже в разы сложнее. Попытки переложить вину раздражают еще сильнее — все видят, что случилось, логи не врут, а человек вместо решения проблемы тратит энергию на оправдания.

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

Самобичевание

Когда долго не получается решить задачу, в голове начинает звучать назойливый шум — «я ничего не понимаю» и «у меня руки не из того места». Знакомо? Я регулярно ловил себя на этом.

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

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

Сроки - это примерно

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

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

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

Телепатия не работает

В рабочем общении постоянно натыкаюсь на одно и то же: люди пишут так, будто собеседник уже в курсе всего контекста. Сообщение из трех слов, куча подразумеваемого, а потом удивление: почему непонятно?

Классика, которую вижу регулярно: «не работает», «сломалось», «есть проблема» — и всё. Дальше начинается пинг-понг вопросами, который растягивается на полчаса (бывает и на пару рабочих дней), а можно было сразу написать, что именно не работает, при каких условиях и что ты уже пробовал.

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

Игнорирование документации

Сейчас многие компании постепенно обзаводятся нормальной документацией и материалами для новичков. Где-то это подробный вики, где-то — набор гайдов для онбординга. Не везде и не всегда идеально, но что-то есть. Документация обычно кажется скучной формальностью. Ну вот есть какой-то вики, ну посмотрю потом, когда время будет. Сам так делал — и каждый раз потом жалел.

Конечно, не стоит задача вызубрить всё наизусть. Просто часто оказывается, что ответы на многие вопросы уже где-то написаны. Как тут принято делать деплой, к кому идти, если что-то сломалось в проде, какие есть договоренности по рабочему процессу, как устроено взаимодействие с соседними отделами.

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

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

Не запоминать, кто за что отвечает

В начале работы в команде всё кажется очевидным: вот разработчики, вот тестировщики, вот DevOps. Но со временем выясняется, что из всех девелоперов Никита лучше всех разбирается в API, инженер Андрей отвечает за деплой конкретного сервиса и с вопросами о других продуктах к нему лучше не обращаться, а Олег — единственный из ноков, кто не просто в курсе, как устроена сетевая инфраструктура, но и может последовательно и конкретно объяснить ее архитектуру.

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

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

Плюс это помогает понять, куда расти. Видишь, какие навыки есть у коллег уровнем выше, и понимаешь, чему стоит учиться дальше.

Я - Данко

Иногда можно наблюдать занятную ситуацию: человек сам себе создает переработки, хотя никто этого не требует. Задерживается допоздна, работает в выходные, а потом удивляется, почему устал и ничего не хочется. При этом объективной необходимости нет. Дедлайны нормальные, задачи не горят, никто не подгоняет. Просто где-то в голове сидит мысль, что «надо больше», «недостаточно стараюсь», «а вдруг подумают, что я плохо работаю».

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

Обычно оказывается, что никто и не ждал доступности 24/7. Команды чаще смотрят на результат и качество, а не на количество часов за компьютером. Выгорание от постоянного самовыжимания приходит быстро, а восстанавливаться долго.

Перенос старых привычек

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

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

Такое поведение раздражает команду довольно быстро — когда человек упорно делает по-своему, не пытаясь понять, как работают остальные, это выглядит как неуважение к сложившимся договоренностям. Имеет смысл первые недели просто наблюдать и спрашивать — как тут принято коммуницировать, какие есть правила, что важно, а что формальность.

Этот список далеко не полон и субъективен, но кто не совершал хоть одну из этих ошибок? Сбой деплоя в пятницу вечером не располагает к вежливости и развернутым сообщениям, а когда третий час бьешься с багом — самобичевание приходит само. Но между «идеально» и «хотя бы не бесить коллег» — огромное пространство для роста.