Заметки #8 7 случаев, когда общение в рабочем чате может вас погубить
И я не про то, что писать в рабочий чат это плохо. Совсем наоборот. Я про случаи, когда разговор занимает слишком много времени, отнимает силы, расфокусирует или попросту не имеет смысла.
Вот эти случаи:
1️⃣ Обсуждение пул-реквеста, который вернули на доработку.
Такое общение очень часто может свестись к обычному спору. Пишите комментарии к пул-реквесту, а в чате можете сообщить, что вы их оставили. Не пытайтесь обсуждать правильность или неправильность того или иного куска кода. Если нужно, созвонитесь с автором, чтобы объяснить, что от него хотите.
2️⃣ Обсуждение архитектуры или технических решений.
Такие обсуждения занимают продолжительное время 30 минут, 1 час и больше. Скорее всего, вам понадобится объяснять что-то, рисуя это на доске, ссылаться на техническую документацию, показывать экран, фиксировать изменения и т.д. Чат, мягко говоря, не приспособлен для эффективного ведения такой беседы.
3️⃣ Обсуждение тем, явно не связанных с работой.
Обменяться парой фоток утром в пятницу — святое. Но если вы регулярно решаете свои личные проблемы в рабочее время, будьте готовы. Как сказал старина Гэндальф: "Гнев Саурона будет ужасным, а воздаяние очень скорым". Всевидящее око не дремлет, и все такое.
4️⃣ Общение по любым рабочим вопросам, обсуждение которых занимает дольше 5-10 минут.
Воспринимайте рабочий чат, как площадку для коротких уведомлений, саммари, брифингов, вопрос-ответов. Но не как площадку для дискуссий. Дискуссии требуют подготовки, выделенного слота времени и полной вовлеченности сотрудников. Сообщения в чате же часто мьютят, ошибочно понимают в отрыве от контекста и т.п.
Если оторвать сотрудника от его текущих дел как бы "на минутку", которая потом превратится в 10-20-30-сколько-угодно минут, угадайте, кто пострадает? Лучше сразу пригласить его на созвон.
5️⃣ Непубличное обсуждение вопросов, которые затрагивают всю команду.
Представим ситуацию. В команде 5 человек. Но двое из них устроили тайный консилиум. Они заметили, что если вместо того, чтобы писать код А, можно написать код Б, который быстрее и надежнее. При этом есть еще несколько похожих модулей приложения, над которыми трудится другая часть команды. Откуда они узнают, что теперь действуем иначе?
Нет, они конечно тоже могут догадаться сами на собственном тайном консилиуме, и даже придумать код В, который быстрее, надежнее и короче в 20 раз. Если ни те, ни другие не удосужились вывести дискуссию в публичное поле, то дальше будет как у Крылова в басне: Запели молодцы: кто в лес, кто по дрова, И у кого что силы стало. В ушах у гостя затрещало И закружилась голова.
6️⃣ Споры по поводу совместно принятых решений.
Я не против споров, когда они уместны. Это отличный способ прийти к соглашению по поводу архитектуры приложения, проанализировав все представленные аргументы. Но когда решение уже принято совместно, любые дополнительные споры только вносят сумятицу и затягивают работу. Поэтому их нужно дозировать.
7️⃣ Споры в режиме перманентного контраргумента.
Мое любимое. Вы, наверно, встречали таких людей. Они спорят буквально по любому поводу, особенно когда речь касается их технической экспертизы. Во всем, что не так, как они привыкли, или считают правильным. Очень любятся меряться... ну вы понимаете.
Если вы допускаете эти ошибки, то легко можете стать тем человеком, чьи сообщения в чате вызывают у всех желание отключить уведомления, а долгосрочные отношения с командой и/или заказчиком оказываются под большим вопросом.
Помните, что рабочий чат — это инструмент для быстрой синхронизации, а не для долгих дискуссий.
—
А если кто-то ищет ментора, пишите в личку.
🧘 Точка останова #заметки
В этом посте были ссылки, но мы их удалили по правилам Сетки
