Comments 39
А какой у вас размер команды?
У нас их несколько. Размеры команд мы стараемся держать небольшим, в идеале не более 5-6 человек. Если команда разрастается, значит разбиваем на две, выделяя каждой свою область ответственности, свой канал в чате, проект в таск-треккере, итд.
Среди наших клиентов есть организации в которых несколько сотен человек, но и там такой же подход - все делятся на относительно небольшие команды.
Работал я в месте, где придерживались такого же подхода. Правда почти всё общение было через email, но мне так даже удобнее. Соответственно, все переписки внутри команды, рассылались на всю команду, уведомления приходили только когда ты явно стоишь как адресат.
Из плюсов - когда к тебе приходят с вопросом ты можешь просмотреть всю историю проблемы, какие пути решения уже пытались предпринять и вот это вот всё.
Из минусов - спам. Много спама. Особенно когда со временем попадаешь в листы рассылки к другим командам в процессе решения каких-то интеграционных проблем. Поэтому все письма в которых я не стоял как прямой адресат сразу фильтром улетали в помойку, я их даже не открывал. За два года работы в этом месте, ни разу ничего серьезного не пропустил.
В общем,
Простой способ держать команду в курсе.
это, на мой взгляд, выдавать желаемое за действительное. В реальности команда в большинстве случаев игнорирует весь этот поток мыслей.
Ну, на самом деле можно легко оценить, до какого предела это мастшабируется. Скажем, у меня достаточно типичная картина, когда писем в сутки порядка 100. И это я еще не учитываю роботов типа битбакета или там дженкинса, или прочие стандартные отчеты, каковые мне приходят по 10 штук в сутки.
Прикиньте, 8 часов рабочего времени, 480 минут, одно письмо в 5 минут, примерно. И минимум что мне нужно сделать — это прочитать, и понять, что я могу это игнорировать. А поскольку я PO, то мне потенциально может быть дело до любой темы, поэтому читать приходится все, заголовками ограничиться не удается. Даже если читать и принимать решение быстро, все равно порядка 100 минут на 100 писем не выглядит чем-то уж очень преувеличенным. Как вам нравится потеря 20-25 процентов рабочего времени? Мне совсем не нравится. Я это пытаюсь оптимизировать всеми силами, но в целом это зло.
Особенно когда со временем попадаешь в листы рассылки к другим командам в процессе решения каких-то интеграционных проблем.
А у меня интеграционный проект по сути. Поэтому за несколько лет работы я уже во всех подобных листах числюсь. При этом размер вашей команды вообще уже роли не играет, потому что вот людей вот из этих прочих команд — их в разы больше.
Никогда по собственной воле не буду подобное внедрять. Разработчикам и пр. специализациям, кому нужна сосредоточенность — противопоказано категорически.
Дело в том, что я еще и разработчик. У нас нехватка людей. Нет, не потеря конечно, но от работы, требующейся от меня же — отвлекает сильно.
>за счёт фильтрации потока входящей почты
Так именно этим я и занимаюсь. Просто автор предлагает этот поток направить на всю команду, чтобы все были в курсе — я же наоборот, пытаюсь избавить остальных от ненужных переписок, донося до них окончательные выводы, когда они будут доступны.
Я вообще не жаловался, если вы вдруг меня так поняли — я просто показал, какого масштаба это бывает, даже при небольшой команде, и почему — потому что интеграция и у маленькой команды может быть со многими другими, а этих других — полно.
Электропочта все-таки отличается от чата, потому что для прочтения каждого письма нужно сделать клик. В чате все сообщения идут подряд и мы их просто скроллим. Разница вроде и небольшая, но привычки в использовании меняет очень сильно. Я порой тоже попадаю в копию длинных переписок в электропочте и это реально боль. Но в чате другая история, там не так.
Discord - сам не пользовался пока, но слышал хорошие отзывы. MS Teams - пользовался, чат (на мой вкус) сильно проигрывает слеку. Зато у MS Teams на удивление неплохие видео-митинги
Zulip - есть каналы, внутри темы, внутри темы комментарии.
Для нас большим плюсом была возможность развернуть сервер у себя в инфраструктуре.
В телеграм-чатах - да, полностью согласен. В Slack ситуация получше обстоит. Способ организации каналов, треды, то как работает поиск, как сообщения отмечаются прочитанными, закладки - в целом, ситуация заметно лучше по сравнению с телеграммой, на мой взгляд.
Тем не менее, даже со всякими улучшениями формат чата плохо подходит для использования его в качестве вики, документации, таск-треккера или чего-то подобного - для этого есть свои специализированные инструменты. Например, инструкцию по развертыванию проекта лучше все же хранить в Readme в репозитории проекта, ну а в чат можно скинуть ссылку если кто спросит.
Прямого аналога папкам и индивидуальным правилам для фильтрации сообщений в слеке нет, это все-таки другой формат общения. Что тут есть:
Каналы у всех одинаковы, но каждый пользователь сам выбирает в какие каналы подключаться, может сгруппировать их у себя удобным ему образом, и настроить режим оповещений индивидуально для каждого канала;
Также есть довольно богатые глобальные настройки оповещений, в которых можно настроить свой список ключевых слов, расписание, оповещать ли об ответах в тредах и другое;
В каждом канале сообщения можно добавлять в закладки, как персональные (Saved items) так и глобальные для всех (Pin to channel);
Сообщения можно помечать обратно как непрочитанные, чтобы вернуться к ним позже;
Можно отправлять сообщения самому себе. Например, пересылать самому себе какие-то сообщения чтобы вести там архив, или просто писать какие-то заметки для себя.
Хорошо если общие чаты как в слаке по топику вглубь уходить могут, а когда весь этот поток мыслей даже на 5-6 человек льётся то тут прям много проблем возникает ибо читать несколько сотен сообщений которые шли в параллель с касающейся тебя темой такое себе.
Соглашусь с основными посылами статьи. Я пропагандирую предложения и вопросы по сути задач писать прямо в Jira в комменты, а обсуждения в общий чат по проекту. Сейчас, правда, безопасность не разрешает чаты - так что в почту с копией на всех причастных.
Вот, например, статья на Forbes с отсылками к нескольким исследованиям и опросам - от PwC, IBM, PMI, HBR.
В этой фразе "проблемы коммуникации" понимаются в более широком смысле, нежели чем какие-то ситуационные сложности с перепиской или звонками. Здесь имеются в виду любые виды проблем, когда одному человеку не удается грамотно, вовремя и достаточно убедительно донести свою мысль другому, например:
Постановка целей - когда менеджмент не может ясно донести команде зачем все это делается;
Работа с требованиями - когда их составитель провел недостаточно хорошую работу по выяснению нужд пользователей;
Оценка рисков - когда команду разработки вообще не спрашивали насколько это сложно сделать, или же ей не удалось убедительно донести свою мысль;
Оценка текущего состояния проекта - когда менеджмент плохо представляет себе реальное положение дел;
Командное взаимодействие - когда люди не могут конструктивно решить возникшие между ними разногласия;
... и т.д.
Если вы взглянете на "проблемы коммуникации" именно в таком, более широком смысле, то да, окажется что они скрываются за большинством проблем проектов.
Каждый, разумеется, вкладывает в этот термин что-то свое. Мне близко определение из википедии, которое по запросу "Коммуникация (психология)" перенаправляет на статью Общение:
сложный многоплановый процесс установления и развития контактов между людьми (межличностное общение) и группами (межгрупповое общение), порождаемый потребностями совместной деятельности...
нет :) Боюсь, не получится объяснить в рамках комментария, слишком обширная тема. Может как-нибудь соберусь статью накатать на эту тему. А может вы свою накатаете, и разобьете эти предрассудки в пух и прах
Наблюдая за тем, как другие люди работают, можно почерпнуть у них то, чем они вовсе не хотят делиться. Почерпнуть то, что отнимет у них монополию на знания, а значит, и отнимет средства для манипулирования коллегами.
Когда другим видно, о чём вы общаетесь — тогда каждый будет вмешиваться в вашу работу, каждая проблема разойдётся тысячей сплетен, и каждый найдёт, в чём упрекнуть вас.
Вы скажете: «Но ведь можно попросить разрешение». Попросить можно, получить нельзя.
Не убедили. С одной стороны, считаю, что 99% сообщений в личке в slack практически в любой нормально работающей компании не являются секретными, и тот факт, что их не могут видеть все, препятствует накоплению базы знаний. Поэтому, наверное, открытая публикация всех переписок в личке для всех сотрудников компании с мощными возможностями по полнотекстовому поиску, возможно, сделала бы жизнь лучше.
Но вот сама идея, что вопросы пишутся всем и никому сразу, и вся команда видит выделенные болдом чаты, не понимая, это вопрос им или нет, пока не залезут вовнутрь, мне кажется омерзительной. Хорошие инженеры часто перфекционисты, и непрочитанный чат будет мозолить глаз и отвлекать внимание, хотя разговор идёт вообще о том, где человек бесполезен. Нельзя так бросаться вниманием...
хорошие инженеры обычно умеют в таймменеджмент и отсекать не важные каналы получения информации(например мьютить каналы в слаке, которые не требует внимания). по другому продуктивно работать в большой компании попросту не получится.
>вопросы пишутся всем и никому сразу
не знаю как у автора, но обычно есть роль дежурного по команде для обработки входящих запросов. он берет на себе все такие запросы в течение какого-то периода времени, при этом вся остальная команда может полностью сфокусироваться на основных историях. при этом внешним людям не нужно думать о том, кто конкретно в команде сейчас дежурит, запрос идет именно команде целиком
но обычно есть роль дежурного по команде для обработки входящих запросов
это не обычно, это очень печально, если в такой роли появляется смысл, ибо задача команды разработки не в том, чтобы сидеть на потоке входящих запросов, а в том, чтобы, непосредственно, разрабатывать. Коммуникация же, которая возникает при нормальной командной работе, носит такой характер, что от дежурного будет толку 0, ибо только 1 человек может ответить быстро и эффективно (к примеру, тестировщик уточняет у девелопера нюансы того, что он делал; девелопер, желая написать сервис по образу и подобию существующего спрашивает совета у его автора, и подобные узкоспециализированные запросы внутри команды). Ваша же ситуация, из моего опыта, применима в трех случаях:
1) в компании отвратительные процессы и плохая документация, - дев команде приходится делать работу продактов, проджектов, аналитиков, и прочих людей, работа которых подразумевает частые коммуникации и не требует вхождения в поток на несколько часов.
2) в компании отвратительная архитектура, - продукты или модули нескольких команд настолько связаны, что одной команде невозможно сделать сколь значимое изменение без риска сломать что-то у соседней команды
2) это дев команда, которую посадили на саппорт продуктов, которые более не развиваются
Все три случая, увы, печальны
Допускаю, что возможно где-то в идеальном мире с розовыми единорогами команды полностью автономны и пилят что-то свое в вакууме общаясь только со своим продактом и документацией, но я про такое пока не слышал. Если у вас есть такие кейсы - реквестирую статью с описанием.
Со своей стороны могу перечислить, чем конкретно у нас занимается дежурный: внешние и внутренние код-ревью, дизайн ревью и вопросы по базам данных(наша команда выступает в качестве центра компетенций), реагирование на алерты и инциденты.
Коммуникация же, которая возникает при нормальной командной работе, носит такой характер, что от дежурного будет толку 0
Вы, наверное, неправильно меня поняли - у дежурного нет цели завернуть на себя внутрикомандную коммуникацию, по большей части он реагирует именно на внешние запросы.
Хорошая статья, спасибо. У нас в команде похожий подход к коммуникации
В раздел Это не “лишний шум” я бы еще добавил возможность кроссчекинга - возможность проверить и дополнить/поправить что-то, что написал один из членов команды.
И как результат, когда вся команда имеет общий контекст и каждый член команды может эффективно отвечать на входящие запросы - такой подход очень сильно снижает bus factor в команде
Автор мешает в кучу базу знаний по проекту и управление проектом. Не заваливайте разработчика информацией. Все эти публичные треды в аналоговом виде выглядят как шум в открытом офисе. Далеко не все хотят в таких условиях работать. Вам кажется, что это нужная информация, но приведение её в читаемое состояние это большая работа, просто так её никто делать не будет. Модераторы и редакторы есть? Если нет, то это не организация, а артель. Поэтому с точки зрения гигиены рабочего места уровень информационного шума надо ограничивать.
У нас тоже слак и отдельный канал на каждый подпроект в системе. Хорошим тоном считается писать в канал, если вы с коллегой работали над вопросом и вели переписку в личке, а потом вопрос выходил на верхний уровень, тимлид просил почитать обсуждение, если оказывалось, что все было сокрыто в личке - то ата-та. Именно для простого подключения других людей (подпроекты ведь все же как-то связаны) и чтобы быть в теме всех переперий проекта все вопросы, обсуждения, решения и результаты надо писать в отдельном общем канале проекта.
Плюс так же публичного общения в каналах то, что он не позволяет отдельным персонажам хамски себя вести. Одно дело в личной переписке себя вести неадекватно, а другое дело публично...
Хватит писать в личку