Прерывания работы
Slack помогает вашим худшим сотрудникам подавить лучших. В этом его сходство с офисом открытого типа.
Он превращает в норму постоянные прерывания, многозадачность и отвлечения, косвенно допуская всё это в офлайне и онлайне. Он делает нормой безумно быстро отвечать на вопросы. В мире Slack люди переходят от прямого вопроса к person до обращения here за несколько минут. И правильно: ведь тут если на вопрос не ответили в течение 5 минут, то о нём вообще забывают.
Как-то по ходу дела мы забыли, что отвлекаться вообще-то вредно для реальной работы. Раньше было по-другому. В первый день своей первой работы трейдером единственной инструкцией, которую я получил, было «Когда рынок откроется, отключи телефон». С подтекстом «иначе ты понимаешь, что будет». Если кто-то скажет мне такое сегодня, я обниму этого человека, хотя я не фанат обнимашек.
Я пытался поговорить с людьми на эту тему, но мне отвечали: «Это офис, а не библиотека». В то время я был просто в ярости. Если сегодня, после двух лет использования Slack, мне кто-нибудь ответит таким образом, то не уверен, как отреагирую.
Культура удалённой работы — это защитный механизм против отвлечений открытого офиса, а Slack — лазейка для обхода этой защиты. Он изнашивает адренальную систему вашей команды и заставляет жить текущим моментом. В отличие от электронной почты, здесь доставку сообщений нельзя отложить на потом. Чат воплощает в реальность для вашей команды закон «Сейчас или никогда».
Когда всё срочно, то ничто не является таковым. Это главный план злодея из пиксаровской «Суперсемейки». Slack — это план суперзлодея по разрушению вашей команды.
Формат фрагментирован и ограничен
Чат нельзя редактировать так, как вам бы хотелось. Вы можете отредактировать текст в течение какого-то времени, но без оповещения остальных. Я думаю, что исправление и тщательное исследование более важны, чем первоначальные реакции. Мне больше нравится модель Google Docs, где оповещения создаются на комментарии/вопросы, а не на первоначальный текст.
Чат в Slack не сгруппирован в цепочки. Вы скажете, что есть отдельные каналы. По моему опыту (как минимум в четырёх компаниях) каналы не являются чётким разграничителем; они скорее разделяют группы, а не темы обсуждения, так что темы/обсуждения по-прежнему дублируются между каналами. В типичных ситуациях, которые я наблюдал, сложно понять текущую тему обсуждения — какому каналу, какой теме соответствует каждое конкретное сообщение.
Отличным способом определить тему была бы прокрутка чата, но скроллинг работает ужасно. Прокрутка больше чем на две страницы вверх приводит к кошмарным перекомпоновкам с прыжками к исходной точке — такие вещи более воспитанные компьютерные пользователи 80-х или 90-х годов назвали бы глюками, а в современном вебе их приходится терпеть.
Электронная почта гораздо лучше группирует обсуждения в цепочки, но Slack убил такую возможность.
Slack по своей сути всегда подгоняет: я чувствую, словно тороплюсь что-то прошептать, пока кто-то другой не закричит. Здесь функция is typing (набирает текст...) — это гвоздь в крышку гроба. Она отключает мою способность связно думать. Я словил себя на том, что пишу сообщения в адресной строке с закрытыми глазами, чтобы отогнать панику.
Из-за функции набирает текст... один медленный пользователь может разложить мыслительный процесс всей группы. Извините за грубую метафору, но это словно старичок писает на вас по капельке. По мне лучше покончить с этим быстрее и умыться.
Парадоксально, но скорость тоже вредна для групповых обсуждений, потому что люди торопятся высказать свои идеи — и те выходят в полуготовом виде или противоречивыми. Моё любимое — потеря частицы «не» в предложении. Когда человек замечает опечатку, то публикует
*не, иногда через несколько строчек после первоначального сообщения. Я чувствую, словно попал в зарисовку «Мира Уэйна».Поиск Slack не работает как положено
Поиск не работает как положено по многим причинам:
- Частично потому что в отличие от цепочек обсуждения в электронной почте и на форумах здесь отсутствует изначальная группировка, так что вы можете искать только отдельные сообщения.
- Частично потому что функция поиска плохо реализована — расположенные рядом сообщения отображаются как отдельные результаты поиска, даже если у них одинаковый контекст до/после.
- Я никогда не знаю, что произойдёт по клику — иногда осуществляется прокрутка канала к этому сообщению, иногда результаты поиска отображаются/скрываются или масштабируются.
- Кнопка “More results” переносит на постраничный вид, но три первых результата те же самые, что я уже видел — то есть «больше результатов» переносит со страницы 1 на страницу 1. Что за хрень.
- Ctrl-F, неизменный стандарт взаимодействия в вебе, не работает на каналах, если вы ищете более чем на одну страницу вверх. Можно винить в этом дерево DOM, но я вижу причину в том, что из-за интенсивного использования CSS приложение потребляет слишком много памяти, чтобы хранить историю длительной прокрутки.
Понимаю, что это лишь проблемы UX и их можно исправить, но (1) я не знаю, можно ли их в принципе исправить, когда ваше приложение основано на таком зыбком фундаменте как DOM; и (2) если был Slack инструментом для помощи в мыслительном процессе, а не его предотвращения, то у него была бы нормальная функция поиска.
Он увеличивает производительность (в плохом смысле)
Закон Гудхарта гласит, что если показатель превращается в цель, то он становится плохим показателем. Slack подрывает важную работу, потому что здесь производительностью считается доступность человека в Slack.
Производительность — сомнительная метрика, поскольку её трудно измерить и даже сформулировать в общем виде. В экономике общая факторная производительность представляет собой остаток после вычета затрат труда и капитала. Тут смущает факт, что лучше давать людям меньше денег (у работников обычно почасовая оплата).
На работе продуктивность объединяет в себе пропускную способность и ценность для бизнеса. Мы знаем, как измерить первое, но больше волнует второе. Оптимизация с прицелом на пропускную способность плохо сказывается на продуктах и командах:
- Менеджеры среднего звена уменьшают размер и ценность предоставляемых результатов, так что при повышении «пропускной способности» могут объявить своим боссам о достижении, а «пиджаки» могут похвастаться перед акционерами.
- Из-за этого проектные работы переходят от экспертов в своей области к менеджерам проектов, результатом чего становятся чокнутые проекты.
- Увеличивается загрузка, что приводит к выгоранию, снижает допустимые пределы безопасности, подавляет инновации (вот для чего использовались те промежутки свободного времени).
Эти пункты — часть крупномасштабного перетягивания каната между менеджерами среднего звена и программистами. Впрочем, тема не для этой статьи. Упомяну лишь, что повсеместный чат помогает менеджерам среднего звена (то есть людям, которые любят много проверять) за счёт здоровья креативных сотрудников и долговременного благополучия вашей организации.
Почему люди не замечают этого? Думаю, потому что большинство никогда не понимало или не задумывалось о том, как именно делается работа. Теперь появился Slack — и сделал «работу» видимой в форме мгновенных ответов на быстрые вопросы, танцующих стикеров эмодзи и беспрерывного трёпа. И некоторые такие: «Да! Посмотрите, как многого добилась моя команда».
Он заменяет документацию
Думаю, большинство согласится: когда работники умственного труда сотрудничают друг с другом в группах, то они должны сохранять в письменной форме то, о чём они договорились работать. В Slack качество этих записей пробивает новое дно. Огромная пропасть между тщательно обдуманной документацией Google Docs, которую отредактировали несколько человек, и потоком сознания вперемешку с анонсами «работа из дома» и «посмотрите, что сделал мой кот».
Доступность 24/7 тоже вредит хорошей практике документации. Когда люди не могут связаться друг с другом в любое время, то организациям приходится проектировать систему с избыточностью, то есть записывать всё в такой форме, чтобы документ был понятен другому человеку без дополнительных обсуждений. Но сейчас выросло целое поколение работников и даже компаний, которые никогда не работали таким образом.
Важнейшая информация для работы вашей компании хранится в трёх местах:
- мозг
- документы (включая почту)
- софт
Модель Slack увеличивает процент критически важных решений, которые зависят от конкретного мозга. Удачи вам с такой системой.
Что Slack делает правильно
Есть одна вещь, в которой Slack превосходит Trello и Jira в управлении проектами. У них нет обратного давления, а у Slack есть, потому что человеческое внимание ограничено.
Тут действует правило Златовласки — ни модель «кухонной раковины» в Jira, ни модель «выноса мозга» в Slack не является идеальной. К тому же многие хотят использовать Slack, Trello и Jira одновременно совершенно не стесняясь (два уже вопиюще, а три — просто безумно). И Slack нельзя назвать подходящим решением для управления проектами как минимум по той причине, что у него нет нормального вида итогов (aggregation view); и у Jira тоже нет. Нам нужно создать инструменты планирования с продуманными ограничениями, а не с произвольными пределами того, что люди способны воспринять под сильным давлением внимания.
Trello и Jira
Тоже программы, которые я ненавижу.
Они продвигают эту «теорию ожидания» (icebox theory) в отношении разработки. Какую идею предложил менеджер проекта полгода назад, и над ней до сих пор никто не работает? Давайте возьмём её. Если ваши лучшие сотрудники не выдвигают идеи и не назначают проекты, зачем кому-то появляться на работе?
У Jira проблема с местом на экране. Видели статьи о «сжатии» страницы с результатами поиска Google, где на скриншоте 2004-го года в основном результаты поиска, а сейчас в основном реклама? Jira тоже пошёл по этому пути. 90% текста на экране — это не ваши проекты, а украшательства Jira.
Другой недостаток Jira: сильно формализованный процесс обычно является помехой, особенно с учётом того, кто в вашей организации придумал этот процесс, внедрил его и получает выгоду от его реализации. Подсказка: менеджеры среднего звена.
Коммодитизация коммуникаций не работает. Так разрешите людям сойти с поезда и снова начать составлять продуманные планы. Чистый лист бумаги — всё, что нужно для этого.
Организациям действительно необходимо ответить на эти вопросы. Вы можете сказать, что чат подходит лучше всего, но у него слишком много недостатков. Когда появился Stack Overflow, он представил интересную инновацию — пометка вопросов, на которые получен хороший ответ. Но имейте в виду, что предыдущий лидер в области вопросов и ответов Experts-Exchange прятал ответы, потому что хотел получить плату за доступ к ним, а не по причинам UX. Stack Overflow сейчас превратился в относительно паршивый сайт и заменил документацию для многих свободных библиотек.
#deleteuber
Кампания по удалению приложения Uber не исправила трудовые отношения в новой экономике, где работодатели отказываются от постоянных сотрудников в пользу временных контрактов, но ваша организация может отказаться от чата в любое время — достаточно просто захотеть.
Прекратите читать эту статью, если вас не волнует ничего из следующего:
- увеличить благополучие лучших людей
- меньше реагировать на отвлекающие факторы
- больше сосредоточиться на реальном прогрессе
Если вас заботят эти вещи, тоже прекратите читать статью, но после этого пойдите и удалите чат.
В 2015 году я уходил в отпуск на четыре месяца, а когда вернулся в 2016 году — это был сумасшедший дом, полный беспорядка и суматохи. Люди проверяли жужжащие телефоны на планёрках. Уведомления из чата клик-клик-кликали без перерыва. Не было никакой культурной поддержки или даже реального понимания, как заставить эту систему работать. Я сказал об этом менеджеру проекта, на что тот ответил: «Эх, у тебя синдром дефицита внимания».
Slack и то вредное поведение, которое он косвенно поощряет, подарит синдром дефицита внимания всей вашей компании. Хотите конкурентное преимущество в один клик? Удалите свой аккаунт.
Комментарии (124)
cjbars
12.02.2018 18:53+1А как же треды в слаке? Это ли не цепочки писем?
alexey-m-ukolov
12.02.2018 19:44+2Треды появились далеко не сразу, да и вообще они ущербные. Почему вот в канал кинуть картинку можно, а в тред нельзя? Никто не знает…
wert_lex
12.02.2018 20:02+2Вот как человек, который вкусил запретный плод пм-ства, не могу не задать вопрос: а как автор видит идеальную коммуникацию в команде и какими типами средств она должна достигаться?
Jon7
12.02.2018 21:05Это перевод статьи. Очень имхо, но мне нравился google way. Делался программистами для программистов. Проект не взлетел google его закрыл, но были последователи и кое что осталось. Исходный код на github. «Потыкать палочкой» можно здесь пока демо сервер работает.
Похоже на чат и wiki в «одном флаконе» или на чат в котором можно править сообщения и смотреть историю правок. Непосредственно чат не заменяет. Это больше похоже на одновременную правку wiki страницы несколькими пользователями одновременно.Я думаю, что исправление и тщательное исследование более важны, чем первоначальные реакции. Мне больше нравится модель Google Docs, где оповещения создаются на комментарии/вопросы, а не на первоначальный текст.
Вот это там есть, это создавалось на основе Google Docs. И все сгруппировано в цепочки. Удобно общаться строго на определенную тему, но это не чат, это подобно обсуждению в карточки Trello. Поскольку карточек как Trello нет, то и никакого продвижения icebox theory нет. Собрали высказывания по теме, перекинули выводы в документы или в wiki, закрыли обсуждение, удалили цепочку.
Есть мобильный клиент. Есть минимальная интеграция. Но ребята не смогли монетизировать проект выложили код и прекратили разработку.
zoonman
12.02.2018 23:22Slack действительно во многом неудобен. Я даже в свое свободное время тоже пытаюсь сделать нечто среднее между чатом и форумом. Проект не очень популярен, но с друзьми общаться получается.
ncix
13.02.2018 16:17Это больше похоже на одновременную правку wiki страницы несколькими пользователями одновременно.
Google Docs умеет. Confluence умеет.
mat300
13.02.2018 06:54-1Идеально — это когда с пм-ом коммуницируешь только пару раз в неделю на митингах и потом больше его не видишь, ни в холле, ни в почте, ни тем более в слаке. Если что-то очень серьезно-неотложное, то пм или менеджер пишет мыло или может сам зайти доложить. А слак только для прояснения чего-то непонятного. Когда все ясно — можно писать Jira.
Да, и еще если кто-то заикается про работу в потоке — гоните сразу в шею. Это не инженер, не программист. Настоящий разработчик должен быть гибким — и код, чтоб писал и кому-то сразу в слаке ответил, и рядом коллеге что-то мог подсказать. И от этого надо еще и удовольствие получать. У умного человека мозг очень гибкий и незашоренный. А в потоке обычно дедушки с альцгеймером.mat300
13.02.2018 08:54-1Для минусующих: это стиль работы HGST. И если качество драйвов от HGST вам о чем-то говорит, то вы поймёте, что обозначенный выше стиль работы весьма действенный и отточенный годами. Для тех, кто в танке — минусуем дальше.
VulvarisMagistralis
13.02.2018 10:09+1Для тех, кто в танке — минусуем дальше.
Вариант, что существуют люди опытнее вас в этом вопросе — вы не рассматриваете в принципе?
timelle
13.02.2018 09:17Мне кажется, идеальная коммуникация должна быть основана на здравом смысле. Здравый смысл состоит в том, что срочная коммуникация — злейшее зло. Помню, меня на фрилансе очень подстёгивало, что и тут я нужен и там, и везде мне пишут! Но если вопрос требует внимания и концентрации — все плохо. Поэтому все коммуникации вывел в почту.
Если что-то мегаважное — пусть звонят по телефону. Удивительно, но за месяц всего пара звонков. Очень часто пишешь клиенту, а он отвечает на следующий день или через несколько часов. Что это значит? То, что он тоже работает.
Это позволяет концентрировтаься на чем-то конкретном и переключаться между задачами, выполнив предыдущую работу до определенного этапа. Вместо дерганья получается планомерная деятельность.
Иными словами, «проблема Слака» в статье — это проблема взаимоотношений в команде, а не инструмента.
firk
12.02.2018 21:16Автор впервые познакомился с instant messager'ами? Откуда такое внимание одному из них и приписывание ему персонально общих их проблем (о том, насколько это проблемы софта, не буду дискутировать)?
Angerslave
12.02.2018 21:53Slack себя позиционирует больше, чем IM. Они говорили, что в слак каналы можно постить всё подряд — тикеты из zendesk, сообщения из электронной почты, видео, фотки и, естественно, обсуждения. К тому же сами чаты делаются только для определённого круга лиц, в отличие от чатов, где все видят всех. То есть многие компоненты были и раньше, но по отдельности. Slack их удачно скомбинировал и скормил малому-среднему бизнесу. Причём настолько хорошо зашло, что имхо слаком начинают заменять то, к чему он изначально не приспособлен. Собственно так я понимаю посыл автора статьи.
niko1aev
12.02.2018 21:45m1rko увидел ваш ник под статьей, и понял, что он мне знаком.
Посмотрел ваш профиль — 150 публикаций. Чуть больше чем за 1 год. Публикация раз в 3-4 дня. Переводы, переводы, переводы. Многие переводы набирают десятки тысяч, некоторые больше сотни тысяч. Многие из них я читал.
Кто вы? Откуда такие ресурсы для переводов? Как вы подбираете статьи? Какие у вас цели? И почему вы не участвуете в рейтинге на Хабре?
alizar
12.02.2018 21:58+1>И почему вы не участвуете в рейтинге на Хабре?
Сотрудники ТМ не участвуют в рейтинге.
ivorobioff
12.02.2018 22:00Не поймите меня не правильно, но статья написана на эмоциях и такое ощущение что у автора личные счеты со Slack ;-)
Вообще, Slack довольно полезный инструмент, если не пытаться на нем улететь на Луну.
sand14
12.02.2018 22:41В статье упор на Slack (хотя для эмуляции чатов слаке многие команды используют чаты в скайпе), но потом упомянута Jira (читай — трекинговые системы), и честно названы бенефициары всего этого в процессах работы — менеджеры среднего звена.
В общем автор описывает конкретные продукты (хотя можно было бы говорить о конкретных классах продуктов), но на самом деле все еще глубже — это честная статья про скрам и аджайл.
Это не отменяет того факта, что в наше время современные средства коммуникации — большой плюс, и нельзя их отметать.
WebArtisan
12.02.2018 23:38+1Зашел почитать статью с интересом и желанием узнать другую точку зрения на то, что уже стало обыденным.
Прочитав, хочу сказать только одно… Критикуешь — предлагай! Никакой альтернативы, которая бы решала проблемы описанные автором, я здесь не увидел.
TheShock
13.02.2018 01:20Так почта и гугл-доки же (я так понял). Основная идея — отказаться от принципа «сперва общение — потом работа» и перейти к принципу «сперва работа — потом общение». Наверное, где-то между ними есть золотая середина, так как принцип отвечай-сразу-же-или-начальство-будет-недовольно на самом деле контрпродуктивен.
lexore
13.02.2018 01:04Так slack/trello/jira/e.t.c — это просто инструменты.
Имхо, в данном случае проблема в тех, кто ими пользуется.
Я бы не назвал нормой постоянно отвлекать человека от работы вопросами, которые не являются срочными или важными.
Особенно в софтверной области — когда программист пишет код, он погружен в свой контекст.
Если его отвлечь, ему может понадобиться время, чтобы вернуться в этот контекст.
Чем больше переключений контекста в час, тем меньше человек пишет кода за этот час.
По идее ПМ должен это понимать и по возможности замыкать вертикальное общение на себя.
Ну а для горизонтального общения сотни лет существуют такие вещи, как хорошие манеры (задал вопрос, подожди ответа и т.д.)
Если в компании все наоборот, то отказ от slack тут не поможет — будет любой другой инструмент, который будет использован против сотрудника.
gnemtsov
13.02.2018 01:14Я в общем-то согласен с автором статьи.
Есть по большому счету две модели общения: синхронная (личная встреча, телефон, чаты) и асинхронная (эл. почта, таск-треккеры).
Синхронная модель — это царство обрывочных мыслей, рассеянного внимания и больших потерь времени. На мой взгляд, синхронная модель нужна только в редких случаях, когда случился форс-мажор. Ну или может когда нужно выразить и передать эмоции.
Асинхронная модель, я считаю, наилучший вариант для разработчиков. Для продуктивной работы асинхронная модель общения должна составлять где-нибудь 80-90%.K0styan
13.02.2018 14:35Синхронная — тоже ок. Но только в том случае, когда все собеседники готовы к ней. Поэтому нормальная встреча должна быть запланирована, должен быть четко определен результат встречи (донесение информации, принятие решения, наброс идей — ни в коем случае не смешивая) и очерчены рамки обсуждаемых тем. Ну либо она должна проходить между людьми, которые достаточно дисциплинированны и понимают друг друга, чтобы сформулировать этот фреймворк в первые минуты и удержаться в нем.
И то, сплошь и рядом ее можно заменить асинхронным вариантом.
dzzh
13.02.2018 01:46Я последний год проработал в компании, которая выросла за это время с 50 до 200 сотрудников в центральном офисе и с примерно 100 до 1000 линейных сотрудников (курьеры/рабочие склада). Практически вся коммуникация была организована в Слаке (а таски в Джире), и это было круто. Безусловно, у Слака есть минусы, как перечисленные в статье, так и обойденные вниманием, но при поддержании определенных правил информационной гигиены Слак — очень удобный инструмент.
Под этими правилами я понимаю например такие:
— единая система именования каналов
— максимальное дробление каналов и общение только по теме канала
— за злоупотребление @channel и here сначала бить по рукам, потом по голове, но можно и наоборот
— не ожидать немедленного ответа на вопрос в личку/канал, по необходимости пинговать через некоторое время
Интеграции в Слаке работают просто шикарно (не технически даже, а в плане юзабилити). Все отчеты, аналитика, статусы билдов, ошибки продакшена, да что угодно, распихивается по своим каналам, по необходимости мьютится и удобно контролируется из одного интерфейса. Работа по фичам в своих каналах, вопросы службы поддержки в своих, офисный треп в своих, ленты новостей в своих, отлично же. Да, к Слаку есть миллион пожеланий по улучшению функционала их софта, но возвращаться назад к электронной почте и всем остальным разрозненным сервисам, которые могут быть сведены в Слак — нет, спасибо.
Соблюдение правил информационной гигиены необходимо конечно немножко контролировать с помощью специально обученного фашиста, его пулемета и овчарки, полностью на самотек общение пускать нельзя. Но это несложно.jahr
14.02.2018 12:08Не очень понятно, что можно сделать в слаке, чего нельзя в электронной почте
dzzh
14.02.2018 12:45Так скажем, большую часть того, что можно сделать в слаке, можно в принципе сделать и в почте (с кучей дополнительной головной боли, вроде списков рассылки, фильтрации сообщений, сервера с историей и так далее). Но это все будет печально и неудобно. В слаке коммуникация сведена в один интерфейс, где все на своем месте, это основной плюс. Из того, что в почте нет в принципе — реакции, например (смайлики под сообщениями, которые тоже вполне себе рабочий инструмент, если с умом им пользоваться). Постоянные группы, которые создаются по клику. Можно конечно вместо каждой комнаты заводить отдельный список рассылки, но это значительно больший геморрой создателю группы и проблемы фильтрации сообщений пользователями. Приоритетные сообщения через знак @. Более неформальный стиль общения, не нужно каждый чих оборачивать в «добрый день, уважаемые коллеги» и «с комсомольским приветом, искренне ваш». Удобное форматирование кода и цитат. Разворот ссылок. Интеграции вроде голосовалок с опять же удобным интерфейсом. Можно долго продолжать.
Нет, почтой конечно вполне себе можно пользоваться, и настроить ее так, что всем будет уютно и комфортно. Целый линукс вон по почте построили, и нормально им. Но как по мне, это лишние расходы на настройку окружения, поддержание его в порядке (те же правила фильтрации, который каждый настраивает себе сам) и выработку правил общения. Слак дает все это из коробки, и еще бантик рядом вешает.
maxlazar
13.02.2018 02:05+1Проблема всех этих чатах, что многие не соблюдают элементарной информационной гигиены. Часто вопросы в чатах идут кусками, люди их не обдумывают и задают беспорядочно. Опять же обратная связь тут с задержками. Разговор, который по телефону может занять 3 минуты, через чат может растянуться минут на 20. И все это время он будет отвлекать от работы.
Для профессий, представители которых большую часть времени работают в «потоке» (вроде разработчиков), чаты это вообще полное злой и performance killers.
Finesse
13.02.2018 02:59+1Я уже давно научился не отвлекаться на электронную почту и сообщения в мессенджерах. Slack мне не нравится по другой причине: он работает медленно как на компьютере, так и на телефоне; если смотреть объективно, то это кажется незначительной мелочью, но на самом деле это оставляет негативное впечатление где-то на подсознательном уровне. Возможно, поэтому он не прижился ни в одной из команд, в которых я работал.
Kobalt_x
13.02.2018 15:45>Slack работает медленно на телефоне
Вы просто не пользовались Skype for business aka lync
dmbreaker
13.02.2018 07:50Да дело не в слаках.
Люди! Перестаньте в мессенджерах начинать общение с сообщения "Привет" — это плохой тон! Пора бы уже понять, что мессенджер не для того, чтобы поздороваться, добавьте свой привет первым предложением сообщения и сразу к сути.
Обычно игнорю приветы, т.к. очевидно, что поздороваться на работе — это совсем не срочно.
LeonidY
13.02.2018 08:01Проблема давно известна, ее еще Айзек Азимов описал в «Время Писать» — royallib.com/book/azimov_ayzek/vremya_pisat.html
К сожалению, сейчас уже мало кто читает книги…
titulusdesiderio
13.02.2018 08:06+1У дядьки бомбит, потому что он не умеет пользоваться IM, путая их с ERP и офисными пакетами.
дело не в инструментах а в людях!
Если коллеги в чате #mainProject-dev постят котиков — они бы и в почте их всем рассылали и в gDoc вставляли.
Он просто работает с неадекватами, а винит в этом инструменты (:
michael_vostrikov
13.02.2018 08:39Огромная пропасть между тщательно обдуманной документацией и потоком сознания вперемешку с анонсами
Вот да. Особенно доставляет, когда всплывает уведомление "@person, надо это сделать", и выше 100500 сообщений, за которыми ты не следил.
BasilSnowman
13.02.2018 09:00сам по себе инструмент полезен. описанная проблема коммуникации скорее связана с атмосферой «взаимного уважения» в компании. если провести аналогии с офисом, это как начальник/менеджер, который постоянно кругами ходит по залу и пингует каждого сотрудника раз в час/полчаса. ПМ по сути должен держать в памяти занятость своего персонала, уровень поставленных задач и не дёргать народ по пустякам.
с другой стороны, есть еще отношения с заказчиком. и тут уже вступает куча нюансов. темперамент заказчика, темперамент менеджера, состояние проекта, темперамент разработчика, качество проделанной работы, сроки предстоящей и т.д. и т.п. худшая модель, когда заказчик тоже допущен в чат разработки. в этом случае может быть всё, что угодно. даже пинги "@here" и "@all" по любому поводу.
scherbakovx
13.02.2018 09:06Ну, про поиск и прокрукруту может и соглашусь. Но остальное – это же чисто проблемы управления. Мгновенные ответы, документация, общение в разных каналах… Все зависит от организации, а не от инструмента.
VulvarisMagistralis
13.02.2018 09:06Зависит от правил.
Мы в свое время пропесочили человека, который постоянно употреблял
@username
И все стало хорошо.
eoffsock
13.02.2018 10:28Для меня слак кроме коммуникатора еще и удобный интерфейс для автоматизации. Вечерние тесты в отдельном канале (специфика такая, что надо каждый вечер смотреть, как за день отработали сервисы, в срезе проблему не увидеть). Экспресс-тест одной командой, информация сразу в чат. Ворнинги от заббикса тоже в отдельном канале.
Для менеджеров пачка команд, формирующих отчеты сразу в чат, текстом и файлом. Гораздо удобнее, чем лезть в админку, искать нужный отчет, и так далее.
Правда у нас команда маленькая, флуда нет, проблем описанных нет. Может поэтому мне слак по душе.
teemour
13.02.2018 11:33Slack не исправит ваши коммуникации. Если вы нашли способ (на самом деле нет) исправить коммуникациии путём замедления и игнорирования то Slack показывает вам что вы неправы
php7
13.02.2018 11:39-4Что я скажу.
Многие вещи, если не большинство, говно.
Но быдло не замечает этого.
Они как мухи, слетевшиеся на говно.
Abyrvalgov
13.02.2018 11:54Какой ужасный перевод. Попытался понять из поста это:
В первый день своей первой работы трейдером единственной инструкцией, которую я получил, было «Когда рынок откроется, отключи телефон». С подтекстом «и всё остальное». Если кто-то скажет мне такое сегодня, я обниму этого человека, хотя я не фанат обнимашек.
Я пытался поговорить с людьми на эту тему, но мне отвечали: «Это офис, а не библиотека». В то время я был просто в ярости
Сдался, полез в оригинал, а там:
On day 1 of my first trading job the only instruction I received was ‘when the market is open, mute your phone.’ The subtext was ‘or else’. If someone said this to me today I’d give them a hug, and I’m not a hugger.
I’ve tried to have this conversation with people who respond with ‘this is an office; it shouldn’t be a library’.
lexore
13.02.2018 12:10Кстати, многие технические моменты, которые не исправить в веб-приложении слака, очень легко лечатся, если подключаться по протоколам irc/jabber (да, slack умеет и такое).
А уже в irc/xmpp клиенте можно настроить любые уведомления (или их отсутствие).
Плюс, сохраняется история (актуально, если вы пользуетесь бесплатной версией slack).dzzh
13.02.2018 14:36О, а это интересно, спасибо. Для сохранения истории кстати и веб-сервисы разные есть, которым можно дать доступ в Слак, а они будут агрегировать содержимое чатиков. Но тут большой вопрос, хотите ли вы давать доступ к своим фото котиков непонятным сервисам.
VolCh
13.02.2018 12:36Как по мне, то в компании должны быть правила, регламентирующие использование разных средств коммуникаций. Приоритеты, срочнлстб и тематика должны быть явно известны всем вовлеченным.
HurrTheDurr
13.02.2018 12:42Это новый, зачастую более эффективный, формат делового общения, к которому автор не смог адаптироваться и потерял производительность. Еще забавно видеть, что он приписывает себя к лучшим сотрудникам и считает адаптировавшихся к мессенджерам\опенспейсам — худшими. Если ты такой лучший, чего тебя надолго выбивает из колеи простой вопрос от коллеги, тогда как все окружающие довольны и производительность компании, в целом, повысилась? :)
VolCh
13.02.2018 15:32В чём его эффективность заключается?
HurrTheDurr
13.02.2018 23:13Это недостающее звено между насильным голосовым общением и медленной ни к чему особо не обязывающей почтой. Мне кажется, большая часть решаемых современными программистами задач недостаточно важны\сложны для вдумчивого обсуждения через почту и недостаточно срочны для звонков. Мессенджеры идеально подходят для обсуждения неважного несрочного, но, конечно, не заменяют почту\телефон полностью, а дополняют их. Использование средства общения, соответствующего классу решаемых задач, эффективнее, чем использование привычных, но неуместных, средств. В общем, я считаю, что новые фичи желательно придумывать голосом, обдумывать через почту, реализовывать\дебажить (а это большая часть времени) в чатах и, параллельно, фиксировать в документации.
VolCh
14.02.2018 13:12Мессенджеры идеально подходят для обсуждения неважного несрочного
В целом согласен, потому предпочитаю игнорировать во время когда занят важным и срочным, то есть всегда, кроме времени отведенного на отдых :)
sand14
13.02.2018 16:49тогда как все окружающие довольны и производительность компании, в целом, повысилась
Ну, не стоит говорить за всех.
Безотносительно обсуждаемой темы:
Если на уровне видимости "все окружающие довольны", то на самом деле это может быть совсем не так.
Доводилось наблюдать разные ситуации, когда "шеф, все пропало" — в состоянии проектов, рабочих процессах и/или отношениях в коллективе, а внешне большинство "держат марку" или — даже излучают позитив, придерживаясь официальной идеологии компании, или даже давая на 80% отличные оценки в анонимных опросах, инициированных руководством.
А если чуть копнуть — то недовольных если не большинство, то существенная часть в районе блок-пакета (25-30%).
Не всегда, но так бывает.
Так и в современных процессах разработки — много положительного по сравнению с условным waterfall, есть и определенные недостатки, но в целом — можно быть уверенными, что довольных ими — меньше, чем принято считать.
Это как в том опыте, когда сажают за стол несколько человек, все по очереди говорят, что круглый предмет на самом деле квадратный, а конце дают слово последнему, который не в курсе "договоренности", то в большинстве случаев последний соглашается с предыдущими ораторами.
HurrTheDurr
13.02.2018 21:03Ни в коем случае не говорю за всех, только в контексте статьи. Цитаты, по которым я сделал вывод, что адаптироваться к непрерывному потоку информации не может только автор, а у всех остальных все в порядке:
… Менеджерам он понравился…
В общем, я не увидел в статье конкретных примеров неэффективности мессенджеров, но увидел много личных трудностей автора с мессенджерами, а точнее — с непрерывно ускоряющимся ритмом жизни и увеличивающимся потоком информации. Причем, он считает, что все «лучшие сотрудники» имеют трудности с мессенджерами, что и вызвало мою личную неприязнь. Даже пример с пропущенной частицей «не» в сообщении совсем не выглядит впечатляющим. Я думаю, часть собеседников сразу поняли, что в предложении пропущено отрицание, а остальные поняли, куда нужно вставить «не» и инцидент был исчерпан через 10 секунд. Автор же от этих мелочных ситуаций чувствует себя персонажем кинокомедии. И, мне кажется, с каждым годом ему будет все труднее и труднее работать над «чокнутыми проектами» в безумных несущихся вперед молодых коллективах.
… мне отвечали: «Это офис, а не библиотека»…
… выросло целое поколение работников и даже компаний, которые никогда не работали таким образом (который привычен автору)…
… Люди проверяли жужжащие телефоны на планёрках. Уведомления из чата клик-клик-кликали без перерыва…
… сказал об этом менеджеру проекта, на что тот ответил: «Эх, у тебя синдром дефицита внимания»...
QuAzI
13.02.2018 15:21+1Жизненная и правильная статья.
Фрагментация кусков ТЗ между тикетам с полуживыми доками, чатикам и «живым общением» — это вообще отдельный ад. Апогей — это когда что-то (но далеко не всё) обсудили голосом (потому что кто-то решил что так быстрее/удобнее), таск либо не сделали, либо он состоит из «позвони, обсудим», а потом на приёмке у тебя спрашивают «Почему ты не сделал вот эту фичу именно вот так и с кандибобером», «Потому что про кандибобер никто не говорил», «Я совершенно точно (ведь ПМ не человек и ничего не забывает, да и слушатель тоже робот) говорил тебе про кандибобер — иди переделывай». И никому ничего не докажешь, что эта хотелка была выдумана, но не была озвучена, либо по ней были вопросы не позволяющие сделать её сейчас без ущерба для другого функционала. Без нормального целостного документирования невозможно понять, как должен работать/выглядеть результат, а чаты и голосовые обсуждения с документированием не связаны никак. Они в принципе не могут иметь важности чем сиюминутный факт, про который можно через 15 минут забыть вообще. Максимум — это пульнуть скриншот и переписка в духе «Так для тикета #123 с кандибобером будет ок? -Да». Всё, на этом активность в чате должна заканчиваться.
Ещё веселило, когда ПМ мог написать/позвонить в любой момент, через любой канал связи, даже на телефон около полуночи из другой страны, но все обращения к ПМ, если не через почту, вполне легко ПМом же игнорируются. Даже если это сообщение о том, что сервер почты сдох.
Ботоводство и прочая автоматизация на чатовых костылях — это отдельный вопрос, который тоже никак не связан с ведением проекта, ведением документации и внутрикомандной коммуникацией. Но те, кто про него тут вспоминают, кажется не поняли о чём пост.
ad1Dima
13.02.2018 17:15В неумении фиксировать договоренности слек тоже не виноват.
VolCh
13.02.2018 17:47Слак позиционируется, в том числе, и как инструмент для фиксации решений и договоренностей.
ad1Dima
13.02.2018 18:00Кем позиционируется? И вы, конечно же, имеете ввиду полную версию?
VolCh
13.02.2018 18:03Slack builds a searchable archive of your team’s… decisions ...
ad1Dima
13.02.2018 18:05Ну, то есть в полной версии можно найти договоренности, которые вы зафиксировали. Если вы, конечно, умеете.
Да, можно.VolCh
13.02.2018 18:13Можно, но сложно. А ещё очень легко пропустить решение, тебя касающееся.
ad1Dima
13.02.2018 18:49А ещё очень легко пропустить решение, тебя касающееся
Как и при любом другом способе коммуникации, если не фиксировать решения.VolCh
13.02.2018 21:02Решения могут быть зафиксированы в слаке, но их легко пропустить.
VulvarisMagistralis
13.02.2018 21:03Решения могут быть зафиксированы в слаке, но их легко пропустить.
А это уже отмазки
Решения были зафиксированы — вот доказательства.VolCh
13.02.2018 21:12Где доказательства, что я с ними ознакомлен, если уж на то пошло.
ad1Dima
15.02.2018 12:09+1Это всё проблемы построения процессов.
Решение зафиксировано, когда есть четкое его описание, с которым все ознакомились и, так или иначе, с ним согласились.
Это не зависит от способа коммуникации. Армейское «Есть {пересказ приказа}» как раз форма фиксации договоренности.
Где доказательства, что ты ознакомлен с решением в почте? Там ровно два способа это сделать: уведомление о прочтении (которое криво работает) и ок ответный письмом, которое производит ненужное уведомление всех участников переписки.
В том же слеке так же два способа: окнуть сообщением (причем тут как может быть уведомление одного или нескольких лиц, так и может его не быть), окнуть реакцией на сообщение, которое вообще никого не отвлекает. Кому надо — посмотрит.VolCh
15.02.2018 15:02ответный письмом, которое производит ненужное уведомление всех участников переписки.
Очень спорно. Как правило, решение как раз касается всех участников переписки и они должны знать и суть решения, и как оно их лично касается, и кого и как оно касается ещё.
В том же слеке так же два способа
Способов много в разных системах. Но на практике в электронной почте сложнее пропустить и проще найти впоследствии зафиксированное решение. В целом, конечно, для этого лучше иметь какую-то СЭД, но почта на практике лучше IM для фиксации важных решений.
ad1Dima
15.02.2018 15:04Очень спорно. Как правило, решение как раз касается всех участников переписки и они должны знать и суть решения, и как оно их лично касается, и кого и как оно касается ещё.
Я понял, почему вы так много спорите. Вы просто ответы по диагонали читаете.
Но на практике в электронной почте сложнее пропустить и проще найти впоследствии зафиксированное решение.
Видимо у вас не было тредов на 20 человек из которых половина не умете пользоваться CC и reply allVolCh
15.02.2018 15:06Нет, не по диагонали. Просто отвечаю на то, на что считаю нужным ответить.
ad1Dima
15.02.2018 15:08И читате то, что считаете нужным прочитать.
Речь шла про подтверждение о прочтении и согласии с зафиксированным решением. Если в ответ на него 20 человек напишут в почту «ок», то это нифига не хорошо.VolCh
15.02.2018 16:34Это нормально. Современные почтовые клиенты умеют группировать письма в цепочки.
QuAzI
13.02.2018 18:25+1В статье речь не только про слак и не конкретно про слак среди IM, а про то, что народ злоупотребляет ими, порождает много информационного шума, да ещё и преподносит эти косяки как фичи, делает с их помощью то, чего через них делаться не должно, про любителей поболтать там, где не нужно болтать, а так же про то, что нужно делать нормальную документацию, которую можно прочитать одним заходом и всё станет понятно, которую не нужно будет собирать по логам чатов и крупицам «кто-то что-то слышал на каком-то митинге».
Можно через чат скинуть ссылку на конкретно место в документации, но нельзя позиционировать чат как замену всему и вся. И тем более нельзя в него долбить аки «официант, господам скучно». Всё, что прошло мимо документации и нормальной системы учёта требований — проходит мимо.
Вообще-то электронной почты эти чатовские проблемы тоже касаются, народ что-то шлёт и ждёт что им ответят сразу, плюс километровые портянки из переписки. Но т.к. все привыкли, что почта редко проверяется, то там стало меньше таких заскоков.
Точно так же применимо и для «суперсрочных телефонных звонков», когда человек не может и даже не собирается чётко объяснить, в чём проблема — во первых просто потому, что скрины и логи звонком не передаются, во вторых, люди почему-то любят играть в сломанный телефон и говорить какую-то ересь вместо состоявшихся фактов (не тот номер записи, не тот пароль, не тот клиент… всё что угодно) + бывают проблемы со связью, а потом они с чувством выполненного долга пропадают (отрубают телефон и идут спать например).
Т.е. в конце всё упирается в то, что нет нормальной документации и системы ведения тикетов, которые в принципе были бы самодостаточны без всяких чатиков, звонков и митингов. Все эти чатики расхолаживают (люди считают что они выполнили долг — доставили информацию, но на самом деле в документацию не попало ничего) и отвлекают, даже если не бибикают явно, а просто в трее навязчиво висит «вы не прочли 100500 сообщений».
А вообще я долго искал какое-нибудь готовое решение, которое можно было бы захостить у себя, в котором можно было бы вести проекты от корки до корки для SOHO (начиная с беклога, тикетов, таймтрекинга, ведения клиентов продаванами, хелпдеска, заканчивая VCS, review), но так ничего и не нашёл, всё равно половина на github/gitlab/bitbucket, а вторая половина размазана по Dropbox/Paper/Google drive/Redmine/CRM и чатикам. И эта фрагментация жрёт время и бесит.ad1Dima
13.02.2018 18:51В конце всё упирается в косяки построения бизнес-процессов. Глупо обвинять в этом инструменты (хоть в частности. хоть в общем)
VolCh
13.02.2018 21:11Ну как сказать. На уровне бизнес-процессов описано "передать информацию о том-то такому-то". И люди передают тем способом, который удобен для отправки. Но вот далеко не факт, что этот способ будет удобен для того, кому информация передаётся. Что он вовремя заметит и вообще заметит факт передачи ему информации. Не инструмент, конечно, в этом виноват, а тот, кто решил использовать неподходящий инструмент для передачи информации.
dzzh
14.02.2018 00:36А вообще я долго искал какое-нибудь готовое решение, которое можно было бы захостить у себя, в котором можно было бы вести проекты от корки до корки для SOHO
Если можно опустить требование хостинга у себя, попробуйте продукты от бывших 37signals, которые сейчас Basecamp + Highrise называются, вдруг понравится. Сам не пользовался, но читаю их блог, все звучит весьма осмысленно.
lazexe
13.02.2018 16:19«Электронная почта гораздо лучше группирует обсуждения в цепочки, но Slack убил такую возможность» — после этого перестал читать статью. Забыли как по эл. почте годами получали ответ на вопрос?
Да и вообще, правильно сказали выше: не умение отключать уведомления не повод поливать грязью Slack. Я наоборот ничего лучшего не встречал…
И еще: критикуешь — предлагай!
Papashkin
13.02.2018 20:47Заметка по Слаку:
Есть вопрос к ПМ. И два варианта решения вопроса:
1. Собираю информацию по вопросу, пишу сообщение в Слак и отправляю ПМ. Жду ответ;
2. Иду к ПМ и напрямую спрашиваю, что к чему и как решить.
Если этот вопрос не первой важности — то его спокойно можно отложить до митинга. А если вопрос первой степени важности, то какой из вариантов лучше?
До сих пор не знаю, как относится к подобного рода моментам работы.
MaratPro
13.02.2018 20:47Тема актуальная, но как всегда надо понимать, что есть разработчики, а есть менеджеры и это люди с разных планет с разными ценностями (приоритетами). Слак для разработчика — это постоянно отвлекающая штука, а для менеджера например оперативное ведение проекта (особенно если у заказчика все горит). Поэтому думаю нужно просто сформировать культуру общения и работы, и Слак не будет такой проблемой.
MisterParser
14.02.2018 20:32В день я общаюсь примерно с 15-20 клиентами и отвечаю на их вопросы, изучаю ошибки, которые они присылают. Если постоянно быть онлайн, то времени на создание нового ПО не остаётся. Поэтому, когда мне нужно сделать задачу, я отключаюсь из скайпа на несколько часов, делаю задачу, а потом возвращаюсь онлайн. Иначе приходится каждые 10 минут смотреть, что же тебе там написали в скайп. Работа в таком случае превращается в прокрастинацию от одного вопроса пользователя до другого.
MooNDeaR
Т.е. ваша неспособность отключить уведомления и отвечать на сообщения раз в час — это проблема Slack?
TheKnight
Если я не отвечаю на сообщение в течении часа — люди грустят.
К сожалению, слак, как и любые другие мессенджеры плохо умеет отделять важные сообщения от неважных.
ad1Dima
AlexTest
Никто никого не должен отвлекать по пустякам, вообще обычный разработчик должен в рабочее время заниматься только выполнением текущих запланированных задач и реагировать только на два типа сообщений:
1. Авария — что-то серьезное на продакшене или ошибка на уровне архитектуры, в первом случае срочно чиним, во втором останавливаемся и обсуждаем т.к. дальнейшая работа может просто оказаться бессмысленной. Если часто проблемы с продом — это чаще всего косяк тетировщиков, если хреново спланирована архитектура или выбраны не те инстументы — косяк архитекторов.
2. Блокировка — т.е. отсутствие реакции на это сообщение реально блокирует работу другого человека. Если есть большой поток блокирующих сообщений, то это либо отсутствие компетенции у других исполнителей — косяк того кто их нанял, либо хреновое планирование и распределение задач между исполнителями — косяк ПМа.
Если же разработчик вынужден по работе напрямую общаться с кем либо кроме ПМа и других разработчиков (например с заказчиками), то ему лучше сменить место работы!
u440
А с аналитиками или архитектором разработчику можно общаться?
AlexTest
Если общаться в специально отведенное время (регулярные митинги, запланированные обсуждения, встречи и т.п.), то можно и нужно общаться хоть с кем: заказчики, аналитики, архитекторы, тестировщики и т.д. — в рабоче время только с руководителем и непосредственными коллегами.
VolCh
А с непосредственными коллегами зачем? Чем они отличаются от архитектора того же?
AlexTest
с непосредственными коллегами разработчик общается по блокировкам см. ниже
dzzh
наверное скучно быть разработчиком
VolCh
Как минимум, ещё
AlexTest
Если кому-то что-то еще нужно объяснять после совместного обсуждения и принятия решения, то у этого кого-то либо проблемы с коммуникацией на собрании, либо недостаток компетенции. В любом случае такие запросы на объяснения должны проходить через ПМа.
Под блокировкой я понимаю либо то, что кому-то нужен еще пока не сделанный твой код, либо то, что необходимый для другого разработчика уже сделанный твой код не работает должным образом и он не может продолжать разработку своей части кода.
VolCh
Недостаток компетенции сплошь и рядом при приходе на новый проект. Ты можешь быть отличным техническим специалистом, но не понимать предметной области, особенностей проекта, фреймворка, соглашений команды, нюансов конкретного модуля и т. п. Но в ходе обсуждений все вопросы не возникнут. А если их задавать ПМу, то проблема не решается в рамках вашей классификации — это не авария и не блокировка. В лучшем случае это потеря времени на самостоятельное изучение, в среднем — то же плюс трата времени на "изобретение велосипеда", в худшем — причина будущей аварии или блокировки.
AlexTest
Зато теперь ПМ знает, что хотя некто себя и позиционирует
на самом деле он понимаетAlexTest
пардон, опечатка, следует читать так:
на самом деле он НЕ понимает
VolCh
Это к технической компетенции не относится. Я не беру ситуации, когда человек вводил в заблуждение утверждая, что он знает какой-то фреймворк. Например, когда человека перекинули на другой проект, где используется не тот фреймворк, специалистом в котором он себя позиционирует. Тот же ПМ решил "да все они одинаковые, знает один — быстро и со вторым разберётся"
tangro
Давайте я Вас научу отличать важные сообщения от неважных: если к Вам врываются в кабинет и что-то кричат — это важное сообщение, если звонят по телефону — это сообщение средней важности, если пишут в Slack — то можно отключить сообщения и отвечать на них раз в час.
TheKnight
Факап чатики?
VulvarisMagistralis
Ну лет 15 назад было примерно так.
Сейчас же — время интернет-коворкинга
tangro
Если у людей есть время потыкать кнопочки набирая вопрос и подождать пока в ответ ему потыкают кнопочки, набирая ответ — то это уже не вопрос критической важности. Важные вопросы — задают голосом и ответы хотят услышать немедленно.
VulvarisMagistralis
1) Гудки, гудки, пока человек возьмет трубку. При том, что ты занят в это время держанием трубки и уже ничего сделать не можешь. Да я в курсе про громкую связь, она реально экономит время, высвобождает руки при очень длительных дозвонах.
2) Концентрация. Пока вы ждете ответа на том конце телефона — это она теряется. Когда пишете — сконцентрировались — изложили мысль — и начали заниматься своими делами в ожидании ответа.
3) Думается у ИТ-шников навык быстрого набора на клавиатуре достаточно хорош.
Но, согласен, иногда важное дело лучше по телефону оговорить.
Не срочное, а важное.
Я например, могу электронную почту читать не каждый день, не то, что отвечать.
Если завис сервер — мне лучше позвонить. Или СМС отправить. Или Телеграмом.
Hardcoin
То, что вы описываете, обычно называют "срочно". Важно — это то, что нужно обязательно сделать, но не обязательно сейчас (как пример, купить еды на ужин — важно, но может подождать до вечера).
Да и не понятно, как ворваться в кабинет к человеку, который прямо сейчас в другой стране.
setevoy4
У нас, например, если не отвечаешь в течении 10-15 минут в Slack — вполне могут пингануть уже твоего менеджера на тему «А где ваш сотрудник шляется и почему он морозится?» (мы в Киеве, клиенты в Европе). Понятно, что ПМ не будет рад такому, и начнёт спрашивать тебя — почему ты не отвечаешь.
Так что — «Не всё так просто» (с).
Dreyk
зависит от компании. у нас считается нормой ответ в слак в течение часа. да и вообще, нет у нас нормы как таковой. мы в Киеве и Кракове, клиенты везде по всему миру
sand14
До появления быстрого интернета и мессенджеров подобное уже пытались внедрять/эмулировать через электронную почту, типа необходимости ответа на письмо в течение 12 минут.
ad1Dima
Methos
Так это же прекрасно!
Прекрасно работать в такой компании, в которой нужно создавать видимость работы.
Нужно создать видимость работы.
Помню, в 2003 году была ICQ, а там охренительная куча разных плагинов.
Так вот поставил я тогда плагин автоответа или даже бота.
И представьте, люди, которые писали мне сообщения, спокойно могли разговаривать с ботом, даже не понимая, что это робот, а думая, что это реальный человек!
Что мешает поставить такое для slack и спокойно отходить от раб-места на пару часов?
sevikl
у нас, например, клиент вообще не может написать сотруднику, только через ПМ. он для того и нужен, чтобы работать точкой соприкосновения и не мешать разрабам.
tangro
В течении Х минут на вопрос должна отвечать первая линия техподдержки и больше, наверное, никто. Если заказчик хочет получать ответы на рандомные вопросы каждые 10 минут от конечного разработчика — то пусть осознаёт, что такой разработчик будет способен лишь на мелкую рутину, а большие серьёзные задачи не будут сделаны никогда.
Arris
Невыдуманный диалог.
timelle
Таких ждунов лечит спам безусловно важными вопросами. Или ответами.
— Ты почему в слаке не отвечаешь? Я тебе три раза писал.
— Я работаю!
— Ну и что? Мог бы ответить! Я же жду!
Arris
На таких ждунов приходится тратить время. Так что не вариант.
MaZaNaX
работал в одной компании, где, если в течение 2 минут нет ответа на вопрос менеджера, тебе звонят в скайп и при этом ещё с претензией по поводу игнора
Methos
Берёшь трубку скайпа и смачный такой звук сливающегося унитаза туда.
slayeek
На один раз прокатит :) А если каждый раз так делать, но оборудуют место с туалете.
maxlazar
отвечать на сообщение раз в час? Это же какие задачи должны быть, чтобы иметь возможность каждый час выходить из потока не для того, чтобы максимум размяться, а «что бы поотвечать» на вопросы?
Любое подобное переключение выбивает большинство людей на 15 минут (не считая время затраченное на ответы). Люди с задатками менеджеров могут быстрее возвращаться к работе, но опять же — это исключение.
Мы стараемся все общение в чатах привести к правилу — только что-то очень важно. И то — если человек в потоке и его день расписан, он в полном праве полностью отключить messenger; если кому-либо надо задать вопросы — пожалуйста в email, или в JIRA;
MooNDeaR
Персонально для меня не проблема переключаться раз в час, чтобы ответить на сообщения. Я стараюсь в процессе работы не входить в состоянии потока, потому что в этом состоянии моя внимательность к коду на нуле, допускаются идиотские архитектурные ошибки, к тому же результативность получается синусоидальной — то очень хорошо, то плохо. В таких условиях планирование работы становится просто невозможным и сильно зависимым от внешних факторов, как необходимость отвечать на письма, например.
К тому же, я ложил болт на всех менеджеров и прочих ждунов. Всем и каждому, кто от меня требует отвечать чаще, чем раз в час, я отвечаю одно и то же: «Я работаю, ждите». Кто-то бесится, кто-то понимает. Пока еще не увольняли и даже не грозили уволить, просто смирялись со временем, считая меня мудаком. Меня устраивает.