Всем привет! Меня зовут Ян, я руководитель разработки Департамента ИТ инвестиционного бизнеса Газпромбанка. Совершенно неожиданно я занял первое место на конференции Highload++ с докладом про то, как организована работа в наших командах разработки.
Очень коротко: мы пересобрали процесс разработки как таковой, постаравшись выкинуть оттуда явно кривые решения. Получилось следующее: каждые две недели в команде есть дежурный, который отвечает вообще за все внешние коммуникации. То есть он не разрабатывает, а ловит всех входящих в мессенджерах и в личке и не даёт им пробиться до самой команды. Естественно, этот дежурный знает всё происходящее и может ответить на любой вопрос, а это требует и понимания архитектуры, и знания интерфейсов, и понимания особенностей кода коллег.
В результате из простой задачи «не трогайте разработчиков» получилось сделать и очень правильное обучение (если вы дежурите, то у вас нет шансов не разбираться во всех процессах команды), и снижение техдолга (дежурный не берёт таски по фичам на спринты, но может заниматься документацией и всякими вещами в наведении порядка, до чего обычно не доходят руки), и много чего ещё. Сначала казалось, что за это мы платим снижением эффективности команды на 8–10 % (ведь мы выключаем дежурного из разработки), но на деле оказалось, что эффективность даже растёт. Есть ряд вещей, которые очень поменялись и в управлении такими командами в лучшую сторону.
Естественно, такой подход имеет кучу подводных камней и подходит далеко не всем и не каждому типу команд.
Сейчас расскажу про практический опыт.
Коротко про историю вопроса
Я поработал руками инженером в нулевых, потом был руководителем команды в интеграторе. То есть отправлял уже своих инженеров на задания. Потом я работал на стороне клиента и обсуждал задачи с руководителями команд в интеграторах. В общем, успел здорово поездить по России, попередавать и пополучать диски с ПО и 600-страничной документацией и увидеть некоторое дерьмо. Всё это время у меня крепло ощущение, что процесс разработки как таковой несколько нездоров и системно, знаете ли, несколько кривой. Но конкретизировать это ощущение я не мог.
Ну то есть сначала, когда ты инженер в нулевых, всё было просто и понятно: релиз раз в девять месяцев, есть план проекта, есть чёткие шаги, есть требования, в которые нужно уложиться. Мир был медленный и спокойный в плане внедрений. Лет так двадцать спустя вы знаете, во что это превратилось: аджайл-аджайл, гроб, кладбище, проект-менеджер. Точнее, девопс, цифровая трансформация и всё такое. В этот момент случилась одна крайне важная вещь: узкое место перестало быть в ИТ-команде.
То есть примерно до 2017 года всегда проблема была в том, что самый ограниченный ресурс — это руки разработчика. А вот позже совершенно внезапно выяснилось, что бутылочное горлышко перекочевало в продуктовую команду. И неразбериха в продуктовой команде уже прямо влияет на эффективность разработки. И лечить надо не процесс разработки как таковой, а процесс управления. Я это видел в нашем проекте розницы (мы входили тогда в топ-10 по России в онлайн-оборотах) и видел на других проектах. А потом я перешёл в банк, и там задачи встали масштабом на пару порядков больше.
Из мира сурового водопада, который мы докручивали как могли, из мира «лежим в сторону аджайла» я вдруг попал в мир внедрённого ультрааджайла 80 lvl, где настоящие аджайл-консультанты из Пивотал (которые сделали Спрингу) очаровали руководство. Если вы не представляете, что это такое, то расскажу: это когда проблема — не в деньгах. На вопрос: «Сколько вы готовы потратить на разработку?» — смело можно отвечать: «Да!» Так вот, у нас было внедрённое парное программирование. В смысле постоянно за столом сидели два разработчика. В парах работали senior или mid +. То есть смело удвойте или утройте бюджет разработки — и не особо ошибётесь. Это были не просто, как говорят эйчары, оверквалифайд-люди, а настоящие звёзды, которых каким-то чудом удалось собрать с рынка и не дать убежать от скуки из проекта, не дать спорить о нюансах реализации до бытовых травм и не дать давить ЧСВ всех окружающих. Ещё раз удвойте бюджет разработки, кстати. У нас в банке, в чёртовом банке, процесс выделения ресурсов занимал от пяти до 15 секунд. Был полноценный портал самообслуживания, где работал сервисный брокер, который создавал нужные виртуальные среды, доступы к шине и просто присылал логин-пароль к новым средам. Работало это так: разработчик говорил: «Хочу», а все остальные вроде ИБ уже постфактум оформляли все согласования и документы так, чтобы ему жилось как можно легче. У нас не было фиксированных лидеров команд — были голосования за временных. Было религиозное 100-процентное покрытие тестами, то есть это было изначально работающее TDD как таковое. Кстати, если вы за последние два предложения ещё не удваивали бюджет разработки, то сделайте это ещё раз. Но это окупалось. Мы занимались скорингом рисков — это какой кредит и кому можно выдавать. На правильном кредитовании банк за час зарабатывал больше нашего месячного бюджета. Мы имели доступ даже к источникам вроде легальной продажи данных парсинга сообщений, которые доставали всякие плагины к мессенджерам, геопозициям и т. п., и знали, что можно делать с данными о том, что Ашот опять зовёт Ивана посидеть в кальянной или Василий замечен в точке с игровыми автоматами. ТТМ на фичи был один день: с утра ставили задачу, в обед делали роллаут, вечером приходила первая аналитика. План был в том, чтобы это глянцевое экспериментальное подразделение раскатать на весь банк через всё то же парное программирование. То есть можно было удваивать команду каждые два-три месяца.
Как вы понимаете, эта история не могла закончиться хорошо.
Закончилась она оборонзаказом, а оборонзаказ требует немного других процессов.
В итоге я посмотрел и на мир, полный грязи, и на чистый мир аджайл-фантастики. И уже в Газпромбанке мы начали строить нечто среднее, потому что ни тот ни другой процесс не выглядели полностью правильными для российских условий.
Что не так с российскими условиями
Дело в том, что ультрааджайл — это классная штука для ситуации полнейшей неопределённости. И ещё он требует мандата на принятие решений у команды. Это работает в не очень большом количестве областей. Несмотря на то, что мир вокруг меняется, обычно всё же уровень неопределённости — средний. То есть должны быть понимание, где надо быть в конце года, и догадки, как это примерно сделать. Есть стратегическая цель вроде «делаем самый удобный банк», или «делаем лучший скоринг», или «давайте перекроим, к чертям, весь ИТ-ландшафт из-за ухода поставщиков, но при этом без потери функциональности».
В России раньше было три разных места ответственности:
- Принятие решений (компания-заказчик).
- Исполнение (интегратор).
- Эксплуатация (сервисная организация).
То есть если заказчик не очень хорошо обдумал требования, а интегратор кое-что сделал с особенностями, то в итоге в эксплуатацию попадает то, что через месяц выкинут. Я, конечно, утрирую, но места неэффективности вы наверняка сами видите в такой модели. Постепенно с образованием продуктовых команд всё это начало съезжаться в одно место, и в итоге ответственным становился либо ПМ, либо технический лидер команды. Конечное состояние такого процесса — «осеньоривание» команд, когда каждый отдельный человек (лично вы) отвечаете и за постановку задачи, и за исполнение, и за то, что будет дальше с кодом в проде. Если вам показалось, что я сейчас сказал «микросервис», то да, это хороший пример.
Естественно, не всем нравится принимать решения и участвовать в их выработке. Есть разработчики, которым менеджер поставил задачу, они закодили и не трогайте. Что это было и где оно используется, даже знать необязательно. Это отличие кодера от программиста — понимание задачи и эмоции по поводу того, как это меняет мир.
Как вы, возможно, знаете, управление большими проектами, по сути, пришло в разработку из строительства. То есть план-факт и водопады — это в конечном счёте переложенные модели управления от задачи «как построить большой дом» или «как построить судно». Позже пути моделей разошлись: небоскрёб в конце строительства должен оставаться небоскрёбом, а не 10 маленькими домиками, соединёнными подземными тоннелями. А вот софт может меняться. Но даже в такой консервативной отрасли, как строительство, ответственность начала концентрироваться в одной точке: в больших проектах сначала начали эксплуатировать те же компании, что построили, а потом они же стали влиять на проектную документацию.
Итак, возвращаясь к российским условиям: нам нужны были продуктовые команды, которые работают в условиях средней неопределённости и могут нести ответственность за то, что на проде. И им не всё равно, как это работает для клиента и заказчика, а не только в показателях аптайма.
И да, поскольку мы банк, наш фокус был на безопасности. То есть можно трансформировать процессы сколько угодно, говорить любые модные слова и удваивать бюджет, но безопасность должна была от этого расти.
Что мы сделали
Задача на старте выглядела так: в Газпромбанке есть кросс-функциональные самостоятельные команды. Если ими не управлять, то каждая из команд начинает решать свои локальные задачи максимально эффективно. То есть получается, что они быстро делают велосипеды — свои логи, свой мониторинг и так далее — и дальше тянут архитектуру в разные стороны.
Возможные решения:
- Можно сделать центральный управляющий орган. Тогда будет очень высокое качество решений, потому что там будут сидеть лучезарные архитекторы и озарять своим светом каждого. Но тогда это будут очень долгое принятие решений и долгие процессы: на любых внешних стыках или согласованиях происходят очень большие задержки.
- Можно взять этот архитектурный комитет и распределить его по компании, то есть посадить в каждую команду разработки по маленькому архитектору, входящему в центральный лучезарный комитет. Он будет загружен на 10–20%, и это раздует состав команды, ведь в идеале нужны безопасник, сетевик, юрист и архитектор в виде таких представителей.
- Можно распределить «маленького архитектора» по 5–10 командам, то есть он станет приходящим экспертом. Минус — эксперт не будет разбираться в продукте достаточно хорошо.
- И, наконец, четвертый способ — управление кросс-функциональными командами через поле знаний. Как магнитное поле выравнивает гвозди, так поле знаний выравнивает самостоятельные команды так, чтобы они двигались в одну сторону. Процессы выстраивания такого поля знаний описаны, но очевидная проблема в том, что мало кто доделал это до конца нормально.
Мы выбрали четвертый способ.
Поле знаний
Это когда команда сама хорошо понимает, где что лежит, сама умеет определять ситуации, когда надо ходить к архитектору, умеет пользоваться архитектурным порталом со справочниками, сама умеет разрабатывать безопасный код, знает, где общие сервисы, как работает мониторинг и так далее. Это делается через деврел. Обычно деврел — это способ найма, но у нас это способ управления. По сути, мы создаём некие альтернативные гильдии, которые дают возможность получать знания.
Но наличие гильдий вообще никак не гарантирует получения знаний, потому что ещё нужно хотеть их получить, потом где-то применить и проверить на практике. Без практики всё это вообще не имеет смысла.
И вот мы подходим к дежурствам.
Дежурства
Дежурный в команде разгребает чатики в «Телеграме», отвечает на почту (куда пишут клиенты и заказчики), берёт L2-заявки из ITSM и пользуется при этом собственной админкой, смотрит в журналы, в Кибану, в Графану, пишет техдокументацию и ОТАР (это кирпич архитектуры). К слову, в банке ОТАР был проблемой: в департаменте был один человек, который умеет писать, а он был нужен на каждый чих. Нам надоело стоять в очереди, и тогда стали писать все, кто умеет это делать. Не очень хорошо, но умеет. И выяснилось, что прочитать ман несложно, а отдать немного криво оформленный ОТАР на ревью лучезарному архитектору лучше, чем уговаривать его писать с нуля.
Ещё дежурный занимается выкладкой релизов. Он же владеет планом всех работ. Он знает, что и в каком релизе, какая сессия тестирования, какой статус тестов. Он может лучше всех ответить тем, у кого что-то поломалось в соседних командах.
Дежурных на продуктовую команду нужно два: один — опытный и самодостаточный, а второй — молодой (например, джун). Опытный ничего не делает руками, кроме случаев ЧП, он ревьюит молодого или объясняет ему, как и что сделать. То есть это обучение всему тому, что происходит в команде.
Дежурный защищает команду от лишних встреч и диалогов в мессенджерах. В постковидную эпоху встречи стали очень дешёвыми технологически, но дорогими интеллектуально. Менеджер может лёгким движением руки на час отвлечь разработчиков просто потому, что ему было лень конкретно сформулировать вопрос. С дежурным такой финт не пройдёт. Отвлечений становится минимум, а каждое из них — это потенциальный выход из потока, то есть 15 минут на выехать обратно из контекста отвлечения и 15 минут — на восстановление контекста решаемого вопроса.
Если менеджеру нужен ответ — вот дежурный. Он прекрасно проконсультирует, у него больше всего информации в команде. В итоге внутренний заказчик сам начинает ходить именно к дежурным.
Как вводили
Начали с инвентаризации вещей, которые отвлекают разработчиков.
Просто выписывали две недели всё то, что бесит.
В нашем случае где-то бесили лишние встречи, где-то — стук-постуки менеджеров в «Телеграм», где-то — тупые ручные операции по выкладке или в сервис деске и так далее. Начали мягко и аккуратно снижать долю каждого. Убрали из ближайших спринтов часть продуктовых задач, написали куски внутренней админки для автоматизации частых рутинных запросов. Плавно ввели дежурства для документирования: за разработчиком фичи Конфлу причёсывает именно дежурный. Постмортемы стал писать дежурный. В итоге он делает то, чего хочет программист, но ему некогда. И поскольку он тоже программист, то любая повторяющаяся задача приводит к замене на скрипт.
В больших продуктовых командах дежурных может быть больше двух, в малых дежурные могут не полностью отвлекаться от кода, но программировать всегда нужно по желанию, то есть без обязанностей и тасков. Как правило, иногда дежурный добавляет автоматизацию логов или что-то ещё, но не бизнес-задачи. На уровне спринта разработки у него нет. И не должен. И не отчитывается за это. Если дежурный недоутилизирует своё время — он чинит баги. Это оказалось наиболее удобной формой «уборки» в малых командах.
Дежурные делают те же сетевые схемы, архитектуру, оформительскую часть. В моих командах тимлиды тоже дежурят: пока тимлид на дежурстве, кто-то другой делает его работу. Это возможность для роста или «второго взгляда» на неэффективности. Правда, перед особо важным релизом дежурство не ставится на лидов.
Стендапы происходят так: разработчики по очереди рассказывают про свои фичи и блокеры, если они есть. Дежурный отчитывается примерно так:
— Вчера было 3 000 заказов, сегодня — 3 500. А ещё у вас три бага, один из которых — повторный, а тут узкое место, развлекайтесь, вот описанная таска. И ещё я задолбался заявку обновлять руками, и сделайте мне удобную страницу, поставил в беклог.
Деплои шли так:
- Фаза 0 — senior делает. Выкладки по выходным.
- Фаза 1 — пришёл админ с книгами и написал скрипт. Оно стало быстрее, возможно, чаще.
- Фаза 2 — поговорили с архитектором и сделали обновление без даунтайма, но только архитекторы и senior знают, где какие костыли.
- Фаза 3 — в команде передают деплой друг другу, исчезает слепое пятно. Процесс выпрямляется в плане понимания разработчиками своего продукта. Разработчики по опыту поддержки понимают термины, задачи, процессы пользователей, лучше принимают непонятные странные задачи от бизнеса и превращают их в понятные.
Когда так делать НЕ надо
Каждый человек в команде либо склонен к пресловутому аджайловскому Т-shape, либо не садится на борт команды с дежурствами. Это значит, что на собеседованиях нужен отбор именно таких людей. Я думал, что это отсечёт около половины кандидатов, но потом, когда разработчики распробовали, как именно дежурства работают, появился гениальный довод: «А было такое, что ты что-то хотел доделать, но всё время руки не доходили?» У каждого такое есть, и много. Дежурство стало передышкой на наведение порядка и ещё решило задачу смены деятельности, то есть переключения потока. Закончилось тем, что многие даже стали ждать его почти так же, как отпуска. Итоговый отказ по причине «не хочет дежурить» — около 10–20 % в зависимости от команды.
Естественно, дежурство подходит только для монопродуктовых команд. Если вы делаете много разных продуктов внутри конвейера, то метод никак не применим.
Софт-скиллы не нужны. Даже если на дежурство выйдет токсик, которого на дух не переносят в соседней команде, то всегда есть второй дежурный, который может урегулировать ситуацию. У нас проблем с софт-скиллами не было. Это же спасает от задач, которые бесят кого-то одного.
Часто дежурство само по себе начинается с ультракрутой поддержки внутреннего заказчика или клиента. Если вам плевать на следующее звено — процесс вам не подойдёт. Нам не плевать, мы не можем на федеральное казначейство завести тикет с отпиской «Ответим в течение трёх рабочих дней». Если вам звонят из аппарата Президента, то они не будут оставлять заявку в чате.
Что ещё узнали за время дежурств
У команд появилось очень чёткое системное понимание, что же они делают для клиента. Потому что, если прилетает задача «кнопки перекрасить», фронт их просто перекрасит — и всё. А фронт, который дежурил, будет понимать, зачем это нужно, и может предложить решение лучше, если пользователь чего-то не понимает. Бекэндер на дежурстве поймёт, где API, а где какие токены. Дежурство стало интерфейсом онбординга, там можно осмотреть соседский код.
Дежурный следит, чтобы не было повторной работы. Сначала это создало большие списки задач вверх и вниз (дежурный может спустить задачу на автоматизацию какого-то отчёта в команду или поднять вверх через инструкцию на КЦ, архитектора и т. п.).
Дежурство снизило потребность в обучении. В командах не осталось тайных знаний, которыми владеет конкретный человек. Каждый знает всё. Отпуск, болезнь, замена человека — не беда. Слова «фактор автобуса» я слышу только на конференциях.
Сначала боялись, что неопытные дежурные уронят прод при деплое. Но оказалось, что парадигма архитектуры в том, чтобы прод падал безопасно, если отключается какой-то кусок инфраструктуры. То есть нам даже не пришлось этого внедрять, это сразу было «из коробки». Но мы на всякий случай сделали приоритеты деплоев и на ответственные или сложные выделяем рядом опытного товарища.
Пришлось делать все доступы всем членам команды. ИБ были от этого в лёгкой панике, но пришли к той же парадигме: защищать нужно не голову человека от данных, а данные от компрометации. Единственный компромиссный момент — они выделили VIP-клиентов, чьи проводки вообще никто никогда не должен видеть, их видят только сотрудники с определённым уровнем доступа.
Дежурных может захлестнуть волной обращений от клиентов. Тогда они говорят: «Команда, откладываем, помогаем», и все знают, что делать, они дежурили. Но это случается довольно редко. Наша цель — чтобы у дежурного не было постоянной работы. Он умеет делать всё — от доков до релизов, но более-менее отдыхает.
Исчезла проблема со странным аттрактором. В разработке есть такая неявная вещь — не дай вам Бог сделать что-то качественно: будете привязаны к этому тикету всю карьеру. Написали хорошо отчётный модуль — теперь менеджеры идут только к вам, потому что получат такой же быстрее и качественнее. В итоге вы становитесь узким специалистом по отчётным модулям синего цвета. Дежурство очень хорошо расширяет кругозор и не даёт запасть на эти аттракторы.
Улучшился ТТМ (мы не ждали этого быстро, но случилось). Дежурства вынудили уйти от тайных знаний и регламентов в пользу автоматизации. Каждый просто вынужден делать так, чтобы понять и запустить мог каждый в команде. А потом это всё ещё посмотрят 10 человек, так что скрипт точно будет хороший. К слову, сам по себе ТТМ ничего не значит, но высокий ТТМ — индикатор какой-то проблемы. Неважно, какие фичи за день можно выложить, но пока вы добьётесь релиза за один день — узнаете и архитектуру, и бекапы, и откаты, и АБ-тесты, и много всего остального, включая lowcode и nocode. Проверите процессы онбординга и создадите шаблоны новых проектов.
Из неожиданного ещё оказалось, что для многих дежурство стало такой демоверсией работы архитектором. Многие разработчики считают, что архитектор — это уровень после senior, но это не так. Вообще-то это может быть достаточно скучная для многих работа по оформлению стандартов. В дежурстве можно почувствовать и понять, ваше это или нет.
Ну и, конечно, дежурство двигает отношение к коду и косякам от «код мой» к «код наш». Косяки сами собой становятся общими, а не лично Васи, анализируется корневая причина, а не то, кто последним трогал код, и так далее. Это значит, что команда ещё и сама фильтрует тех, кто ей подходит.
В общем, это работает. У метода — куча ограничений, его сложно внедрять, но это работает. Я не уверен, что мы сделали лучшее из возможного, что это вообще оптимально для решения задач разработки, но чувствую, что в нашей предметной области процесс разработки перестал быть кривым.
Комментарии (65)
serjeant
21.07.2022 10:54+3Спасибо за статью. Было очень интересно познакомиться с вашим подходом. Почерпнул для себя много полезного.
MonkAlex
21.07.2022 10:56+11Много текста, но так и не понял, есть краткое TLDR чем отличается от существующих ролей тимлида, менеджера, руководителя (проекта) и прочего? Потому что закрытие команды от внешних раздражителей они обычно и выполняли всю жизнь.
yanwork Автор
21.07.2022 10:58+4Краткое - команда Dev по очереди, по расписанию, занимается Ops. А именно — day-2 operations. Релизы, консультации, все дела.
За счёт этого они лучше понимают жизнь админа, пишут для него (для себя!) более чистый поддерживаемый код и помогают коллегам защищать «поток».
MonkAlex
21.07.2022 11:27+7Звучит некомфортно. Пошел читать статью.
Дочитал то дежурства. Непонятные моменты:
Упомянуто, что вы выбрали 5 вариант, но вариантов всего 4. Какой то выпал в редактуре?
Чем плох предыдущий вариант (3 из 4), с приходящим экспертом? Эксперт, на то и эксперт, что разбирается в своей теме, достаточно компетентен, чтобы быстро включиться в любой вопрос. Плюс, у него есть понимание, как уже сделано или делается в соседних командах, т.к. их он тоже консультирует по этим темам.
Упомянуты devrel и гильдии, но по статье непонятно, к чему их упомянули. Devrel обычно упоминается как что-то маркетинговое и для привлечения внимания. Чем оно поможет тут?
yanwork Автор
21.07.2022 11:40+2Вариант с приходящим экспертом хорош тем, что он принимает самые умные решения. А плох он тем, что эксперт не "живет" продуктом. Он "живет" темой своей экспертизы. То есть он делает качественно, но не для себя. Это вполне рабочий компромисс, так часто делают в корпорациях. И эта схема хорошо подходит для Юристов, например.
А вот эксперта по архитектуре написания сервисов приглашать смысла уже меньше - эти знания нужны часто, много, в сложных запросах - и приходится идти по трудному пути и "подсаживать" знания прямо в головы разработчиков. Чтобы они сами знали что тут где лежит и по каким вопросам реально все же нужно вызывать эксперта.
Гильдии как инструмент обмена знаниями. Конечная цель в том, чтобы все знания, необходимые для выпуска продукта были доступны само-организованной команде без необходимости куда-то долго ходить. DevRel-ы у нас занимаются не только HR-брендом (найм) но и организуют внутренние сообщества, чтобы разработчики сговаривались между собой. Так повелось)
MonkAlex
21.07.2022 11:47+1А плох он тем, что эксперт не "живет" продуктом
Почему не живет? Условно, у вас большой проект в банке. Эксперт что, живет вне продукта? Не занимается продуктом? Просто ходит и консультирует остальных?
Я подразумевал, что эксперт - сотрудник на проекте. Просто он разбирается лучше остальных (по любым причинам, у него больше опыта, он тратит на это доп время, ещё что-то -- это его специализация).
А вот эксперта по архитектуре написания сервисов приглашать смысла уже меньше - эти знания нужны часто, много, в сложных запросах - и приходится идти по трудному пути и "подсаживать" знания прямо в головы разработчиков. Чтобы они сами знали что тут где лежит и по каким вопросам реально все же нужно вызывать эксперта.
А с сервисами звучит странно. Основная идея сервисов - упрощение. Каждый сервис должен быть максимально простым и понятным, чтобы его можно было заменить в случае чего, чтобы разработчиков новых было подключать легко и тому подобное. Если экспертиза при рядовой разработке нужна часто - что-то пошло не так. Либо оверинжениринг, либо разработчики слабоваты для таких задач (каких таких - сложно сказать, потом что типовые бизнес задачи покрываются разными вариантами CRUD операций на 80%).
Да, я понимаю, что на словах этот момент можно обсуждать долго и бессмысленно. Просто у меня большие сомнения, что команда достаточно компетентна в вопросах безопасности например, чисто на основании дежурств. Это так не работает =)
yanwork Автор
21.07.2022 11:49+3Она достаточно компетентна, чтобы УЖЕ понимать, где она некомпетентна.
Сойдёмся на этом. То есть какой то минимальный ликбез это даёт все равно.
MonkAlex
21.07.2022 11:36+3И по остальному тексту - в scrum например выделяют всего 3 роли - PO, Scrum master и developers. И вопросы "не мешайте разработчику работать", общение с клиентами вида государства или крупных внешних заказчиков на себя берёт PO (ему оно по задачам положено, к слову). А вопросы разработки, релизов, и всей технарской кухни берет на себя команда разработки. Как они сами решат внутри, это же agile, гибкость. Где то инициативного сотрудника, где то будет сменная рутина, кому как удобнее.
И имхо, ваш вариант получился сложным. Перегруз разработчиков кучей всего.
ПС: некоторые вещи, которые вы приносите через дежурства (понимание предметки, понимание болей пользователя) имхо должно и без дежурств работать. Варианты тут разные, сильно зависит от области и разработчиков. PO когда ставит задачу, должен её ставить именно со стороны клиента\пользователя, команда должна изначально знать что и зачем она делает. Иное звучит плохо =)
usego
21.07.2022 12:00+2В реалиях жизни такие команды обычно распадаются (а чаще строятся) на определённые роли с зонами ответственности и со всеми вытекающими побочками от сакральных знаний до отмашек "это не моё" и "а у меня работает". Описаный подход весьма интересен и, судя по описанному, свои задачи решает, вот только мало кто такое себе может позволить.
MonkAlex
21.07.2022 12:09Не понял, если честно.
Сакральные знания - это экспертиза? Всмысле, мы пишем код по предметке годами, мы в ней разбираемся, это ожидаемо и выгодно для менеджера который ставит нам задачи.
А отмашки вида "не мое" - это странный аргумент. С человеком надо конкретным работать, который считает это нормальным ответом на вопросы.
usego
21.07.2022 12:15Ну к примеру условный отчёт из статьи, который пишет гуру отчётов и все проблемы по эксплуатации отчёта прилетают к нему напрямую, а остальные даже не включают голову, где KPI этого отчёта надо смотреть и как вообще он работает. Т.е. в команде естественным образом создаются круги комфорта из которых мало кто хочет вылезать. Будучи регулярным ОПСом и L2 саппортом по отчёту хочешь не хочешь, голову в эту сторону приходится включать. Тем самым происходит шаринг знаний и круг комфорта расширяется вокруг всего проекта в целом, а не только избранной песочницы.
inkelyad
21.07.2022 12:25+4а остальные даже не включают голову, где KPI этого отчёта надо смотреть и как вообще он работает.
А им дают время на 'включать голову' по поводу этого отчета?
Пока вся статья выглядит как 'мы дали время разработчикам почитать весь остальной код и доделать то, на что обычно "нет времени"'.
Вероятно, без дежурства, а с каким-нибудь другими способами указания на 'тайное знание' и проверки 'теперь это знание явное' -- могло получиться еще лучше.
MonkAlex
21.07.2022 12:33+1Слушайте, ну это куча разных вариантов.
Кто в команде? Если в команде десяток бэк разработчиков, каждый из которых способен написать отчет и пишет разные отчеты (т.е. у каждого есть по несколько отчетов, за которые он в первую очередь отвечает) - то они взаимозаменяемы вполне, пусть компетенции в конкретном отчете у них и различаются.
Если в команде 1-2 спеца, которые отчеты делают и ничего более - каким образом фронт в команде, назначенный дежурным, станет разбираться хоть на каком то полезном уровне?
Если отчет сложный бизнесово (не просто выгрузка таблички), то отчет прекрасно знают аналитик и тестировщик помимо разработчика.
Обсуждать этот вопрос можно с тысячи разных сторон. Если по отчету часто прилетают вопросы - может отчет требует переработки? Может он слишком сложный для потребителя?
kiaplayer
21.07.2022 11:07+5Спасибо за статью.
Если позволите, несколько вопросов:
1) Как я понял, вам в любом случае требуются overqualified-сотрудники, которые "и швец, и жнец, и на дуде игрец" (погружены в бизнес-область, в архитектуру, умеют работать с клиентами, реагируют на инциденты). В рамках одного проекта такие люди могут очень быстро соскучиться. Как решаете вопрос удержания?
2) Как выстроен процесс работы для тех, кто отказался от дежурств (вы упоминаете цифру 10-20%)?
3) По поводу VIP-клиентов не до конца понятно написано. Если там свой уровень доступа, то для таких клиентов нужен свой отдельный дежурный с таким доступом?
yanwork Автор
21.07.2022 11:11+31) Да, и именно таких мы стараемся набирать в продуктовые команды с самого начала. Мы на первом собеседовании сейчас проговариваем эту практику как раз как решение от "соскучивания". Ведь одно то же подряд делать (пилить год свой отчет) может быть скучно - а заниматься целиком целым продуктом и самому решать куда направить свой взор внимательный - как раз интересно.
2) Часть сотрудников не хотят делать какие-то конкретные вещи (ну, например, некоторые из react программистов ну совсем не хотят жать кнопку в ТимСити по поставке релиза). В этом случае учитываем предпочтения при сборе пар. То есть в пару берётся человек который хочет и любит делать конкретно этот кусок.
3) Там более сложная система, она точно выходит за рамки статьи. Основной тезис тут - что мы заранее знаем о таком вопросе и можем заранее спроектировать систему. Например по принципу двух "ключей" как фильмах.
Green21
21.07.2022 19:43Насчет первого пункта. У нас, например, есть отдел эксплуатации, который и занимается решением абсолютно всех задач (швец, певец, на дуде игрец и не только). Главная задача эксплуатации - отладка и поиск ошибок. Причем нужно разбираться в большом технологическом стеке (Python, NodeJS, NestJS, VueJS, SQL, PL/SQL, RabbitMQ, RESTFull API). Но самое страшное - это аналитика.
Думаю, что именно попытки прокачивать себя во всех этих технологиях и не дают соскучиться. А вот развитие (developers), которые целыми днями кодят ток на одном языке соскучиться могут намного быстрее.
amarao
21.07.2022 11:09+5А чем администрация президента важнее любого другого заказчика?
yanwork Автор
21.07.2022 11:28+2Привет! Не знаю.
Основная идея тут в том, что подключив команду разработки к поддержке, мы в целом даем более высокий уровень поддержки клиентам, а разработчикам - высокий уровень понимания продукта. Реального опыта клиентов по взаимодействию с нашими сервисами.И там, где качество поддержки реально важно, а количество обращений не слишком высокое - метод показал себя довольно успешно. То есть high-risk high-reward окружение.
Если же речь о более массовых сегментах, тогда нужно сосредоточиться на том, чтобы дежурный старался не делать одну и ту же работу несколько раз. Первый - сделал, второй - задумался, третий - написал инструкцию, далее - автоматизировали.
Надеюсь, помог ответом понять суть.
Gryphon88
21.07.2022 12:01+3Спасибо за статью, интересный рецепт, хоть и дорогой и сложный. Главный смущающий момент: думал, что обязанность закрывать своим телом команду от непрофиля и отвлечений РО, РМ или лид.
MaxLK
21.07.2022 13:57+4мне показалось что за термином "высокий уровень понимания продукта " скрывается желание содрать с людей три шкуры за один оклад и не нанимать профильных специалистов заставляя имеющихся крутиться волчком на двух стульях? а то "назначается дневальный" наводит именно на такие мысли, потому что иначе просто нанимается специалист закрывающий задачу.
avelor
21.07.2022 14:36+3Давно ещё один CTO, родом из программистов, говорил - если разработчик не общается с бизнесом и с заказчиком - то это в лучшем случае кодировщик. Ну и действительно, есть такое явление - программисты не понимают продукт, цели, задачи, максимум доходят user story, и то не всегда, сидят, кодируют. В итоге продукт выходит немного оторванный от желания (см боянистую картинку про качели).
Естественно, в ряде случаев хватает кодировщиков, да и построить вовлечённую команду сложно. «Лайфхак» с дежурствами занятный
MaxLK
21.07.2022 17:12+2Тут ведь какая штука? По этому Лайфхаку специалист две недели вместо своей работы сидит на телефоне и рассказывает пользователям на какую кнопочку кликать. Это либо работодатель платит оклад программиста работнику саппорта, либо на должность программистов набрали специалистов с низкой квалификацией и их зарплата "отбивается" и на телефоне. Ведь было запланировано, что заданный объем работ данная команда выполнит в установленный срок. Из команды выкинули одного человека, значит либо работа будет выполнена позже, либо за него кто-то впахивает. А то, что Вы назвали "общаться с бизнесом и заказчиком" это, на мой взгляд, немного другое. Как Вы себе представляете работу, например, Гугла или Микрософта, если бы все разработчики пошли общаться с заказчиками? Или там сплошь все "бездарные кодеры"?
Описанная "оптимизация" по моему опыту - детище менеджеров. Начальник обосновал свою премию проведенной оптимизацией и публикациями. А как там на самом деле работа работается - никого особо и не интересует, главное что отчеты красивые написаны и показаны. Как новый начальник приходит, так тут же что-то "оптимизируется". Потом оптимизация затихает - загубить на корню производство и развалить налаженные процессы никто не хочет.yanwork Автор
21.07.2022 17:17+4Если есть такие сомнения, а они есть (и часто!), тогда начать можно следующего алгоритма. Как говорится, следите за руками.
Мы не добавляем новой работы разработчикам, и не убираем существующую. А:определяем какая деятельность больше всего, делаясь ИМИ отвлекает их от написания кода
начинаем ровно эти активности делать не рандомно, затрагивая всех разработчиков, а нести по расписанию. То есть не добавлять им сначала новых активностей "общаться с пользователями попивая кофе", а просто взять например поддержку сессий тестирования или еще что-то, что обычно отвлекает.
Объем работы не увеличивается, количество отвлечений снижается
...
PROFIT!
Таким образом можно начать, а дальше когда вы увидите подходит вам в общем методика или нет, добавлять туда и другие активности типа day-2-operations, поиск узких мест, обновление ОТАРов и сетевых схем, мониторинг и прочее.
avelor
21.07.2022 18:24+1потенциально - программист пока сидит на телефоне, немного переключает контекст и может потенциально закрывать техдолг. вместо закапывания в непосредственную работу или игр в кикер\приставку, так что в теории тут можно даже наблюдать рост продуктивности при том же штате. ну и заодно повышается экспертиза саппорта (ведь по сути с 3-4 линии человек переходит на 2 и может чем-то поделиться), а может заодно и на продактах выйдет экономия :)
про гугл-микрософт там ниже скинули ссылку, да и как раз в гугле-майкрософте и прочем сбере ИМХО больше распространена практика "сиди и кодируй". я к слову не умаляю "кодировщиков" - если упростить, это тот кто превращает ТЗ в код. вспоминая того СТО - в его понимании кодер - это ремесленник, разработчик - уже должность более творческая, где уже рядом архитектура и дизайн продукта.
ну и конечно же, описанная в статье "оптимизация" явно подойдёт не всем (компаниям, командам). прям до детища эффективных менеджеров не хватает kpi, sla и прочих метрик :D лично мне концепт чем-то глянулся, внедрять его я конечно не буду:)
sshmakov
21.07.2022 14:19+1Супер. Дежурства - отличная и оригинальная идея.
Но я хочу узнать про "поле знаний". Оно только через дежурства достигается? Как, к примеру, выравниваются архитектурные решения в различных командах?
YaDr
21.07.2022 14:41+3Очень напомнило путь гугла, описанный в https://sre.google/books/ . Почитайте, там есть моменты которые вы еще не прошли и рецепты по их устранению.
Yago
21.07.2022 14:42+8Встречался с подобным. На себе ощущал все прелести и недостатки подобных дежурств.
Из плюсов можно отметить:
1) Погружение в домен происходит быстрее. Но здесь важно понимать, что нельзя доверить дежурство человеку с малыи погружением (только если в качестве наблюдающего за работой сеньера), иначе будет отталкивающий эффект.
2) На команду в целом снижается нагрузка и наплывы вопросов (запросов) от посторонних людей
3) У людей по ту сторону разработки появляются единые каналы решения проблем, и не уходит много времени на понимание, куда именно обращаться за помощью по вопросам разработки.
Из минусов:
1) Сам дежурный, как правило, в состоянии пофиксить только самые легкие баги и ответить на простейшие вопросы. Обычно дежурный все равно редиректит поступившие обращения к более погруженным сотрудникам, т.к. на том конце провода всегда все срочно. Способных покрыть хотя бы 50% запросов дежурных я не встречал. У схемы огромный порог вхождения, который только порождает доп. bus factor на ключевых людей.
2) Передача дел между дежурными почти не осуществляется, и проблемы, которые не решились в смены дежурств, переходят другим дежурным, которые либо отвлекают предыдущих дежурных, чтобы понять статус и ход мыслей, либо просто начинают решение проблемы с чистого листа. Видел, как некоторые вопросы в результате подвисали на месяца, и каждый новый дежурный добавлял по паре сообщений в тред, который в результате невозможно было читать новому человеку.
3) Практика "релизы + техподдержка + дебаг + техдолг", как правило, не работает в полной мере. Потому что иногда какой-то из этих пунктов способен просто перекрыть остальные на все время дежурства (сложные релизы с конфликтами, под видом простенького бага оказался слоняра, на фикс которого ушло все время, срочные вопросы от клиентов или техподдержки, которые постоянно отвлекали от остальных обязанностей, недодекомпозированный техдолг, который потребовал много действий). Слишком большая нагрузка на человека, и слишком много неизвестных в планировании дежурства, т.к. в любой момент дежурство может потребовать переключения.
В целом, я так и не ощутил на себе, как можно сделать этот процесс не породив суперменов-разработчиков, которые будут на себе тащить многое, выходя за рамки своих базовых обязанностей. Это очень сильно увеличивает разрыв между старичками и новичками в команде, иногда даже порождая дедовщину. Поэтому соглашусь с комментариями выше, в которых писалось про то, что дежурства - это отдельный процесс, а погружение в домен, онбоардинги и различные повышения квалификаций - совсем другой, и они невзаимозаменяемы.
yanwork Автор
21.07.2022 14:48+1Интересно! А у вас дежурство было одиночное или в парах? То есть было с кем в процессе обсудить и учиться?
и какая была «длительность смены» и было ли не обязательно в это время, собственно, код писать? Или просто «в нагрузку»?
Yago
21.07.2022 14:55+3Дежурство было в разрезе команды. Сами команды делились по продуктам и стеку. Каждую неделю выделялся разработчик. До парного дежурства дело не доходило, обычно "пара" была как раз в виде тимлида или старших разработчиков, которые делали тот или иной функционал. Чаще всего лид.
Разработчик освобождался от своих непосредственных задач, и занимался только дежурствами с описанным регламентом. Смены были недельными, примерно раз в 1.5-2 месяца.
Gryphon88
21.07.2022 14:57+1Предложенная схема парного дежурства, когда младший делает, а старший контролирует, не нова, но хороша. Насколько я помню, путь примерно как в компартии Италии 50х - свежеобученных товарищей из тамошнего аналога комсомола отправляли помощниками не на низовые должности, а наоборот, поближе к верхушке и принятию решений. По мере набора опыта во время стажировки молодёжь не поднималась по должностям, а а наоборот, постепенно перемещалась от точки принятия решений к точке исполнения.
yanwork Автор
21.07.2022 14:59+2Чтобы получилось «обучение через делание», да. Причём по довольно широкой области и в рабочее время. Как подмастерье.
Mishootk
21.07.2022 18:06+1Если делать дежурства парными по две недели, а каждого в паре сместить на неделю, что в паре дежурных каждую неделю меняется один человек, контекст не теряется, дела передаются без стрессов.
yanwork Автор
21.07.2022 18:15+2Кстати, интересное решение. Мы так делали когда-то давно, сейчас не делаем. Убрали просто потому что со временем вся команда обучилась и так было проще и удобнее формировать графики.
Сейчас есть приток новых участников и это хорошая идея вернуться к такому "перекрытию". Спасибо за подсказку!
Yago
21.07.2022 18:20-1Тогда идет прямой конфликт интересов разработчиков в разрезе того, чем они занимаются на работе.
Дежурства - навязанная сверху инициатива начальства, которая не фигурирует в основных обязанностях при заключении договоров. И если разработчик будет посвящать этому много времени, в голове рождается вопрос "а тем ли я занимаюсь, и что получаю взамен?". И ответы на эти вопросы в пользу компании рождаются лишь у людей с горизонтальными обязанностями (лиды, пм, и т.д.).
Обычный разработчик в этом плане получит замедление роста как программиста (о котором его спросят на собеседованиях с более высокой зп), но получит горизонтальный рост внутри компании.
Конфликтов не будет только в том случае, где разработчиков холят и лелеют, десятилетиями учитывая их профессиональные интересы. Судя по современным тенденциям, таких компаний везде все меньше и меньше.
Если речь идет о таких сроках дежурства, скорее всего требуется отдельная должность.
yanwork Автор
21.07.2022 18:52+1Самое правильное, на мой взгляд, что мы можем тут предложить или сделать — это дать выбор самому разработчику и проговорить все эти моменты заранее. Ещё на входном интервью.
Отобрать тех, кому интересен именно такой подход. Кому нужен Т-shape, а не I, причём когда дают растить его в рабочее время, а не требуют учиться когда-то в личное.
Действительно, может быть такой эффект, что специализация будет ниже, а значит если цель разработчика - прохождение тех интервью на рынке, где ценится именно I - ему будет сложнее.
Главное тут прямо и честно все проговорить на вхоже и убедиться что цели совпадают, и что разработчик следует за своими целями, просто с помощью и ресурсами компании. Принося пользу обоим.
nikolas78
21.07.2022 19:25+1Дежурный получает две вещи, которые всегда спрашивают на собеседованиях: софт-скилы и погружение в предметную область (умение переносить задачи из нее в код).
Yago
21.07.2022 19:28+1И какова текучка с таким подходом? Просто, сколько не видел продуктовых компаний, которые изрядно проповедовали T-shape и различные мантры в духе "наш разработчик - нечто большее, чем просто кодер", там в основном лиды это все активно слушали, и им это было действительно полезно и интересно. Рядовые разработчики же либо холодно игнорировали такие посылы, либо открыто конфликтовали с наводящими запросами на тему должностных обязанностей и перенагрузки на одного человека. Как следствие, из-за несбалансированной нагрузки некоторые либо сидели без отпусков, либо выгорали, либо уходили в компании c I, награждая T-компанию постоянной текучкой кадров.
Когда человек выходит на рынок труда, от его T мало чего остается. Потому что вся квалификация становится очень специфичной в разрезе компании. В терминальных стадиях я встречал человека, которого отправляли на различные продуктовые командировки и конференции, хотя тот просто корпоративный сайт поддерживать нанимался. В итоге, человек забывал, что такое полиморфизм, зато говорил про то, как он помимо сайта еще 90 дел не относящихся к программированию делал. С одной стороны, видишь человека, который был предан компании и говорит про нее с горящими глазами. С другой - не можешь ему предложить даже стажерскую вакансию из-за протухших напрочь хард-скиллов.
astenix
21.07.2022 15:09+6Да это же факин осом!
Я пришел в тестирование после работы в газетах. Там в норме каждый журналист работает дежурным по выпуску — отслеживает не только тексты по-отдельности, но и как всё смотрится вместе, нет ли явных логических ляпов по-отдельности или какой-то ненужной переклички заголовков на соседних страницах. Поначалу это очень тяжело осознать, но позже это становится нормой жизни, и не работать выпускающим становится даже тяжко, постоянно видишь что-то «не так».
Ближайший аналог этой роли в команде — ведущий демо для заказчика со стороны разработки. Он не просто собирает в эксельку перечень выполненных задач, но и показывает их работу, а для этого надо софт потыкать и ой чего всякого становится очевидно видно…
ivashkaper
21.07.2022 16:01+1Сложная и хорошо выполненная работа! Поздравляю!
Спасибо за информацию. Сохранил в закладки
Пока читал комментарии, вспомнил, что на прошлом продукте руководство свыше тоже вводили дежурных (было это в конце 21 и начале 22гг).
Хорошего тогда ничего не произошло. Но это было мобильное приложение и там стек был android + ios + back (python). Все дежурные были только на бэке
Отсюда вопрос: как вы решили проблему с разным стеком у дежурных?
Например, как разработчик react решает проблему (И особенно разбирается в коде) бэкенда? Тоже самое наоборот.
И мобильные разработчики не становятся дежурными? Если да, то они не работают в потоке и их постоянно дёргают?))
Есть ли у вас отдельно выделенные devops и если да, то чем они занимаются при наличии дежурных?
А также вопрос, я правильно понял, что у вас несколько команд, каждая из которых работает над своим функционалом и становятся дежурными в целом по продукту?
yanwork Автор
21.07.2022 16:06+1Плюс именно в том, что они работают в парах.
Один пока объясняет друг другу - идет как бы отладка в режиме "rubber duck debugging" - и сам лучше понимает. Второй - получает ликбез и карту что где лежит. У него нет задачи досконально разбираться и что-то править. Он не фиксит баги, по крайней мере массово, он собирает логи для основной команды. И задачи им ставит на исправление. В мониторинг смотрит и понимает какие метрики что значат. А каких ему лично там не хватает?То есть цель дежурного - получить тот самый Т-shape знаний. Подтянуть свои "белые пятна". Разработчик react смотрит где какой API торчит и какие контроллеры, и где лог пишется, спеки, тесты. В веб-аналитику может заглянуть (а обычно не смотрит!) Ему это уже полезно. Не только по своему модулю, а по всем.
Выделенные инженеры конечно есть, в Банке есть и инфраструктурщики и сетевики и безопасники и ... yaml-программисты) Смысл дежурных в том, чтобы понять где какие ключи от какой комнаты и куда идти с какими словами. Это как знакомство.
Да, несколько команд, по каждому продукту свои дежурные.
А потом он возвращается писать код и пишет его уже с оглядкой на свой опыт сопровожденца)
ivashkaper
21.07.2022 16:18Несколько команд и по каждому продукту свои дежурные - наверно, тут немного о разном.
Допустим, мобильное приложение "Пятерочка". Это один продукт, но 10 команд.
Дежурный назначается на все 10 команд? Это имелось ввиду?
И на практике - это всегда back + front (2 человека) дежурных?
Что насчёт мобильщиков, они тоже дежурят?)
1x1
21.07.2022 17:50+2Отлично работает и не в коммерческой разработке. Один программист, такое же дежурство пару дней в неделю и максимальная продуктивность в оставшиеся дни.
altervision
21.07.2022 19:09+2Сейчас эту методику возьмут на вооружение разные команды. Потом попробуют увеличить срок дежурства. Потом кому-то понравится дежурить. И после из этого получится обычный такой "начальник отдела разработки" здорового человека.
Gryphon88
22.07.2022 12:12Да пусть получится что угодно, лишь бы здорового человека! И гибкие методологии можно приготовить грамотно, и водопад с V-моделью, главное дорасти и осмысленно работать. В карго-культ что угодно превратить можно, как и убить несистемными или не поддерживаемыми командой нововведениями.
nikolas78
21.07.2022 19:09+2Любая схема менеджмента всегда отражает тип мышления руководителя компании. Поэтому я думаю, что нет одной идеальной схемы для всех (даже если взять одно и тоже продуктовое задание)
acordell
21.07.2022 23:04+1Спасибо, интересный опыт, но только что-то я не очень уловил: c чего это вдруг клиенты пишут разработке? Аналитиков нет? Поддержки нет? И отчего дежурный по разработке в ответе за то какой сейчас цикл тестирования? Команда тестировщиков за что отвечает? В общем, интересно было бы поглядеть какие еще у вас там есть подразделения и как с ними налажено взаимодействие.
И, да, парное программирование это не аджайл а XP
rtemchenko
23.07.2022 01:29Звучит вполне здраво. Хороший компромисс между убер-аджайлом, где все должны быть фуллстеком, и тотальным огораживанием, где никто не смотрит дальше своего носа.
Особенно правильная мысль о том, что с разработчика снимаются все продуктовые задачи. Зачастую дежурства не влючают это. Убирают часть задач, но ничего хорошего из этого не получается. Разработчик не может магическим образом тратить только 10% времени на он-колл. В итоге и продуктовые задачи буксуют, и он-колл ощущается как пустая трата времени.
Пойду питчить идею менеджеру.
yanwork Автор
23.07.2022 01:37Спасибо!
Да, обязательное условие в том, чтобы это было не «в нагрузку», а взамен.
Дежурный может (в терминах RFC :-) ) писать код, особенно если ему прямо невмоготу и он это хочет делать и если маленькая команда. Но он не должен (тоже RFC) это делать и не отчитывается за это на стендапе.
Он делает то, что разработчик хотел бы сделать, но ему некогда из за написания кода.
MonkAlex
23.07.2022 15:25Тот, кто сказал вам про фуллстеков в аджайле - наврал =)
Команда должна уметь закрывать все бизнесовые задачи, в идеале - даже при уходе части сотрудников в отпуск\увольнение. Больше от команды в аджайле ничего не ждут, никаких фуллстеков.
Anterenoire
23.07.2022 07:50"Мы имели доступ даже к источникам вроде легальной продажи данных парсинга сообщений, которые доставали всякие плагины к мессенджерам, геопозициям и т. п., и знали, что можно делать с данными о том, что Ашот опять зовёт Ивана посидеть в кальянной или Василий замечен в точке с игровыми автоматами. ТТМ на фичи был один день: с утра ставили задачу, в обед делали роллаут, вечером приходила первая аналитика." после этого все вскукареки про прекрасную разработку не стоят ничего. Вы тупо покупаете продукт слежки за пользователями, да еще и перехват сообщений в мессенджерах, аналитики недоделанные. Жаль что не могу миллион минусов поставить. Еще и хвастается этим, мол, мы сделали то, мы сделали другое, у нас даже такое есть. Яйца выеденного не стоите. Без "напарсенных данных с мессенджеров" даже аналитику нормальную не можете сделать. А потом всякие "служба поддержки сбербанка звонят".
smarthomeblog
23.07.2022 09:19Был такой опыт на предыдущей работе. С точки зрения передачи знаний и прокачки членов команды - отличный вариант. Минус нашего подхода - дежурный имел еще пару-тройку задач из спринта. А это уже было перебором.
Немного оффтопика. Вопрос про ОТАР - как я понимаю, это организационно-техническое и архитектурное решение? Где храните эти описания?
RaFaeL-NN
23.07.2022 09:31Я всегда был на проекте "вечным дежурным", т.е. занимался этим всем на постоянной основе много лет. Плюс еще техподдержка 3го уровня. Самая интересная работа, как по мне. И нет рутинных тасков, которые пилить надо неделями
svr_91
Как всегда, по закону все равны, но некоторые равнее
pyrk2142
Причина очень простая: последствия от того, что кодер сольёт информацию хотя бы по одному VIP-клиенту, слишком серьёзные, поэтому проще и дешевле нанять отдельную команду для работы с ними.
А так VIP-клиенты есть даже в такси, например, если обычному клиенту сотрудник поддержки может легально хамить, то в регламенте для работы с VIP-клиентами прямо прописана максимальная лояльность, выдача максимальных промокодов на любую жалобу и так далее. Просто потому, что риск его недовольства выше. Из лайфхаков - сотрудники часто могут засунуть себя в список VIP-клиентов и ездить с комфортом и горой компенсаций за все.
svr_91
Мне кажется, тут подойдет другое сравнение:
"А так Vip-клиенты есть даже в такси, например, если обычному клиенту могут выдать водителя - серийного маньяка, то VIP-у только прилежного дядечку с высшим образованием, прошедшим все проверки СБ"
Ну тоесть одно дело, когда с кем-то просто обращаются лучше, чем с другими, а другое дело, это когда "тут опасно, надо ограничить. А с этими... а с этими ниче не случится, забей". Типа давайте выдавать каски на стройке только начальникам, они же випы все-таки
yanwork Автор
Посмотрите, я ответил на комментарий ниже. Тут характеристикой скорее служит малое количество таких запросов и особые требования к качеству обслуживания и ответов.
По крайней мере для такого технического сайта как Хабр, имеющей значение является именно эта характеристика.
Для массовых запросов оптимальный алгоритм будет другим
terraplane
Когда у общества нет цветовой дифференциации штанов, то нет цели!