Как стать автором
Обновить

Комментарии 39

А какой у вас размер команды?

У нас их несколько. Размеры команд мы стараемся держать небольшим, в идеале не более 5-6 человек. Если команда разрастается, значит разбиваем на две, выделяя каждой свою область ответственности, свой канал в чате, проект в таск-треккере, итд.

Среди наших клиентов есть организации в которых несколько сотен человек, но и там такой же подход - все делятся на относительно небольшие команды.

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

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

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

В общем,

Простой способ держать команду в курсе.

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

>игнорирует весь этот поток мыслей
Ну, на самом деле можно легко оценить, до какого предела это мастшабируется. Скажем, у меня достаточно типичная картина, когда писем в сутки порядка 100. И это я еще не учитываю роботов типа битбакета или там дженкинса, или прочие стандартные отчеты, каковые мне приходят по 10 штук в сутки.

Прикиньте, 8 часов рабочего времени, 480 минут, одно письмо в 5 минут, примерно. И минимум что мне нужно сделать — это прочитать, и понять, что я могу это игнорировать. А поскольку я PO, то мне потенциально может быть дело до любой темы, поэтому читать приходится все, заголовками ограничиться не удается. Даже если читать и принимать решение быстро, все равно порядка 100 минут на 100 писем не выглядит чем-то уж очень преувеличенным. Как вам нравится потеря 20-25 процентов рабочего времени? Мне совсем не нравится. Я это пытаюсь оптимизировать всеми силами, но в целом это зло.

Особенно когда со временем попадаешь в листы рассылки к другим командам в процессе решения каких-то интеграционных проблем.

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

Никогда по собственной воле не буду подобное внедрять. Разработчикам и пр. специализациям, кому нужна сосредоточенность — противопоказано категорически.
НЛО прилетело и опубликовало эту надпись здесь
>немного странно слышать от PO
Дело в том, что я еще и разработчик. У нас нехватка людей. Нет, не потеря конечно, но от работы, требующейся от меня же — отвлекает сильно.

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

Discord - сам не пользовался пока, но слышал хорошие отзывы. MS Teams - пользовался, чат (на мой вкус) сильно проигрывает слеку. Зато у MS Teams на удивление неплохие видео-митинги

Zulip - есть каналы, внутри темы, внутри темы комментарии.

Для нас большим плюсом была возможность развернуть сервер у себя в инфраструктуре.

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

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

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

И оно может быть разложено по папкам? В почте, в отличие от того же телеграма, я могу общий поток разложить по папкам, применяя правила. Причем мои правила, у коллег могут быть другие.

Прямого аналога папкам и индивидуальным правилам для фильтрации сообщений в слеке нет, это все-таки другой формат общения. Что тут есть:

  • Каналы у всех одинаковы, но каждый пользователь сам выбирает в какие каналы подключаться, может сгруппировать их у себя удобным ему образом, и настроить режим оповещений индивидуально для каждого канала;

  • Также есть довольно богатые глобальные настройки оповещений, в которых можно настроить свой список ключевых слов, расписание, оповещать ли об ответах в тредах и другое;

  • В каждом канале сообщения можно добавлять в закладки, как персональные (Saved items) так и глобальные для всех (Pin to channel);

  • Сообщения можно помечать обратно как непрочитанные, чтобы вернуться к ним позже;

  • Можно отправлять сообщения самому себе. Например, пересылать самому себе какие-то сообщения чтобы вести там архив, или просто писать какие-то заметки для себя.

НЛО прилетело и опубликовало эту надпись здесь

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

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

Многочисленные исследования показывают, что в той или иной форме проблемы коммуникации стоят за большинством причин, по которым проваливаются IT-проекты.

Поделитесь ссылками plz.

Видимо у меня совсем плохо с английским, но в приведённой ссылке я не нашёл подтверждение утверждению «в той или иной форме проблемы коммуникации стоят за большинством причин, по которым проваливаются IT-проекты». Можете мне помочь?

В этой фразе "проблемы коммуникации" понимаются в более широком смысле, нежели чем какие-то ситуационные сложности с перепиской или звонками. Здесь имеются в виду любые виды проблем, когда одному человеку не удается грамотно, вовремя и достаточно убедительно донести свою мысль другому, например:

  • Постановка целей - когда менеджмент не может ясно донести команде зачем все это делается;

  • Работа с требованиями - когда их составитель провел недостаточно хорошую работу по выяснению нужд пользователей;

  • Оценка рисков - когда команду разработки вообще не спрашивали насколько это сложно сделать, или же ей не удалось убедительно донести свою мысль;

  • Оценка текущего состояния проекта - когда менеджмент плохо представляет себе реальное положение дел;

  • Командное взаимодействие - когда люди не могут конструктивно решить возникшие между ними разногласия;

  • ... и т.д.

Если вы взглянете на "проблемы коммуникации" именно в таком, более широком смысле, то да, окажется что они скрываются за большинством проблем проектов.

Вы искусственно свели почти все возможные проблемы в «коммуникации», что не верно (по мне). Таким же образом сюда можно добавить:

  • проблемы с железом (оно не рассказало заранее, когда выйдет из строя)

  • проблемы с софтом (недостаточно информирует пользователя о будущих багах)

  • рыночная неопределенность или риски (не уведомили о возможных проблемах в рамках 100 лет)

Мне было бы интересно узнать про исследование коммуникаций в изначальном толковании этого термина: как объём общения в рамках компании/команды, открытость или закрытость общения, способы общения и пр влияют на развитие компании или команды. Поэтому и попросил поделиться ссылками на «многочисленные исследования», т.к. сам такие исследования не встречал и не слышал о них.

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

Каждый, разумеется, вкладывает в этот термин что-то свое. Мне близко определение из википедии, которое по запросу "Коммуникация (психология)" перенаправляет на статью Общение:

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

Снова софистика ((

Ок, давайте в вашем ключе пойдём. Правильно ли я понял, что есть исследования (и вы ими поделитесь), на основании которых можно утверждать:

  • увеличение количества контактов и объёма общения (я же правильно понял формулировку «процесс установления и развитие контактов»?) повышают вероятность успеха it-проекта

  • объём и открытость общения снижает вероятность любых проблем в it-проектах

нет :) Боюсь, не получится объяснить в рамках комментария, слишком обширная тема. Может как-нибудь соберусь статью накатать на эту тему. А может вы свою накатаете, и разобьете эти предрассудки в пух и прах

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

Наблюдая за тем, как другие люди работают, можно почерпнуть у них то, чем они вовсе не хотят делиться. Почерпнуть то, что отнимет у них монополию на знания, а значит, и отнимет средства для манипулирования коллегами.

Когда другим видно, о чём вы общаетесь — тогда каждый будет вмешиваться в вашу работу, каждая проблема разойдётся тысячей сплетен, и каждый найдёт, в чём упрекнуть вас.
Что-то прям какое-то змеиное гнездо описываете, я бы наоборот сказал что хорошо когда больше людей узнает что именно я не знаю, выше шанс что кто-то да подскажет где и как это лучше изучить.
Практические наблюдения описываю. — Вот лежит на столе у человека книжка. Но подойти, развернуть её и прочитать нельзя, потому что это только его книжка, а не общая. Сфотографировать тоже нельзя, потому что нарушится монополия доступа.

Вы скажете: «Но ведь можно попросить разрешение». Попросить можно, получить нельзя.

Какое то у вас токсическое место работы...

Не убедили. С одной стороны, считаю, что 99% сообщений в личке в slack практически в любой нормально работающей компании не являются секретными, и тот факт, что их не могут видеть все, препятствует накоплению базы знаний. Поэтому, наверное, открытая публикация всех переписок в личке для всех сотрудников компании с мощными возможностями по полнотекстовому поиску, возможно, сделала бы жизнь лучше.

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

хорошие инженеры обычно умеют в таймменеджмент и отсекать не важные каналы получения информации(например мьютить каналы в слаке, которые не требует внимания). по другому продуктивно работать в большой компании попросту не получится.

>вопросы пишутся всем и никому сразу

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

но обычно есть роль дежурного по команде для обработки входящих запросов

это не обычно, это очень печально, если в такой роли появляется смысл, ибо задача команды разработки не в том, чтобы сидеть на потоке входящих запросов, а в том, чтобы, непосредственно, разрабатывать. Коммуникация же, которая возникает при нормальной командной работе, носит такой характер, что от дежурного будет толку 0, ибо только 1 человек может ответить быстро и эффективно (к примеру, тестировщик уточняет у девелопера нюансы того, что он делал; девелопер, желая написать сервис по образу и подобию существующего спрашивает совета у его автора, и подобные узкоспециализированные запросы внутри команды). Ваша же ситуация, из моего опыта, применима в трех случаях:
1) в компании отвратительные процессы и плохая документация, - дев команде приходится делать работу продактов, проджектов, аналитиков, и прочих людей, работа которых подразумевает частые коммуникации и не требует вхождения в поток на несколько часов.
2) в компании отвратительная архитектура, - продукты или модули нескольких команд настолько связаны, что одной команде невозможно сделать сколь значимое изменение без риска сломать что-то у соседней команды
2) это дев команда, которую посадили на саппорт продуктов, которые более не развиваются
Все три случая, увы, печальны

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

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

Коммуникация же, которая возникает при нормальной командной работе, носит такой характер, что от дежурного будет толку 0

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

Хорошая статья, спасибо. У нас в команде похожий подход к коммуникации

В раздел Это не “лишний шум” я бы еще добавил возможность кроссчекинга - возможность проверить и дополнить/поправить что-то, что написал один из членов команды.

И как результат, когда вся команда имеет общий контекст и каждый член команды может эффективно отвечать на входящие запросы - такой подход очень сильно снижает bus factor в команде

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

Автор мешает в кучу базу знаний по проекту и управление проектом. Не заваливайте разработчика информацией. Все эти публичные треды в аналоговом виде выглядят как шум в открытом офисе. Далеко не все хотят в таких условиях работать. Вам кажется, что это нужная информация, но приведение её в читаемое состояние это большая работа, просто так её никто делать не будет. Модераторы и редакторы есть? Если нет, то это не организация, а артель. Поэтому с точки зрения гигиены рабочего места уровень информационного шума надо ограничивать.

У нас тоже слак и отдельный канал на каждый подпроект в системе. Хорошим тоном считается писать в канал, если вы с коллегой работали над вопросом и вели переписку в личке, а потом вопрос выходил на верхний уровень, тимлид просил почитать обсуждение, если оказывалось, что все было сокрыто в личке - то ата-та. Именно для простого подключения других людей (подпроекты ведь все же как-то связаны) и чтобы быть в теме всех переперий проекта все вопросы, обсуждения, решения и результаты надо писать в отдельном общем канале проекта.

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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации