Баг трекеры и тикет системы у нас есть и используются по прямому назначению. Но заводить тикет в ситуации, когда у разработчика сервис смежной команды отдает 503 ошибку в стейдже, мешая продолжать отладку, не самый оперативный подход.
Или поддержка пользователей завела тикет о проблеме на проде, и в процессе локализации проблемы одной команде требуется консультация с другой? Можно это сделать в рамках тикета и подождать, когда вторая команда увидит комментарии.
Или написать в чат команды, отвечающей за сервис. Кто начнет смотреть проблему? Или самый быстрый или несколько человек или все будут ждать того самого, кто публично отреагирует на вопрос. Это как раз к вашим словам о том, что кто-то пишет сообщение и отвлекает всю команду.
Решить такого рода ситуации можно по-разному, мы выбрали и успешно обкатали путь, при котором зона ответственности сотрудника четко определена и автоматизирована и не обязывает его бесперерывно отсматривать рабочие сообщения. А остальные члены команды сосредоточены на своих задачах и не отвлекаются
В это же время коллеги, столкнувшиеся с проблемой не чувствуют себя частью бюрократической машины, где на каждый технический вопрос или проблему нужно создавать подробный тикет.
Сообщения без тега не игнорируются, но могут доходить до адресата с большим опозданием Любая наша команда работает в режиме многозадачности, водрузить человека на трон дежурного, который будет в течение всего дня только отслеживать запросы на поддержку - не лучшее решение.
И вот представьте ситуацию, когда дежурный инженер сидит и занимается, к примеру репликацией большого массива данных, а у коллеги разработчика билд продового приложения упал. Разработчик оповестил о проблеме безадресно, дежурный в это время кропотливо проверяет, что ничего не пропустил, сообщения не видит. Начинается излишний переполох.
Плюс командные каналы не ограничиваются вопросами поддержки, там может быть много разных тем. Выискивать среди десятков сообщений то самое, адресованное дежурному, тоже крадет лишнее время инженера. Гораздо проще именно в нашей ситуации оказалось автоматизировать процесс. Эта схема в нашей компании удобно внедряется в любую специфику дежурств. Будь то сами разработчики, или QA или системные аналитики.
Что мы получили? Нуждающийся в помощи коллега знает один тег, а дежурный не мониторит чат на протяжении всего дня, оперативно получая алерт.
Баг трекеры и тикет системы у нас есть и используются по прямому назначению.
Но заводить тикет в ситуации, когда у разработчика сервис смежной команды отдает 503 ошибку в стейдже, мешая продолжать отладку, не самый оперативный подход.
Или поддержка пользователей завела тикет о проблеме на проде, и в процессе локализации проблемы одной команде требуется консультация с другой? Можно это сделать в рамках тикета и подождать, когда вторая команда увидит комментарии.
Или написать в чат команды, отвечающей за сервис.
Кто начнет смотреть проблему? Или самый быстрый или несколько человек или все будут ждать того самого, кто публично отреагирует на вопрос. Это как раз к вашим словам о том, что кто-то пишет сообщение и отвлекает всю команду.
Решить такого рода ситуации можно по-разному, мы выбрали и успешно обкатали путь, при котором зона ответственности сотрудника четко определена и автоматизирована и не обязывает его бесперерывно отсматривать рабочие сообщения. А остальные члены команды сосредоточены на своих задачах и не отвлекаются
В это же время коллеги, столкнувшиеся с проблемой не чувствуют себя частью бюрократической машины, где на каждый технический вопрос или проблему нужно создавать подробный тикет.
Сообщения без тега не игнорируются, но могут доходить до адресата с большим опозданием
Любая наша команда работает в режиме многозадачности, водрузить человека на трон дежурного, который будет в течение всего дня только отслеживать запросы на поддержку - не лучшее решение.
И вот представьте ситуацию, когда дежурный инженер сидит и занимается, к примеру репликацией большого массива данных, а у коллеги разработчика билд продового приложения упал. Разработчик оповестил о проблеме безадресно, дежурный в это время кропотливо проверяет, что ничего не пропустил, сообщения не видит. Начинается излишний переполох.
Плюс командные каналы не ограничиваются вопросами поддержки, там может быть много разных тем. Выискивать среди десятков сообщений то самое, адресованное дежурному, тоже крадет лишнее время инженера. Гораздо проще именно в нашей ситуации оказалось автоматизировать процесс.
Эта схема в нашей компании удобно внедряется в любую специфику дежурств.
Будь то сами разработчики, или QA или системные аналитики.
Что мы получили? Нуждающийся в помощи коллега знает один тег, а дежурный не мониторит чат на протяжении всего дня, оперативно получая алерт.