Кстати, интересное решение. Мы так делали когда-то давно, сейчас не делаем. Убрали просто потому что со временем вся команда обучилась и так было проще и удобнее формировать графики.
Сейчас есть приток новых участников и это хорошая идея вернуться к такому "перекрытию". Спасибо за подсказку!
Если есть такие сомнения, а они есть (и часто!), тогда начать можно следующего алгоритма. Как говорится, следите за руками.
Мы не добавляем новой работы разработчикам, и не убираем существующую. А:
определяем какая деятельность больше всего, делаясь ИМИ отвлекает их от написания кода
начинаем ровно эти активности делать не рандомно, затрагивая всех разработчиков, а нести по расписанию. То есть не добавлять им сначала новых активностей "общаться с пользователями попивая кофе", а просто взять например поддержку сессий тестирования или еще что-то, что обычно отвлекает.
Объем работы не увеличивается, количество отвлечений снижается
...
PROFIT!
Таким образом можно начать, а дальше когда вы увидите подходит вам в общем методика или нет, добавлять туда и другие активности типа day-2-operations, поиск узких мест, обновление ОТАРов и сетевых схем, мониторинг и прочее.
Плюс именно в том, что они работают в парах. Один пока объясняет друг другу - идет как бы отладка в режиме "rubber duck debugging" - и сам лучше понимает. Второй - получает ликбез и карту что где лежит. У него нет задачи досконально разбираться и что-то править. Он не фиксит баги, по крайней мере массово, он собирает логи для основной команды. И задачи им ставит на исправление. В мониторинг смотрит и понимает какие метрики что значат. А каких ему лично там не хватает?
То есть цель дежурного - получить тот самый Т-shape знаний. Подтянуть свои "белые пятна". Разработчик react смотрит где какой API торчит и какие контроллеры, и где лог пишется, спеки, тесты. В веб-аналитику может заглянуть (а обычно не смотрит!) Ему это уже полезно. Не только по своему модулю, а по всем.
Выделенные инженеры конечно есть, в Банке есть и инфраструктурщики и сетевики и безопасники и ... yaml-программисты) Смысл дежурных в том, чтобы понять где какие ключи от какой комнаты и куда идти с какими словами. Это как знакомство.
Да, несколько команд, по каждому продукту свои дежурные.
А потом он возвращается писать код и пишет его уже с оглядкой на свой опыт сопровожденца)
Посмотрите, я ответил на комментарий ниже. Тут характеристикой скорее служит малое количество таких запросов и особые требования к качеству обслуживания и ответов.
По крайней мере для такого технического сайта как Хабр, имеющей значение является именно эта характеристика.
Для массовых запросов оптимальный алгоритм будет другим
Вариант с приходящим экспертом хорош тем, что он принимает самые умные решения. А плох он тем, что эксперт не "живет" продуктом. Он "живет" темой своей экспертизы. То есть он делает качественно, но не для себя. Это вполне рабочий компромисс, так часто делают в корпорациях. И эта схема хорошо подходит для Юристов, например.
А вот эксперта по архитектуре написания сервисов приглашать смысла уже меньше - эти знания нужны часто, много, в сложных запросах - и приходится идти по трудному пути и "подсаживать" знания прямо в головы разработчиков. Чтобы они сами знали что тут где лежит и по каким вопросам реально все же нужно вызывать эксперта.
Гильдии как инструмент обмена знаниями. Конечная цель в том, чтобы все знания, необходимые для выпуска продукта были доступны само-организованной команде без необходимости куда-то долго ходить. DevRel-ы у нас занимаются не только HR-брендом (найм) но и организуют внутренние сообщества, чтобы разработчики сговаривались между собой. Так повелось)
Привет! Не знаю. Основная идея тут в том, что подключив команду разработки к поддержке, мы в целом даем более высокий уровень поддержки клиентам, а разработчикам - высокий уровень понимания продукта. Реального опыта клиентов по взаимодействию с нашими сервисами.
И там, где качество поддержки реально важно, а количество обращений не слишком высокое - метод показал себя довольно успешно. То есть high-risk high-reward окружение.
Если же речь о более массовых сегментах, тогда нужно сосредоточиться на том, чтобы дежурный старался не делать одну и ту же работу несколько раз. Первый - сделал, второй - задумался, третий - написал инструкцию, далее - автоматизировали.
1) Да, и именно таких мы стараемся набирать в продуктовые команды с самого начала. Мы на первом собеседовании сейчас проговариваем эту практику как раз как решение от "соскучивания". Ведь одно то же подряд делать (пилить год свой отчет) может быть скучно - а заниматься целиком целым продуктом и самому решать куда направить свой взор внимательный - как раз интересно.
2) Часть сотрудников не хотят делать какие-то конкретные вещи (ну, например, некоторые из react программистов ну совсем не хотят жать кнопку в ТимСити по поставке релиза). В этом случае учитываем предпочтения при сборе пар. То есть в пару берётся человек который хочет и любит делать конкретно этот кусок.
3) Там более сложная система, она точно выходит за рамки статьи. Основной тезис тут - что мы заранее знаем о таком вопросе и можем заранее спроектировать систему. Например по принципу двух "ключей" как фильмах.
Кстати, интересное решение. Мы так делали когда-то давно, сейчас не делаем. Убрали просто потому что со временем вся команда обучилась и так было проще и удобнее формировать графики.
Сейчас есть приток новых участников и это хорошая идея вернуться к такому "перекрытию". Спасибо за подсказку!
Если есть такие сомнения, а они есть (и часто!), тогда начать можно следующего алгоритма. Как говорится, следите за руками.
Мы не добавляем новой работы разработчикам, и не убираем существующую. А:
определяем какая деятельность больше всего, делаясь ИМИ отвлекает их от написания кода
начинаем ровно эти активности делать не рандомно, затрагивая всех разработчиков, а нести по расписанию. То есть не добавлять им сначала новых активностей "общаться с пользователями попивая кофе", а просто взять например поддержку сессий тестирования или еще что-то, что обычно отвлекает.
Объем работы не увеличивается, количество отвлечений снижается
...
PROFIT!
Таким образом можно начать, а дальше когда вы увидите подходит вам в общем методика или нет, добавлять туда и другие активности типа day-2-operations, поиск узких мест, обновление ОТАРов и сетевых схем, мониторинг и прочее.
Плюс именно в том, что они работают в парах.
Один пока объясняет друг другу - идет как бы отладка в режиме "rubber duck debugging" - и сам лучше понимает. Второй - получает ликбез и карту что где лежит. У него нет задачи досконально разбираться и что-то править. Он не фиксит баги, по крайней мере массово, он собирает логи для основной команды. И задачи им ставит на исправление. В мониторинг смотрит и понимает какие метрики что значат. А каких ему лично там не хватает?
То есть цель дежурного - получить тот самый Т-shape знаний. Подтянуть свои "белые пятна". Разработчик react смотрит где какой API торчит и какие контроллеры, и где лог пишется, спеки, тесты. В веб-аналитику может заглянуть (а обычно не смотрит!) Ему это уже полезно. Не только по своему модулю, а по всем.
Выделенные инженеры конечно есть, в Банке есть и инфраструктурщики и сетевики и безопасники и ... yaml-программисты) Смысл дежурных в том, чтобы понять где какие ключи от какой комнаты и куда идти с какими словами. Это как знакомство.
Да, несколько команд, по каждому продукту свои дежурные.
А потом он возвращается писать код и пишет его уже с оглядкой на свой опыт сопровожденца)
Чтобы получилось «обучение через делание», да. Причём по довольно широкой области и в рабочее время. Как подмастерье.
Интересно! А у вас дежурство было одиночное или в парах? То есть было с кем в процессе обсудить и учиться?
и какая была «длительность смены» и было ли не обязательно в это время, собственно, код писать? Или просто «в нагрузку»?
Спасибо!
Посмотрите, я ответил на комментарий ниже. Тут характеристикой скорее служит малое количество таких запросов и особые требования к качеству обслуживания и ответов.
По крайней мере для такого технического сайта как Хабр, имеющей значение является именно эта характеристика.
Для массовых запросов оптимальный алгоритм будет другим
Да! Именно!
Она достаточно компетентна, чтобы УЖЕ понимать, где она некомпетентна.
Сойдёмся на этом. То есть какой то минимальный ликбез это даёт все равно.
Вариант с приходящим экспертом хорош тем, что он принимает самые умные решения. А плох он тем, что эксперт не "живет" продуктом. Он "живет" темой своей экспертизы. То есть он делает качественно, но не для себя. Это вполне рабочий компромисс, так часто делают в корпорациях. И эта схема хорошо подходит для Юристов, например.
А вот эксперта по архитектуре написания сервисов приглашать смысла уже меньше - эти знания нужны часто, много, в сложных запросах - и приходится идти по трудному пути и "подсаживать" знания прямо в головы разработчиков. Чтобы они сами знали что тут где лежит и по каким вопросам реально все же нужно вызывать эксперта.
Гильдии как инструмент обмена знаниями. Конечная цель в том, чтобы все знания, необходимые для выпуска продукта были доступны само-организованной команде без необходимости куда-то долго ходить. DevRel-ы у нас занимаются не только HR-брендом (найм) но и организуют внутренние сообщества, чтобы разработчики сговаривались между собой. Так повелось)
Привет! Не знаю.
Основная идея тут в том, что подключив команду разработки к поддержке, мы в целом даем более высокий уровень поддержки клиентам, а разработчикам - высокий уровень понимания продукта. Реального опыта клиентов по взаимодействию с нашими сервисами.
И там, где качество поддержки реально важно, а количество обращений не слишком высокое - метод показал себя довольно успешно. То есть high-risk high-reward окружение.
Если же речь о более массовых сегментах, тогда нужно сосредоточиться на том, чтобы дежурный старался не делать одну и ту же работу несколько раз. Первый - сделал, второй - задумался, третий - написал инструкцию, далее - автоматизировали.
Надеюсь, помог ответом понять суть.
1) Да, и именно таких мы стараемся набирать в продуктовые команды с самого начала. Мы на первом собеседовании сейчас проговариваем эту практику как раз как решение от "соскучивания". Ведь одно то же подряд делать (пилить год свой отчет) может быть скучно - а заниматься целиком целым продуктом и самому решать куда направить свой взор внимательный - как раз интересно.
2) Часть сотрудников не хотят делать какие-то конкретные вещи (ну, например, некоторые из react программистов ну совсем не хотят жать кнопку в ТимСити по поставке релиза). В этом случае учитываем предпочтения при сборе пар. То есть в пару берётся человек который хочет и любит делать конкретно этот кусок.
3) Там более сложная система, она точно выходит за рамки статьи. Основной тезис тут - что мы заранее знаем о таком вопросе и можем заранее спроектировать систему. Например по принципу двух "ключей" как фильмах.
Краткое - команда Dev по очереди, по расписанию, занимается Ops. А именно — day-2 operations. Релизы, консультации, все дела.
За счёт этого они лучше понимают жизнь админа, пишут для него (для себя!) более чистый поддерживаемый код и помогают коллегам защищать «поток».