Comments 79
Единственный компромиссный момент — они выделили VIP-клиентов, чьи проводки вообще никто никогда не должен видеть, их видят только сотрудники с определённым уровнем доступа.
Как всегда, по закону все равны, но некоторые равнее
Причина очень простая: последствия от того, что кодер сольёт информацию хотя бы по одному VIP-клиенту, слишком серьёзные, поэтому проще и дешевле нанять отдельную команду для работы с ними.
А так VIP-клиенты есть даже в такси, например, если обычному клиенту сотрудник поддержки может легально хамить, то в регламенте для работы с VIP-клиентами прямо прописана максимальная лояльность, выдача максимальных промокодов на любую жалобу и так далее. Просто потому, что риск его недовольства выше. Из лайфхаков - сотрудники часто могут засунуть себя в список VIP-клиентов и ездить с комфортом и горой компенсаций за все.
Мне кажется, тут подойдет другое сравнение:
"А так Vip-клиенты есть даже в такси, например, если обычному клиенту могут выдать водителя - серийного маньяка, то VIP-у только прилежного дядечку с высшим образованием, прошедшим все проверки СБ"
Ну тоесть одно дело, когда с кем-то просто обращаются лучше, чем с другими, а другое дело, это когда "тут опасно, надо ограничить. А с этими... а с этими ниче не случится, забей". Типа давайте выдавать каски на стройке только начальникам, они же випы все-таки
Посмотрите, я ответил на комментарий ниже. Тут характеристикой скорее служит малое количество таких запросов и особые требования к качеству обслуживания и ответов.
По крайней мере для такого технического сайта как Хабр, имеющей значение является именно эта характеристика.
Для массовых запросов оптимальный алгоритм будет другим
Типа давайте выдавать каски на стройке только начальникам, они же випы все-таки
А выдавать випам усиленные каски?
Спасибо за статью. Было очень интересно познакомиться с вашим подходом. Почерпнул для себя много полезного.
Много текста, но так и не понял, есть краткое TLDR чем отличается от существующих ролей тимлида, менеджера, руководителя (проекта) и прочего? Потому что закрытие команды от внешних раздражителей они обычно и выполняли всю жизнь.
Краткое - команда Dev по очереди, по расписанию, занимается Ops. А именно — day-2 operations. Релизы, консультации, все дела.
За счёт этого они лучше понимают жизнь админа, пишут для него (для себя!) более чистый поддерживаемый код и помогают коллегам защищать «поток».
Звучит некомфортно. Пошел читать статью.
Дочитал то дежурства. Непонятные моменты:
Упомянуто, что вы выбрали 5 вариант, но вариантов всего 4. Какой то выпал в редактуре?
Чем плох предыдущий вариант (3 из 4), с приходящим экспертом? Эксперт, на то и эксперт, что разбирается в своей теме, достаточно компетентен, чтобы быстро включиться в любой вопрос. Плюс, у него есть понимание, как уже сделано или делается в соседних командах, т.к. их он тоже консультирует по этим темам.
Упомянуты devrel и гильдии, но по статье непонятно, к чему их упомянули. Devrel обычно упоминается как что-то маркетинговое и для привлечения внимания. Чем оно поможет тут?
1) пофиксили, спасибо.
Вариант с приходящим экспертом хорош тем, что он принимает самые умные решения. А плох он тем, что эксперт не "живет" продуктом. Он "живет" темой своей экспертизы. То есть он делает качественно, но не для себя. Это вполне рабочий компромисс, так часто делают в корпорациях. И эта схема хорошо подходит для Юристов, например.
А вот эксперта по архитектуре написания сервисов приглашать смысла уже меньше - эти знания нужны часто, много, в сложных запросах - и приходится идти по трудному пути и "подсаживать" знания прямо в головы разработчиков. Чтобы они сами знали что тут где лежит и по каким вопросам реально все же нужно вызывать эксперта.
Гильдии как инструмент обмена знаниями. Конечная цель в том, чтобы все знания, необходимые для выпуска продукта были доступны само-организованной команде без необходимости куда-то долго ходить. DevRel-ы у нас занимаются не только HR-брендом (найм) но и организуют внутренние сообщества, чтобы разработчики сговаривались между собой. Так повелось)
А плох он тем, что эксперт не "живет" продуктом
Почему не живет? Условно, у вас большой проект в банке. Эксперт что, живет вне продукта? Не занимается продуктом? Просто ходит и консультирует остальных?
Я подразумевал, что эксперт - сотрудник на проекте. Просто он разбирается лучше остальных (по любым причинам, у него больше опыта, он тратит на это доп время, ещё что-то -- это его специализация).
А вот эксперта по архитектуре написания сервисов приглашать смысла уже меньше - эти знания нужны часто, много, в сложных запросах - и приходится идти по трудному пути и "подсаживать" знания прямо в головы разработчиков. Чтобы они сами знали что тут где лежит и по каким вопросам реально все же нужно вызывать эксперта.
А с сервисами звучит странно. Основная идея сервисов - упрощение. Каждый сервис должен быть максимально простым и понятным, чтобы его можно было заменить в случае чего, чтобы разработчиков новых было подключать легко и тому подобное. Если экспертиза при рядовой разработке нужна часто - что-то пошло не так. Либо оверинжениринг, либо разработчики слабоваты для таких задач (каких таких - сложно сказать, потом что типовые бизнес задачи покрываются разными вариантами CRUD операций на 80%).
Да, я понимаю, что на словах этот момент можно обсуждать долго и бессмысленно. Просто у меня большие сомнения, что команда достаточно компетентна в вопросах безопасности например, чисто на основании дежурств. Это так не работает =)
Она достаточно компетентна, чтобы УЖЕ понимать, где она некомпетентна.
Сойдёмся на этом. То есть какой то минимальный ликбез это даёт все равно.
Эксперт не живёт продуктом в том смысле, что он "расшарен" между рядом проектов. В рамках стрима, например. Со всеми вытекающими от такого рода многозадачности последствиями, в т.ч. не слишком достаточное погружение в детали или выпадение из контекста проекта.
Не совсем понимаю, эксперт ли он тогда. Условно, есть у вас человек на проекте, который лучше всех знает, как готовить технологию N. И каждый в целом может пользоваться технологией, но если на этой технологии хотят напилить велосипед или полезли странные непонятные проблемы - и вот пора привлечь опытного сотрудника-эксперта, который быстро разберется и вы вместе как то решаете задачу-проблему.
Он уже сам решит, достаточно ему технических деталей или нужна бизнесовая составляющая в каждом конкретном случае.
То время, которое он не тратит на экспертизу я вполне допускаю что он занимается другими вопросами на проекте.
ПС: это же можно использовать и для нетехнических экспертов - безопасников, юристов, прочее.
И по остальному тексту - в scrum например выделяют всего 3 роли - PO, Scrum master и developers. И вопросы "не мешайте разработчику работать", общение с клиентами вида государства или крупных внешних заказчиков на себя берёт PO (ему оно по задачам положено, к слову). А вопросы разработки, релизов, и всей технарской кухни берет на себя команда разработки. Как они сами решат внутри, это же agile, гибкость. Где то инициативного сотрудника, где то будет сменная рутина, кому как удобнее.
И имхо, ваш вариант получился сложным. Перегруз разработчиков кучей всего.
ПС: некоторые вещи, которые вы приносите через дежурства (понимание предметки, понимание болей пользователя) имхо должно и без дежурств работать. Варианты тут разные, сильно зависит от области и разработчиков. PO когда ставит задачу, должен её ставить именно со стороны клиента\пользователя, команда должна изначально знать что и зачем она делает. Иное звучит плохо =)
В реалиях жизни такие команды обычно распадаются (а чаще строятся) на определённые роли с зонами ответственности и со всеми вытекающими побочками от сакральных знаний до отмашек "это не моё" и "а у меня работает". Описаный подход весьма интересен и, судя по описанному, свои задачи решает, вот только мало кто такое себе может позволить.
Не понял, если честно.
Сакральные знания - это экспертиза? Всмысле, мы пишем код по предметке годами, мы в ней разбираемся, это ожидаемо и выгодно для менеджера который ставит нам задачи.
А отмашки вида "не мое" - это странный аргумент. С человеком надо конкретным работать, который считает это нормальным ответом на вопросы.
Ну к примеру условный отчёт из статьи, который пишет гуру отчётов и все проблемы по эксплуатации отчёта прилетают к нему напрямую, а остальные даже не включают голову, где KPI этого отчёта надо смотреть и как вообще он работает. Т.е. в команде естественным образом создаются круги комфорта из которых мало кто хочет вылезать. Будучи регулярным ОПСом и L2 саппортом по отчёту хочешь не хочешь, голову в эту сторону приходится включать. Тем самым происходит шаринг знаний и круг комфорта расширяется вокруг всего проекта в целом, а не только избранной песочницы.
Да! Именно!
а остальные даже не включают голову, где KPI этого отчёта надо смотреть и как вообще он работает.
А им дают время на 'включать голову' по поводу этого отчета?
Пока вся статья выглядит как 'мы дали время разработчикам почитать весь остальной код и доделать то, на что обычно "нет времени"'.
Вероятно, без дежурства, а с каким-нибудь другими способами указания на 'тайное знание' и проверки 'теперь это знание явное' -- могло получиться еще лучше.
Слушайте, ну это куча разных вариантов.
Кто в команде? Если в команде десяток бэк разработчиков, каждый из которых способен написать отчет и пишет разные отчеты (т.е. у каждого есть по несколько отчетов, за которые он в первую очередь отвечает) - то они взаимозаменяемы вполне, пусть компетенции в конкретном отчете у них и различаются.
Если в команде 1-2 спеца, которые отчеты делают и ничего более - каким образом фронт в команде, назначенный дежурным, станет разбираться хоть на каком то полезном уровне?
Если отчет сложный бизнесово (не просто выгрузка таблички), то отчет прекрасно знают аналитик и тестировщик помимо разработчика.
Обсуждать этот вопрос можно с тысячи разных сторон. Если по отчету часто прилетают вопросы - может отчет требует переработки? Может он слишком сложный для потребителя?
Спасибо за статью.
Если позволите, несколько вопросов:
1) Как я понял, вам в любом случае требуются overqualified-сотрудники, которые "и швец, и жнец, и на дуде игрец" (погружены в бизнес-область, в архитектуру, умеют работать с клиентами, реагируют на инциденты). В рамках одного проекта такие люди могут очень быстро соскучиться. Как решаете вопрос удержания?
2) Как выстроен процесс работы для тех, кто отказался от дежурств (вы упоминаете цифру 10-20%)?
3) По поводу VIP-клиентов не до конца понятно написано. Если там свой уровень доступа, то для таких клиентов нужен свой отдельный дежурный с таким доступом?
1) Да, и именно таких мы стараемся набирать в продуктовые команды с самого начала. Мы на первом собеседовании сейчас проговариваем эту практику как раз как решение от "соскучивания". Ведь одно то же подряд делать (пилить год свой отчет) может быть скучно - а заниматься целиком целым продуктом и самому решать куда направить свой взор внимательный - как раз интересно.
2) Часть сотрудников не хотят делать какие-то конкретные вещи (ну, например, некоторые из react программистов ну совсем не хотят жать кнопку в ТимСити по поставке релиза). В этом случае учитываем предпочтения при сборе пар. То есть в пару берётся человек который хочет и любит делать конкретно этот кусок.
3) Там более сложная система, она точно выходит за рамки статьи. Основной тезис тут - что мы заранее знаем о таком вопросе и можем заранее спроектировать систему. Например по принципу двух "ключей" как фильмах.
Насчет первого пункта. У нас, например, есть отдел эксплуатации, который и занимается решением абсолютно всех задач (швец, певец, на дуде игрец и не только). Главная задача эксплуатации - отладка и поиск ошибок. Причем нужно разбираться в большом технологическом стеке (Python, NodeJS, NestJS, VueJS, SQL, PL/SQL, RabbitMQ, RESTFull API). Но самое страшное - это аналитика.
Думаю, что именно попытки прокачивать себя во всех этих технологиях и не дают соскучиться. А вот развитие (developers), которые целыми днями кодят ток на одном языке соскучиться могут намного быстрее.
3) Там основная проблема - протечка данных по конкретным клиентам. Закрыты именно балансы/статусы/транзакции закрытого списка лиц.
А чем администрация президента важнее любого другого заказчика?
Привет! Не знаю.
Основная идея тут в том, что подключив команду разработки к поддержке, мы в целом даем более высокий уровень поддержки клиентам, а разработчикам - высокий уровень понимания продукта. Реального опыта клиентов по взаимодействию с нашими сервисами.
И там, где качество поддержки реально важно, а количество обращений не слишком высокое - метод показал себя довольно успешно. То есть high-risk high-reward окружение.
Если же речь о более массовых сегментах, тогда нужно сосредоточиться на том, чтобы дежурный старался не делать одну и ту же работу несколько раз. Первый - сделал, второй - задумался, третий - написал инструкцию, далее - автоматизировали.
Надеюсь, помог ответом понять суть.
Спасибо за статью, интересный рецепт, хоть и дорогой и сложный. Главный смущающий момент: думал, что обязанность закрывать своим телом команду от непрофиля и отвлечений РО, РМ или лид.
Хорошо если все же не лид, а PO, PM и BA, в общем-то их роль в этом и состоит, если девелоперы еще и этим станут заниматься - кто вообще код писать будет?
Но статья хорошая, я так понимаю зайцев автор статьи убивает сразу 2. Напишу более откровенно, т.к. автор по понятным причинам не может крепко выразиться:
1) Развлекает таким образом SSE, которые иначе сойдут с ума от скуки, покрывая каждую формочку очередного отчета юнит тестами вплоть до жирноты подчеркивания подписи. А так SSE не сбегает, а чувствует свою важность, играет периодически в ПМ, да и
2) В энтерпрайзах с огромной кодовой базой реально существует прослойка девелоперов, которой с глубокой колокольни что и для чего они делают. Даже я например, работая на стартапе, замечал что если приходит от PO просто требование - может для меня звучать как околесица, я буду ругаться на идиотов в маркетинге. Но когда мне объяснят в чем истинный смысл фичи - я проникаюсь важностью и с бОльшей мотивацией пишу код. А это ж банк, самая скучная в мире работа. Одно дело верстать бесконечные формочки отчетов, другое дело - если ты будешь понимать, зачем и кому это надо, а еще и людям поможет (хоть и ненавижу это слово, но как выразился автор - как это изменит мир)
мне показалось что за термином "высокий уровень понимания продукта " скрывается желание содрать с людей три шкуры за один оклад и не нанимать профильных специалистов заставляя имеющихся крутиться волчком на двух стульях? а то "назначается дневальный" наводит именно на такие мысли, потому что иначе просто нанимается специалист закрывающий задачу.
Давно ещё один CTO, родом из программистов, говорил - если разработчик не общается с бизнесом и с заказчиком - то это в лучшем случае кодировщик. Ну и действительно, есть такое явление - программисты не понимают продукт, цели, задачи, максимум доходят user story, и то не всегда, сидят, кодируют. В итоге продукт выходит немного оторванный от желания (см боянистую картинку про качели).
Естественно, в ряде случаев хватает кодировщиков, да и построить вовлечённую команду сложно. «Лайфхак» с дежурствами занятный
Тут ведь какая штука? По этому Лайфхаку специалист две недели вместо своей работы сидит на телефоне и рассказывает пользователям на какую кнопочку кликать. Это либо работодатель платит оклад программиста работнику саппорта, либо на должность программистов набрали специалистов с низкой квалификацией и их зарплата "отбивается" и на телефоне. Ведь было запланировано, что заданный объем работ данная команда выполнит в установленный срок. Из команды выкинули одного человека, значит либо работа будет выполнена позже, либо за него кто-то впахивает. А то, что Вы назвали "общаться с бизнесом и заказчиком" это, на мой взгляд, немного другое. Как Вы себе представляете работу, например, Гугла или Микрософта, если бы все разработчики пошли общаться с заказчиками? Или там сплошь все "бездарные кодеры"?
Описанная "оптимизация" по моему опыту - детище менеджеров. Начальник обосновал свою премию проведенной оптимизацией и публикациями. А как там на самом деле работа работается - никого особо и не интересует, главное что отчеты красивые написаны и показаны. Как новый начальник приходит, так тут же что-то "оптимизируется". Потом оптимизация затихает - загубить на корню производство и развалить налаженные процессы никто не хочет.
Если есть такие сомнения, а они есть (и часто!), тогда начать можно следующего алгоритма. Как говорится, следите за руками.
Мы не добавляем новой работы разработчикам, и не убираем существующую. А:
определяем какая деятельность больше всего, делаясь ИМИ отвлекает их от написания кода
начинаем ровно эти активности делать не рандомно, затрагивая всех разработчиков, а нести по расписанию. То есть не добавлять им сначала новых активностей "общаться с пользователями попивая кофе", а просто взять например поддержку сессий тестирования или еще что-то, что обычно отвлекает.
Объем работы не увеличивается, количество отвлечений снижается
...
PROFIT!
Таким образом можно начать, а дальше когда вы увидите подходит вам в общем методика или нет, добавлять туда и другие активности типа day-2-operations, поиск узких мест, обновление ОТАРов и сетевых схем, мониторинг и прочее.
потенциально - программист пока сидит на телефоне, немного переключает контекст и может потенциально закрывать техдолг. вместо закапывания в непосредственную работу или игр в кикер\приставку, так что в теории тут можно даже наблюдать рост продуктивности при том же штате. ну и заодно повышается экспертиза саппорта (ведь по сути с 3-4 линии человек переходит на 2 и может чем-то поделиться), а может заодно и на продактах выйдет экономия :)
про гугл-микрософт там ниже скинули ссылку, да и как раз в гугле-майкрософте и прочем сбере ИМХО больше распространена практика "сиди и кодируй". я к слову не умаляю "кодировщиков" - если упростить, это тот кто превращает ТЗ в код. вспоминая того СТО - в его понимании кодер - это ремесленник, разработчик - уже должность более творческая, где уже рядом архитектура и дизайн продукта.
ну и конечно же, описанная в статье "оптимизация" явно подойдёт не всем (компаниям, командам). прям до детища эффективных менеджеров не хватает kpi, sla и прочих метрик :D лично мне концепт чем-то глянулся, внедрять его я конечно не буду:)
Супер. Дежурства - отличная и оригинальная идея.
Но я хочу узнать про "поле знаний". Оно только через дежурства достигается? Как, к примеру, выравниваются архитектурные решения в различных командах?
Очень напомнило путь гугла, описанный в https://sre.google/books/ . Почитайте, там есть моменты которые вы еще не прошли и рецепты по их устранению.
Встречался с подобным. На себе ощущал все прелести и недостатки подобных дежурств.
Из плюсов можно отметить:
1) Погружение в домен происходит быстрее. Но здесь важно понимать, что нельзя доверить дежурство человеку с малыи погружением (только если в качестве наблюдающего за работой сеньера), иначе будет отталкивающий эффект.
2) На команду в целом снижается нагрузка и наплывы вопросов (запросов) от посторонних людей
3) У людей по ту сторону разработки появляются единые каналы решения проблем, и не уходит много времени на понимание, куда именно обращаться за помощью по вопросам разработки.
Из минусов:
1) Сам дежурный, как правило, в состоянии пофиксить только самые легкие баги и ответить на простейшие вопросы. Обычно дежурный все равно редиректит поступившие обращения к более погруженным сотрудникам, т.к. на том конце провода всегда все срочно. Способных покрыть хотя бы 50% запросов дежурных я не встречал. У схемы огромный порог вхождения, который только порождает доп. bus factor на ключевых людей.
2) Передача дел между дежурными почти не осуществляется, и проблемы, которые не решились в смены дежурств, переходят другим дежурным, которые либо отвлекают предыдущих дежурных, чтобы понять статус и ход мыслей, либо просто начинают решение проблемы с чистого листа. Видел, как некоторые вопросы в результате подвисали на месяца, и каждый новый дежурный добавлял по паре сообщений в тред, который в результате невозможно было читать новому человеку.
3) Практика "релизы + техподдержка + дебаг + техдолг", как правило, не работает в полной мере. Потому что иногда какой-то из этих пунктов способен просто перекрыть остальные на все время дежурства (сложные релизы с конфликтами, под видом простенького бага оказался слоняра, на фикс которого ушло все время, срочные вопросы от клиентов или техподдержки, которые постоянно отвлекали от остальных обязанностей, недодекомпозированный техдолг, который потребовал много действий). Слишком большая нагрузка на человека, и слишком много неизвестных в планировании дежурства, т.к. в любой момент дежурство может потребовать переключения.
В целом, я так и не ощутил на себе, как можно сделать этот процесс не породив суперменов-разработчиков, которые будут на себе тащить многое, выходя за рамки своих базовых обязанностей. Это очень сильно увеличивает разрыв между старичками и новичками в команде, иногда даже порождая дедовщину. Поэтому соглашусь с комментариями выше, в которых писалось про то, что дежурства - это отдельный процесс, а погружение в домен, онбоардинги и различные повышения квалификаций - совсем другой, и они невзаимозаменяемы.
Интересно! А у вас дежурство было одиночное или в парах? То есть было с кем в процессе обсудить и учиться?
и какая была «длительность смены» и было ли не обязательно в это время, собственно, код писать? Или просто «в нагрузку»?
Дежурство было в разрезе команды. Сами команды делились по продуктам и стеку. Каждую неделю выделялся разработчик. До парного дежурства дело не доходило, обычно "пара" была как раз в виде тимлида или старших разработчиков, которые делали тот или иной функционал. Чаще всего лид.
Разработчик освобождался от своих непосредственных задач, и занимался только дежурствами с описанным регламентом. Смены были недельными, примерно раз в 1.5-2 месяца.
Предложенная схема парного дежурства, когда младший делает, а старший контролирует, не нова, но хороша. Насколько я помню, путь примерно как в компартии Италии 50х - свежеобученных товарищей из тамошнего аналога комсомола отправляли помощниками не на низовые должности, а наоборот, поближе к верхушке и принятию решений. По мере набора опыта во время стажировки молодёжь не поднималась по должностям, а а наоборот, постепенно перемещалась от точки принятия решений к точке исполнения.
Если делать дежурства парными по две недели, а каждого в паре сместить на неделю, что в паре дежурных каждую неделю меняется один человек, контекст не теряется, дела передаются без стрессов.
Кстати, интересное решение. Мы так делали когда-то давно, сейчас не делаем. Убрали просто потому что со временем вся команда обучилась и так было проще и удобнее формировать графики.
Сейчас есть приток новых участников и это хорошая идея вернуться к такому "перекрытию". Спасибо за подсказку!
Тогда идет прямой конфликт интересов разработчиков в разрезе того, чем они занимаются на работе.
Дежурства - навязанная сверху инициатива начальства, которая не фигурирует в основных обязанностях при заключении договоров. И если разработчик будет посвящать этому много времени, в голове рождается вопрос "а тем ли я занимаюсь, и что получаю взамен?". И ответы на эти вопросы в пользу компании рождаются лишь у людей с горизонтальными обязанностями (лиды, пм, и т.д.).
Обычный разработчик в этом плане получит замедление роста как программиста (о котором его спросят на собеседованиях с более высокой зп), но получит горизонтальный рост внутри компании.
Конфликтов не будет только в том случае, где разработчиков холят и лелеют, десятилетиями учитывая их профессиональные интересы. Судя по современным тенденциям, таких компаний везде все меньше и меньше.
Если речь идет о таких сроках дежурства, скорее всего требуется отдельная должность.
Самое правильное, на мой взгляд, что мы можем тут предложить или сделать — это дать выбор самому разработчику и проговорить все эти моменты заранее. Ещё на входном интервью.
Отобрать тех, кому интересен именно такой подход. Кому нужен Т-shape, а не I, причём когда дают растить его в рабочее время, а не требуют учиться когда-то в личное.
Действительно, может быть такой эффект, что специализация будет ниже, а значит если цель разработчика - прохождение тех интервью на рынке, где ценится именно I - ему будет сложнее.
Главное тут прямо и честно все проговорить на вхоже и убедиться что цели совпадают, и что разработчик следует за своими целями, просто с помощью и ресурсами компании. Принося пользу обоим.
И какова текучка с таким подходом? Просто, сколько не видел продуктовых компаний, которые изрядно проповедовали T-shape и различные мантры в духе "наш разработчик - нечто большее, чем просто кодер", там в основном лиды это все активно слушали, и им это было действительно полезно и интересно. Рядовые разработчики же либо холодно игнорировали такие посылы, либо открыто конфликтовали с наводящими запросами на тему должностных обязанностей и перенагрузки на одного человека. Как следствие, из-за несбалансированной нагрузки некоторые либо сидели без отпусков, либо выгорали, либо уходили в компании c I, награждая T-компанию постоянной текучкой кадров.
Когда человек выходит на рынок труда, от его T мало чего остается. Потому что вся квалификация становится очень специфичной в разрезе компании. В терминальных стадиях я встречал человека, которого отправляли на различные продуктовые командировки и конференции, хотя тот просто корпоративный сайт поддерживать нанимался. В итоге, человек забывал, что такое полиморфизм, зато говорил про то, как он помимо сайта еще 90 дел не относящихся к программированию делал. С одной стороны, видишь человека, который был предан компании и говорит про нее с горящими глазами. С другой - не можешь ему предложить даже стажерскую вакансию из-за протухших напрочь хард-скиллов.
Да это же факин осом!
Я пришел в тестирование после работы в газетах. Там в норме каждый журналист работает дежурным по выпуску — отслеживает не только тексты по-отдельности, но и как всё смотрится вместе, нет ли явных логических ляпов по-отдельности или какой-то ненужной переклички заголовков на соседних страницах. Поначалу это очень тяжело осознать, но позже это становится нормой жизни, и не работать выпускающим становится даже тяжко, постоянно видишь что-то «не так».
Ближайший аналог этой роли в команде — ведущий демо для заказчика со стороны разработки. Он не просто собирает в эксельку перечень выполненных задач, но и показывает их работу, а для этого надо софт потыкать и ой чего всякого становится очевидно видно…
Сложная и хорошо выполненная работа! Поздравляю!
Спасибо за информацию. Сохранил в закладки
Пока читал комментарии, вспомнил, что на прошлом продукте руководство свыше тоже вводили дежурных (было это в конце 21 и начале 22гг).
Хорошего тогда ничего не произошло. Но это было мобильное приложение и там стек был android + ios + back (python). Все дежурные были только на бэке
Отсюда вопрос: как вы решили проблему с разным стеком у дежурных?
Например, как разработчик react решает проблему (И особенно разбирается в коде) бэкенда? Тоже самое наоборот.
И мобильные разработчики не становятся дежурными? Если да, то они не работают в потоке и их постоянно дёргают?))
Есть ли у вас отдельно выделенные devops и если да, то чем они занимаются при наличии дежурных?
А также вопрос, я правильно понял, что у вас несколько команд, каждая из которых работает над своим функционалом и становятся дежурными в целом по продукту?
Плюс именно в том, что они работают в парах.
Один пока объясняет друг другу - идет как бы отладка в режиме "rubber duck debugging" - и сам лучше понимает. Второй - получает ликбез и карту что где лежит. У него нет задачи досконально разбираться и что-то править. Он не фиксит баги, по крайней мере массово, он собирает логи для основной команды. И задачи им ставит на исправление. В мониторинг смотрит и понимает какие метрики что значат. А каких ему лично там не хватает?
То есть цель дежурного - получить тот самый Т-shape знаний. Подтянуть свои "белые пятна". Разработчик react смотрит где какой API торчит и какие контроллеры, и где лог пишется, спеки, тесты. В веб-аналитику может заглянуть (а обычно не смотрит!) Ему это уже полезно. Не только по своему модулю, а по всем.
Выделенные инженеры конечно есть, в Банке есть и инфраструктурщики и сетевики и безопасники и ... yaml-программисты) Смысл дежурных в том, чтобы понять где какие ключи от какой комнаты и куда идти с какими словами. Это как знакомство.
Да, несколько команд, по каждому продукту свои дежурные.
А потом он возвращается писать код и пишет его уже с оглядкой на свой опыт сопровожденца)
Несколько команд и по каждому продукту свои дежурные - наверно, тут немного о разном.
Допустим, мобильное приложение "Пятерочка". Это один продукт, но 10 команд.
Дежурный назначается на все 10 команд? Это имелось ввиду?
И на практике - это всегда back + front (2 человека) дежурных?
Что насчёт мобильщиков, они тоже дежурят?)
Отлично работает и не в коммерческой разработке. Один программист, такое же дежурство пару дней в неделю и максимальная продуктивность в оставшиеся дни.
Сейчас эту методику возьмут на вооружение разные команды. Потом попробуют увеличить срок дежурства. Потом кому-то понравится дежурить. И после из этого получится обычный такой "начальник отдела разработки" здорового человека.
Спасибо, интересный опыт, но только что-то я не очень уловил: c чего это вдруг клиенты пишут разработке? Аналитиков нет? Поддержки нет? И отчего дежурный по разработке в ответе за то какой сейчас цикл тестирования? Команда тестировщиков за что отвечает? В общем, интересно было бы поглядеть какие еще у вас там есть подразделения и как с ними налажено взаимодействие.
И, да, парное программирование это не аджайл а XP
Звучит вполне здраво. Хороший компромисс между убер-аджайлом, где все должны быть фуллстеком, и тотальным огораживанием, где никто не смотрит дальше своего носа.
Особенно правильная мысль о том, что с разработчика снимаются все продуктовые задачи. Зачастую дежурства не влючают это. Убирают часть задач, но ничего хорошего из этого не получается. Разработчик не может магическим образом тратить только 10% времени на он-колл. В итоге и продуктовые задачи буксуют, и он-колл ощущается как пустая трата времени.
Пойду питчить идею менеджеру.
Спасибо!
Да, обязательное условие в том, чтобы это было не «в нагрузку», а взамен.
Дежурный может (в терминах RFC :-) ) писать код, особенно если ему прямо невмоготу и он это хочет делать и если маленькая команда. Но он не должен (тоже RFC) это делать и не отчитывается за это на стендапе.
Он делает то, что разработчик хотел бы сделать, но ему некогда из за написания кода.
Тот, кто сказал вам про фуллстеков в аджайле - наврал =)
Команда должна уметь закрывать все бизнесовые задачи, в идеале - даже при уходе части сотрудников в отпуск\увольнение. Больше от команды в аджайле ничего не ждут, никаких фуллстеков.
А код-ревью кто делает? Только один архитектор на всех?
Как архитектор обучает других чистому коду и мониторит костыли?
"Мы имели доступ даже к источникам вроде легальной продажи данных парсинга сообщений, которые доставали всякие плагины к мессенджерам, геопозициям и т. п., и знали, что можно делать с данными о том, что Ашот опять зовёт Ивана посидеть в кальянной или Василий замечен в точке с игровыми автоматами. ТТМ на фичи был один день: с утра ставили задачу, в обед делали роллаут, вечером приходила первая аналитика." после этого все вскукареки про прекрасную разработку не стоят ничего. Вы тупо покупаете продукт слежки за пользователями, да еще и перехват сообщений в мессенджерах, аналитики недоделанные. Жаль что не могу миллион минусов поставить. Еще и хвастается этим, мол, мы сделали то, мы сделали другое, у нас даже такое есть. Яйца выеденного не стоите. Без "напарсенных данных с мессенджеров" даже аналитику нормальную не можете сделать. А потом всякие "служба поддержки сбербанка звонят".
Был такой опыт на предыдущей работе. С точки зрения передачи знаний и прокачки членов команды - отличный вариант. Минус нашего подхода - дежурный имел еще пару-тройку задач из спринта. А это уже было перебором.
Немного оффтопика. Вопрос про ОТАР - как я понимаю, это организационно-техническое и архитектурное решение? Где храните эти описания?
Я всегда был на проекте "вечным дежурным", т.е. занимался этим всем на постоянной основе много лет. Плюс еще техподдержка 3го уровня. Самая интересная работа, как по мне. И нет рутинных тасков, которые пилить надо неделями
Очень полечно, спаибо, будем внедрятт!
У меня маленький вопрос к автору статьи - саму статью я прочитал с наслаждением, сразу виден опытный в работе человек, который внедряет процессы не потому, что так делали на предыдущей работе, не потому, что вчера прочитал в PmBook, а сам благодаря опыту чувствует, чего не хватает бизнесу, команде и грамотно скрещивает обе эти цели для всеобщего блага как PO, так и команды.
Но вот все формулировки про изменение мира - я когда первый раз услышал их от PO в одной достаточно известной компании лет 10 назад, меня аж передернуло. Ну прям мы все меняем мир, если подходить с такой позиции то и клинер меняет твой мир, и массажист.
Мне ближе, и к своей работе я отношусь точно так же как любят говорить американские полицейские - я просто хорошо делаю свою работу. У них это возведено в абсолют - я делаю свою работу, мне никто не должен мешать делать хорошо свою работу, и тогда все у всех будет хорошо. Мир меняет Илон Маск, мир менял Стив Джобс, Альберт Эйнштейн (и то к науке это слабо относится, если б не он - открытие сделал бы кто-то другой, просто позже). Если б не Маск - то да, НАСА и Роскосмос бы спокойно пилили бюджеты двуручными пилами до скончания веков, если б не Джобс - ходили бы мы с кнопками и стилусами.
Но когда каждый банковский девелопер и менеджер меняет мир - ну как-то пафос этих формулировок несоизмерим с реальным вэлью меняльщика.
Есть в продуктовых командах или вне их системные аналитики?
Так вроде ж стандартная схема в крупных продуктовых компаниях, по крайней мере в западных. Могут быть ротации по разным типам дежурств, или один на все как у автора. У нас в Амазоне в моей команде обычно совмещается с онколл дежурством, из отдела в 30-40 человек обычно дежурят 3, один пейджер держит и тикеты разгребает, другой больше на всякой рутине (скрипты, дашборды, ранбуки, доки), третий (самый сеньористый, зачастую тимлид или дев менеджер) руководит онколл сменой и ответственный за внешние контакты (вплоть до разговоров с заказчиком в случае инцидентов), все вместе занимаются выкатками. В разных отделах и компаниях свои нюансы, но в целом принцип дежурств очень часто применяется, по причинам описанным автором.
Не трогайте разработчиков. Отстаньте. Просто не беспокойте