Comments 138
Т.е. ваша неспособность отключить уведомления и отвечать на сообщения раз в час — это проблема Slack?
Если я не отвечаю на сообщение в течении часа — люди грустят.
К сожалению, слак, как и любые другие мессенджеры плохо умеет отделять важные сообщения от неважных.
К сожалению, слак, как и любые другие мессенджеры плохо умеет отделять важные сообщения от неважных.
Если я не отвечаю на сообщение в течении часа — люди грустят.Это должна быть их проблема, а не ваша.
Это должна быть их проблема, а не ваша.Этой проблемы вообще не должно быть.
Никто никого не должен отвлекать по пустякам, вообще обычный разработчик должен в рабочее время заниматься только выполнением текущих запланированных задач и реагировать только на два типа сообщений:
1. Авария — что-то серьезное на продакшене или ошибка на уровне архитектуры, в первом случае срочно чиним, во втором останавливаемся и обсуждаем т.к. дальнейшая работа может просто оказаться бессмысленной. Если часто проблемы с продом — это чаще всего косяк тетировщиков, если хреново спланирована архитектура или выбраны не те инстументы — косяк архитекторов.
2. Блокировка — т.е. отсутствие реакции на это сообщение реально блокирует работу другого человека. Если есть большой поток блокирующих сообщений, то это либо отсутствие компетенции у других исполнителей — косяк того кто их нанял, либо хреновое планирование и распределение задач между исполнителями — косяк ПМа.
Если же разработчик вынужден по работе напрямую общаться с кем либо кроме ПМа и других разработчиков (например с заказчиками), то ему лучше сменить место работы!
А с аналитиками или архитектором разработчику можно общаться?
Если общаться в специально отведенное время (регулярные митинги, запланированные обсуждения, встречи и т.п.), то можно и нужно общаться хоть с кем: заказчики, аналитики, архитекторы, тестировщики и т.д. — в рабоче время только с руководителем и непосредственными коллегами.
А с непосредственными коллегами зачем? Чем они отличаются от архитектора того же?
с непосредственными коллегами разработчик общается по блокировкам см. ниже
Жуть какая.
Вы описываете программный конвейер времён Генри Форда. По выпуску релизов «Железной Лиззи» :)
В нормальных компаниях или ИТ-блоках (банков, розницы, производственных компаний) в порядке вещей работа аналитика, разработчика и тестировщика в связке по задаче.
Когда разработчик плотно общается со всеми участниками цепи в ходе уточнения требований, корректировки тест-кейсов и прочих необходимых «активностей по взаимодействию».
«Тупо кодить» в современных условиях просто нельзя — как аналитик должен понимать «что там по капотом», так и разработчик — «а для чего собственно этот алгоритм предназначен в конечном счёте».
Про «тикеты в JIRA» справедливо ответили ниже.
Вы описываете программный конвейер времён Генри Форда. По выпуску релизов «Железной Лиззи» :)
В нормальных компаниях или ИТ-блоках (банков, розницы, производственных компаний) в порядке вещей работа аналитика, разработчика и тестировщика в связке по задаче.
Когда разработчик плотно общается со всеми участниками цепи в ходе уточнения требований, корректировки тест-кейсов и прочих необходимых «активностей по взаимодействию».
«Тупо кодить» в современных условиях просто нельзя — как аналитик должен понимать «что там по капотом», так и разработчик — «а для чего собственно этот алгоритм предназначен в конечном счёте».
Про «тикеты в JIRA» справедливо ответили ниже.
В нормальных компаниях… в порядке вещей работа аналитика, разработчика и тестировщика в связке… Когда разработчик плотно общается со всеми участниками цепи ...В моем понимании слова «плотное общение» означают частое, регулярное и скорее всего достаточно длительное. И если я вас правильно понял — ответьте пожалуйста, по какому тарифу в этих «нормальных компаниях» оплачивают разработчику и остальным «участникам цепи» рабочее время, потраченное на такое вот «плотное общение»?
«Тупо кодить» в современных условиях просто нельзя — как аналитик должен понимать «что там по капотом», так и разработчик — «а для чего собственно этот алгоритм предназначен в конечном счёте».«Тупо кодить» нельзя в любых условиях. Для того, чтобы все понимали кто, что и для чего делает — вполне достаточно общения в предназначенное для этого время, конечно при условии, что все участники процесса — профессионалы своего дела.
наверное скучно быть разработчиком
Как минимум, ещё
- Нужно кому-то что-то объяснить. При условии, что потери ресурсов на переключения контекста и объяснения меньше чем потери ресурсов на самостоятельное изучение вопроса интересующимся и, возможно, принятие им неправильного решения. Не реальная блокировка ещё, но сопоставима с ней по последствиям: ресурсы компании будут тратиться не оптимально, близко к простою части из них, а в худших случаях будут тратиться во вред компании.
Если кому-то что-то еще нужно объяснять после совместного обсуждения и принятия решения, то у этого кого-то либо проблемы с коммуникацией на собрании, либо недостаток компетенции. В любом случае такие запросы на объяснения должны проходить через ПМа.
Под блокировкой я понимаю либо то, что кому-то нужен еще пока не сделанный твой код, либо то, что необходимый для другого разработчика уже сделанный твой код не работает должным образом и он не может продолжать разработку своей части кода.
Под блокировкой я понимаю либо то, что кому-то нужен еще пока не сделанный твой код, либо то, что необходимый для другого разработчика уже сделанный твой код не работает должным образом и он не может продолжать разработку своей части кода.
Недостаток компетенции сплошь и рядом при приходе на новый проект. Ты можешь быть отличным техническим специалистом, но не понимать предметной области, особенностей проекта, фреймворка, соглашений команды, нюансов конкретного модуля и т. п. Но в ходе обсуждений все вопросы не возникнут. А если их задавать ПМу, то проблема не решается в рамках вашей классификации — это не авария и не блокировка. В лучшем случае это потеря времени на самостоятельное изучение, в среднем — то же плюс трата времени на "изобретение велосипеда", в худшем — причина будущей аварии или блокировки.
Зато теперь ПМ знает, что хотя некто себя и позиционирует
отличным техническим специалистомна самом деле он понимает
предметной области, особенностей проекта, фреймворка, соглашений команды ...
пардон, опечатка, следует читать так:
на самом деле он НЕ понимает
на самом деле он НЕ понимает
Это к технической компетенции не относится. Я не беру ситуации, когда человек вводил в заблуждение утверждая, что он знает какой-то фреймворк. Например, когда человека перекинули на другой проект, где используется не тот фреймворк, специалистом в котором он себя позиционирует. Тот же ПМ решил "да все они одинаковые, знает один — быстро и со вторым разберётся"
обычный разработчик должен в рабочее время заниматься только выполнением текущих запланированных задач
такие разработчики плохо подходят для работы в продуктовых компания/стартапах.
позиция «меня волнуют только тикеты в Jira» — много где встречается с недопониманием
То о чем я написал — это не пожелание разработчика, это должна быть позиция компании. Лично у меня большее недопонимание вызвало бы смещение приоритета от тасков в Jira в сторону различного не запланированного «общения».
Хотя если в упомянутых вами компания/стартапах разработчику платят не за выполнение задач, а за «общение», то почему нет — пусть «общается».
Хотя если в упомянутых вами компания/стартапах разработчику платят не за выполнение задач, а за «общение», то почему нет — пусть «общается».
Если контекст, в котором находится разработчик, шире чем просто тикеты в Jira — с высокой долей вероятности ваш итоговый продукт будет лучше.
Я работаю в продуктовой компании и ее позиция такова: успех нашего продукта = успех каждого из нас. если над нашим продуктом думать будет не только продакт команда, но еще и каждый на проекте — мы достигнем бОльшего успеха с меньшим количеством ошибок.
А вот эти все
Я работаю в продуктовой компании и ее позиция такова: успех нашего продукта = успех каждого из нас. если над нашим продуктом думать будет не только продакт команда, но еще и каждый на проекте — мы достигнем бОльшего успеха с меньшим количеством ошибок.
А вот эти все
в рабочее время заниматься только выполнением текущих запланированных задач— это выступления в пользу бедных. «Пускай менеджеры думают, а я кодик попишу» — путь в никуда для компании, которая делает что-то, а не просто продает тушки внешним заказчикам
успех нашего продукта = успех каждого из насНу если все в вашей компании являются одновременно еще и совладельцами «вашего продукта» (что предполагает получение каждым своей части прибыли), то тогда — да, все правильно. Если ли же дело обстоит по другому, то все эти лозунги — просто разводилово исполнителей на дополнительную и естественно неоплачиваемую работу, которую им надо выполнить помимо основной.
В моей компании все выполняют хорошо именно свою работу и получают именно за это хорошую зарплату. Как показала практика, это возможно только при тщательном планировании работ, их правильном распределении между исполнителями и четком определении зоны ответственности каждого исполнителя, что (возвращаясь к теме) исключает какое-либо дополнительное «общение» в рабочее время.
минус подобных разработчиков в том, что они реально хорошо работают только если все тщательно спланировано. в критической же ситуации они теряются и оказываются абсолютно неспособны срочно решить внезапную проблему.
это вообще не обязательно. я хочу получать удовольствие от своей работы, я хочу того самого пресловутого творчества, новых идей и всего такого. если я не вовлечен в процесс, не принимаю участия в обсуждениях и просто плыву по течению бездумно делая что мне написали в тикет — какое от этого удовольствие? какое от этого ощущение своего вклада в итоговый продукт?
предполагает получение каждым своей части прибыли
это вообще не обязательно. я хочу получать удовольствие от своей работы, я хочу того самого пресловутого творчества, новых идей и всего такого. если я не вовлечен в процесс, не принимаю участия в обсуждениях и просто плыву по течению бездумно делая что мне написали в тикет — какое от этого удовольствие? какое от этого ощущение своего вклада в итоговый продукт?
Давайте я Вас научу отличать важные сообщения от неважных: если к Вам врываются в кабинет и что-то кричат — это важное сообщение, если звонят по телефону — это сообщение средней важности, если пишут в Slack — то можно отключить сообщения и отвечать на них раз в час.
Факап чатики?
Давайте я Вас научу отличать важные сообщения от неважных: если к Вам врываются в кабинет и что-то кричат — это важное сообщение, если звонят по телефону — это сообщение средней важности, если пишут в Slack — то можно отключить сообщения и отвечать на них раз в час.
Ну лет 15 назад было примерно так.
Сейчас же — время интернет-коворкинга
Если у людей есть время потыкать кнопочки набирая вопрос и подождать пока в ответ ему потыкают кнопочки, набирая ответ — то это уже не вопрос критической важности. Важные вопросы — задают голосом и ответы хотят услышать немедленно.
Если у людей есть время потыкать кнопочки набирая вопрос и подождать пока в ответ ему потыкают кнопочки, набирая ответ — то это уже не вопрос критической важности. Важные вопросы — задают голосом и ответы хотят услышать немедленно.
1) Гудки, гудки, пока человек возьмет трубку. При том, что ты занят в это время держанием трубки и уже ничего сделать не можешь. Да я в курсе про громкую связь, она реально экономит время, высвобождает руки при очень длительных дозвонах.
2) Концентрация. Пока вы ждете ответа на том конце телефона — это она теряется. Когда пишете — сконцентрировались — изложили мысль — и начали заниматься своими делами в ожидании ответа.
3) Думается у ИТ-шников навык быстрого набора на клавиатуре достаточно хорош.
Но, согласен, иногда важное дело лучше по телефону оговорить.
Не срочное, а важное.
Я например, могу электронную почту читать не каждый день, не то, что отвечать.
Если завис сервер — мне лучше позвонить. Или СМС отправить. Или Телеграмом.
То, что вы описываете, обычно называют "срочно". Важно — это то, что нужно обязательно сделать, но не обязательно сейчас (как пример, купить еды на ужин — важно, но может подождать до вечера).
Да и не понятно, как ворваться в кабинет к человеку, который прямо сейчас в другой стране.
У нас, например, если не отвечаешь в течении 10-15 минут в Slack — вполне могут пингануть уже твоего менеджера на тему «А где ваш сотрудник шляется и почему он морозится?» (мы в Киеве, клиенты в Европе). Понятно, что ПМ не будет рад такому, и начнёт спрашивать тебя — почему ты не отвечаешь.
Так что — «Не всё так просто» (с).
Так что — «Не всё так просто» (с).
зависит от компании. у нас считается нормой ответ в слак в течение часа. да и вообще, нет у нас нормы как таковой. мы в Киеве и Кракове, клиенты везде по всему миру
До появления быстрого интернета и мессенджеров подобное уже пытались внедрять/эмулировать через электронную почту, типа необходимости ответа на письмо в течение 12 минут.
Понятно, что ПМ не будет рад такому, и начнёт спрашивать тебя — почему ты не отвечаешь.Потому что РАБОТАЮ. Отвечать — работа менеджера.
Так это же прекрасно!
Прекрасно работать в такой компании, в которой нужно создавать видимость работы.
Нужно создать видимость работы.
Помню, в 2003 году была ICQ, а там охренительная куча разных плагинов.
Так вот поставил я тогда плагин автоответа или даже бота.
И представьте, люди, которые писали мне сообщения, спокойно могли разговаривать с ботом, даже не понимая, что это робот, а думая, что это реальный человек!
Что мешает поставить такое для slack и спокойно отходить от раб-места на пару часов?
Прекрасно работать в такой компании, в которой нужно создавать видимость работы.
Нужно создать видимость работы.
Помню, в 2003 году была ICQ, а там охренительная куча разных плагинов.
Так вот поставил я тогда плагин автоответа или даже бота.
И представьте, люди, которые писали мне сообщения, спокойно могли разговаривать с ботом, даже не понимая, что это робот, а думая, что это реальный человек!
Что мешает поставить такое для slack и спокойно отходить от раб-места на пару часов?
UFO just landed and posted this here
В течении Х минут на вопрос должна отвечать первая линия техподдержки и больше, наверное, никто. Если заказчик хочет получать ответы на рандомные вопросы каждые 10 минут от конечного разработчика — то пусть осознаёт, что такой разработчик будет способен лишь на мелкую рутину, а большие серьёзные задачи не будут сделаны никогда.
— Ты почему в слаке не отвечаешь? Я тебе три раза писал.
— Я работаю!
— Ну и что? Мог бы ответить! Я же жду!
Невыдуманный диалог.
работал в одной компании, где, если в течение 2 минут нет ответа на вопрос менеджера, тебе звонят в скайп и при этом ещё с претензией по поводу игнора
отвечать на сообщение раз в час? Это же какие задачи должны быть, чтобы иметь возможность каждый час выходить из потока не для того, чтобы максимум размяться, а «что бы поотвечать» на вопросы?
Любое подобное переключение выбивает большинство людей на 15 минут (не считая время затраченное на ответы). Люди с задатками менеджеров могут быстрее возвращаться к работе, но опять же — это исключение.
Мы стараемся все общение в чатах привести к правилу — только что-то очень важно. И то — если человек в потоке и его день расписан, он в полном праве полностью отключить messenger; если кому-либо надо задать вопросы — пожалуйста в email, или в JIRA;
Любое подобное переключение выбивает большинство людей на 15 минут (не считая время затраченное на ответы). Люди с задатками менеджеров могут быстрее возвращаться к работе, но опять же — это исключение.
Мы стараемся все общение в чатах привести к правилу — только что-то очень важно. И то — если человек в потоке и его день расписан, он в полном праве полностью отключить messenger; если кому-либо надо задать вопросы — пожалуйста в email, или в JIRA;
Персонально для меня не проблема переключаться раз в час, чтобы ответить на сообщения. Я стараюсь в процессе работы не входить в состоянии потока, потому что в этом состоянии моя внимательность к коду на нуле, допускаются идиотские архитектурные ошибки, к тому же результативность получается синусоидальной — то очень хорошо, то плохо. В таких условиях планирование работы становится просто невозможным и сильно зависимым от внешних факторов, как необходимость отвечать на письма, например.
К тому же, я ложил болт на всех менеджеров и прочих ждунов. Всем и каждому, кто от меня требует отвечать чаще, чем раз в час, я отвечаю одно и то же: «Я работаю, ждите». Кто-то бесится, кто-то понимает. Пока еще не увольняли и даже не грозили уволить, просто смирялись со временем, считая меня мудаком. Меня устраивает.
К тому же, я ложил болт на всех менеджеров и прочих ждунов. Всем и каждому, кто от меня требует отвечать чаще, чем раз в час, я отвечаю одно и то же: «Я работаю, ждите». Кто-то бесится, кто-то понимает. Пока еще не увольняли и даже не грозили уволить, просто смирялись со временем, считая меня мудаком. Меня устраивает.
А как же треды в слаке? Это ли не цепочки писем?
Про прокрутку — в точку
Вот как человек, который вкусил запретный плод пм-ства, не могу не задать вопрос: а как автор видит идеальную коммуникацию в команде и какими типами средств она должна достигаться?
Это перевод статьи. Очень имхо, но мне нравился google way. Делался программистами для программистов. Проект не взлетел google его закрыл, но были последователи и кое что осталось. Исходный код на github. «Потыкать палочкой» можно здесь пока демо сервер работает.
Похоже на чат и wiki в «одном флаконе» или на чат в котором можно править сообщения и смотреть историю правок. Непосредственно чат не заменяет. Это больше похоже на одновременную правку wiki страницы несколькими пользователями одновременно.
Есть мобильный клиент. Есть минимальная интеграция. Но ребята не смогли монетизировать проект выложили код и прекратили разработку.
Похоже на чат и wiki в «одном флаконе» или на чат в котором можно править сообщения и смотреть историю правок. Непосредственно чат не заменяет. Это больше похоже на одновременную правку wiki страницы несколькими пользователями одновременно.
Я думаю, что исправление и тщательное исследование более важны, чем первоначальные реакции. Мне больше нравится модель Google Docs, где оповещения создаются на комментарии/вопросы, а не на первоначальный текст.Вот это там есть, это создавалось на основе Google Docs. И все сгруппировано в цепочки. Удобно общаться строго на определенную тему, но это не чат, это подобно обсуждению в карточки Trello. Поскольку карточек как Trello нет, то и никакого продвижения icebox theory нет. Собрали высказывания по теме, перекинули выводы в документы или в wiki, закрыли обсуждение, удалили цепочку.
Есть мобильный клиент. Есть минимальная интеграция. Но ребята не смогли монетизировать проект выложили код и прекратили разработку.
Slack действительно во многом неудобен. Я даже в свое свободное время тоже пытаюсь сделать нечто среднее между чатом и форумом. Проект не очень популярен, но с друзьми общаться получается.
Спасибо за наводку, ушел крутить в докере.
Я так понимаю, под «google way» подразумевался Google Wave.
Это больше похоже на одновременную правку wiki страницы несколькими пользователями одновременно.
Google Docs умеет. Confluence умеет.
Идеально — это когда с пм-ом коммуницируешь только пару раз в неделю на митингах и потом больше его не видишь, ни в холле, ни в почте, ни тем более в слаке. Если что-то очень серьезно-неотложное, то пм или менеджер пишет мыло или может сам зайти доложить. А слак только для прояснения чего-то непонятного. Когда все ясно — можно писать Jira.
Да, и еще если кто-то заикается про работу в потоке — гоните сразу в шею. Это не инженер, не программист. Настоящий разработчик должен быть гибким — и код, чтоб писал и кому-то сразу в слаке ответил, и рядом коллеге что-то мог подсказать. И от этого надо еще и удовольствие получать. У умного человека мозг очень гибкий и незашоренный. А в потоке обычно дедушки с альцгеймером.
Да, и еще если кто-то заикается про работу в потоке — гоните сразу в шею. Это не инженер, не программист. Настоящий разработчик должен быть гибким — и код, чтоб писал и кому-то сразу в слаке ответил, и рядом коллеге что-то мог подсказать. И от этого надо еще и удовольствие получать. У умного человека мозг очень гибкий и незашоренный. А в потоке обычно дедушки с альцгеймером.
Мне кажется, идеальная коммуникация должна быть основана на здравом смысле. Здравый смысл состоит в том, что срочная коммуникация — злейшее зло. Помню, меня на фрилансе очень подстёгивало, что и тут я нужен и там, и везде мне пишут! Но если вопрос требует внимания и концентрации — все плохо. Поэтому все коммуникации вывел в почту.
Если что-то мегаважное — пусть звонят по телефону. Удивительно, но за месяц всего пара звонков. Очень часто пишешь клиенту, а он отвечает на следующий день или через несколько часов. Что это значит? То, что он тоже работает.
Это позволяет концентрировтаься на чем-то конкретном и переключаться между задачами, выполнив предыдущую работу до определенного этапа. Вместо дерганья получается планомерная деятельность.
Иными словами, «проблема Слака» в статье — это проблема взаимоотношений в команде, а не инструмента.
Если что-то мегаважное — пусть звонят по телефону. Удивительно, но за месяц всего пара звонков. Очень часто пишешь клиенту, а он отвечает на следующий день или через несколько часов. Что это значит? То, что он тоже работает.
Это позволяет концентрировтаься на чем-то конкретном и переключаться между задачами, выполнив предыдущую работу до определенного этапа. Вместо дерганья получается планомерная деятельность.
Иными словами, «проблема Слака» в статье — это проблема взаимоотношений в команде, а не инструмента.
Автор впервые познакомился с instant messager'ами? Откуда такое внимание одному из них и приписывание ему персонально общих их проблем (о том, насколько это проблемы софта, не буду дискутировать)?
Slack себя позиционирует больше, чем IM. Они говорили, что в слак каналы можно постить всё подряд — тикеты из zendesk, сообщения из электронной почты, видео, фотки и, естественно, обсуждения. К тому же сами чаты делаются только для определённого круга лиц, в отличие от чатов, где все видят всех. То есть многие компоненты были и раньше, но по отдельности. Slack их удачно скомбинировал и скормил малому-среднему бизнесу. Причём настолько хорошо зашло, что имхо слаком начинают заменять то, к чему он изначально не приспособлен. Собственно так я понимаю посыл автора статьи.
m1rko увидел ваш ник под статьей, и понял, что он мне знаком.
Посмотрел ваш профиль — 150 публикаций. Чуть больше чем за 1 год. Публикация раз в 3-4 дня. Переводы, переводы, переводы. Многие переводы набирают десятки тысяч, некоторые больше сотни тысяч. Многие из них я читал.
Кто вы? Откуда такие ресурсы для переводов? Как вы подбираете статьи? Какие у вас цели? И почему вы не участвуете в рейтинге на Хабре?
Посмотрел ваш профиль — 150 публикаций. Чуть больше чем за 1 год. Публикация раз в 3-4 дня. Переводы, переводы, переводы. Многие переводы набирают десятки тысяч, некоторые больше сотни тысяч. Многие из них я читал.
Кто вы? Откуда такие ресурсы для переводов? Как вы подбираете статьи? Какие у вас цели? И почему вы не участвуете в рейтинге на Хабре?
UFO just landed and posted this here
В статье упор на Slack (хотя для эмуляции чатов слаке многие команды используют чаты в скайпе), но потом упомянута Jira (читай — трекинговые системы), и честно названы бенефициары всего этого в процессах работы — менеджеры среднего звена.
В общем автор описывает конкретные продукты (хотя можно было бы говорить о конкретных классах продуктов), но на самом деле все еще глубже — это честная статья про скрам и аджайл.
Это не отменяет того факта, что в наше время современные средства коммуникации — большой плюс, и нельзя их отметать.
Зашел почитать статью с интересом и желанием узнать другую точку зрения на то, что уже стало обыденным.
Прочитав, хочу сказать только одно… Критикуешь — предлагай! Никакой альтернативы, которая бы решала проблемы описанные автором, я здесь не увидел.
Прочитав, хочу сказать только одно… Критикуешь — предлагай! Никакой альтернативы, которая бы решала проблемы описанные автором, я здесь не увидел.
Так почта и гугл-доки же (я так понял). Основная идея — отказаться от принципа «сперва общение — потом работа» и перейти к принципу «сперва работа — потом общение». Наверное, где-то между ними есть золотая середина, так как принцип отвечай-сразу-же-или-начальство-будет-недовольно на самом деле контрпродуктивен.
Так slack/trello/jira/e.t.c — это просто инструменты.
Имхо, в данном случае проблема в тех, кто ими пользуется.
Я бы не назвал нормой постоянно отвлекать человека от работы вопросами, которые не являются срочными или важными.
Особенно в софтверной области — когда программист пишет код, он погружен в свой контекст.
Если его отвлечь, ему может понадобиться время, чтобы вернуться в этот контекст.
Чем больше переключений контекста в час, тем меньше человек пишет кода за этот час.
По идее ПМ должен это понимать и по возможности замыкать вертикальное общение на себя.
Ну а для горизонтального общения сотни лет существуют такие вещи, как хорошие манеры (задал вопрос, подожди ответа и т.д.)
Если в компании все наоборот, то отказ от slack тут не поможет — будет любой другой инструмент, который будет использован против сотрудника.
Я в общем-то согласен с автором статьи.
Есть по большому счету две модели общения: синхронная (личная встреча, телефон, чаты) и асинхронная (эл. почта, таск-треккеры).
Синхронная модель — это царство обрывочных мыслей, рассеянного внимания и больших потерь времени. На мой взгляд, синхронная модель нужна только в редких случаях, когда случился форс-мажор. Ну или может когда нужно выразить и передать эмоции.
Асинхронная модель, я считаю, наилучший вариант для разработчиков. Для продуктивной работы асинхронная модель общения должна составлять где-нибудь 80-90%.
Есть по большому счету две модели общения: синхронная (личная встреча, телефон, чаты) и асинхронная (эл. почта, таск-треккеры).
Синхронная модель — это царство обрывочных мыслей, рассеянного внимания и больших потерь времени. На мой взгляд, синхронная модель нужна только в редких случаях, когда случился форс-мажор. Ну или может когда нужно выразить и передать эмоции.
Асинхронная модель, я считаю, наилучший вариант для разработчиков. Для продуктивной работы асинхронная модель общения должна составлять где-нибудь 80-90%.
Синхронная — тоже ок. Но только в том случае, когда все собеседники готовы к ней. Поэтому нормальная встреча должна быть запланирована, должен быть четко определен результат встречи (донесение информации, принятие решения, наброс идей — ни в коем случае не смешивая) и очерчены рамки обсуждаемых тем. Ну либо она должна проходить между людьми, которые достаточно дисциплинированны и понимают друг друга, чтобы сформулировать этот фреймворк в первые минуты и удержаться в нем.
И то, сплошь и рядом ее можно заменить асинхронным вариантом.
И то, сплошь и рядом ее можно заменить асинхронным вариантом.
Я последний год проработал в компании, которая выросла за это время с 50 до 200 сотрудников в центральном офисе и с примерно 100 до 1000 линейных сотрудников (курьеры/рабочие склада). Практически вся коммуникация была организована в Слаке (а таски в Джире), и это было круто. Безусловно, у Слака есть минусы, как перечисленные в статье, так и обойденные вниманием, но при поддержании определенных правил информационной гигиены Слак — очень удобный инструмент.
Под этими правилами я понимаю например такие:
— единая система именования каналов
— максимальное дробление каналов и общение только по теме канала
— за злоупотребление @channel и here сначала бить по рукам, потом по голове, но можно и наоборот
— не ожидать немедленного ответа на вопрос в личку/канал, по необходимости пинговать через некоторое время
Интеграции в Слаке работают просто шикарно (не технически даже, а в плане юзабилити). Все отчеты, аналитика, статусы билдов, ошибки продакшена, да что угодно, распихивается по своим каналам, по необходимости мьютится и удобно контролируется из одного интерфейса. Работа по фичам в своих каналах, вопросы службы поддержки в своих, офисный треп в своих, ленты новостей в своих, отлично же. Да, к Слаку есть миллион пожеланий по улучшению функционала их софта, но возвращаться назад к электронной почте и всем остальным разрозненным сервисам, которые могут быть сведены в Слак — нет, спасибо.
Соблюдение правил информационной гигиены необходимо конечно немножко контролировать с помощью специально обученного фашиста, его пулемета и овчарки, полностью на самотек общение пускать нельзя. Но это несложно.
Под этими правилами я понимаю например такие:
— единая система именования каналов
— максимальное дробление каналов и общение только по теме канала
— за злоупотребление @channel и here сначала бить по рукам, потом по голове, но можно и наоборот
— не ожидать немедленного ответа на вопрос в личку/канал, по необходимости пинговать через некоторое время
Интеграции в Слаке работают просто шикарно (не технически даже, а в плане юзабилити). Все отчеты, аналитика, статусы билдов, ошибки продакшена, да что угодно, распихивается по своим каналам, по необходимости мьютится и удобно контролируется из одного интерфейса. Работа по фичам в своих каналах, вопросы службы поддержки в своих, офисный треп в своих, ленты новостей в своих, отлично же. Да, к Слаку есть миллион пожеланий по улучшению функционала их софта, но возвращаться назад к электронной почте и всем остальным разрозненным сервисам, которые могут быть сведены в Слак — нет, спасибо.
Соблюдение правил информационной гигиены необходимо конечно немножко контролировать с помощью специально обученного фашиста, его пулемета и овчарки, полностью на самотек общение пускать нельзя. Но это несложно.
UFO just landed and posted this here
Так скажем, большую часть того, что можно сделать в слаке, можно в принципе сделать и в почте (с кучей дополнительной головной боли, вроде списков рассылки, фильтрации сообщений, сервера с историей и так далее). Но это все будет печально и неудобно. В слаке коммуникация сведена в один интерфейс, где все на своем месте, это основной плюс. Из того, что в почте нет в принципе — реакции, например (смайлики под сообщениями, которые тоже вполне себе рабочий инструмент, если с умом им пользоваться). Постоянные группы, которые создаются по клику. Можно конечно вместо каждой комнаты заводить отдельный список рассылки, но это значительно больший геморрой создателю группы и проблемы фильтрации сообщений пользователями. Приоритетные сообщения через знак @. Более неформальный стиль общения, не нужно каждый чих оборачивать в «добрый день, уважаемые коллеги» и «с комсомольским приветом, искренне ваш». Удобное форматирование кода и цитат. Разворот ссылок. Интеграции вроде голосовалок с опять же удобным интерфейсом. Можно долго продолжать.
Нет, почтой конечно вполне себе можно пользоваться, и настроить ее так, что всем будет уютно и комфортно. Целый линукс вон по почте построили, и нормально им. Но как по мне, это лишние расходы на настройку окружения, поддержание его в порядке (те же правила фильтрации, который каждый настраивает себе сам) и выработку правил общения. Слак дает все это из коробки, и еще бантик рядом вешает.
Нет, почтой конечно вполне себе можно пользоваться, и настроить ее так, что всем будет уютно и комфортно. Целый линукс вон по почте построили, и нормально им. Но как по мне, это лишние расходы на настройку окружения, поддержание его в порядке (те же правила фильтрации, который каждый настраивает себе сам) и выработку правил общения. Слак дает все это из коробки, и еще бантик рядом вешает.
Проблема всех этих чатах, что многие не соблюдают элементарной информационной гигиены. Часто вопросы в чатах идут кусками, люди их не обдумывают и задают беспорядочно. Опять же обратная связь тут с задержками. Разговор, который по телефону может занять 3 минуты, через чат может растянуться минут на 20. И все это время он будет отвлекать от работы.
Для профессий, представители которых большую часть времени работают в «потоке» (вроде разработчиков), чаты это вообще полное злой и performance killers.
Для профессий, представители которых большую часть времени работают в «потоке» (вроде разработчиков), чаты это вообще полное злой и performance killers.
Я уже давно научился не отвлекаться на электронную почту и сообщения в мессенджерах. Slack мне не нравится по другой причине: он работает медленно как на компьютере, так и на телефоне; если смотреть объективно, то это кажется незначительной мелочью, но на самом деле это оставляет негативное впечатление где-то на подсознательном уровне. Возможно, поэтому он не прижился ни в одной из команд, в которых я работал.
Да дело не в слаках.
Люди! Перестаньте в мессенджерах начинать общение с сообщения "Привет" — это плохой тон! Пора бы уже понять, что мессенджер не для того, чтобы поздороваться, добавьте свой привет первым предложением сообщения и сразу к сути.
Обычно игнорю приветы, т.к. очевидно, что поздороваться на работе — это совсем не срочно.
Да ладно.
Если за «приветы» платят, то отчего бы не поприветоваться?
Если за «приветы» платят, то отчего бы не поприветоваться?
Отправляйте людям вот эту ссылку: neprivet.ru
Проблема давно известна, ее еще Айзек Азимов описал в «Время Писать» — royallib.com/book/azimov_ayzek/vremya_pisat.html
К сожалению, сейчас уже мало кто читает книги…
К сожалению, сейчас уже мало кто читает книги…
У дядьки бомбит, потому что он не умеет пользоваться IM, путая их с ERP и офисными пакетами.
дело не в инструментах а в людях!
Если коллеги в чате #mainProject-dev постят котиков — они бы и в почте их всем рассылали и в gDoc вставляли.
Он просто работает с неадекватами, а винит в этом инструменты (:
Огромная пропасть между тщательно обдуманной документацией и потоком сознания вперемешку с анонсами
Вот да. Особенно доставляет, когда всплывает уведомление "@person, надо это сделать", и выше 100500 сообщений, за которыми ты не следил.
UFO just landed and posted this here
Ну, про поиск и прокрукруту может и соглашусь. Но остальное – это же чисто проблемы управления. Мгновенные ответы, документация, общение в разных каналах… Все зависит от организации, а не от инструмента.
Зависит от правил.
Мы в свое время пропесочили человека, который постоянно употреблял
И все стало хорошо.
Мы в свое время пропесочили человека, который постоянно употреблял
@username
И все стало хорошо.
Для меня слак кроме коммуникатора еще и удобный интерфейс для автоматизации. Вечерние тесты в отдельном канале (специфика такая, что надо каждый вечер смотреть, как за день отработали сервисы, в срезе проблему не увидеть). Экспресс-тест одной командой, информация сразу в чат. Ворнинги от заббикса тоже в отдельном канале.
Для менеджеров пачка команд, формирующих отчеты сразу в чат, текстом и файлом. Гораздо удобнее, чем лезть в админку, искать нужный отчет, и так далее.
Правда у нас команда маленькая, флуда нет, проблем описанных нет. Может поэтому мне слак по душе.
Для менеджеров пачка команд, формирующих отчеты сразу в чат, текстом и файлом. Гораздо удобнее, чем лезть в админку, искать нужный отчет, и так далее.
Правда у нас команда маленькая, флуда нет, проблем описанных нет. Может поэтому мне слак по душе.
Slack не исправит ваши коммуникации. Если вы нашли способ (на самом деле нет) исправить коммуникациии путём замедления и игнорирования то Slack показывает вам что вы неправы
Что я скажу.
Многие вещи, если не большинство, говно.
Но быдло не замечает этого.
Они как мухи, слетевшиеся на говно.
Многие вещи, если не большинство, говно.
Но быдло не замечает этого.
Они как мухи, слетевшиеся на говно.
Какой ужасный перевод. Попытался понять из поста это:
Сдался, полез в оригинал, а там:
В первый день своей первой работы трейдером единственной инструкцией, которую я получил, было «Когда рынок откроется, отключи телефон». С подтекстом «и всё остальное». Если кто-то скажет мне такое сегодня, я обниму этого человека, хотя я не фанат обнимашек.
Я пытался поговорить с людьми на эту тему, но мне отвечали: «Это офис, а не библиотека». В то время я был просто в ярости
Сдался, полез в оригинал, а там:
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’.
Кстати, многие технические моменты, которые не исправить в веб-приложении слака, очень легко лечатся, если подключаться по протоколам irc/jabber (да, slack умеет и такое).
А уже в irc/xmpp клиенте можно настроить любые уведомления (или их отсутствие).
Плюс, сохраняется история (актуально, если вы пользуетесь бесплатной версией slack).
Как по мне, то в компании должны быть правила, регламентирующие использование разных средств коммуникаций. Приоритеты, срочнлстб и тематика должны быть явно известны всем вовлеченным.
Это новый, зачастую более эффективный, формат делового общения, к которому автор не смог адаптироваться и потерял производительность. Еще забавно видеть, что он приписывает себя к лучшим сотрудникам и считает адаптировавшихся к мессенджерам\опенспейсам — худшими. Если ты такой лучший, чего тебя надолго выбивает из колеи простой вопрос от коллеги, тогда как все окружающие довольны и производительность компании, в целом, повысилась? :)
В чём его эффективность заключается?
Это недостающее звено между насильным голосовым общением и медленной ни к чему особо не обязывающей почтой. Мне кажется, большая часть решаемых современными программистами задач недостаточно важны\сложны для вдумчивого обсуждения через почту и недостаточно срочны для звонков. Мессенджеры идеально подходят для обсуждения неважного несрочного, но, конечно, не заменяют почту\телефон полностью, а дополняют их. Использование средства общения, соответствующего классу решаемых задач, эффективнее, чем использование привычных, но неуместных, средств. В общем, я считаю, что новые фичи желательно придумывать голосом, обдумывать через почту, реализовывать\дебажить (а это большая часть времени) в чатах и, параллельно, фиксировать в документации.
тогда как все окружающие довольны и производительность компании, в целом, повысилась
Ну, не стоит говорить за всех.
Безотносительно обсуждаемой темы:
Если на уровне видимости "все окружающие довольны", то на самом деле это может быть совсем не так.
Доводилось наблюдать разные ситуации, когда "шеф, все пропало" — в состоянии проектов, рабочих процессах и/или отношениях в коллективе, а внешне большинство "держат марку" или — даже излучают позитив, придерживаясь официальной идеологии компании, или даже давая на 80% отличные оценки в анонимных опросах, инициированных руководством.
А если чуть копнуть — то недовольных если не большинство, то существенная часть в районе блок-пакета (25-30%).
Не всегда, но так бывает.
Так и в современных процессах разработки — много положительного по сравнению с условным waterfall, есть и определенные недостатки, но в целом — можно быть уверенными, что довольных ими — меньше, чем принято считать.
Это как в том опыте, когда сажают за стол несколько человек, все по очереди говорят, что круглый предмет на самом деле квадратный, а конце дают слово последнему, который не в курсе "договоренности", то в большинстве случаев последний соглашается с предыдущими ораторами.
Ни в коем случае не говорю за всех, только в контексте статьи. Цитаты, по которым я сделал вывод, что адаптироваться к непрерывному потоку информации не может только автор, а у всех остальных все в порядке:
… Менеджерам он понравился…В общем, я не увидел в статье конкретных примеров неэффективности мессенджеров, но увидел много личных трудностей автора с мессенджерами, а точнее — с непрерывно ускоряющимся ритмом жизни и увеличивающимся потоком информации. Причем, он считает, что все «лучшие сотрудники» имеют трудности с мессенджерами, что и вызвало мою личную неприязнь. Даже пример с пропущенной частицей «не» в сообщении совсем не выглядит впечатляющим. Я думаю, часть собеседников сразу поняли, что в предложении пропущено отрицание, а остальные поняли, куда нужно вставить «не» и инцидент был исчерпан через 10 секунд. Автор же от этих мелочных ситуаций чувствует себя персонажем кинокомедии. И, мне кажется, с каждым годом ему будет все труднее и труднее работать над «чокнутыми проектами» в безумных несущихся вперед молодых коллективах.
… мне отвечали: «Это офис, а не библиотека»…
… выросло целое поколение работников и даже компаний, которые никогда не работали таким образом (который привычен автору)…
… Люди проверяли жужжащие телефоны на планёрках. Уведомления из чата клик-клик-кликали без перерыва…
… сказал об этом менеджеру проекта, на что тот ответил: «Эх, у тебя синдром дефицита внимания»...
Жизненная и правильная статья.
Фрагментация кусков ТЗ между тикетам с полуживыми доками, чатикам и «живым общением» — это вообще отдельный ад. Апогей — это когда что-то (но далеко не всё) обсудили голосом (потому что кто-то решил что так быстрее/удобнее), таск либо не сделали, либо он состоит из «позвони, обсудим», а потом на приёмке у тебя спрашивают «Почему ты не сделал вот эту фичу именно вот так и с кандибобером», «Потому что про кандибобер никто не говорил», «Я совершенно точно (ведь ПМ не человек и ничего не забывает, да и слушатель тоже робот) говорил тебе про кандибобер — иди переделывай». И никому ничего не докажешь, что эта хотелка была выдумана, но не была озвучена, либо по ней были вопросы не позволяющие сделать её сейчас без ущерба для другого функционала. Без нормального целостного документирования невозможно понять, как должен работать/выглядеть результат, а чаты и голосовые обсуждения с документированием не связаны никак. Они в принципе не могут иметь важности чем сиюминутный факт, про который можно через 15 минут забыть вообще. Максимум — это пульнуть скриншот и переписка в духе «Так для тикета #123 с кандибобером будет ок? -Да». Всё, на этом активность в чате должна заканчиваться.
Ещё веселило, когда ПМ мог написать/позвонить в любой момент, через любой канал связи, даже на телефон около полуночи из другой страны, но все обращения к ПМ, если не через почту, вполне легко ПМом же игнорируются. Даже если это сообщение о том, что сервер почты сдох.
Ботоводство и прочая автоматизация на чатовых костылях — это отдельный вопрос, который тоже никак не связан с ведением проекта, ведением документации и внутрикомандной коммуникацией. Но те, кто про него тут вспоминают, кажется не поняли о чём пост.
Фрагментация кусков ТЗ между тикетам с полуживыми доками, чатикам и «живым общением» — это вообще отдельный ад. Апогей — это когда что-то (но далеко не всё) обсудили голосом (потому что кто-то решил что так быстрее/удобнее), таск либо не сделали, либо он состоит из «позвони, обсудим», а потом на приёмке у тебя спрашивают «Почему ты не сделал вот эту фичу именно вот так и с кандибобером», «Потому что про кандибобер никто не говорил», «Я совершенно точно (ведь ПМ не человек и ничего не забывает, да и слушатель тоже робот) говорил тебе про кандибобер — иди переделывай». И никому ничего не докажешь, что эта хотелка была выдумана, но не была озвучена, либо по ней были вопросы не позволяющие сделать её сейчас без ущерба для другого функционала. Без нормального целостного документирования невозможно понять, как должен работать/выглядеть результат, а чаты и голосовые обсуждения с документированием не связаны никак. Они в принципе не могут иметь важности чем сиюминутный факт, про который можно через 15 минут забыть вообще. Максимум — это пульнуть скриншот и переписка в духе «Так для тикета #123 с кандибобером будет ок? -Да». Всё, на этом активность в чате должна заканчиваться.
Ещё веселило, когда ПМ мог написать/позвонить в любой момент, через любой канал связи, даже на телефон около полуночи из другой страны, но все обращения к ПМ, если не через почту, вполне легко ПМом же игнорируются. Даже если это сообщение о том, что сервер почты сдох.
Ботоводство и прочая автоматизация на чатовых костылях — это отдельный вопрос, который тоже никак не связан с ведением проекта, ведением документации и внутрикомандной коммуникацией. Но те, кто про него тут вспоминают, кажется не поняли о чём пост.
В неумении фиксировать договоренности слек тоже не виноват.
Слак позиционируется, в том числе, и как инструмент для фиксации решений и договоренностей.
Кем позиционируется? И вы, конечно же, имеете ввиду полную версию?
Slack builds a searchable archive of your team’s… decisions ...
Ну, то есть в полной версии можно найти договоренности, которые вы зафиксировали. Если вы, конечно, умеете.
Да, можно.
Да, можно.
Можно, но сложно. А ещё очень легко пропустить решение, тебя касающееся.
А ещё очень легко пропустить решение, тебя касающеесяКак и при любом другом способе коммуникации, если не фиксировать решения.
Решения могут быть зафиксированы в слаке, но их легко пропустить.
Решения могут быть зафиксированы в слаке, но их легко пропустить.
А это уже отмазки
Решения были зафиксированы — вот доказательства.
Где доказательства, что я с ними ознакомлен, если уж на то пошло.
Это всё проблемы построения процессов.
Решение зафиксировано, когда есть четкое его описание, с которым все ознакомились и, так или иначе, с ним согласились.
Это не зависит от способа коммуникации. Армейское «Есть {пересказ приказа}» как раз форма фиксации договоренности.
Где доказательства, что ты ознакомлен с решением в почте? Там ровно два способа это сделать: уведомление о прочтении (которое криво работает) и ок ответный письмом, которое производит ненужное уведомление всех участников переписки.
В том же слеке так же два способа: окнуть сообщением (причем тут как может быть уведомление одного или нескольких лиц, так и может его не быть), окнуть реакцией на сообщение, которое вообще никого не отвлекает. Кому надо — посмотрит.
Решение зафиксировано, когда есть четкое его описание, с которым все ознакомились и, так или иначе, с ним согласились.
Это не зависит от способа коммуникации. Армейское «Есть {пересказ приказа}» как раз форма фиксации договоренности.
Где доказательства, что ты ознакомлен с решением в почте? Там ровно два способа это сделать: уведомление о прочтении (которое криво работает) и ок ответный письмом, которое производит ненужное уведомление всех участников переписки.
В том же слеке так же два способа: окнуть сообщением (причем тут как может быть уведомление одного или нескольких лиц, так и может его не быть), окнуть реакцией на сообщение, которое вообще никого не отвлекает. Кому надо — посмотрит.
ответный письмом, которое производит ненужное уведомление всех участников переписки.
Очень спорно. Как правило, решение как раз касается всех участников переписки и они должны знать и суть решения, и как оно их лично касается, и кого и как оно касается ещё.
В том же слеке так же два способа
Способов много в разных системах. Но на практике в электронной почте сложнее пропустить и проще найти впоследствии зафиксированное решение. В целом, конечно, для этого лучше иметь какую-то СЭД, но почта на практике лучше IM для фиксации важных решений.
Очень спорно. Как правило, решение как раз касается всех участников переписки и они должны знать и суть решения, и как оно их лично касается, и кого и как оно касается ещё.Я понял, почему вы так много спорите. Вы просто ответы по диагонали читаете.
Но на практике в электронной почте сложнее пропустить и проще найти впоследствии зафиксированное решение.Видимо у вас не было тредов на 20 человек из которых половина не умете пользоваться CC и reply all
В статье речь не только про слак и не конкретно про слак среди IM, а про то, что народ злоупотребляет ими, порождает много информационного шума, да ещё и преподносит эти косяки как фичи, делает с их помощью то, чего через них делаться не должно, про любителей поболтать там, где не нужно болтать, а так же про то, что нужно делать нормальную документацию, которую можно прочитать одним заходом и всё станет понятно, которую не нужно будет собирать по логам чатов и крупицам «кто-то что-то слышал на каком-то митинге».
Можно через чат скинуть ссылку на конкретно место в документации, но нельзя позиционировать чат как замену всему и вся. И тем более нельзя в него долбить аки «официант, господам скучно». Всё, что прошло мимо документации и нормальной системы учёта требований — проходит мимо.
Вообще-то электронной почты эти чатовские проблемы тоже касаются, народ что-то шлёт и ждёт что им ответят сразу, плюс километровые портянки из переписки. Но т.к. все привыкли, что почта редко проверяется, то там стало меньше таких заскоков.
Точно так же применимо и для «суперсрочных телефонных звонков», когда человек не может и даже не собирается чётко объяснить, в чём проблема — во первых просто потому, что скрины и логи звонком не передаются, во вторых, люди почему-то любят играть в сломанный телефон и говорить какую-то ересь вместо состоявшихся фактов (не тот номер записи, не тот пароль, не тот клиент… всё что угодно) + бывают проблемы со связью, а потом они с чувством выполненного долга пропадают (отрубают телефон и идут спать например).
Т.е. в конце всё упирается в то, что нет нормальной документации и системы ведения тикетов, которые в принципе были бы самодостаточны без всяких чатиков, звонков и митингов. Все эти чатики расхолаживают (люди считают что они выполнили долг — доставили информацию, но на самом деле в документацию не попало ничего) и отвлекают, даже если не бибикают явно, а просто в трее навязчиво висит «вы не прочли 100500 сообщений».
А вообще я долго искал какое-нибудь готовое решение, которое можно было бы захостить у себя, в котором можно было бы вести проекты от корки до корки для SOHO (начиная с беклога, тикетов, таймтрекинга, ведения клиентов продаванами, хелпдеска, заканчивая VCS, review), но так ничего и не нашёл, всё равно половина на github/gitlab/bitbucket, а вторая половина размазана по Dropbox/Paper/Google drive/Redmine/CRM и чатикам. И эта фрагментация жрёт время и бесит.
Можно через чат скинуть ссылку на конкретно место в документации, но нельзя позиционировать чат как замену всему и вся. И тем более нельзя в него долбить аки «официант, господам скучно». Всё, что прошло мимо документации и нормальной системы учёта требований — проходит мимо.
Вообще-то электронной почты эти чатовские проблемы тоже касаются, народ что-то шлёт и ждёт что им ответят сразу, плюс километровые портянки из переписки. Но т.к. все привыкли, что почта редко проверяется, то там стало меньше таких заскоков.
Точно так же применимо и для «суперсрочных телефонных звонков», когда человек не может и даже не собирается чётко объяснить, в чём проблема — во первых просто потому, что скрины и логи звонком не передаются, во вторых, люди почему-то любят играть в сломанный телефон и говорить какую-то ересь вместо состоявшихся фактов (не тот номер записи, не тот пароль, не тот клиент… всё что угодно) + бывают проблемы со связью, а потом они с чувством выполненного долга пропадают (отрубают телефон и идут спать например).
Т.е. в конце всё упирается в то, что нет нормальной документации и системы ведения тикетов, которые в принципе были бы самодостаточны без всяких чатиков, звонков и митингов. Все эти чатики расхолаживают (люди считают что они выполнили долг — доставили информацию, но на самом деле в документацию не попало ничего) и отвлекают, даже если не бибикают явно, а просто в трее навязчиво висит «вы не прочли 100500 сообщений».
А вообще я долго искал какое-нибудь готовое решение, которое можно было бы захостить у себя, в котором можно было бы вести проекты от корки до корки для SOHO (начиная с беклога, тикетов, таймтрекинга, ведения клиентов продаванами, хелпдеска, заканчивая VCS, review), но так ничего и не нашёл, всё равно половина на github/gitlab/bitbucket, а вторая половина размазана по Dropbox/Paper/Google drive/Redmine/CRM и чатикам. И эта фрагментация жрёт время и бесит.
В конце всё упирается в косяки построения бизнес-процессов. Глупо обвинять в этом инструменты (хоть в частности. хоть в общем)
Глупо вообще кого-то обвинять не разобравшись в проблеме. Автор как раз проблему и поднял. Важно тут не цепляться за конкретное наименование отдельно взятой программы.
Ну как сказать. На уровне бизнес-процессов описано "передать информацию о том-то такому-то". И люди передают тем способом, который удобен для отправки. Но вот далеко не факт, что этот способ будет удобен для того, кому информация передаётся. Что он вовремя заметит и вообще заметит факт передачи ему информации. Не инструмент, конечно, в этом виноват, а тот, кто решил использовать неподходящий инструмент для передачи информации.
А вообще я долго искал какое-нибудь готовое решение, которое можно было бы захостить у себя, в котором можно было бы вести проекты от корки до корки для SOHO
Если можно опустить требование хостинга у себя, попробуйте продукты от бывших 37signals, которые сейчас Basecamp + Highrise называются, вдруг понравится. Сам не пользовался, но читаю их блог, все звучит весьма осмысленно.
«Электронная почта гораздо лучше группирует обсуждения в цепочки, но Slack убил такую возможность» — после этого перестал читать статью. Забыли как по эл. почте годами получали ответ на вопрос?
Да и вообще, правильно сказали выше: не умение отключать уведомления не повод поливать грязью Slack. Я наоборот ничего лучшего не встречал…
И еще: критикуешь — предлагай!
Да и вообще, правильно сказали выше: не умение отключать уведомления не повод поливать грязью Slack. Я наоборот ничего лучшего не встречал…
И еще: критикуешь — предлагай!
Заметка по Слаку:
Есть вопрос к ПМ. И два варианта решения вопроса:
1. Собираю информацию по вопросу, пишу сообщение в Слак и отправляю ПМ. Жду ответ;
2. Иду к ПМ и напрямую спрашиваю, что к чему и как решить.
Если этот вопрос не первой важности — то его спокойно можно отложить до митинга. А если вопрос первой степени важности, то какой из вариантов лучше?
До сих пор не знаю, как относится к подобного рода моментам работы.
Есть вопрос к ПМ. И два варианта решения вопроса:
1. Собираю информацию по вопросу, пишу сообщение в Слак и отправляю ПМ. Жду ответ;
2. Иду к ПМ и напрямую спрашиваю, что к чему и как решить.
Если этот вопрос не первой важности — то его спокойно можно отложить до митинга. А если вопрос первой степени важности, то какой из вариантов лучше?
До сих пор не знаю, как относится к подобного рода моментам работы.
Тема актуальная, но как всегда надо понимать, что есть разработчики, а есть менеджеры и это люди с разных планет с разными ценностями (приоритетами). Слак для разработчика — это постоянно отвлекающая штука, а для менеджера например оперативное ведение проекта (особенно если у заказчика все горит). Поэтому думаю нужно просто сформировать культуру общения и работы, и Слак не будет такой проблемой.
В день я общаюсь примерно с 15-20 клиентами и отвечаю на их вопросы, изучаю ошибки, которые они присылают. Если постоянно быть онлайн, то времени на создание нового ПО не остаётся. Поэтому, когда мне нужно сделать задачу, я отключаюсь из скайпа на несколько часов, делаю задачу, а потом возвращаюсь онлайн. Иначе приходится каждые 10 минут смотреть, что же тебе там написали в скайп. Работа в таком случае превращается в прокрастинацию от одного вопроса пользователя до другого.
У нас слак используется постоянно в работе, совместно с Jira/Confluence. Очень удобная вещь, если научится ею нормально пользоваться. Звонки мы делаем по Skype, это удобно. Выписывание багов в джиру. Слак в отличие от скайпа не теряет историю сообщений. Ветки можно в текущей версии делать. А самое удобное подключение ботов с той же Jira или зеплина.
Sign up to leave a comment.
Slack — это противоположность организационной памяти