Комментарии 170
Вывод: некоторые люди по-умолчанию не совместимы с таким режимом, либо время ПМа на их координацию должно расти пропорционально и это становится не выгодно.
Вы таски ставите в чатиках и эмейлах? Может в консерватории что-то поправить?
Проблема в том, что в асинхронном режиме таски следуют один за другим, без ожидания предыдущих. В итоге некоторые таски остаются висеть не сделанными не смотря на постоянное повышение их приоритетов. Если же переходить в синхронный режим, с отчетами по каждому таску, обязательной приемкой и правками до победного конца, то теряется смысл асинхронности.
В любом случае, со временем наблюдаю заметное увеличение орг. работы от удаленки и медленную деградацию некоторых сотрудников (не всех!). Возможно, нужен отдельный ПМ для удаленщиков, либо мне нужна прокачка дополнительных навыков для компенсации этих перекосов. Ну или как-то классифицировать исполнителей по параметру «пригоден к удаленной службе» и держать отдельно офис и удаленку.
ЗЫ. Я посредственный ПМ, переученный из программиста, да еще и не полностью. Мы не рассматриваем варианты прирожденных руководителей и психологов с тремя дипломами, у которых даже приходящий электрик бросил пить и стал кабеля цифрами маркировать и цветные гофры укладывать.
Синхронизируйтесь раз в день на утреннем стендапе, вот и всё решение
(Если что это была не разработка ПО)
Вы на руководящей должности? Мне тревожно.
Также, не знаю, как у других, но у меня бывает такое, что просто не могу переключиться на другую задачу, пока не произойдет синхронизация и я не додумаю свою часть.
Ну и взаимодействие с удаленными работниками требует больше времени на подготовку, особенно если человек занимает не ведущую роль и/или не сильно замотивирован и соответственно не проявляет инициативы.
Асинхронная коммуникация далеко не всегда будет возможна. И как раз там где она возможна это очень часто и приводит к тому, что работа делается на удалёнке или вообще на аутсорсе.
Но пытаться перевести абсолютно всё на асинхронную коммуникацию это на мой взгляд не самая лучшая идея. Потому что часто как раз нужна "быстрая коммуникация".
А у вас логика выглядит примерно как "у мотоциклов полно плюсов и мотоциклисты перемещаются быстрее чем грузовики. Поэтому давайте всех пересадим с грузовиков на мотоциклы". Я конечно сильно преувеличил, но надеюсь что идея понятна.
А вы точно статью дочитали? Там же целая глава про необходимость и синхронных коммуникаций тоже
Вы вот это имеете в виду
Мы знаем, что мы бросаем вызов статус-кво и что спокойная, асинхронная связь не является текущей нормой. Требуется настоящая смена парадигмы. Держим пари, что в будущем наиболее успешными компаниями станут те, кто решится на такую смену.
?
Но! Вам по-прежнему нужна и синхронная связь
Как у всего в жизни, у асинхронной культуры есть плюсы и минусы. Doist испытала и то, и другое..
… и далее по тексту несколько экранов
… и далее по тексту несколько экранов
И при этом в конце всё равно делается вывод что надо всем переходить на асинхронную коммуникацию.
И лично у меня после прочтения всего текста целиком сложилось чёткое впечатление что эту самую асинхронную коммуникацию считают этакой серебрянной пулей, которая сразу сделает прямо всех эффективней.
P.S. И да, "иногда вам нужна и синхронная коммуникация" это очень классная вставка. Только в ней нет никакого смысла пока чётко не опрeделено когда оно конкретно так. Потому что у нас сейчас практически во всех фирмах "асинхронная коммуникация" с "иногда" используемой "синхронной коммуникацией". И те кто используют синхронную уверены что в их случае это "нужно".
Тут с вами абсолютно согласен. Особенно в опенспейсах, каждый почитает за святое право подойти к любому сотруднику в любой момент и о чем-то начать говорить. Проблема кстати еще более актуальна для руководителей среднего звена, которые и руками сами что-то делают (почта, отчеты, аналитика, презентации) и оперативным управлением занимаются — сотрудники ходят один за другим "посоветоваться", постоянно переключая контекст. И пока напрямую их не заставишь самостоятельно принимать свои решения — так и будут ходить.
Но есть еще вышестоящие руководители, и сотрудники смежных подразделений — их выстроить куда сложнее чем своих.
1) клиент пишет письмо с требованием новой фичи и/или вопросами. Со всеми деталями.
2) работник пишет подробный ответ в течение 24 часов (кроме экстренных задач типа «сайт упал, посмотри, что там»). По новой фиче ответ — или 1. «уже сделано» (со всеми деталями «как это работает» + ссылкой «где посмотреть работающую фичу»), или 2. уточняющие вопросы по требованиям (например, «по добавлению поля Картинка в форму, позволяющую пользователю сайта опубликовать короткую заметку: достаточно ли одной картинки или пользователю нужно загружать много картинок?»), или 3. «сложность оцениваю так-то, ETA (предположительное время выполнения) — 32 мартобря».
С сотрудниками компании, с которой работаю — то же самое. Если мне нужно что-то от дизайнера или маркетолога — пишу письмо №1 и получаю письмо №2. Если им что-то нужно от меня — аналогично.
От созвонов и обсуждений в чатах (с которых часто начинают новые клиенты, когда они ещё не знают, хорошо ли я работаю — либо клиенты, у которых был плохой опыт с фрилансерами) мы с клиентами довольно быстро переходим к письмам по всем контрактам.
Был случай, в одной компании (где я работал давно) появилась маркетолог (ну вы знаете, какие они soft skills и общительные), которой было непривычно без еженедельных созвонов. У неё была уйма новых идей по фичам, и было очень важно хранить всё это в письменном виде. Настоял на письмах. Через месяц и она признала, что этот подход работает (с удивлением «даже не представляла себе, что координировать коммуникацию получится без звонков голосом»).
Требования из письма (в отличие от обговоренного устно) можно сразу скопировать в баг-трекер. Описание реализованной фичи (из моего ответа) можно скопировать в документацию. Клиент не может забыть, что именно просил (есть текст запроса фичи). Работник не может забыть, что у него просили. Если новый сотрудник Б спросит что-то, о чём уже спрашивал сотрудник А, то можно переслать ему письмо с ответом (а не рассказывать заново, как на совещаниях). Одни плюсы.
А как вы ищете в большом количестве писем?
В случае, если Б просит что-то у А, что было обговорено, допустим, год назад. С вашим подходом получается очень много переписки, как это организовано?
(если вопрос про робот-пылесос, то предыдущая цепочка писем не могла не содержать это слово)
Встречный вопрос: как искать в большом количестве разговоров? Великая ценность вот этой всей асинхронщины в протоколировании. Компьютеры отлично ищут в тексте, достаточно взять себя в руки и писать на более-менее грамотном языке. В случае разговоров люди массово не помнят через месяц, до чего они договорились и почему.
Мой вопрос был исключительно о роли почты в общении сотрудников А и Б относительно задачи решённой год назад.
Как мне кажется, почта проигрывает вещам типа багтрекеров и прочих Confluence.
Как в плане изначального удобства заполнения, так и категоризации с поиском.
А, недопонял. На мой взгляд, багтрекеры проигрывают почте, потому что себя нужно в руках держать сильнее, чем просто для генерации связного письменного текста. В почте человек отвечает человеку, а в багтрекере — бездушной машине, которой «ни в глаз не дать, ни отпеть» (если, конечно, нет специального человека, который ходит и прямо читает содержимое тикетов и статей в Confluence).
И только тогда, когда открыл почту сам (без всплывающих уведомлений «пришло новое письмо»).
Я очень часто проверяю почту.
Тогда какая же это тогда асинхронная коммуникация если вы постоянно почту проверяете?
Бегло просмотреть письмо можно сразу. Если запрошенная там фича — низкоприоритетная, а разработчик занят, то он не должен всё бросать.
Он может спокойно доделать то, чем занимался ранее.
А если не низкоприоритетное, то должен делать сразу?
И чем это отличается от ситуации когда кто-то подошёл ко мне когда я работаю и просит решить его проблему. А я ему говорю что проблема низкоприоритетная и я её сделаю на следующей неделе. Или вообще его игнорирую и делаю свою работу. Это тоже асинхронная коммуникация?
Все остальные задачи должны быть рассмотрены в течение 24 часов.
И чем это отличается от ситуации когда кто-то подошёл ко мне когда я работаю и просит решить его проблему. А я ему говорю что проблема низкоприоритетная и я её сделаю на следующей неделе. Или вообще его игнорирую и делаю свою работу.Тем, что он уже отвлёк вас от работы, нет? Даже если не получил ответ. И у вас не было выбора, когда им заниматься.
Выслушать нельзя вполуха. Чтобы понять, о срочной проблеме он говорит или нет, надо полностью отвлечься и дослушать, что он говорит. Пробежать глазами по тексту можно моментально (лично меня это даже не «отвлекает от потока»).
Тут ниже писали про «отвлечение от потока» из-за «посмотреть 5-10 секунд на текст». Вы только посылать этого человека, который подошёл к вам ногами, будете минуту. И он потом ещё будет дуться и жаловаться, что его игнорили (и такое бывает).
Ну начнём с того, что форс-мажор — это 1-2 письма в год.
Но чтобы не пропустить такое вы при этом всё равно должны просматривать абсолютно каждое письмо.
Тем, что он уже отвлёк вас от работы, нет?
Вы когда просматриваете письма точно так же уже отвлекаетесь от работы. И я бы даже предположил что на просматривание писем вы в среднем отвлекаетесь чаще, чем меня от работы отвлекают коллеги.
И кто из нас тогда более "эффективно" работает?
Тут ниже писали про «отвлечение от потока» из-за «посмотреть 5-10 секунд на текст».
Так в том-то и дело что как минимум для меня в обоих случаях идёт это самое "отвлечение от потока". И если я уже отвлёкся, то всё поезд ушёл и мне снова надо время чтобы "войти" обратно в поток.
Вы когда просматриваете письма точно так же уже отвлекаетесь от работы.Специфика моей работы — много мелких задач (я не лезу в почту во время реализации фичи, а только между фичами) плюс крупные архитектурные задачи (при обдумывании которых я делаю обязательные паузы специально, т.к. через час-другой может прийти в голову хорошая идея об альтернативной реализации).
Я привык быстро переключаться между задачами и (по ощущениям) не отвлекаюсь от потока, посмотрев на почту.
Специфика моей работы
То есть получается что конкретно для вас это работает, но совсем не обязательно что это будет работать для всех или хотя бы для большинства.
В почте уже есть обычно способ классификации писем по важности. Может быть, можно настроить почтового клиента, чтобы уведомления показал только на важные письма?
На одной фирме где я работал так пытались сделать. Знаете чем кончилось? Тем что больше половины писем имели категорию "срочно" или даже "очень срочно". :)
Просто если люди сами не понимают когда что-то действительно достаточно важно чтобы отвлекать других людей от работы, а когда нет, то вам никакой тулинг не поможет.
Есть один момент, который обошли стороной в этой статье. Когда несколько человек работают над чем-то одним, ожидание ответа или реакции от коллеги может блокировать твою дальнейшую работу. В синхронной модели такой "блокер" можно снять моментально.
На мой взгляд это ещё зависит от конкретного человека и должности. Кто-то может быть и целиком "асинхронным", а кто-то постоянно должен быть на связи.
Выход: у этих двух людей один и тот же блокер, т. е. режим работы в промежутке от парного программирования до работы в тесной связке над одной и той же фичей.
Не понял, как это "До 80% этого времени уходит на общение по электронной почте (в среднем, шесть часов в день)".
Если у сотрудника 7.5 часов (6/0.8) в день уходит на общение, то на собственно выполнение задач остаётся не больше получаса. Он вообще нужен при таком раскладе или вместо 10 таких можно нанять одного, который общается 3 часа в день?
Сейчас происходит так — юзер спрашивает в чате поддержки в Телеграме, как решить проблему. Техпод не совсем в курсе как её решать, он спрашивает в чате разработчиков. Кто-нибудь из разработчиков отвечает.
А если ввести асинхронность? Юзер в Телеге должен ждать 24 часа?
Юзер в телеге, которому надо прям сейчас — это как раз синхронная коммуникация. Асинхронным будет имейл на support@example.com или там вопрос на форуме.
Есть почта, есть открытый issue-трэкер на гитхабе, есть все соцсети, есть свой форум, есть ветки форумов на 4pda и xda-developers, и есть чаты в телеге — русскоязычный и англоязычный.
И вот чаты в телеге, всё-таки, считаются «быстрым способом» спросить о решении какой-нибудь проблемы.
А ведь в наше время всем всё нужно «здесь и сейчас», поэтому вот такие пироги.
надо сделать в стиле ITSM: сделать прддержка первой линии, второй линии.
первая линия принимает жалобы от юзеров и отвечает как модет, ечли не модет эскалируетв во вторую линию.
вторая линия не обяз-но должна состоять из прогеров, туда можно ротировать по очереди одного прогера, чтобы читал чат и отвечпл, но лучше кого-то из команды тестирования QA т.к. они знают все граничные случаи
Вопрос только в том устроит юзера такой ответ или нет. Представьте вы приходите вечером домой и хотите расслабиться и посмотреть свежую серию крутейщего сериала, которая вышла прямо вот сегодня и которую завтра все на работе будут обсуждать. А у вас скажем вдруг ваш "нетфликс" не работет. Или интернет. Или электричество. Вас устроит в такой ситуации ответ: «Мы подключили специалистов к решению вашей проблемы. Пожалуйста, ожидайте ответа в течении 24 часов»?
Даже если вас устроит, то я могу себе представить что кучу людей не устроит. И не только если речь идёт о "нетфликсе" из моего примера.
То есть если всё насктолько сложно, что нужно подключать основных разработчиков, то это наверняка несрочная проблема.
А вот это уже зависит от размера вашей фирмы, того что у вас за продукты/клиенты и того в чём конкретно заключается проблема.
У нас 24 часа в сутки минимум два разработчика(из них один сениор или выше) сидят "на дежурстве". Хотя бы просто потому что клиенты так хотят. Другое дело что размер фирмы позволяет такие дежурства делать добровольными и достаточно редкими. И контракт с клентами позволяет время на дежурстве на 50% рассматривать как рабочее и при этом ещё и оплачивать по двойной ставке(это если аврала не было, аврал оплачивается отдельно). То есть грубо говоря если сел после работы на дежурство, то следующий день у тебя выходной и оплачивается по двойному тарифу.
Но я знаю кучу фирм, которые себе такого люксуса позволить не могут и там "дежурство" это когда тебе просто могут после работы позвонить и сказать что есть проблема и её надо решать.
В статье говорится о том, что не нужно дёргать разработчика по любому чиху, а не то, что следует забить на форс-мажоры.
На мой взгляд проблема статьи как раз в том и заключается что в ней нигде не определено что такое "чих" и что такое "не чих". И даже не даётся никаких "инструментов" или "правил" для того чтобы провести границу между этими вещами.
Потому что спросите кого угодно и он с вами согласится что "не нужно дёргать разработчика по любому чиху" даже если никогда про асинхронное общение и не слышал. Но при этом всё равно постоянно дёргают.
в ней нигде не определено что такое «чих» и что такое «не чих».
Соглашусь, этого не хватает. Но я думаю, целью статьи было только объяснять, что асинхронность — это действительно важно. Потому что… вы уже описали выше :-)
Например у нас есть синхронная поддержка (и асинхронной её сделать нельзя, клиенты привыкли что им отвечают в течение нескольких минут, да и по конкурентам это стандарт). Есть вопросы, на которые поддержка может ответить сама, есть вопросы по которым надо дёрнуть разработчика (например, баг в системе. Поддержка может его воспроизвести, проверить точно ли это баг на нашей стороне, но не может исправить). Или например запрос на новую фичу, поддержка не может оценить в какие сроки мы можем её сделать.
Однако с ведением базы знаний, таск-менеджера и т.д. можно со временем снизить вовлечённость разработчиков до минимума.
Т.е. сперва идёт фильтрация по базе знаний, может этот вопрос уже всплывал, затем оценивается срочность, если задача не «горит», то просто создаётся тикет в Джире. И только если совсем горит — вынимаем разработчика из потока. По мере обучения сотрудника техподдержки и заполнения базы — дёргать разработчика приходится всё реже.
А если ввести асинхронность? Юзер в Телеге должен ждать 24 часа?Техподдержку надо разбивать на группы/линии. Асинхронность нужна только разработчикам.
1 линия — работник техподдержки, сидящий в чате (синхронное общение с юзером). Если он знает ответ, то отвечает юзеру немедленно. Если не знает, то дёргает 2 линию.
2 линия — опытный работник техподдержки, который знает ответы на почти всё, но не является разработчиком. Синхронное общение с 1 линией. Если он определяет, что это баг, суперсложный вопрос или для расследования надо рыться в коде и т.п., то сообщает юзеру «передал вопрос разрабочикам» и дёргает 3 линию.
3 линия — разработчик, которого дёргают только при сложнейших тикетах. Он может работать асинхронно.
Вы спрашиваете, что делать с граничными случаями или исключениями.
Менеджер не хочет думать, брать на себя ответственность и отвечать на эти вопросы, поэтому звонит.
А вы не резюмируете его пространные слова из разговора в описании задачи.
Очень эффективная работа :-D
У меня за правило — если обсуждение по таске произошло в чате или звонке, то я оставляю комментарий с кратким содержанием звонка в тикете, и тегаю всех кто был в звонке
- Рабочее время менеджера стоит не меньше вашего, а вы хотите чтобы оно было потрачено на составление формального и исчерпывающего описания для вашего удобства.
- Успех работы зависит в очень значительной степени от того, насколько хороши принимаемые менеджером решения. А это означает, что голова менеджера должна быть максимально свободна от задач, которые могу быть решены без него. Вы же пытаетесь заставить мегеджера формализовать то, что можете формализовать и сами. Да еще по удобному вам графику.
Для меня это выглядит как своего рода программистский снобизм. Менеджер — это не сервис для удобства разработчика, менеджер — это тот кто создает продукт с помощью разработчиков.
Это от ситуации зависит. Встречал в своей жизни оба варианта. И даже вариант когда разработчик это сервис для удобства менеджера :)
Ваш «менеджер» в этой цепочке где находится?Мне интересен этот вопрос. Поэтому опишу свое представление подробно.
Из того, что я видел это работает примерно так. Менеджер соберет информацию об этой задаче с отчетом, посидит поразмышляет как это будет выглядеть, что стоит реализовывать, а что слишком накладно, справится ли с этим текущий коллектив, или нужны еще люди, кто примерно в команде какую часть может делать. Очень сильно в детали возможно влезть не сможет, все зависит от его компетенции.
Потом (если менеджер не выполняет функций тимлида и аналитика) он будет детально обсуждать все с тимлидом и аналитиком. Когда они вместе поймут как это все будет работать, тимлид начнет «нарезать» задачи для программистов, описывая детальные требования. Менеджер по ходу работ будет смотреть что получается, укладываемся ли в сроки, согласовывать задачи программистам, помогать выбрать решение, когда это решение требует общего видения задачи и бизнеса, которого недостает тимлиду.
Наверно есть много других вариантов, с которыми я знаком похуже. Например, менеджер может быть чистым управленцем и не разбираться больше не в чем. Тогда чем меньше он будет вмешиваться, тем лучше. Его задача — только ресурсы и быть прокладкой между руководством компании и программистами.
Менеджер может быть управленцем и аналитиком бизнес-требований одновременно. Тогда он объясняет эти требования тимлиду, который уже подробно формулирует их программистам.
Если в команде нет тимлида, тогда либо каждый программист должен выполнять функции тимлида по своему направлению (т.е. понимать и интерпретировать бизнес-требования к своим модулям), либо менеджер должен взять на себя функции тимлида. Второй вариант подразумевает, что менеджер — хороший программист или был хорошим программистом.
ИМХО, в исходном сообщении eumorozov проблема в том, что в его компании менеджеры и программисты спихивают с себя функции, которые как правило берет на себя тимлид, не желая ими заниматься.
Менеджер хочет позвонить и объяснить свои туманные мысли программисту, потому что именно так он бы работал с тимлидом, который «в теме». Сформулировать требования детально менеджер не может, потому что считает, что ему платят за менеджмент а не за функции лидера команды разработчиков.
Программист не желает преобразовывать туманные объяснения менеджера, потому что считает, что ему платят только за программирование и знание фреймворков, а разжевывать бизнес-требования не его задача.
Как обычно, лучшее оружие в таких битвах со стороны программиста — ограничение неформальных контактов. Типа, напишите мне все это формально, в письме, чтобы я четко понял что мне делать (и чтобы ваша некомпетентность и вина в глупостях которые мы натворим была задокументирована).
Такая борьба делает работу неэффективной.
Обычное решение — добавить тимлида, который разжует и нарежет все для программистов.
Другое решение — программист может взять на себя обязанности тимлида-самому-себе. В некоторых случаях это может не совпадать с текущими карьерными планами программиста. Например, зачем ему изучать область бизнес-требований, если возможно завтра он будет работать уже в другой области?
Худший вариант — если чистый менеджер (не тимлид по совместительству) возьмет на себя эти обязанности. Потому что если он недостаточно компетентен как разработчик для функций тим-лидерства, то от его детальной формулировки все равно не будет пользы, а время он потратит. Если он достаточно компетентен для этого, то возможно у него нет на это времени. Если у него есть на это время, тогда возможно пора навалить на него больше проектов, чтобы у него не было времени заниматься функциями тим-лидера по каждому. Потому, что специалиста, который достаточно хорош, чтобы быть и менеджером и тимлидом одновременно выгоднее привлечь в большее число проектов, чем позволить ему утонуть в тимлидской работе на одном проекте.
Возможны варианты.
- Допустим, ваш менеджер — уважаемый всеми специалист с большой буквы, на голову выше любого разработчика. Тогда такого человека нужно предельно экономить. Оптимально, чтобы этот человек не вырабатывал решения а только выбирал наиболее приемлемое из предлагаемых разработчиками. Т.е. разработчик из своего опыта прикидывает несколько работоспосоьных вариантов, описывает их менеджеру и тот быстро выбирает приемлемое для пользователей или других целей.
- Допустим, ваш менеджер просто довольно посредственная прокладка между пользователями и программистами. Тогда бесполезно требовать от него детально сформулированных требований. Эта задача ему просто не по зубам. Он потратит кучу времени и все равно что-то не учтет. Не так легко детально продумать задачу, которую не собираешься сам реализовывать. Сколько раз сложности становились для вас очевидными только в середине разработки? У менеджера ведь нет таких возможностей. Поэтому самый эффективный вариант опять тот же что в предыдущем пункте — менеджер только выбирает. Или
- Допустим, менеджер ставит задачи детально, описывает все подробно и почти все предусматривает. Возможно это означает, что компания все время решает однотипные задачи и благодаря этому работу удается эффективно распределять. В такой компании наверно работать легко, но скучно. Возможно это означает, что менеджер слишком хорош и скоро его повысят. Еще вариант — этот менеджер не умеет распределять работу и слишком много работы берет на себя. Тогда он работает неэффективно.
- Задачи однотипные, задача менеджера тривиальна и все равно от него сплошной вред. Это просто плохой менеджер, которого нужно заменить.
Я: «Но ведь в задаче не говорилось, что они должны обрабатываться отдельно, а так как всем признакам в задаче соответствуют, то и появляются первыми»
Менеджер: «Переделать»
Вам нужен бизнес-аналитик. Хороший.
Тогда он будет пинать плохих менеджеров, заказчиков и прочих людей, не имеющих системного мышления. Он обеспечит полноту и непротиворечивость требований.
Беда в том, что хорошие аналитики встречаются пожалуй даже реже хороших разрабов. А кроме того, пока роль аналитика равномерно размазана по вам и вашим коллегам, руководство не захочет нанимать нового спеца.
Именно поэтому у них такая чудовищная бюрократия. Советую копировать из чата цитаты прямо в таски и записи конференций, и решать только письменно и желательно по почте. Уже ни раз это выручало.
Еще есть дурацкая привычка у западных менеджеров все решать по телефону (может быть, только у меня так, но слышал, что нет).
Подтверждаю. Работаем с американской компанией. Когда можно более эффективно всё решить в несколько предложений текста, они зачем-то хотят всё обсудить голосом. При этом каждый раз остаётся что-то, о чём не успели или забыли поговорить. При этом с их стороны никто не делает план совещания и я ещё не видел, чтобы после совещания кто-то написал какой-то протокол: что обсуждали, что решили, что делать, что не делать и т. п.
Поэтому я просто не хожу на большинство совещаний, потому что они лично для меня бессмысленны и только отнимают время, более того в вечерние часы.
Я обычно в таком случае открываю тикет скриншарю его и дописываю туда то, что говорят потом спрашиваю правильно ли я написал. Таким образом остаётся согласованная запись принятых решений
Примеры:
Наш механик приходит на работу к 8 утра, что для меня unreal. С вечера я ему оставляю чертеж с запиской, на следующий день я могу получить готовую деталь или уточняющие вопросы — если я что-то не так нарисовал.
Вчетвером (географически из разных мест Москвы) писали некую программу, встречались раз в месяц для пития чая и обсуждения оргвопросов, а не технических. Всё техническое вполне решалось по почте.
А вот контрпример — есть коллега из другой страны — он переписываться не любит, ему нужен эмоциональный контакт и хочется по размахивать руками по скайпу.
* Лично — наиболее «агрессивный» вид коммуникаций; канал не только (и не столько) звуковой, но еще и зрительный (80%-90% информации, ага). Совершенно нет времени подумать и палишься по полной (мимика, жесты, невербальные реакции). Зато результат — здесь и сейчас. Синхронный, да.
* Телефон — тоже синхронный, чуть менее «агрессивный» вариант (меньше каналов передачи информации), но тоже нет времени.
* IM (instant messages — SMS, асечьки, всё это) — кагбэ асинхронный, но предполагает достаточно быстрое время реакции. Не секунды, но желательно реагировать побыстрее. Немного времени уже появляется, но не очень. Зато ожидаемое время реакции достаточно короткое.
* Email — наиболее «мягкий» вариант — не предполагает мгновенной реакции, есть время подумать и реагировать правильно. НО — от респондента не стоит ожидать не то что быстрой реакции, но и реакции вообще.
Это всё разные инструменты и применяются в разных случаях.
Поэтому начальство любит совещания — у начальника вся информация, он подготовился, он быстро реагирует. А совещаемые имеют бледный вид — информации мало, а времени на соображение нет совсем. Еще и палятся мимикой.
Поэтому клиенты любят личные встречи с «компьютерщиками». Им так удобнее, клиент любит ушами. А компьютерщику-интроверту при синхронном общении ппц.
Поэтому «компьютерщики» любят асинхронное общение — IM вместо личных встреч (достаточно «быстрое» общение, хотя начальство/клиент не сильно любит тыкать пальчиком в буковки) и электропочта для всего остального. Когда есть время подумать и правильно сформулировать.
«Серебрянкой пули» нет — для каждой задачи и каждого человека свой комфортный инструмент общения.
Поэтому «компьютерщики» любят асинхронное общение — IM вместо личных встреч
Зависит от компании. Я работаю в IT компании, тут IM мало кто любит, почти все предпочитают лично подойти и поговорить по любому поводу. Ну либо email. Так сложилось. сперва подгорало знатно)
Когда есть время подумать и правильно сформулировать.
Поэтому я узнаю тему будущей встречи, тезисы и делаю себе план. Подглядывать туда выглядит так себе, особенно когда встреча разноуровневая (начальник-подчиненный), но работает. Альтернатива — учить план, но это на любителя. Хотя перед особо важными переговорами я планы именно учу.
Если встреча проходит по телефону, то у меня бывает целый скрипт, чтобы ничего не забыть и все сделать правильно. Как минимум — чеклист. Результат, обычно, превосходит ожидания.
Требует времени, но оно того стоит — если от таких встреч зависит что-то лично мне важное.
- IM (instant messages — SMS, асечьки, всё это) — кагбэ асинхронный, но предполагает достаточно быстрое время реакции. Не секунды, но желательно реагировать побыстрее. Немного времени уже появляется, но не очень. Зато ожидаемое время реакции достаточно короткое.
Зависит от. Я позволяю себе часами не отвечать в слаке, если занят. Могу отвлечься только при личном меншне.
Очень многие письма между коллегами пишутся потому, что автор письма что-то не понимает (иногда не осознавая этого). Решение таких проблем асинхронно это ооочень долгий с сложный процесс.
Формальное общение тимлида с программистами по почте по моему опыту приводит к ситуации, когда тимлиду быстрее и проще написать весь код самому, чем бороться с этими роботами, которым нужно все разжевать и все равно они что-то сделают не так.
В этом случае нужно разграничить должностные обязанности тимлида. Либо он тоже пишет код, не отвлекаясь на обезьянок и общаясь с ними асинхронно, либо синхронно нянчится с обезьянками.
Проблема в том, что программирование и наставничество — две разные задачи, которые не могут решаться одновременно одним человеком. Довольно часто в маленьких командах лиду приходится совмещать эти две функции, что приводит к перегрузкам и снижению работоспособности.
Вот ещё чтиво на эту тему:
https://habr.com/ru/company/touchinstinct/blog/332056/
И какой выход?
Во всех своих проектах я кодил всю предметную логику бекенда как минимум, писал грубый прототип UI, детальные требования, потом все пояснял разработчикам, потом проверял до тестировщиков, отвечал на вопросы тестировщиков и проверял после тестировщиков. Это ужасно утомительно, но я не нашел других способов создать нечто достаточно сложное и не заставить каждого разработчика по уши утонуть в предметной области.
Сортировка писем помогает, но так себе.
В результате у меня в почте общаются юниксоиды, ораклисты, ноsqlщики, постряшники, заказчики всех мастей… и из всего этого приходится находить крупицы полезной информации.
Значит надо менять работу.
Когда я перестал быть молодым, я понял — если это нужно было вчера, вы должны были прийти ко мне позавчера. Ну или хотя бы вчера.
Задача, поставленная после обеда, к окончанию рабочего дня выполнена не будет с шансом в 99% и я об этом сразу и спокойно говорю.
если сам прячешься — нечего от других требовать смелого отстаивания гражданской позицииДоводя до логического завершения: или поименное открытое голосование на выборах, или не сметь критиковать правительство?
На мой взгляд вы с вашим оппонентом взаимно, кхм, погорячились. Если посмотреть, с чего началась дискуссия, то «авралить» или «не авралить» зависит от тысячи причин. От отношений с начальником, от важности конкретной работы, от регулярности авралов, етц, етц. Универсального решения тут нет: вы же оба ведете себя так, как будто оно в наличии, причем у каждого единственно верное для всех случаев жизни.
А дальше ваша дискуссия закономерно развивалась по классическому сценарию срача в стиле двача. Когда мне она совсем стала напоминать блаженные девяностые, я решил тоже высказаться и напомнить, что сейчас вообще-то десятые на исходе.
Вот и все.
А что и как там было на дваче, я не в курсе (кстати, разве он уже существовал в девяностые?). Я просто следую принципу: в равном положении не требуй от других того, чего сам не делаешь. Разве это неправильно?
Пока оставим за скобками вопросы, как сменить страну, когда есть мать-инвалид, девять кошаков, подруга, у которой свои причины не менять страну, и такую мелочь, как любовь к родине. Предположим, что меня только разговорный язык держит.
Да легко. Упал ПРОД в ключевом проекте. Это же подчас происходит неожиданно и мгновенно.
А "дежурная смена" разве не на синхронной связи должна находиться?
Как быть если прод "падает" из-за багов в коде? Если эти баги появились после релиза в котором ваши коммиты и возможно проблема именно в них? Если откат к предыдущей версии возможен, но пока баг не исправлен и новая версия опять не вернулась на прод, то фирма теряет деньги?
Как быть если даже не прод упал, а скажем из-за каких-то предположительно ваших действий появились какие-то проблемы, которые блокируют работу нескольких человек? Всего отдела? Всей фирмы?
Это в принципе невозможно? Тогда вам повезло и вас можно перевести на асинхронную коммуникацию. Но для кучи людей такой сценарий полностью исключить нельзя.
Как быть если прод «падает» из-за багов в коде?
Откатить его. Кстати, а как он может упасть? Его ведь должны предварительно протестировать, перед выпуском в релиз. Значит, ответственность несёт не разработчик, а тестировщик.
ваши коммиты и возможно проблема именно в них?
Очевидно, исправить и закоммитить.
то фирма теряет деньги?
Нет, в 99% случаев фирма не теряет деньги.
из-за каких-то предположительно ваших действий… блокируют работу нескольких человек? Всего отдела? Всей фирмы?
Отправить разработчику письмо, чтобы он всё исправил. Более того, таких ситуаций не может возникнуть при грамотной организации рабочих процессов.
Это в принципе невозможно?
Это возможно, но 1) для очень малой доли компаний
2) это ожидаемые риски инвестиций, и, соответственно, их можно предотвратить или скомпенсировать
3) обычно по вине самой компании, а не разработчика.
Вас почитать, так разработчик вообще никакой ответственности за свою работу не несет. Плохие процессы, тестировщики, руководство, какая-то мистическая "сама компания".
Допустим, что самолёт упал на город. Естественно, ждать, пока службы разберут завалы и восстановят жилищные условия, неприемлемо. Однако, сама возможность падения самолёта недопустима и многократно важнее.
Аналогично, как часто и как долго у вас дома нет света? Или может воды? Трубы, знаете ли, старые везде, ненадёжные, но вода у вас почему-то есть почти всегда.
Почему вы думаете, что «ронять» сервера — это нормально, а вот именно никак не связанный с этим разработчик обязательно должен всё починить как можно быстрее? Надо бороться с причинами, а не последствиями.
Кстати, а как он может упасть? Его ведь должны предварительно протестировать, перед выпуском в релиз. Значит, ответственность несёт не разработчик, а тестировщик.
Решить кто несёт ответственность можно и потом в асинхронном режиме. Ответственность в этот момент мало кого интересует. Большинство людей в такой момент интересует как максимально быстро и эффективно решить проблему.
Очевидно, исправить и закоммитить.
Если это должны делать вы, а вы в "асинхронном режиме" и смотрите почту пару раз в день?
Нет, в 99% случаев фирма не теряет деньги.
Откуда статистика? И даже если, то что делать в 1% случаев?
Отправить разработчику письмо, чтобы он всё исправил.
И ждать полдня-день пока он это письмо прочитает? А все остальные всё это время просто ждут? Офигенная эффективность работы получается.
Это возможно, но
И ещё раз: откуда такая статистика?
как максимально быстро и эффективно решить проблему
Ну… ответ мы уже выяснили. А вот когда проблема решается, наступает фаза анализа и наказания. И тогда оказывается, что сообщение Коляна из вк не оправдывает тебя за отключение питания в серверной.
Если это должны делать вы, а вы в «асинхронном режиме» и смотрите почту пару раз в день?
Получается, что придётся подождать новый супер-крутой функции для релиза ещё один день. Если вы не выпускаете релизы каждый день, то это не проблема. Проблема в том, что текущие сервера упали.
Откуда статистика? И даже если, то что делать в 1% случаев?
Из моего личного опыта. Конечно, можете не верить. Тем более, как можно терять то, чего ещё не существует? Упущенную выгоду? Да, это и есть тот самый 1%, когда надо применять «особую» стратегию. Какую? Я не помню.
И ждать полдня-день пока он это письмо прочитает?
Да. Только где-то это письмо называется приказом и его доставляют лично в руки.
А все остальные всё это время просто ждут?
Не бывает компаний, где всего 1 разработчик и множество пост-продакшен + административного персонала.
Офигенная эффективность работы получается.
эффективность = Деньги/время = зарплата/30 дней = константа. Не зависит от подобных ситуаций.
И ещё раз: откуда такая статистика?
Это не статистика, а анализ рисков бизнес-плана и выработка соответствующих стратегий/сценариев.
Ну… ответ мы уже выяснили
Где?
Получается, что придётся подождать новый супер-крутой функции для релиза ещё один день
Если подождать придётся исключительно из-за того что вы любитель асинхронной коммуникации и из-за этого фирма потерет приличную сумму денег, то скорее всего вы либо измените свои приоритеты в плане коммуникации, либо не очень долго проработаете на этой фирме.
Из моего личного опыта.
Так себе источник честно говоря.
Да. Только где-то это письмо называется приказом и его доставляют лично в руки.
В какие руки, вы о чём сейчас вообще? Как вы это будете кому-то в руки доставлять если у вас человек сидит на удалёнке на другом конце земного шара и в этот день решил поработать не из дома?
Не бывает компаний, где всего 1 разработчик и множество пост-продакшен + административного персонала.
Так если у вас все разработчики такие умные и все "асинхронно коммуницируют", то кто тогда должен проблему решать?
эффективность = Деньги/время = зарплата/30 дней = константа. Не зависит от подобных ситуаций.
Извините, но это вы вообще о чём сейчас? То есть если я работаю весь месяц или если я весь месяц мух на потолке считаю, то у меня эффективность одинаковая и зависит исключительно от моей зарплаты?
Это не статистика, а анализ рисков бизнес-плана и выработка соответствующих стратегий/сценариев.
От того что вы это назвали по другому, вы на мой вопрос не ответили. Но если вам так проще будет, то откуда такие "анализы рисков бизнес-плана и выработки соответствующих стратегий/сценариев"?
Где?
Откатить сервер на предыдущую рабочую версию.
либо не очень долго проработаете на этой фирме.
Вас не могут уволить по причине медленного ответа на сообщения в телеге. Либо это должно быть записано в вашем договоре/должностной инструкции.
Если подождать придётся исключительно из-за того что вы любитель асинхронной коммуникации
Подождать придётся из-за плохой работы пост-продакшена, которая выпустила в релиз нерабочий продукт. В первую очередь, в этом виноват контроль качества. А асинхронность всего лишь усугубляет последствия.
эффективность одинаковая и зависит исключительно от моей зарплаты?
К несчастью, именно так и есть. Чтобы повысить свою эффективность, вам надо меньше работать. Такой вот парадокс ежемесячной оплаты труда.
Причём, давно уже известно, как избавиться от этого парадокса — платить за результат, а не за время.
все «асинхронно коммуницируют», то кто тогда должен проблему решать?
Будут решать проблему асинхронно.
От того что вы это назвали по другому, вы на мой вопрос не ответили.
Давайте рассуждать логически. Вы бы завязали свой бизнес и «приличную сумму денег» на том, что все ваши работники мгновенно отвечают на сообщения и никогда не болеют, не опаздывают, не уезжают в отпуск, не отключаются от света или интернета? В таком случае в вас бы никто не инвестировал. Это же бред, тратить деньги на рандомные случайности, от которых вы никак не застрахованы.
Откатить сервер на предыдущую рабочую версию.
Это не решает проблему в абсолютно всех ситуациях.
Вас не могут уволить по причине медленного ответа на сообщения в телеге. Либо это должно быть записано в вашем договоре/должностной инструкции.
Ну так это часто и прописано если вы удалёнщик или на аутсорсе. И как раз об этом же речь и идёт: как устроить рабочие процессы чтобы такого прописывать никому не пришлось. И пока я ответа не увидел.
Подождать придётся из-за плохой работы пост-продакшена, которая выпустила в релиз нерабочий продукт. В первую очередь, в этом виноват контроль качества. А асинхронность всего лишь усугубляет последствия.
Ещё раз: кто там виноват это вопрос отдельный. Вопрос в том как решать возникшую проблему. И если асинхронность мешает или даже не даёт это сделать вовремя, то для многих фирм она просто не вариант и всё.
К несчастью, именно так и есть. Чтобы повысить свою эффективность, вам надо меньше работать. Такой вот парадокс ежемесячной оплаты труда.
Извините, но эффективность в моём понимании это количество работы сделанное за единицу времени. Или сделанное за единицу оплаты. И поэтому чтобы повысить свою эффективность надо успевать сделать больше работы при равных времени и/или оплате. А вы на мой взгляд какую-то чушь пишите.
Будут решать проблему асинхронно.
То есть велика вероятность что проблема не будет решена за приемлемое для фирмы время. И поэтому получается что асинхронность опять таки вариант далеко не для всех фирм и ситуаций.
Вы бы завязали свой бизнес и «приличную сумму денег» на том, что все ваши работники мгновенно отвечают на сообщения и никогда не болеют, не опаздывают, не уезжают в отпуск, не отключаются от света или интернета?
Я бы завязал свой бизнес на то, что в любой момент времени есть необходимое количество работников, которые будут мгновенно доступны для решения проблемы. И что ещё какое-то количество работников можно будет привлечь к решению проблемы относительно быстро.
Более того я бы планировал свои релизы так чтобы какой-то срок сразу после релиза, наиболее большое количество сотрудников что-то делавших для этого релиза, были максимально быстро доступны для устранения возможных проблем.
Такое вполне себе реально и реализовано в куче фирм. И я не знаю как это должно работать если все ваши сотрудники сидят в "асинхронном режиме".
И я не знаю как это должно работать
Я пытался вам объяснить, но вы упорно не хотите понять меня.
эффективность это количество работы сделанное за единицу оплаты
Я очень рад за вас, что вы готовы работать даже не за еду, а просто за бесплатно. Но я предпочитаю, что бы, когда я делаю в 2 раза больше, мне платили в 2 раза больше. А в вашем случае, эффективность будет снижаться в 2 раза…
Я пытался вам объяснить, но вы упорно не хотите понять меня
Потому что так, как вы это объясняете оно работает в каких-то отдельных случаях, а не так что это будет работать всегда и везде.
Я очень рад за вас, что вы готовы работать даже не за еду, а просто за бесплатно.
Хм. На основании чего вы сделали такой вывод?
Но я предпочитаю, что бы, когда я делаю в 2 раза больше, мне платили в 2 раза больше.
Поэтому в большинстве случаев эффективность работы высчитывают на единицу времени. И тогда если кто-то работает эффективнее, то ему повышают зарплату.
Иногда(правда гораздо реже) эффективность высчитывают на единицу оплаты. Но тогда если кто-то работает эффективнее, то ему сокращают рабочее время.
Спасибо, автор, полняли очень важную тему. Действительно, есть производственная деятельность требующая синхронного общения, но ещё больше той, которая не требует постоянной синхронизации. По хорошему все виды деятельности должны быть перечислены с указанием способов коммуникаций.
У руководителей больше синхронной, пожалуй. Но тоже не вся. У топ-менеджера почти вся деятельность синхронная.
Ситуации бывают разные. Иногда асинтрон помогает подумать, переварить и выдать достойный вариант. А иногда он означает потерянный день для нескольких человек, там где все можно было выяснить и решить за 15 немедленно.
Я вот в компании, очень любящей зум и слак стал людей вытаскивать на личные встречи, особенно когда надо что-нибудь кроссфункциональное обсудить с QA, аналитиками и архитекторами какими-нибудь разом. И знаете что? Работает, время тратим меньше, проблемы решаются.
Практикуем это у себя, но пропорции скорее 50 на 50. Когда пришёл в компанию, это было отчасти непривычно, так как воспринимал только почту как способ асинхронной коммуникации.
Хотел бы выделить некоторые моменты:
Мы так же используем голосовые сообщения, к примеру, если необходимо описать что-то большое, при этом отправляем его с кратким резюме, чтобы легче было искать. Чаще это делают менеджеры, разработчики слегка меньше, но тоже. Плюсом возможность слушать их на 1.5/2x.
Очень важно, чтобы асинхронная коммуникация не затягивалась. Особенно важно с голосовыми сообщениями. Пришли к этому не сразу, но возникали ситуации, в которых эффективность общения понижалась. Главная проблема неэффективности длинных ассинхронных коммуникаций — необходимость восстанавливать контекст каждый раз. Это очень затратно для больших обсуждений. Собственно теперь, если видим с самого начала(первые 2-4 сообщения), что нужно много обсуждать, планируем созвон.
Отдельно отмечу, что если начинается общение в реальном времени в моменте, где собирались общаться асинхронно, рекомендуется созваниваться, ибо это будет эффективнее.
Планирование тикетов. Мы делаем комбинированный вариант. Сначала в асинхронном режиме каждый пишет вопросы, комментарии, часть из них решается сразу, потом непосредственно на созвоне решаются остальные утверждаются окончательно требования и делается оценка.
В целом, всё примерно так, как изложено в статье.
Но есть особенности.
Например, на той стороне должны быть люди, которые вместе со мной образуют сколоченный коллектив. Не со всеми работа по переписке возможна. Нужно, чтобы люди друг друга понимали. В том числе, в психологическом плане. Не один проект проваливался из-за того, что корреспонденты не могли найти общий язык и раздражали друг друга. Да и письма могут писать далеко не все.
Периодически (от раза в неделю до ораза в месяц) желательно проводить личные встречи для синхронизации задач и понимания, где мы стоим.
Телефонные разговоры и скайп помогают, но живое общение заменить трудно.
В целом, работу дома, которую я практикую в той или иной степени с 1987 года (не путать с удаленной работой) следует рассматривать, как изощренный способ самоэксплуатации, поскольку рабочий день не нормирован и не ограничен.
Есть и обратные примеры — когда начальник пишет в 9 часов в почту «сделать что-то-там до 12-00», а я в 8 уже выехал и давно за городом в сотне километров, и даже знать не знаю, что там письмо какое-то пришло. Другой коллега считает нормальным в рабочий чат всякие поздравления писать. Или двое между собой по своему вопросу в этом чате что-то обсуждают — почему бы не писать в личку конкретному человеку, если выяснили, что это только вас двоих касается? Пришлось просто выключить звуковое оповещение этого чата, срабатывает только когда кто-то мне отвечает.
Я думаю какое-то решение для себя все нашли. Или как минимум многие. Мы например каждые пару часов ходим всей командой "пить кофе". И в этот момент обсуждаем какие-то общие вопросы, которые кто-то не в состоянии решить один. И люди из других команд в это время к нам приходят со своими проблемами и мы смотрим когда и как мы им можем с их проблемами помочь. И это можно сказать "асинхронно" и великолепно работает большую часть времени.
Но где-то в среднем один-два раза в неделю происходят события когда кто-то нарушает этот ритуал и общается "синхронно" потому ему это надо очень срочно. Примерно в двух случаях из трёх это действительно так и это вполне себе оправдывает существование "синхронного варианта" как такового.
— разработчик наиболее эффективно работает в асинхронном режиме
— клиенты хотят чтобы им отвечали синхронно (быстрый ответ — стандарт во многих направлениях), и не всегда можно ответить не выдёргивая разработчиков
— при асинхронной работе страдает командное взаимодействие. Начиная с того, что например дизайнер будет простаивать, пока не получит ответа от асинхронного разработчика сможет ли он запилить такую-то фичу на макете. И заканчивая тем, что в таком режиме задачи слишком атомизируются, разработчик может не видеть полной картины, которая бы всплыла на митапе. Например, я перед тем как реализовать очередной фича-реквест стараюсь понять для чего конкретно нужна клиенту эта фича. Может быть он и так может сделать это в нашей системе каким-то другим способом, просто не знает как и поэтому изобретает велосипед. Без полноценного контакта такое теряется.
Т.е. да, асинхронность это хорошо, не нужно слишком увлекаться Slack и иже с ними. Но и асинхронностью тоже слишком увлекаться не стоит.
Асинхронное общение — вот настоящая причина, почему удалённая работа более эффективна