Теперь асинхронную связь внедряют не только на удалёнке
Иллюстрация: Yin Weihung
Исследование за исследованием вновь доказывают, что удалённые работники более продуктивны, чем их коллеги в офисе.
Только не совсем понятно, почему.
Да, люди сохраняют время (и рассудок), избегая пробок в час пик. На них не действуют отвлекающие факторы в офисе. Они обретают чувство контроля над рабочим графиком. Больше времени остаётся для семьи, друзей и хобби.
Но кроме поездок на работу, все эти преимущества не столько результат автономного расположения, сколько побочный продукт асинхронной связи — сотрудники сами решают, когда общаться с коллегами.
Многие руководители думают об организации удалённой работы, но мало кто рассматривают идею более асинхронной коммуникации. Хотя я верю, что будущее за удалённой работой, но асинхронная связь — ещё более важный фактор в производительности команды, независимо от того, работает она удалённо или нет. Асинхронность не только обеспечивает наилучший результат, но позволяет людям делать более важную работу и жить более свободной и полноценной жизнью.
Опираясь на опыт собственной удалённой и в значительной степени асинхронной компании Doist, попробую объяснить, что такое асинхронная связь, как она повышает производительность и какие конкретные шаги вы можете предпринять для создания более асинхронной среды.
Что такое асинхронная связь?
По сути, асинхронная связь — это когда вы отправляете сообщение, не ожидая немедленного ответа. Например, электронное письмо. Я открываю и отвечаю на письма через несколько часов.
Напротив, синхронная связь — это когда вы отправляете сообщение, а получатель сразу его читает и немедленно отвечает. Личное общение, как и совещания — примеры чисто синхронного общения. Вы что-то говорите, я сразу получаю информацию и тут же реагирую.
Но цифровые формы коммуникации, такие как обмен сообщениями в реальном времени, тоже могут быть синхронными. Вы отправляете сообщение, я получаю уведомление и открываю Slack, чтобы в режиме реального времени прочитать сообщение и ответить. Даже электронная почта рассматривается в основном как синхронная форма общения. Исследование Yahoo Labs от 2015 года показало, что среднее время ответа на электронные письма составляет всего две минуты.
Прежде чем углубиться в преимущества более асинхронного подхода к совместной работе, давайте посмотрим, почему мы должны подвергать сомнению наши текущие, в основном синхронные, способы работы и общения.
Проблемы с постоянным общением в режиме реального времени
Если сотрудники более продуктивны вне офиса, что-то не так с офисом.
Согласно статье ”Collaborative Overload” в Harvard Business Review, за последние двадцать лет работники стали на 50% больше времени уделять общению с коллегами. До 80% этого времени уходит на общение по электронной почте (в среднем, шесть часов в день), совещания (в среднем, 15%), а в последнее время ещё и приложения для обмена мгновенными сообщениями (пользователь Slack отправляет в среднем 200 сообщений в день, хотя и тысяча сообщений — «не исключение» для самых активных).
Эта тенденция к почти постоянному общению означает, что средний работник умственного труда должен планировать рабочий день вокруг нескольких совещаний, причём в промежутках между ними он работает рассеянно, отвлекаясь на электронную почту и Slack.
Что ещё хуже, рост мобильных технологий означает, что рабочие коммуникации больше не ограничиваются физическим рабочим местом или рабочим временем. Мы можем проверять электронную почту и отвечать на сообщения в любое время суток. В результате, мы никогда полностью не отключаемся. Как сказал один офисный работник в комментарии New York Magazine: «Раньше я просыпался, выключал будильник и проверял Tinder. Теперь я просыпаюсь и проверяю Slack».
Slack хвастается, что в рабочий день пользователи проводят в приложении девять и более часов. 90 минут активного использования, растянутые на девять часов, — это целая куча отвлекающих факторов
Такой исключительно синхронный стиль работы был бы оправдан, если бы давал результат. Но всё больше доказательств, что накладные расходы на общение в реальном времени мешают сфокусироваться на работе, истощают умственные ресурсы и в целом затрудняют достижение значимого прогресса.
Я уже приводил аргументы против приложений для обмена сообщениями в реальном времени, но стоит суммировать основные проблемы, которые распространяются на большинство форм синхронной связи:
- Постоянные отвлечения. Они отвлекают внимание и затрудняют прогресс в работе. Высокоэффективные, требующие когнитивных усилий виды деятельности, такие как программирование, написание текстов, проектирование, разработка стратегий и решение проблем, требуют длительных периодов глубокой, сфокусированной работы. Синхронная связь не позволяет выделить на это длительные отрезки времени.
Примеры мелкой работы Примеры глубокой работы Разбор писем в почтовом ящике Набросок плана для запуска новой фичи Ответы коллегам в чатах вроде Slack Программирование Телефонные звонки для налаживания логистики Подготовка к ключевой презентации Посещение совещаний с текучкой Поиск и анализ информации по определённой проблеме
Фразу «глубокая работа» ввёл профессор компьютерных наук Джорджтаунского университета и автор книг Кэл Ньюпорт
- Приоритет подключённости вместо продуктивности. В режиме реального времени вас стимулируют оставаться на связи и быть доступным в любое время. Если вы отключитесь, обсуждения продолжатся без вас, так что вы не можете ответить или даже увидеть их. Чтобы не пропустить важные решения и обсуждения, люди стараются всегда быть в сети и на как можно большем количестве совещаний, что вредит их благополучию и производительности.
- Ненужный стресс. Постоянная доступность означает, что работник не контролирует своё время. В течение дня он реагирует на запросы, а не проактивно устанавливает собственное расписание. Одно исследование показало, что люди компенсируют время, потерянное из-за отвлечений, пытаясь работать быстрее, что приводит к «большему стрессу, разочарованию, трате лишних сил и давлению». Синхронная культура прямо ведёт к выгоранию.
- Снижение качества обсуждений и неоптимальные решения. Когда нужно ответить немедленно, у людей нет времени тщательно продумать ключевые вопросы и дать вдумчивые ответы. Ваша первая реакция на ситуацию зачастую не будет самой лучшей.
Преимущества более асинхронной среды
Большинство людей воспринимают отвлечения как рутину, но некоторые компании, такие как Doist, Gitlab, Zapier, Automattic и Buffer, пытаются внедрить асинхронный подход. Вот некоторые из основных преимуществ лучшего контроля над персональными коммуникациями:
- Контроль рабочего времени = более счастливые и продуктивные сотрудники. В асинхронной среде нет установленных рабочих часов. У сотрудников почти полный контроль над тем, как они структурируют свои рабочие дни в соответствии с образом жизни, своими биоритмами и обязанностями (например, уход за детьми!). Некоторые работают ночью, потому что так им удобнее. Я каждое утро провожу час с сыном, и никто в моей асинхронной организации этого не замечает.
- Высококачественные коммуникации вместо поверхностных ответов. По общему признанию, асинхронная связь медленнее, но обычно более высокого качества. Люди учатся общаться более чётко и тщательно, чтобы избежать ненужной болтовни. У них есть время, чтобы обдумать конкретную проблему или идею и дать более продуманные ответы. Вместо рефлексивных реакций люди могут ответить тогда, когда готовы к этому (в качестве дополнительного преимущества: при наличии времени на обдумывание гораздо реже мы видим бездумные эмоциональные вспышки, за последние восемь лет у нас не было ни одной серьёзной проблемы с некорректным общением).
- Лучшее планирование = меньше стресс. Если отпадает возможность выслать запрос ASAP в последнюю минуту, возникает необходимость в продвинутом планировании. Люди учатся планировать рабочую нагрузку и более тщательно координировать свои действия, чтобы у коллег оставалось достаточно времени для ответа на их запросы. Это снимает напряжение, и в конечном итоге работа выполняется более качественно.
- Глубокая работа по умолчанию. Поскольку сотрудникам не обязательно читать сообщения в момент получения, они могут выделять большие отрезки времени на работу, которая создаёт наибольшую ценность для организации. Они возвращаются для пакетного ответа на сообщения 1-3 раза в день, а не прыгают туда-сюда между работой и сообщениями/совещаниями.
Хорошо Плохо Найти время для интересной беседы, а затем вернуться в режим глубокой работы Жонглёрские попытки общаться во время работы - Автоматическое документирование и лучшая прозрачность. Поскольку большинство сообщений происходит в письменной форме, ключевые обсуждения и важная информация автоматически документируются, особенно если вы используете более открытый инструмент, чем электронная почта. На эти разговоры проще поставить ссылку. Например, в Doist вместо выяснения причин решения или статуса конкретного проекта принято давать ссылку на соответствующие темы Twist.
В этом резюме за месяц наш директор по маркетингу Бренна ссылается на соответствующие темы, чтобы людям было удобно разобраться в асинхронном режиме.
- Равенство часовых поясов. Плавная связь между часовыми поясами, никто не будет в невыгодном положении из-за своего часового пояса. Таким образом, вы расширяете свой пул возможных кандидатов. Вы можете создать звёздную и действительно разнообразную команду сотрудников со всего мира.
Хотя удержание сотрудников — своего рода показатель тщеславия, мы считаем, что именно благодаря асинхронной культуре за последние пять лет у нас практически нет текучки кадров. Удержание сотрудников превышает 90%, это намного выше среднего показателя по индустрии. Например, даже в Google с её легендарными кампусами, кучей льгот от бесплатного питания до бесплатных стрижек, средний срок работы сотрудника всего 1,1 года. Свобода работать из любого места в любое время важнее печенюшек и стоит нашей компании ровно ноль.
Но! Вам по-прежнему нужна и синхронная связь
Как у всего в жизни, у асинхронной культуры есть плюсы и минусы. Doist испытала и то, и другое.
В начале нашего асинхронного путешествия мы внесли в чёрный список большинство совещаний, так как считали их пустой тратой времени. Почти всё можно решить в письменной форме. Но недавно наш директор по маркетингу Бренна откровенно сказала, что мы потеряли некий человеческий контакт, а она чувствует себя в изоляции без личного контакта с другими сотрудниками.
Мы обнаружили, что излишняя асинхронность — тоже нехорошо
В итоге мы усвоили, что нужно всё-таки подмешивать синхронное общение там, где это имеет смысл: например, встречи один на один или выезды на природу. Трудно построить взаимопонимание и личные отношения только в письменной форме — we are human after all ©Daft Pank.
Вот некоторые приёмы, которые помогают нам устанавливать личные связи в команде:
- Каждый сотрудник как минимум ежемесячно беседует один на один со своим непосредственным руководителем, чтобы прощупать почву, обсудить проблемы, установить цели профессионального развития и т. д.
- Эксперименты со случайными командными тусовками через Zoom, где люди из разных команд могут собраться и поговорить о нерабочих вещах.
- Ежегодные корпоративные и командные выезды, где люди общаются лично.
Корпоративный выезд Doist на природу. Азорские острова, 2019
- Для всех новичков неделя личной работы с ведущим руководителем команды. Это помогает новичкам более комфортно влиться в процесс, задавая любые вопросы.
- Мы возмещаем стоимость коворкингов, чтобы люди при желании выходили из домов и больше общались в офисе/сообществе.
(Если интересно, вот моя более подробная статья про удалённую работу и душевное здоровье).
Сегодня мы минимизируем количество совещаний, но не запрещаем их. Наш текущий стек коммуникаций выглядит примерно так:
- 70% в асинхронном режиме через Twist, Github, Paper
- 25% в синхронном режиме через инструменты вроде Zoom, Appear.in или Google Meet
- 5% личных встреч, например, ежегодные выезды на природу всей фирмой или командой
Больше информации об используемых инструментах и наших способах общения см. в статье «Пирамида удалённого общения в команде».
Наш коммуникативный стек
В целом, используйте синхронную связь в следующих случаях:
- Вы хотите установить взаимопонимание между людьми (например, подходят беседы один на один или собрания команды).
- Нужно довести важную информацию или обсудить некие чувствительные темы.
- Много неизвестных факторов, и вы хотите провести мозговой штурм различных идей и решений.
- Много быстро меняющихся переменных, а вы хотите быстро довести до всех одинаковую информацию, например, на собрании по поводу запуска проекта.
- Произошёл кризис, требующий немедленного внимания, например, сбой сервера. Мы используем Telegram с включёнными уведомлениями только для экстренной связи.
Синхронная связь должна быть исключением, а не правилом.
Вместо (а иногда в дополнение) еженедельных собраний каждая команда в понедельник запускает поток и публикует результаты прошлой недели план на текущую. Таким образом, каждый может видеть, над чем работают все остальные в разных командах
Как создать асинхронную культуру внутри команды
Переход к асинхронности не произойдёт в одночасье. Он требует глубокого изменения инструментов, процессов, привычек и культуры. Вот некоторые конкретные шаги, которые вы можете предпринять как индивидуально, так и в качестве руководителя группы.
Что может сделать сотрудник:
- Оверкоммуникация. При отправке сообщения укажите как можно больше информации. Визуализируйте скриншотами или скринкастами. Чётко говорите, что вам нужно от другого человека и в какие сроки. Несколько минут, потраченных на детали и редактирование текста (для лучшего понимания), могут сэкономить дни общения туда-сюда в асинхронной среде.
Недостаточная коммуникация Оверкоммуникация Можешь прислать отчёт по контенту, как только найдётся время? Можешь прислать краткий отчёт (?1 стр.) с метриками блога из Google Analytics к следующему вторнику до 14-00 EST? Отметь вот что: топовые посты, кол-во уникальных просмотров, показатель отказов, CTR и план будущих постов. Вот неплохой пример такого отчёта: шаблон контент-отчёта. Буду благодарен!
Составляйте сообщение как можно более чётко и тщательно
- Заранее всё планируйте, чтобы у людей было время рассмотреть ваше сообщение. Например, «Хотелось бы закончить это за два дня, желательно с твоим участием», а не «Нужен твой ответ в течение часа».
- Всегда проверяйте настройки общего доступа к документам. Это кажется мелочью, но если кому-то придётся запросить доступ, это может задержать общий процесс на несколько часов или даже дней.
- Перед собраниями запустите поток или создайте документ. Поделитесь всей информацией и обсудите ключевые вопросы перед встречей, чтобы каждый мог прийти с полным пониманием темы.
- После встречи запишите обсуждение и результат. Запустите поток или продолжите документ, чтобы все пропустившие могли найти эту информацию. Мы даже начали экспериментировать с записью собраний на видео, чтобы все могли асинхронно «поприсутствовать».
- Отключить уведомления. Вместо этого выделите определённые интервалы времени в течение дня для проверки и ответов на электронные письма и сообщения.
- Продуктивно используйте время ожидания. Ожидание ответа не станет огромной проблемой, если есть, чем заняться.
Что может сделать тимлид:
- Содействовать тому, чтобы все освоили письменную коммуникацию как основной навык. Это позволит сократить время ожидания и быстрее передавать суть вещей. В асинхронной среде каждый обязан быть отличным писателем.
- Оценивать людей по их результатам, а не скорости отклика или количеству рабочих часов. Мы уже подробно писали об оценке производительности.
- Отменить обязательные часы работы или посещение офиса. Это позволит нанимать сотрудников из любой точки мира и естественным образом сдвинет вашу организацию в сторону более асинхронной связи, когда похлопывания по плечу более не доступны.
- Акцентировать внимание на доверии, организованности, независимости и подотчётности. Без этого асинхронная связь никогда не заработает. Например, одна из основных ценностей Doist гласит, что все доверяют вашим дедлайнам — и товарищам не нужно думать о том, что вы держите слово. Наш маркетолог Бренна Лори более подробно рассказывала, как выстроить доверие в удалённом коллективе с асинхронными коммуникациями.
- Внедрить в управление и принятие решений модель прямой ответственности (Direct Responsible Individual, DRI). Эту модель сделала популярной компания Apple. Она означает, что в компании всегда есть конкретный человек, ответственный за любую конкретную область или проект. Этот человек не делает всё сам, а скорее организует команду или проект, принимает ключевые решения и, как правило, информирован о сроках и результатах. Чем меньше человек участвует в принятии решений, чем более децентрализованы полномочия и выше индивидуальная ответственность каждого, тем эффективнее команда. Это верно в любой компании, но особенно важно для успеха в асинхронной среде.
- Установить разумные нормы на приемлемое время ответа. Например, у нас в Doist это 24 часа.
- Поставить прозрачность приоритетом. Например, каждый в Doist может прочитать все основные обсуждения любой команды, включая беседы руководства. Благодаря прозрачности никто не пропускает важные разговоры или решения. Все могут работать более эффективно и независимо, если не нужно запрашивать у других необходимую информацию.
Каждый сотрудник Doist имеет доступ ко всем разговорам руководства на общедоступном канале «Боссы Doist» (Doist Heads)
- Использовать инструменты, которые способствуют прозрачности, глубокой работе и асинхронной коммуникации, как пул-реквесты на GitHub, обсуждения Basecamp и потоки Twist. Не используйте электронную почту внутри компании. Хотя почта подходит для асинхронной связи, но она изолирует информацию внутри почтовых ящиков, где её никто не найдёт. Если люди не могут найти нужную информацию, эффективность сотрудничества резко снижается. Подробнее о подводных камнях электронной почты для общения см. здесь.
- Заведите каналы связи для чрезвычайных ситуаций. У нас это канал в Telegram. Есть ещё номера телефонов сотрудников. Мы используем их несколько раз в год. Большинство обсуждений не срочные и не требуют мгновенного ответа.
Асинхронность — это тяжёлая битва, которая бросает вызов привычному положению дел
Мы знаем, что мы бросаем вызов статус-кво и что спокойная, асинхронная связь не является текущей нормой. Требуется настоящая смена парадигмы.
Держим пари, что в будущем наиболее успешными компаниями станут те, кто решится на такую смену. Команды, которые не требуют от сотрудников постоянно быть на связи, которые ставят в приоритет асинхронное общение, чтобы создать условия для глубокой работы. Которые позволяют сотрудникам уходить в офлайн и полностью восстанавливать силы. Мы рады поделиться своим путешествием в этот мир и приглашаем вас исследовать его.
Комментарии (148)
Kanut
26.10.2019 11:21+5Асинхронная коммуникация далеко не всегда будет возможна. И как раз там где она возможна это очень часто и приводит к тому, что работа делается на удалёнке или вообще на аутсорсе.
Но пытаться перевести абсолютно всё на асинхронную коммуникацию это на мой взгляд не самая лучшая идея. Потому что часто как раз нужна "быстрая коммуникация".
А у вас логика выглядит примерно как "у мотоциклов полно плюсов и мотоциклисты перемещаются быстрее чем грузовики. Поэтому давайте всех пересадим с грузовиков на мотоциклы". Я конечно сильно преувеличил, но надеюсь что идея понятна.
ncix
27.10.2019 00:17+2А вы точно статью дочитали? Там же целая глава про необходимость и синхронных коммуникаций тоже
Kanut
27.10.2019 00:20-1Вы вот это имеете в виду
Мы знаем, что мы бросаем вызов статус-кво и что спокойная, асинхронная связь не является текущей нормой. Требуется настоящая смена парадигмы. Держим пари, что в будущем наиболее успешными компаниями станут те, кто решится на такую смену.
?
ncix
27.10.2019 03:29+1Но! Вам по-прежнему нужна и синхронная связь
Как у всего в жизни, у асинхронной культуры есть плюсы и минусы. Doist испытала и то, и другое..… и далее по тексту несколько экранов
Kanut
27.10.2019 11:57… и далее по тексту несколько экранов
И при этом в конце всё равно делается вывод что надо всем переходить на асинхронную коммуникацию.
И лично у меня после прочтения всего текста целиком сложилось чёткое впечатление что эту самую асинхронную коммуникацию считают этакой серебрянной пулей, которая сразу сделает прямо всех эффективней.
P.S. И да, "иногда вам нужна и синхронная коммуникация" это очень классная вставка. Только в ней нет никакого смысла пока чётко не опрeделено когда оно конкретно так. Потому что у нас сейчас практически во всех фирмах "асинхронная коммуникация" с "иногда" используемой "синхронной коммуникацией". И те кто используют синхронную уверены что в их случае это "нужно".
ncix
28.10.2019 09:53Тут с вами абсолютно согласен. Особенно в опенспейсах, каждый почитает за святое право подойти к любому сотруднику в любой момент и о чем-то начать говорить. Проблема кстати еще более актуальна для руководителей среднего звена, которые и руками сами что-то делают (почта, отчеты, аналитика, презентации) и оперативным управлением занимаются — сотрудники ходят один за другим "посоветоваться", постоянно переключая контекст. И пока напрямую их не заставишь самостоятельно принимать свои решения — так и будут ходить.
Но есть еще вышестоящие руководители, и сотрудники смежных подразделений — их выстроить куда сложнее чем своих.
edwardspec
26.10.2019 11:52+6Фрилансер (по допиливанию большого чужого ПО). Механизм общения с клиентом/менеджером:
1) клиент пишет письмо с требованием новой фичи и/или вопросами. Со всеми деталями.
2) работник пишет подробный ответ в течение 24 часов (кроме экстренных задач типа «сайт упал, посмотри, что там»). По новой фиче ответ — или 1. «уже сделано» (со всеми деталями «как это работает» + ссылкой «где посмотреть работающую фичу»), или 2. уточняющие вопросы по требованиям (например, «по добавлению поля Картинка в форму, позволяющую пользователю сайта опубликовать короткую заметку: достаточно ли одной картинки или пользователю нужно загружать много картинок?»), или 3. «сложность оцениваю так-то, ETA (предположительное время выполнения) — 32 мартобря».
С сотрудниками компании, с которой работаю — то же самое. Если мне нужно что-то от дизайнера или маркетолога — пишу письмо №1 и получаю письмо №2. Если им что-то нужно от меня — аналогично.
От созвонов и обсуждений в чатах (с которых часто начинают новые клиенты, когда они ещё не знают, хорошо ли я работаю — либо клиенты, у которых был плохой опыт с фрилансерами) мы с клиентами довольно быстро переходим к письмам по всем контрактам.
Был случай, в одной компании (где я работал давно) появилась маркетолог (ну вы знаете, какие они soft skills и общительные), которой было непривычно без еженедельных созвонов. У неё была уйма новых идей по фичам, и было очень важно хранить всё это в письменном виде. Настоял на письмах. Через месяц и она признала, что этот подход работает (с удивлением «даже не представляла себе, что координировать коммуникацию получится без звонков голосом»).
Требования из письма (в отличие от обговоренного устно) можно сразу скопировать в баг-трекер. Описание реализованной фичи (из моего ответа) можно скопировать в документацию. Клиент не может забыть, что именно просил (есть текст запроса фичи). Работник не может забыть, что у него просили. Если новый сотрудник Б спросит что-то, о чём уже спрашивал сотрудник А, то можно переслать ему письмо с ответом (а не рассказывать заново, как на совещаниях). Одни плюсы.
fougasse
26.10.2019 12:33А как вы ищете в большом количестве писем?
В случае, если Б просит что-то у А, что было обговорено, допустим, год назад. С вашим подходом получается очень много переписки, как это организовано?edwardspec
26.10.2019 12:53Поиском по ключевым словам + письма сгруппированы в цепочки.
(если вопрос про робот-пылесос, то предыдущая цепочка писем не могла не содержать это слово)fougasse
26.10.2019 13:44А если просто пылесос и таких цепочек несколько?
А если слово которое везде есть, что-то типа мощность или цвет?
Как вы такие вещи категоризируете в почте, тэгами?edwardspec
26.10.2019 14:33«Просто пылесоса» в сложном софте не бывает. Бывает софт из сотен фич, у которых есть свои названия.
Да, бывают цепочки сообщений типа «мой пылесос не работает, разберитесь», но когда я нахожу причину, то я всегда упоминаю сломавшуюся фичу в своём ответе. Поэтому по её названию цепочка найдётся.
rzerda
26.10.2019 13:30+8Встречный вопрос: как искать в большом количестве разговоров? Великая ценность вот этой всей асинхронщины в протоколировании. Компьютеры отлично ищут в тексте, достаточно взять себя в руки и писать на более-менее грамотном языке. В случае разговоров люди массово не помнят через месяц, до чего они договорились и почему.
fougasse
26.10.2019 13:35+1Мой вопрос был исключительно о роли почты в общении сотрудников А и Б относительно задачи решённой год назад.
Как мне кажется, почта проигрывает вещам типа багтрекеров и прочих Confluence.
Как в плане изначального удобства заполнения, так и категоризации с поиском.rzerda
26.10.2019 18:53-2А, недопонял. На мой взгляд, багтрекеры проигрывают почте, потому что себя нужно в руках держать сильнее, чем просто для генерации связного письменного текста. В почте человек отвечает человеку, а в багтрекере — бездушной машине, которой «ни в глаз не дать, ни отпеть» (если, конечно, нет специального человека, который ходит и прямо читает содержимое тикетов и статей в Confluence).
alekciy
27.10.2019 09:19+4В багтрекере так же человек отвечает человеку. Прекрасно там ведутся диалоги и это переписка видна всем. Просто не пишите в трекер как бездушная машина, пишите как при живом диалоге.
faoriu
27.10.2019 09:10+4На мой взгляд звонки вообще самый отвратительный способ передачи важной инфы, особенно когда звонящих несколько человек и звонят они в любой удобный им момент со своим словесным поносом, который уже ты сам как-то должен систематизировать и документировать.
sumanai
27.10.2019 12:442) работник пишет подробный ответ в течение 24 часов (кроме экстренных задач типа «сайт упал, посмотри, что там»).
А как определяется срочность? Тут или все письма читать, хотя бы заголовки, что приводит нас к постоянному отвлечению, или какие-то настройки использовать.edwardspec
27.10.2019 13:03Беглым просмотром письма. 5-10 секунд достаточно, чтобы узнать, форс-мажор там или нет.
И только тогда, когда открыл почту сам (без всплывающих уведомлений «пришло новое письмо»).sumanai
27.10.2019 13:11То есть вам приходится достаточно часто открывать почтовый клиент, иначе задача «Упал сервер, срочно починить» может провисеть полдня, что обычно неприемлемо.
edwardspec
27.10.2019 13:15А это вопрос привычки. Я очень часто проверяю почту.
Kanut
27.10.2019 13:42Я очень часто проверяю почту.
Тогда какая же это тогда асинхронная коммуникация если вы постоянно почту проверяете?
edwardspec
27.10.2019 13:53+1Синхронная коммуникация — это когда вы немедленно отвечаете.
Бегло просмотреть письмо можно сразу. Если запрошенная там фича — низкоприоритетная, а разработчик занят, то он не должен всё бросать.
Он может спокойно доделать то, чем занимался ранее.Kanut
27.10.2019 14:48А если не низкоприоритетное, то должен делать сразу?
И чем это отличается от ситуации когда кто-то подошёл ко мне когда я работаю и просит решить его проблему. А я ему говорю что проблема низкоприоритетная и я её сделаю на следующей неделе. Или вообще его игнорирую и делаю свою работу. Это тоже асинхронная коммуникация?
edwardspec
27.10.2019 15:06Ну начнём с того, что форс-мажор — это 1-2 письма в год. Major service disruption. Например, «по IP-адресу сервиса попало блокировкой Роскомнадзора, надо срочно поднять reverse proxy на другом IP».
Все остальные задачи должны быть рассмотрены в течение 24 часов.
И чем это отличается от ситуации когда кто-то подошёл ко мне когда я работаю и просит решить его проблему. А я ему говорю что проблема низкоприоритетная и я её сделаю на следующей неделе. Или вообще его игнорирую и делаю свою работу.
Тем, что он уже отвлёк вас от работы, нет? Даже если не получил ответ. И у вас не было выбора, когда им заниматься.
Выслушать нельзя вполуха. Чтобы понять, о срочной проблеме он говорит или нет, надо полностью отвлечься и дослушать, что он говорит. Пробежать глазами по тексту можно моментально (лично меня это даже не «отвлекает от потока»).
Тут ниже писали про «отвлечение от потока» из-за «посмотреть 5-10 секунд на текст». Вы только посылать этого человека, который подошёл к вам ногами, будете минуту. И он потом ещё будет дуться и жаловаться, что его игнорили (и такое бывает).Kanut
27.10.2019 15:14+1Ну начнём с того, что форс-мажор — это 1-2 письма в год.
Но чтобы не пропустить такое вы при этом всё равно должны просматривать абсолютно каждое письмо.
Тем, что он уже отвлёк вас от работы, нет?
Вы когда просматриваете письма точно так же уже отвлекаетесь от работы. И я бы даже предположил что на просматривание писем вы в среднем отвлекаетесь чаще, чем меня от работы отвлекают коллеги.
И кто из нас тогда более "эффективно" работает?
Тут ниже писали про «отвлечение от потока» из-за «посмотреть 5-10 секунд на текст».
Так в том-то и дело что как минимум для меня в обоих случаях идёт это самое "отвлечение от потока". И если я уже отвлёкся, то всё поезд ушёл и мне снова надо время чтобы "войти" обратно в поток.
edwardspec
27.10.2019 15:29Вы когда просматриваете письма точно так же уже отвлекаетесь от работы.
Специфика моей работы — много мелких задач (я не лезу в почту во время реализации фичи, а только между фичами) плюс крупные архитектурные задачи (при обдумывании которых я делаю обязательные паузы специально, т.к. через час-другой может прийти в голову хорошая идея об альтернативной реализации).
Я привык быстро переключаться между задачами и (по ощущениям) не отвлекаюсь от потока, посмотрев на почту.Kanut
27.10.2019 15:39+1Специфика моей работы
То есть получается что конкретно для вас это работает, но совсем не обязательно что это будет работать для всех или хотя бы для большинства.
edwardspec
27.10.2019 15:41не обязательно что это будет работать для всех или хотя бы для большинства.
Этого и я не утверждал. Я рассказал о своём опыте.
Разработчик, который пилит одну алгоритмическую фичу 7 часов подряд, конечно же может быть выбит из потока вопросом.Kanut
27.10.2019 15:43Тогда возможно это уже я что-то неправильно понял. Но всё равно спасибо за дискуссию :)
sumanai
27.10.2019 14:02+2Проблема постоянного отвлечения от потока остаётся. Я вот, когда решаю сложную и интересную задачу, забываю пить и в туалет ходить на 2-3 часа.
Я бы на вашем месте попробовал внедрить другой мессенджер для срочных задач, с уведомлением. Ну или настроить уведомление в почтовом клиенте для важных вещей. Можно было бы реже проверять почту и быстрее реагировать на важные вещи.
ApeCoder
28.10.2019 06:41В почте уже есть обычно способ классификации писем по важности. Может быть, можно настроить почтового клиента, чтобы уведомления показал только на важные письма?
Kanut
28.10.2019 10:09На одной фирме где я работал так пытались сделать. Знаете чем кончилось? Тем что больше половины писем имели категорию "срочно" или даже "очень срочно". :)
Просто если люди сами не понимают когда что-то действительно достаточно важно чтобы отвлекать других людей от работы, а когда нет, то вам никакой тулинг не поможет.
ApeCoder
29.10.2019 23:12+1Так никто не говорит, что это помогает всем и всегда. Это просто один из способов разделения сообщений по срочности, как мессенджер и почта. Кому-то помогает, кому-то нет.
AlexanderBlack
26.10.2019 12:06+6Есть один момент, который обошли стороной в этой статье. Когда несколько человек работают над чем-то одним, ожидание ответа или реакции от коллеги может блокировать твою дальнейшую работу. В синхронной модели такой "блокер" можно снять моментально.
usego
26.10.2019 13:54+14Ага, поставив блокер коллеге и сбив его с контекса и рабочего ритма. Асинхронность заставляет включать голову и планировать наперёд. но да, не всегда оно работает. Имхо истина где-то посередине — синхронные созвонки, но не очень часто, раз в 2-3 дня + асинхронщина.
Kanut
26.10.2019 13:56+1На мой взгляд это ещё зависит от конкретного человека и должности. Кто-то может быть и целиком "асинхронным", а кто-то постоянно должен быть на связи.
leventov
26.10.2019 19:50+2Выход: у этих двух людей один и тот же блокер, т. е. режим работы в промежутке от парного программирования до работы в тесной связке над одной и той же фичей.
trueMoRoZ
27.10.2019 07:30+1для этого они и пишут про экстренный канал связи в виде телеграма и даже про приоритеты каналов связи, в которых можно настроить разные таймауты оповещений.
aamonster
26.10.2019 13:07+5Не понял, как это "До 80% этого времени уходит на общение по электронной почте (в среднем, шесть часов в день)".
Если у сотрудника 7.5 часов (6/0.8) в день уходит на общение, то на собственно выполнение задач остаётся не больше получаса. Он вообще нужен при таком раскладе или вместо 10 таких можно нанять одного, который общается 3 часа в день?
Revertis
26.10.2019 13:20Интересно, а как быть с техподдержкой?
Сейчас происходит так — юзер спрашивает в чате поддержки в Телеграме, как решить проблему. Техпод не совсем в курсе как её решать, он спрашивает в чате разработчиков. Кто-нибудь из разработчиков отвечает.
А если ввести асинхронность? Юзер в Телеге должен ждать 24 часа?
ilammy
26.10.2019 13:41Юзер в телеге, которому надо прям сейчас — это как раз синхронная коммуникация. Асинхронным будет имейл на support@example.com или там вопрос на форуме.
Revertis
26.10.2019 13:45Я это и имел ввиду. Техпод отвечает синхронно, а разработчики, например, асинхронны. Когда юзер получит ответ? :)
usego
26.10.2019 13:59+6А с какого юзер должен получать ответ моментально, блокировав работу весьма недешёвых специалистов? Если юзер — CEO, оно понятно, но вы ведь не этот кейс описываете?
Revertis
26.10.2019 14:04У нас бизнес B2C, и мы стараемся оказывать поддержку всеми возможными способами.
Есть почта, есть открытый issue-трэкер на гитхабе, есть все соцсети, есть свой форум, есть ветки форумов на 4pda и xda-developers, и есть чаты в телеге — русскоязычный и англоязычный.
И вот чаты в телеге, всё-таки, считаются «быстрым способом» спросить о решении какой-нибудь проблемы.
А ведь в наше время всем всё нужно «здесь и сейчас», поэтому вот такие пироги.somurzakov
26.10.2019 17:13+1надо сделать в стиле ITSM: сделать прддержка первой линии, второй линии.
первая линия принимает жалобы от юзеров и отвечает как модет, ечли не модет эскалируетв во вторую линию.
вторая линия не обяз-но должна состоять из прогеров, туда можно ротировать по очереди одного прогера, чтобы читал чат и отвечпл, но лучше кого-то из команды тестирования QA т.к. они знают все граничные случаи
fingolfin
28.10.2019 07:49+2Можно отписаться юзеру подобным образом: «Мы подключили специалистов к решению вашей проблемы. Пожалуйста, ожидайте ответа в течении 24 часов».
Kanut
28.10.2019 10:13Вопрос только в том устроит юзера такой ответ или нет. Представьте вы приходите вечером домой и хотите расслабиться и посмотреть свежую серию крутейщего сериала, которая вышла прямо вот сегодня и которую завтра все на работе будут обсуждать. А у вас скажем вдруг ваш "нетфликс" не работет. Или интернет. Или электричество. Вас устроит в такой ситуации ответ: «Мы подключили специалистов к решению вашей проблемы. Пожалуйста, ожидайте ответа в течении 24 часов»?
Даже если вас устроит, то я могу себе представить что кучу людей не устроит. И не только если речь идёт о "нетфликсе" из моего примера.
fingolfin
28.10.2019 10:39+1Обычно для таких ситуаций существует дежурный инженер и сотрудники ЦП. Я говорил о сложных ситуациях, с которыми они не справятся.
То есть если всё насктолько сложно, что нужно подключать основных разработчиков, то это наверняка несрочная проблема.Kanut
28.10.2019 10:48А вот это уже зависит от размера вашей фирмы, того что у вас за продукты/клиенты и того в чём конкретно заключается проблема.
У нас 24 часа в сутки минимум два разработчика(из них один сениор или выше) сидят "на дежурстве". Хотя бы просто потому что клиенты так хотят. Другое дело что размер фирмы позволяет такие дежурства делать добровольными и достаточно редкими. И контракт с клентами позволяет время на дежурстве на 50% рассматривать как рабочее и при этом ещё и оплачивать по двойной ставке(это если аврала не было, аврал оплачивается отдельно). То есть грубо говоря если сел после работы на дежурство, то следующий день у тебя выходной и оплачивается по двойному тарифу.
Но я знаю кучу фирм, которые себе такого люксуса позволить не могут и там "дежурство" это когда тебе просто могут после работы позвонить и сказать что есть проблема и её надо решать.
fingolfin
28.10.2019 11:52+2Я, честно, не могу понять, что вы хотите узнать. Если компания занимается круглосуточной поддержкой чего-то, то у неё в штате должны быть сотрудники специально для этого. Если это не входит в задачи компании, то такие срочные проблемы называются форс-мажорами и случаются крайне редко. В статье говорится о том, что не нужно дёргать разработчика по любому чиху, а не то, что следует забить на форс-мажоры.
Kanut
28.10.2019 12:02В статье говорится о том, что не нужно дёргать разработчика по любому чиху, а не то, что следует забить на форс-мажоры.
На мой взгляд проблема статьи как раз в том и заключается что в ней нигде не определено что такое "чих" и что такое "не чих". И даже не даётся никаких "инструментов" или "правил" для того чтобы провести границу между этими вещами.
Потому что спросите кого угодно и он с вами согласится что "не нужно дёргать разработчика по любому чиху" даже если никогда про асинхронное общение и не слышал. Но при этом всё равно постоянно дёргают.
fingolfin
28.10.2019 12:15в ней нигде не определено что такое «чих» и что такое «не чих».
Соглашусь, этого не хватает. Но я думаю, целью статьи было только объяснять, что асинхронность — это действительно важно. Потому что… вы уже описали выше :-)
tcapb1
28.10.2019 14:16+1Ну вообще это решаемо.
Например у нас есть синхронная поддержка (и асинхронной её сделать нельзя, клиенты привыкли что им отвечают в течение нескольких минут, да и по конкурентам это стандарт). Есть вопросы, на которые поддержка может ответить сама, есть вопросы по которым надо дёрнуть разработчика (например, баг в системе. Поддержка может его воспроизвести, проверить точно ли это баг на нашей стороне, но не может исправить). Или например запрос на новую фичу, поддержка не может оценить в какие сроки мы можем её сделать.
Однако с ведением базы знаний, таск-менеджера и т.д. можно со временем снизить вовлечённость разработчиков до минимума.
Т.е. сперва идёт фильтрация по базе знаний, может этот вопрос уже всплывал, затем оценивается срочность, если задача не «горит», то просто создаётся тикет в Джире. И только если совсем горит — вынимаем разработчика из потока. По мере обучения сотрудника техподдержки и заполнения базы — дёргать разработчика приходится всё реже.
edwardspec
26.10.2019 15:25+1А если ввести асинхронность? Юзер в Телеге должен ждать 24 часа?
Техподдержку надо разбивать на группы/линии. Асинхронность нужна только разработчикам.
1 линия — работник техподдержки, сидящий в чате (синхронное общение с юзером). Если он знает ответ, то отвечает юзеру немедленно. Если не знает, то дёргает 2 линию.
2 линия — опытный работник техподдержки, который знает ответы на почти всё, но не является разработчиком. Синхронное общение с 1 линией. Если он определяет, что это баг, суперсложный вопрос или для расследования надо рыться в коде и т.п., то сообщает юзеру «передал вопрос разрабочикам» и дёргает 3 линию.
3 линия — разработчик, которого дёргают только при сложнейших тикетах. Он может работать асинхронно.
alekciy
27.10.2019 09:25+1Если это важно для бизнеса (квалифицированный инженер на первой линии), то решается просто выделением человека (даже несколько), спецом в техсаппорт. Т. е. они не занимаются разработкой, а сидят целенаправленно на поддержке. Вариант дорогой, но где это хорошо работает (как правило B2B).
eumorozov
26.10.2019 13:31+16Мне кажется, что синхронное общение непроизводительно тратит время. На моем текущем месте работы постоянно идут какие-то сообщения в Slack. Постоянно горящий огонек новых сообщений уже достал. Большая часть разговоров не относится к тому, что я сейчас делаю/должен сделать — это просто непроизводительное отвлечение.
Еще есть дурацкая привычка у западных менеджеров все решать по телефону (может быть, только у меня так, но слышал, что нет). Появляется задача в таск-трекере, описание — ровно одна строка, типа: «В результатах поиска сортировка должна учитывать признак foo». Пишешь комментарий: «Как именно учитывать, а что делать в такой ситуации, а в этой, а если нет признака foo, то показывать в начале результатов или в конце». Вместо ответа: «Mate, let me call you and explain» (раньше сразу был звонок, хоть приучил сначала спрашивать, можно ли звонить).
И получается напрасное отвлечение и трата времени на 15-30 минут. Потому что:
а) звонок совершенно конкретно выбивает из контекста, потом еще нужно время, чтобы сосредоточиться и вернуться к задаче
б) в звонке они могут не формализовать свои мысли, а вывалить на тебя некое бесформенное видение — и формализуй его сам как хочешь
в) звонок нигде не сохраняется. Если есть необходимость вернуться к этой задаче хотя бы спустя день, то уже не осталось никаких материальных свидетельств разговора, к которым можно обращаться снова, чтобы вспомнить какой-либо упущенный момент
Возможно, это только у меня так, но у друзей спрашивал, говорят, на западе так часто принято. Работа менеджера — разговаривать. Он позвонил, и таким образом «сделал» свою работу. А то, что тебе это никак не помогло — уже не забота менеджера, главное, что он перед своим начальством чист.
Revertis
26.10.2019 13:50+2То есть, менеджер ставит задачу когда зачесалась какая-нибудь пятка.
Вы спрашиваете, что делать с граничными случаями или исключениями.
Менеджер не хочет думать, брать на себя ответственность и отвечать на эти вопросы, поэтому звонит.
А вы не резюмируете его пространные слова из разговора в описании задачи.
Очень эффективная работа :-Deumorozov
26.10.2019 13:57+4Ну, да, я понимаю, что на моем месте работы все организовано чрезвычайно неэффективно. И давно уже понял, что менеджеры не хотят и не могут думать. Поэтому все происходит чрезвычайно неэффективно. Я сам пытаюсь формализовать спецификации, но так как я не являюсь автором/заказчиком решаемых задач, то мне в более, чем половине случаев приходится додумывать исходя из своего понимания. После выкатывания реализации, выясняется, что хотели другое: «Ну ты че, сам не понимаешь что-ли, что если пользователь делает изменение, то оно должно действовать 6 месяцев, а если админ — то бессрочно» (в задаче вообще никакие сроки не указывались ни для пользователя, ни для админа, и вывести это откуда-либо было невозможно).
Потому ищу новое место работы, и немотря на то, что вроде бы спрос превышает предложение, пока никакого предложения не получил (совсем где попало работать тоже не хочется, чтобы не попасть из огня в полымя).
Это, видимо, комментарий о наболевшем. :(
faoriu
27.10.2019 09:18вроде бы спрос превышает предложение
В-основном в рекламах курсов по вхождению в IT, ну и в местах с "грязной" работой, которую делать никому не хочется.
Yngvie
26.10.2019 17:20+2У меня за правило — если обсуждение по таске произошло в чате или звонке, то я оставляю комментарий с кратким содержанием звонка в тикете, и тегаю всех кто был в звонке
muhaa
26.10.2019 18:26-2- Рабочее время менеджера стоит не меньше вашего, а вы хотите чтобы оно было потрачено на составление формального и исчерпывающего описания для вашего удобства.
- Успех работы зависит в очень значительной степени от того, насколько хороши принимаемые менеджером решения. А это означает, что голова менеджера должна быть максимально свободна от задач, которые могу быть решены без него. Вы же пытаетесь заставить мегеджера формализовать то, что можете формализовать и сами. Да еще по удобному вам графику.
rkuvaldin
26.10.2019 18:53+12Рабочее время менеджера стоит не меньше вашего, а вы хотите чтобы оно было потрачено на составление формального и исчерпывающего описания для вашего удобства.
Если менеджер был нанят как раз для того чтобы нарезать задачи программистам — то да, иначе за что ему платят?muhaa
28.10.2019 22:42-1Для меня это выглядит как своего рода программистский снобизм. Менеджер — это не сервис для удобства разработчика, менеджер — это тот кто создает продукт с помощью разработчиков.
Kanut
28.10.2019 22:44+2Это от ситуации зависит. Встречал в своей жизни оба варианта. И даже вариант когда разработчик это сервис для удобства менеджера :)
rkuvaldin
29.10.2019 01:01С одной стороны у нас есть задачи от бизнеса типа «сформировать годовой отчет на базе...», с другой — ряд высокочастотных сигналов на микросхемах. По пути от первого ко второму есть несколько ступеней.
Начнем с конца.
Первая ступень — получение низкоуровневых инструкций для процессора на основе исходного кода программного обеспечения для решения соответствующих задач. Этим занимаются интерпретаторы и компиляторы.
Вторая ступень — написание этого самого ПО для решения поставленных задач. Этим занимаются программисты.
Третья ступень — составление списка функций и подсистем для реализации программистами. Как правило это задача архитектора.
Выше — уже вроде бы бизнес-требования.
Ваш «менеджер» в этой цепочке где находится?muhaa
29.10.2019 13:43Ваш «менеджер» в этой цепочке где находится?
Мне интересен этот вопрос. Поэтому опишу свое представление подробно.
Из того, что я видел это работает примерно так. Менеджер соберет информацию об этой задаче с отчетом, посидит поразмышляет как это будет выглядеть, что стоит реализовывать, а что слишком накладно, справится ли с этим текущий коллектив, или нужны еще люди, кто примерно в команде какую часть может делать. Очень сильно в детали возможно влезть не сможет, все зависит от его компетенции.
Потом (если менеджер не выполняет функций тимлида и аналитика) он будет детально обсуждать все с тимлидом и аналитиком. Когда они вместе поймут как это все будет работать, тимлид начнет «нарезать» задачи для программистов, описывая детальные требования. Менеджер по ходу работ будет смотреть что получается, укладываемся ли в сроки, согласовывать задачи программистам, помогать выбрать решение, когда это решение требует общего видения задачи и бизнеса, которого недостает тимлиду.
Наверно есть много других вариантов, с которыми я знаком похуже. Например, менеджер может быть чистым управленцем и не разбираться больше не в чем. Тогда чем меньше он будет вмешиваться, тем лучше. Его задача — только ресурсы и быть прокладкой между руководством компании и программистами.
Менеджер может быть управленцем и аналитиком бизнес-требований одновременно. Тогда он объясняет эти требования тимлиду, который уже подробно формулирует их программистам.
Если в команде нет тимлида, тогда либо каждый программист должен выполнять функции тимлида по своему направлению (т.е. понимать и интерпретировать бизнес-требования к своим модулям), либо менеджер должен взять на себя функции тимлида. Второй вариант подразумевает, что менеджер — хороший программист или был хорошим программистом.
ИМХО, в исходном сообщении eumorozov проблема в том, что в его компании менеджеры и программисты спихивают с себя функции, которые как правило берет на себя тимлид, не желая ими заниматься.
Менеджер хочет позвонить и объяснить свои туманные мысли программисту, потому что именно так он бы работал с тимлидом, который «в теме». Сформулировать требования детально менеджер не может, потому что считает, что ему платят за менеджмент а не за функции лидера команды разработчиков.
Программист не желает преобразовывать туманные объяснения менеджера, потому что считает, что ему платят только за программирование и знание фреймворков, а разжевывать бизнес-требования не его задача.
Как обычно, лучшее оружие в таких битвах со стороны программиста — ограничение неформальных контактов. Типа, напишите мне все это формально, в письме, чтобы я четко понял что мне делать (и чтобы ваша некомпетентность и вина в глупостях которые мы натворим была задокументирована).
Такая борьба делает работу неэффективной.
Обычное решение — добавить тимлида, который разжует и нарежет все для программистов.
Другое решение — программист может взять на себя обязанности тимлида-самому-себе. В некоторых случаях это может не совпадать с текущими карьерными планами программиста. Например, зачем ему изучать область бизнес-требований, если возможно завтра он будет работать уже в другой области?
Худший вариант — если чистый менеджер (не тимлид по совместительству) возьмет на себя эти обязанности. Потому что если он недостаточно компетентен как разработчик для функций тим-лидерства, то от его детальной формулировки все равно не будет пользы, а время он потратит. Если он достаточно компетентен для этого, то возможно у него нет на это времени. Если у него есть на это время, тогда возможно пора навалить на него больше проектов, чтобы у него не было времени заниматься функциями тим-лидера по каждому. Потому, что специалиста, который достаточно хорош, чтобы быть и менеджером и тимлидом одновременно выгоднее привлечь в большее число проектов, чем позволить ему утонуть в тимлидской работе на одном проекте.
eumorozov
26.10.2019 19:49+2А это означает, что голова менеджера должна быть максимально свободна от задач, которые могу быть решены без него. Вы же пытаетесь заставить мегеджера формализовать то, что можете формализовать и сами. Да еще по удобному вам графику.
Помилуйте, как же я могу без него решить, если он дает 20% информации, необходимой для реализации задачи, а остальные 80% приходится либо додумывать, либо вытаскивать клещами во время итераций.
Например, у нас есть поиск по некоторым объектам. У объектов есть куча свойств, и поиск использует массу параметров для фильтрации и сортировки результатов. Как происходил процесс раньше:
Менеджер: «Надо, чтобы при сортировке по дате добавления первыми отображались объекты, добавленные пользователями с признаком Y».
Я, спустя время: «Сделано, проверяйте».
Менеджер: «А почему объекты с вложенными подъобъектами появляются первыми?! Так не должно быть»
Я: «Но ведь в задаче не говорилось, что они должны обрабатываться отдельно, а так как всем признакам в задаче соответствуют, то и появляются первыми»
Менеджер: «Переделать»
И таких итераций десятки. Невозможно ведь прочитать мысли в голове менеджера/владельца бизнеса, и если все условия не даны, то либо вообще не знаю, как реализовать задачу, либо реализую в меру своего понимания.
Конкретно с поиском история повторялась так часто, что всем набила оскомину. Потому что помимо всего прочего они даже не пытаясь формализовать задачу, не понимали, что, например, A и B — связанные признаки, и нельзя поменять A не влияя на B и наоборот. Потом сильно удивлялись результату. Я же при всем желании понять и формализовать не мог, так как для меня любой вариант сортировки кажется удовлетворительным.
Говорю же, что все запущено. Очень много задач, которые вообще стостоят из одного предложения. Ровно одного предложения, типа: «Форма добавления Y работает неправильно». Но у нас, например, 6 различных продуктов, в которых есть формы Y, для каждого есть по несколько серверов (например, продакшн, тестирование, и т.д.). Более того, в каждом продукте существуют несколько различных форм добавления Y. То есть, неясно, что работает не так и где работает не так. Можно потратить время и проверить все
6*2*4комбинаций (каждый продукт на каждом сервере во всех вариациях формы), обнаружить, что все они работают, и тогда выяснится, что, имелось в виду, что в конкретной форме в конкретном поле надо было запретить возможность вводить нулевое значение. Потерянное время исчисляется часами, а ведь можно было сразу указать. А когда таких однострочных тасков накидывается два десятка в день? Если на каждую такую задачу созваниваться, то весь день пройдет в телефонных разговорах. Иногда так и происходило, кстати. Вроде все при деле, только работа не двигается.
Стресс невероятный. Я понимаю, что это конкретно мой случай, и, видимо, патологический.
muhaa
27.10.2019 01:24+1Возможны варианты.
- Допустим, ваш менеджер — уважаемый всеми специалист с большой буквы, на голову выше любого разработчика. Тогда такого человека нужно предельно экономить. Оптимально, чтобы этот человек не вырабатывал решения а только выбирал наиболее приемлемое из предлагаемых разработчиками. Т.е. разработчик из своего опыта прикидывает несколько работоспосоьных вариантов, описывает их менеджеру и тот быстро выбирает приемлемое для пользователей или других целей.
- Допустим, ваш менеджер просто довольно посредственная прокладка между пользователями и программистами. Тогда бесполезно требовать от него детально сформулированных требований. Эта задача ему просто не по зубам. Он потратит кучу времени и все равно что-то не учтет. Не так легко детально продумать задачу, которую не собираешься сам реализовывать. Сколько раз сложности становились для вас очевидными только в середине разработки? У менеджера ведь нет таких возможностей. Поэтому самый эффективный вариант опять тот же что в предыдущем пункте — менеджер только выбирает. Или
- Допустим, менеджер ставит задачи детально, описывает все подробно и почти все предусматривает. Возможно это означает, что компания все время решает однотипные задачи и благодаря этому работу удается эффективно распределять. В такой компании наверно работать легко, но скучно. Возможно это означает, что менеджер слишком хорош и скоро его повысят. Еще вариант — этот менеджер не умеет распределять работу и слишком много работы берет на себя. Тогда он работает неэффективно.
- Задачи однотипные, задача менеджера тривиальна и все равно от него сплошной вред. Это просто плохой менеджер, которого нужно заменить.
Gradiens
28.10.2019 15:53Я: «Но ведь в задаче не говорилось, что они должны обрабатываться отдельно, а так как всем признакам в задаче соответствуют, то и появляются первыми»
Менеджер: «Переделать»Вам нужен бизнес-аналитик. Хороший.
Тогда он будет пинать плохих менеджеров, заказчиков и прочих людей, не имеющих системного мышления. Он обеспечит полноту и непротиворечивость требований.
Беда в том, что хорошие аналитики встречаются пожалуй даже реже хороших разрабов. А кроме того, пока роль аналитика равномерно размазана по вам и вашим коллегам, руководство не захочет нанимать нового спеца.
faoriu
27.10.2019 09:27+2В серьёзных проектах вроде авионики используется V-model, в которой работа программиста (Implementation) — это лишь 1/4 часть от процесса разработки проекта, всё остальное — формирование концепции, требований и проектирование. Оно и понятно, ведь средний программист не может одновременно быть экспертом в C++ и аэронавигации или двигателестроении. А у вас получается какой-то колхоз, когда за всё отдувается тот, кто непосредственно написал код, ведь "он же мог понять, что от него другого хотят", а менеджер — слишком важная птица, чтобы себе голову продуктом забивать.
arTk_ev
26.10.2019 23:35+2Переводят на звонки, устные объяснения и всякие митинги — это у всех западных менедежеров. Делают они это только ради того чтобы снять с себя всю отвественность, и у них такая культура, собираться в кружок и болтать о своих проблемах друга и друг дружку хвалить.
Именно поэтому у них такая чудовищная бюрократия. Советую копировать из чата цитаты прямо в таски и записи конференций, и решать только письменно и желательно по почте. Уже ни раз это выручало.
iroln
27.10.2019 19:15Еще есть дурацкая привычка у западных менеджеров все решать по телефону (может быть, только у меня так, но слышал, что нет).
Подтверждаю. Работаем с американской компанией. Когда можно более эффективно всё решить в несколько предложений текста, они зачем-то хотят всё обсудить голосом. При этом каждый раз остаётся что-то, о чём не успели или забыли поговорить. При этом с их стороны никто не делает план совещания и я ещё не видел, чтобы после совещания кто-то написал какой-то протокол: что обсуждали, что решили, что делать, что не делать и т. п.
Поэтому я просто не хожу на большинство совещаний, потому что они лично для меня бессмысленны и только отнимают время, более того в вечерние часы.
ApeCoder
28.10.2019 06:48Я обычно в таком случае открываю тикет скриншарю его и дописываю туда то, что говорят потом спрашиваю правильно ли я написал. Таким образом остаётся согласованная запись принятых решений
Daddy_Cool
26.10.2019 15:01Статья хорошая — как реклама асинхронности. Ну вообще вроде так и происходит в нормальных местах. У нас область научная — такое тоже есть.
Примеры:
Наш механик приходит на работу к 8 утра, что для меня unreal. С вечера я ему оставляю чертеж с запиской, на следующий день я могу получить готовую деталь или уточняющие вопросы — если я что-то не так нарисовал.
Вчетвером (географически из разных мест Москвы) писали некую программу, встречались раз в месяц для пития чая и обсуждения оргвопросов, а не технических. Всё техническое вполне решалось по почте.
А вот контрпример — есть коллега из другой страны — он переписываться не любит, ему нужен эмоциональный контакт и хочется по размахивать руками по скайпу.
justhabrauser
26.10.2019 15:58+4Много текста можно свернуть в варианты коммуникаций:
* Лично — наиболее «агрессивный» вид коммуникаций; канал не только (и не столько) звуковой, но еще и зрительный (80%-90% информации, ага). Совершенно нет времени подумать и палишься по полной (мимика, жесты, невербальные реакции). Зато результат — здесь и сейчас. Синхронный, да.
* Телефон — тоже синхронный, чуть менее «агрессивный» вариант (меньше каналов передачи информации), но тоже нет времени.
* IM (instant messages — SMS, асечьки, всё это) — кагбэ асинхронный, но предполагает достаточно быстрое время реакции. Не секунды, но желательно реагировать побыстрее. Немного времени уже появляется, но не очень. Зато ожидаемое время реакции достаточно короткое.
* Email — наиболее «мягкий» вариант — не предполагает мгновенной реакции, есть время подумать и реагировать правильно. НО — от респондента не стоит ожидать не то что быстрой реакции, но и реакции вообще.
Это всё разные инструменты и применяются в разных случаях.
Поэтому начальство любит совещания — у начальника вся информация, он подготовился, он быстро реагирует. А совещаемые имеют бледный вид — информации мало, а времени на соображение нет совсем. Еще и палятся мимикой.
Поэтому клиенты любят личные встречи с «компьютерщиками». Им так удобнее, клиент любит ушами. А компьютерщику-интроверту при синхронном общении ппц.
Поэтому «компьютерщики» любят асинхронное общение — IM вместо личных встреч (достаточно «быстрое» общение, хотя начальство/клиент не сильно любит тыкать пальчиком в буковки) и электропочта для всего остального. Когда есть время подумать и правильно сформулировать.
«Серебрянкой пули» нет — для каждой задачи и каждого человека свой комфортный инструмент общения.
mapron
26.10.2019 18:30Поэтому «компьютерщики» любят асинхронное общение — IM вместо личных встреч
Зависит от компании. Я работаю в IT компании, тут IM мало кто любит, почти все предпочитают лично подойти и поговорить по любому поводу. Ну либо email. Так сложилось. сперва подгорало знатно)justhabrauser
26.10.2019 19:14Зависит.
Все мои выводы сделаны по опыту работы «приходящим компьютерщиком» (мнэ… «ИТ-специалистом широкого профиля на аутсорсе», так будет моднявее) с компаниями неИТшного профиля.
С обычными людьми, короче.
А там своя специфика, мы с ними не одной крови.
Areso
26.10.2019 22:55Когда есть время подумать и правильно сформулировать.
Поэтому я узнаю тему будущей встречи, тезисы и делаю себе план. Подглядывать туда выглядит так себе, особенно когда встреча разноуровневая (начальник-подчиненный), но работает. Альтернатива — учить план, но это на любителя. Хотя перед особо важными переговорами я планы именно учу.
Если встреча проходит по телефону, то у меня бывает целый скрипт, чтобы ничего не забыть и все сделать правильно. Как минимум — чеклист. Результат, обычно, превосходит ожидания.
Требует времени, но оно того стоит — если от таких встреч зависит что-то лично мне важное.
muhaa
26.10.2019 17:38+2Очень многие письма между коллегами пишутся потому, что автор письма что-то не понимает (иногда не осознавая этого). Решение таких проблем асинхронно это ооочень долгий с сложный процесс.
Формальное общение тимлида с программистами по почте по моему опыту приводит к ситуации, когда тимлиду быстрее и проще написать весь код самому, чем бороться с этими роботами, которым нужно все разжевать и все равно они что-то сделают не так.DistortNeo
26.10.2019 18:34+1В этом случае нужно разграничить должностные обязанности тимлида. Либо он тоже пишет код, не отвлекаясь на обезьянок и общаясь с ними асинхронно, либо синхронно нянчится с обезьянками.
Проблема в том, что программирование и наставничество — две разные задачи, которые не могут решаться одновременно одним человеком. Довольно часто в маленьких командах лиду приходится совмещать эти две функции, что приводит к перегрузкам и снижению работоспособности.
Вот ещё чтиво на эту тему:
https://habr.com/ru/company/touchinstinct/blog/332056/leventov
26.10.2019 19:58И какой выход?
DistortNeo
26.10.2019 22:33Разграничение должностных обязанностей тимлида, логично же.
Если тимлид оказывается недозагружен, тогда увеличивается размер команды.
muhaa
27.10.2019 01:41+1Во всех своих проектах я кодил всю предметную логику бекенда как минимум, писал грубый прототип UI, детальные требования, потом все пояснял разработчикам, потом проверял до тестировщиков, отвечал на вопросы тестировщиков и проверял после тестировщиков. Это ужасно утомительно, но я не нашел других способов создать нечто достаточно сложное и не заставить каждого разработчика по уши утонуть в предметной области.
Areso
26.10.2019 22:58Меня в письмах больше всего напрягает вариант «не знаю кому написать, напишу всему отделу/подразделению/департаменту/функции и поставлю в копию еще один-два отдела/подразделения/департамента/функции.
Сортировка писем помогает, но так себе.
В результате у меня в почте общаются юниксоиды, ораклисты, ноsqlщики, постряшники, заказчики всех мастей… и из всего этого приходится находить крупицы полезной информации.
torbasow
26.10.2019 18:17-3Устами бы автора да мёд пить. А что если работа выстраивается под внезапное «через десять минут начальник будет смотреть»?..
Areso
26.10.2019 23:00+6Когда я был молодым, я на это вёлся.
Когда я перестал быть молодым, я понял — если это нужно было вчера, вы должны были прийти ко мне позавчера. Ну или хотя бы вчера.
Задача, поставленная после обеда, к окончанию рабочего дня выполнена не будет с шансом в 99% и я об этом сразу и спокойно говорю.torbasow
27.10.2019 09:45Я тоже говорю. А потом делаю.
Whuthering
28.10.2019 20:44+1И зачем? Вам эти авральные работы оплачивают в троекратном размере, а потом дают дополнительный отпуск? Или, может быть, у вас есть опционы/акции, и от релиза фичи в сжатые сроки зависит финансовый успех компании и ценность ваших бумаг? Нет? Тогда не понимаю смысла рвать себе нервы ради прихоти самодуров из руководства. Есть достаточно мест с хорошими условиями и деньгами, где менеджмент подобными загонами не страдает.
torbasow
27.10.2019 09:44-5Кто не хочет надрываться за большие деньги, может надрываться за маленькие, так-то да. А ещё можно переехать в другой город/страну, переквалифицироваться в биржевые спекулянты или поймать золотую рыбку.
faoriu
27.10.2019 09:52+3Нет, лучше быть терпилой: делать то, что скажут и голосовать за того, кого надо, а то как-бы чего не вышло.
sumanai
27.10.2019 12:54+4Кто не хочет надрываться за большие деньги, может надрываться за маленькие, так-то да.
Обычно в компаниях с хорошо организованным рабочим процессом и платят больше, так как они более продуктивны.
Whuthering
28.10.2019 20:41Вы так говорите, как будто подобный маразм творится везде, где платят большие деньги.
Griboks
26.10.2019 23:40Вы путаете взаимодействие внутри/между бизнес-процессами и повседневное общение людей. Вот как можно пропустить что-то важное, если ты не в сети пару часов? Это насколько должна быть неорганизованная компания…
ncix
27.10.2019 00:22+1Да легко. Упал ПРОД в ключевом проекте. Это же подчас происходит неожиданно и мгновенно.
pyrk2142
27.10.2019 03:46+4Имхо, это как раз неорганизованность. Если упавшую систему не может поднять дежурная смена/специалист/оператор (а тут уже есть почти гарантированная синхронная связь), то она обязательно упадёт в тот момент, когда ключевой специалист летит из Москвы в Таиланд или лежит в операционной в больнице (реальный случай, однако).
ncix
27.10.2019 12:29А "дежурная смена" разве не на синхронной связи должна находиться?
Griboks
27.10.2019 14:26Вы правы, дежурная служба на то и дежурная, чтобы оперативно реагировать на такие проблемы.
Но, мы ведь говорим не о тех ребятах, которым платят за дежурства, а о тех, которые постоянно тратят время на лишнее общение из-за каких-то негласных (не имеющих юр. силу) правил внутри компании.ncix
27.10.2019 14:41Статья описывает коммуникации всех сотрудников компании, насколько я ее понял. Я в своей ветке имел в виду также всех. Да и строгое разделение на поддержку и разработку есть только в крупных компаниях, да и то не во всех.
tcapb1
28.10.2019 15:00Здесь очень зависит от ресурсов компании. Если можно выделить на быстрое реагирование на падение прода толкового специалиста — это хорошо. Но я далеко не всем сотрудникам доверю доступ к проду, так как риск что они там чего-то не того наворотят больше, чем вероятность что они оперативно и успешно поднимут сервер в случае ЧП при недоступности других сотрудников. Поэтому приходится принимать риск «прод упал + ключевой сотрудник в больнице». К счастью и первое и второе довольно маловероятные события.
Griboks
27.10.2019 10:03-1Согласен с pyrk2142. Тем более, если упал, то его надо поднять. И мне, например, как разработчику должно быть всё-равно, что там происходит с этим сервером, т.к. это не моя сфера интересов (мне платят за разработку, а не обслуживание серверов). Опять же, почему они вообще должны писать мне, и ждать принятия именно моего решения?
Kanut
27.10.2019 12:04Как быть если прод "падает" из-за багов в коде? Если эти баги появились после релиза в котором ваши коммиты и возможно проблема именно в них? Если откат к предыдущей версии возможен, но пока баг не исправлен и новая версия опять не вернулась на прод, то фирма теряет деньги?
Как быть если даже не прод упал, а скажем из-за каких-то предположительно ваших действий появились какие-то проблемы, которые блокируют работу нескольких человек? Всего отдела? Всей фирмы?
Это в принципе невозможно? Тогда вам повезло и вас можно перевести на асинхронную коммуникацию. Но для кучи людей такой сценарий полностью исключить нельзя.
Griboks
27.10.2019 14:14+2Как быть если прод «падает» из-за багов в коде?
Откатить его. Кстати, а как он может упасть? Его ведь должны предварительно протестировать, перед выпуском в релиз. Значит, ответственность несёт не разработчик, а тестировщик.
ваши коммиты и возможно проблема именно в них?
Очевидно, исправить и закоммитить.
то фирма теряет деньги?
Нет, в 99% случаев фирма не теряет деньги.
из-за каких-то предположительно ваших действий… блокируют работу нескольких человек? Всего отдела? Всей фирмы?
Отправить разработчику письмо, чтобы он всё исправил. Более того, таких ситуаций не может возникнуть при грамотной организации рабочих процессов.
Это в принципе невозможно?
Это возможно, но 1) для очень малой доли компаний
2) это ожидаемые риски инвестиций, и, соответственно, их можно предотвратить или скомпенсировать
3) обычно по вине самой компании, а не разработчика.ncix
27.10.2019 14:44Вас почитать, так разработчик вообще никакой ответственности за свою работу не несет. Плохие процессы, тестировщики, руководство, какая-то мистическая "сама компания".
Griboks
27.10.2019 17:22+1Его ответственность записана в его договоре и должностной инструкции. Ну а если будущее проекта решается через вк/твиттер/стим/дискорд, то о какой ответственности может идти речь? Во всяком случае, явно не юридической.
tcapb1
28.10.2019 15:03Даже если ответственность не на разработчике — всё равно придётся дёрнуть разработчика чтобы он оперативно пофиксил баг, блокирующий нормальную работу. Ждать пока он асинхронно дойдёт до вашей задачи в данном случае неприемлемо.
Griboks
28.10.2019 17:48+3Вы не поняли суть. Проведём аналогию с самолётом.
Допустим, что самолёт упал на город. Естественно, ждать, пока службы разберут завалы и восстановят жилищные условия, неприемлемо. Однако, сама возможность падения самолёта недопустима и многократно важнее.
Аналогично, как часто и как долго у вас дома нет света? Или может воды? Трубы, знаете ли, старые везде, ненадёжные, но вода у вас почему-то есть почти всегда.
Почему вы думаете, что «ронять» сервера — это нормально, а вот именно никак не связанный с этим разработчик обязательно должен всё починить как можно быстрее? Надо бороться с причинами, а не последствиями.tcapb1
28.10.2019 19:21Ну вы передёрнули. Я же не предлагаю регулярно ронять сервера или вводить практику Bug Driven Development. Я к тому, что если вдруг прод упал — это достаточная причина выдернуть разработчика из потока вне зависимости от того, по чьей вине этот прод упал. Но разумеется надо прилагать все усилия к тому, чтобы прод не падал. При нормально поставленных процессах это должно быть экстраординарное событие, случающееся очень редко.
Griboks
28.10.2019 20:08Я согласен с вами. Но я говорю о том, что и моментальный отклик разработчика тоже должен быть экстраординарным событием, а не 24/7 он обязан сидеть в конфе тех. обслуживания.
Kanut
27.10.2019 14:55Кстати, а как он может упасть? Его ведь должны предварительно протестировать, перед выпуском в релиз. Значит, ответственность несёт не разработчик, а тестировщик.
Решить кто несёт ответственность можно и потом в асинхронном режиме. Ответственность в этот момент мало кого интересует. Большинство людей в такой момент интересует как максимально быстро и эффективно решить проблему.
Очевидно, исправить и закоммитить.
Если это должны делать вы, а вы в "асинхронном режиме" и смотрите почту пару раз в день?
Нет, в 99% случаев фирма не теряет деньги.
Откуда статистика? И даже если, то что делать в 1% случаев?
Отправить разработчику письмо, чтобы он всё исправил.
И ждать полдня-день пока он это письмо прочитает? А все остальные всё это время просто ждут? Офигенная эффективность работы получается.
Это возможно, но
И ещё раз: откуда такая статистика?
Griboks
27.10.2019 17:36+1как максимально быстро и эффективно решить проблему
Ну… ответ мы уже выяснили. А вот когда проблема решается, наступает фаза анализа и наказания. И тогда оказывается, что сообщение Коляна из вк не оправдывает тебя за отключение питания в серверной.
Если это должны делать вы, а вы в «асинхронном режиме» и смотрите почту пару раз в день?
Получается, что придётся подождать новый супер-крутой функции для релиза ещё один день. Если вы не выпускаете релизы каждый день, то это не проблема. Проблема в том, что текущие сервера упали.
Откуда статистика? И даже если, то что делать в 1% случаев?
Из моего личного опыта. Конечно, можете не верить. Тем более, как можно терять то, чего ещё не существует? Упущенную выгоду? Да, это и есть тот самый 1%, когда надо применять «особую» стратегию. Какую? Я не помню.
И ждать полдня-день пока он это письмо прочитает?
Да. Только где-то это письмо называется приказом и его доставляют лично в руки.
А все остальные всё это время просто ждут?
Не бывает компаний, где всего 1 разработчик и множество пост-продакшен + административного персонала.
Офигенная эффективность работы получается.
эффективность = Деньги/время = зарплата/30 дней = константа. Не зависит от подобных ситуаций.
И ещё раз: откуда такая статистика?
Это не статистика, а анализ рисков бизнес-плана и выработка соответствующих стратегий/сценариев.Kanut
27.10.2019 18:28Ну… ответ мы уже выяснили
Где?
Получается, что придётся подождать новый супер-крутой функции для релиза ещё один день
Если подождать придётся исключительно из-за того что вы любитель асинхронной коммуникации и из-за этого фирма потерет приличную сумму денег, то скорее всего вы либо измените свои приоритеты в плане коммуникации, либо не очень долго проработаете на этой фирме.
Из моего личного опыта.
Так себе источник честно говоря.
Да. Только где-то это письмо называется приказом и его доставляют лично в руки.
В какие руки, вы о чём сейчас вообще? Как вы это будете кому-то в руки доставлять если у вас человек сидит на удалёнке на другом конце земного шара и в этот день решил поработать не из дома?
Не бывает компаний, где всего 1 разработчик и множество пост-продакшен + административного персонала.
Так если у вас все разработчики такие умные и все "асинхронно коммуницируют", то кто тогда должен проблему решать?
эффективность = Деньги/время = зарплата/30 дней = константа. Не зависит от подобных ситуаций.
Извините, но это вы вообще о чём сейчас? То есть если я работаю весь месяц или если я весь месяц мух на потолке считаю, то у меня эффективность одинаковая и зависит исключительно от моей зарплаты?
Это не статистика, а анализ рисков бизнес-плана и выработка соответствующих стратегий/сценариев.
От того что вы это назвали по другому, вы на мой вопрос не ответили. Но если вам так проще будет, то откуда такие "анализы рисков бизнес-плана и выработки соответствующих стратегий/сценариев"?
Griboks
27.10.2019 18:44+1Где?
Откатить сервер на предыдущую рабочую версию.
либо не очень долго проработаете на этой фирме.
Вас не могут уволить по причине медленного ответа на сообщения в телеге. Либо это должно быть записано в вашем договоре/должностной инструкции.
Если подождать придётся исключительно из-за того что вы любитель асинхронной коммуникации
Подождать придётся из-за плохой работы пост-продакшена, которая выпустила в релиз нерабочий продукт. В первую очередь, в этом виноват контроль качества. А асинхронность всего лишь усугубляет последствия.
эффективность одинаковая и зависит исключительно от моей зарплаты?
К несчастью, именно так и есть. Чтобы повысить свою эффективность, вам надо меньше работать. Такой вот парадокс ежемесячной оплаты труда.
Причём, давно уже известно, как избавиться от этого парадокса — платить за результат, а не за время.
все «асинхронно коммуницируют», то кто тогда должен проблему решать?
Будут решать проблему асинхронно.
От того что вы это назвали по другому, вы на мой вопрос не ответили.
Давайте рассуждать логически. Вы бы завязали свой бизнес и «приличную сумму денег» на том, что все ваши работники мгновенно отвечают на сообщения и никогда не болеют, не опаздывают, не уезжают в отпуск, не отключаются от света или интернета? В таком случае в вас бы никто не инвестировал. Это же бред, тратить деньги на рандомные случайности, от которых вы никак не застрахованы.Kanut
27.10.2019 19:03Откатить сервер на предыдущую рабочую версию.
Это не решает проблему в абсолютно всех ситуациях.
Вас не могут уволить по причине медленного ответа на сообщения в телеге. Либо это должно быть записано в вашем договоре/должностной инструкции.
Ну так это часто и прописано если вы удалёнщик или на аутсорсе. И как раз об этом же речь и идёт: как устроить рабочие процессы чтобы такого прописывать никому не пришлось. И пока я ответа не увидел.
Подождать придётся из-за плохой работы пост-продакшена, которая выпустила в релиз нерабочий продукт. В первую очередь, в этом виноват контроль качества. А асинхронность всего лишь усугубляет последствия.
Ещё раз: кто там виноват это вопрос отдельный. Вопрос в том как решать возникшую проблему. И если асинхронность мешает или даже не даёт это сделать вовремя, то для многих фирм она просто не вариант и всё.
К несчастью, именно так и есть. Чтобы повысить свою эффективность, вам надо меньше работать. Такой вот парадокс ежемесячной оплаты труда.
Извините, но эффективность в моём понимании это количество работы сделанное за единицу времени. Или сделанное за единицу оплаты. И поэтому чтобы повысить свою эффективность надо успевать сделать больше работы при равных времени и/или оплате. А вы на мой взгляд какую-то чушь пишите.
Будут решать проблему асинхронно.
То есть велика вероятность что проблема не будет решена за приемлемое для фирмы время. И поэтому получается что асинхронность опять таки вариант далеко не для всех фирм и ситуаций.
Вы бы завязали свой бизнес и «приличную сумму денег» на том, что все ваши работники мгновенно отвечают на сообщения и никогда не болеют, не опаздывают, не уезжают в отпуск, не отключаются от света или интернета?
Я бы завязал свой бизнес на то, что в любой момент времени есть необходимое количество работников, которые будут мгновенно доступны для решения проблемы. И что ещё какое-то количество работников можно будет привлечь к решению проблемы относительно быстро.
Более того я бы планировал свои релизы так чтобы какой-то срок сразу после релиза, наиболее большое количество сотрудников что-то делавших для этого релиза, были максимально быстро доступны для устранения возможных проблем.
Такое вполне себе реально и реализовано в куче фирм. И я не знаю как это должно работать если все ваши сотрудники сидят в "асинхронном режиме".
Griboks
27.10.2019 19:39И я не знаю как это должно работать
Я пытался вам объяснить, но вы упорно не хотите понять меня.
эффективность это количество работы сделанное за единицу оплаты
Я очень рад за вас, что вы готовы работать даже не за еду, а просто за бесплатно. Но я предпочитаю, что бы, когда я делаю в 2 раза больше, мне платили в 2 раза больше. А в вашем случае, эффективность будет снижаться в 2 раза…Kanut
27.10.2019 19:46Я пытался вам объяснить, но вы упорно не хотите понять меня
Потому что так, как вы это объясняете оно работает в каких-то отдельных случаях, а не так что это будет работать всегда и везде.
Я очень рад за вас, что вы готовы работать даже не за еду, а просто за бесплатно.
Хм. На основании чего вы сделали такой вывод?
Но я предпочитаю, что бы, когда я делаю в 2 раза больше, мне платили в 2 раза больше.
Поэтому в большинстве случаев эффективность работы высчитывают на единицу времени. И тогда если кто-то работает эффективнее, то ему повышают зарплату.
Иногда(правда гораздо реже) эффективность высчитывают на единицу оплаты. Но тогда если кто-то работает эффективнее, то ему сокращают рабочее время.
ncix
27.10.2019 00:21+1Спасибо, автор, полняли очень важную тему. Действительно, есть производственная деятельность требующая синхронного общения, но ещё больше той, которая не требует постоянной синхронизации. По хорошему все виды деятельности должны быть перечислены с указанием способов коммуникаций.
У руководителей больше синхронной, пожалуй. Но тоже не вся. У топ-менеджера почти вся деятельность синхронная.
pyrk2142
27.10.2019 03:40+2Отдельный интересный момент — асинхронное взаимодействие часто не даёт возможность изображать бурную деятельность так просто: нельзя просто так ссылаться на постоянную занятость, совещания, митинги и подобное, надо что-то делать. Конечно, работает не везде и не со всеми, но все равно бывает довольно полезным.
Thebear
27.10.2019 05:49Ситуации бывают разные. Иногда асинтрон помогает подумать, переварить и выдать достойный вариант. А иногда он означает потерянный день для нескольких человек, там где все можно было выяснить и решить за 15 немедленно.
Я вот в компании, очень любящей зум и слак стал людей вытаскивать на личные встречи, особенно когда надо что-нибудь кроссфункциональное обсудить с QA, аналитиками и архитекторами какими-нибудь разом. И знаете что? Работает, время тратим меньше, проблемы решаются.
nikolainefedov
27.10.2019 09:31+1Работаю удаленно, дома. В рабочем процессе полный порядок, с начальством контакт хороший, никто ни к кому претензий не имеет. Думаю, в этом вопросе все зависит от самих работников, их дисциплинированности и желании нормально работать
411
27.10.2019 10:19Практикуем это у себя, но пропорции скорее 50 на 50. Когда пришёл в компанию, это было отчасти непривычно, так как воспринимал только почту как способ асинхронной коммуникации.
Хотел бы выделить некоторые моменты:
Мы так же используем голосовые сообщения, к примеру, если необходимо описать что-то большое, при этом отправляем его с кратким резюме, чтобы легче было искать. Чаще это делают менеджеры, разработчики слегка меньше, но тоже. Плюсом возможность слушать их на 1.5/2x.
Очень важно, чтобы асинхронная коммуникация не затягивалась. Особенно важно с голосовыми сообщениями. Пришли к этому не сразу, но возникали ситуации, в которых эффективность общения понижалась. Главная проблема неэффективности длинных ассинхронных коммуникаций — необходимость восстанавливать контекст каждый раз. Это очень затратно для больших обсуждений. Собственно теперь, если видим с самого начала(первые 2-4 сообщения), что нужно много обсуждать, планируем созвон.
Отдельно отмечу, что если начинается общение в реальном времени в моменте, где собирались общаться асинхронно, рекомендуется созваниваться, ибо это будет эффективнее.
Планирование тикетов. Мы делаем комбинированный вариант. Сначала в асинхронном режиме каждый пишет вопросы, комментарии, часть из них решается сразу, потом непосредственно на созвоне решаются остальные утверждаются окончательно требования и делается оценка.
Foxcool
27.10.2019 11:56+3Согласен с автором. Вообще, с того момента, когда только начинаешь работать в командах на джуновских ролях, идея того, что командное взаимодействие должно быть по-умолчанию асинхронным — очевидна. Когда моявилась возможность собирать свою команду и устанавливать правила игры, то стал сразу избегать синхронности, сместив акцент в ведение дел в тикетах и мердж реквестах. Даже чаты — это то место, где информация быстро улетает в историю. Голосовое общнение — это вообще место, где ничего не найдешь потом.
predessor
27.10.2019 16:39Работаю удаленно в асинхронном режиме около 20 лет.
В целом, всё примерно так, как изложено в статье.
Но есть особенности.
Например, на той стороне должны быть люди, которые вместе со мной образуют сколоченный коллектив. Не со всеми работа по переписке возможна. Нужно, чтобы люди друг друга понимали. В том числе, в психологическом плане. Не один проект проваливался из-за того, что корреспонденты не могли найти общий язык и раздражали друг друга. Да и письма могут писать далеко не все.
Периодически (от раза в неделю до ораза в месяц) желательно проводить личные встречи для синхронизации задач и понимания, где мы стоим.
Телефонные разговоры и скайп помогают, но живое общение заменить трудно.
В целом, работу дома, которую я практикую в той или иной степени с 1987 года (не путать с удаленной работой) следует рассматривать, как изощренный способ самоэксплуатации, поскольку рабочий день не нормирован и не ограничен.
AVX
27.10.2019 18:27+1Очень хорошая статья, и рассмотрены важные моменты. Но есть нюанс — нужно чтобы каждый правильно понимал, когда использовать почту, когда мессенджер, а когда нужно позвонить или подойти обсудить лично. Не так, чтобы кто-то решил «я самый важный сотрудник, мне нужно решить вопрос прямо сейчас», и начал названивать, а я в это время работаю с оборудованием в отведённое «окно», и времени в обрез.
Есть и обратные примеры — когда начальник пишет в 9 часов в почту «сделать что-то-там до 12-00», а я в 8 уже выехал и давно за городом в сотне километров, и даже знать не знаю, что там письмо какое-то пришло. Другой коллега считает нормальным в рабочий чат всякие поздравления писать. Или двое между собой по своему вопросу в этом чате что-то обсуждают — почему бы не писать в личку конкретному человеку, если выяснили, что это только вас двоих касается? Пришлось просто выключить звуковое оповещение этого чата, срабатывает только когда кто-то мне отвечает.
AlexKarapet
28.10.2019 07:49+1Это даже обсуждать нет смысла. Давно интуитивно пришли к асинхронному общению, даже с коллегами в одной комнате общались в аське(ICQ, может кто-то уже и не знает что это такое). Суть проста: человек сосредоточенно думает над некой задачей, решил, открыл аську, ответил. Представьте асинхронное общение-только задумался, пошла мысль-звонок, или того хуже, начальник хлопает по плечу-сделай ещё вот эту задачку. Это же здорово выматывает психологически. В итоге в конце дня выполненных задач 0(ноль), а чувствуешь себя уставшим. Надо дать возможность человеку сосредоточенно думать над ОДНОЙ задачей, чтобы там ни говорили про мультизадачность, но не можем мы люди делать два дела одновременно хорошо.
Kanut
28.10.2019 10:20Я думаю какое-то решение для себя все нашли. Или как минимум многие. Мы например каждые пару часов ходим всей командой "пить кофе". И в этот момент обсуждаем какие-то общие вопросы, которые кто-то не в состоянии решить один. И люди из других команд в это время к нам приходят со своими проблемами и мы смотрим когда и как мы им можем с их проблемами помочь. И это можно сказать "асинхронно" и великолепно работает большую часть времени.
Но где-то в среднем один-два раза в неделю происходят события когда кто-то нарушает этот ритуал и общается "синхронно" потому ему это надо очень срочно. Примерно в двух случаях из трёх это действительно так и это вполне себе оправдывает существование "синхронного варианта" как такового.
tcapb1
28.10.2019 15:21Золотой пули нет, всё равно мы упираемся в конфликт интересов.
— разработчик наиболее эффективно работает в асинхронном режиме
— клиенты хотят чтобы им отвечали синхронно (быстрый ответ — стандарт во многих направлениях), и не всегда можно ответить не выдёргивая разработчиков
— при асинхронной работе страдает командное взаимодействие. Начиная с того, что например дизайнер будет простаивать, пока не получит ответа от асинхронного разработчика сможет ли он запилить такую-то фичу на макете. И заканчивая тем, что в таком режиме задачи слишком атомизируются, разработчик может не видеть полной картины, которая бы всплыла на митапе. Например, я перед тем как реализовать очередной фича-реквест стараюсь понять для чего конкретно нужна клиенту эта фича. Может быть он и так может сделать это в нашей системе каким-то другим способом, просто не знает как и поэтому изобретает велосипед. Без полноценного контакта такое теряется.
Т.е. да, асинхронность это хорошо, не нужно слишком увлекаться Slack и иже с ними. Но и асинхронностью тоже слишком увлекаться не стоит.somurzakov
28.10.2019 18:18Agile/Scrum по идее должен хорошо изолировать разработчика от заказчика на время спринта. Требования замораживаются на 2 недели и все обсуждения и претензии высказываются после окончания. Таким образом разработка софта ставится на конвеер и все со временем дрессируются соответствовать процессу — заказчик будет тщательнее и точнее продумывать требования, разрабы будут тянуть свою лямку, правильно коммититься на таски и выполнять их, а лид будет лучше лавировать между емкостью команды и требования заказчика
Nomad1
У меня несколько сотрудников поломалось из-за асинхронной работы: некоторые таски стали теряться, система приоритетов нарушилась, началась рассинхронизация. Со временем регрессия усилилась и вместо выработки самодисциплины они стали просто неконтролируемыми и ненадежными. На стадии, когда даже четко сформулированная задача «сделать к 14:00 к вторнику» перестала выполняться, пришлось применить систему штрафов и испытательных сроков. Рефакторингу не поддаются, хотят в офис, чтобы «работать как все».
Вывод: некоторые люди по-умолчанию не совместимы с таким режимом, либо время ПМа на их координацию должно расти пропорционально и это становится не выгодно.
usego
> некоторые таски стали теряться
Вы таски ставите в чатиках и эмейлах? Может в консерватории что-то поправить?
Nomad1
Я вам могу сказать точно, что больше двух тасков из чатика или эмейла могут потеряться даже у адекватного сотрудника с внутренней дисциплиной :)
Проблема в том, что в асинхронном режиме таски следуют один за другим, без ожидания предыдущих. В итоге некоторые таски остаются висеть не сделанными не смотря на постоянное повышение их приоритетов. Если же переходить в синхронный режим, с отчетами по каждому таску, обязательной приемкой и правками до победного конца, то теряется смысл асинхронности.
usego
Тасков в чатах и мейлах не должно быть по определению. Из такого детсада уже почти все выросли. Шортлист тасков в нормальном процессе ну никак не зависит от того, как они поступают, синхронно или асинхронно. Ну хоть канбан заведите себе что ли.
Nomad1
Мой коммент означал, что таски в чатиках и е-мейликах не работают вообще ни для кого. Поэтому и не используются в принципе. В моем случае все проходит через Redmine, заодно с еженедельной выгрузкой списка в Google Docs (некоторым сотрудникам удобнее видеть список, а не трекер). Да, каюсь, диаграммы Ганта перестал рисовать много лет назад.
В любом случае, со временем наблюдаю заметное увеличение орг. работы от удаленки и медленную деградацию некоторых сотрудников (не всех!). Возможно, нужен отдельный ПМ для удаленщиков, либо мне нужна прокачка дополнительных навыков для компенсации этих перекосов. Ну или как-то классифицировать исполнителей по параметру «пригоден к удаленной службе» и держать отдельно офис и удаленку.
ЗЫ. Я посредственный ПМ, переученный из программиста, да еще и не полностью. Мы не рассматриваем варианты прирожденных руководителей и психологов с тремя дипломами, у которых даже приходящий электрик бросил пить и стал кабеля цифрами маркировать и цветные гофры укладывать.
ncix
Синхронизируйтесь раз в день на утреннем стендапе, вот и всё решение
alekciy
Отчет и приемка может так же происходить асинхронно. На уровне тасктрекера можно вводить запрет на святые в работу менее приоритетных задач.
torbasow
«по-умолчанию»
Вы на руководящей должности? Мне тревожно.
Nomad1
Вы не представляете, насколько мне от этого тревожно :)
x67
дело не только в людях. И в самой работе. Что-то хорошо ложится на асинхронную модель, что-то нет. Работать с фрилансером, чья работа детально прописана в тз и скорее всего однопоточна — удобно. А взаимодействие с программистом, который реализует какую-то новую фичу в асинхронном режиме может быть очень неудобным. Даже когда обсудили все детали, что-то может всплыть, что-то забыться, поменяться. В итоге нерешенный сейчас вопрос или забывается совсем или уходит в релиз не в лучшем виде или работа просто стопорится до решения.
Также, не знаю, как у других, но у меня бывает такое, что просто не могу переключиться на другую задачу, пока не произойдет синхронизация и я не додумаю свою часть.
Ну и взаимодействие с удаленными работниками требует больше времени на подготовку, особенно если человек занимает не ведущую роль и/или не сильно замотивирован и соответственно не проявляет инициативы.
DonCarBon
Я бы даже сказал, не некоторые, а большинство. Включая начальство.