Привет! Меня зовут Кирилл Покладов, я ИТ-директор корпоративного, инвестиционного и депозитарного бизнеса в Росбанке. В прошлый раз я рассказал о некоторых принципах нашей инженерной культуры.

Сегодня я продолжу знакомить вас с другими принципами, которые помогают совершенствовать процессы в быстро меняющемся мире ИТ. 

Думаю о том, как будет работать после меня

Мы активно делимся с командами знаниями о текущих решениях и уникальных компетенциях, чтобы избежать BUS-фактора. Создаем базу для изменений и развития, чтобы облегчить работу будущим поколениям разработчиков. На своем примере расскажу, как реализован этот принцип на практике.

Открыто рассказываю команде о наших решениях и решениях команды топ-менеджеров банка, объясняю, почему именно такое решение принято, на чем оно основано и какую пользу оно нам принесет. Встречаемся со смежными командами, минимум раз в квартал для общей синхронизации, рассказываем, что сделали и какие ближайшие планы, какое взаимовлияние есть между нами.

Также индивидуально работаем с нашими ключевыми сотрудниками, поддерживаем и развиваем их, при этом стараемся делать так, чтобы они развивали и других сотрудников, а не хранили все знания в себе. И конечно, команда документирует всю техническую информацию в Confluence, чтобы каждый сотрудник имел доступ к необходимым знаниям.

Есть только одна вещь, которая ценнее времени. Это твоя репутация. На эту главную ценность нельзя жалеть ни времени, ни сил. Поэтому оставляй после себя хороший код, понятную документацию, в общем делай так, чтобы тебя вспоминали только хорошими словами и мысленно благодарили.

Понимаю, зачем делаю

Ключевой принцип, определяющий направление и мотивацию каждого инженера в команде. Наши действия получают истинное значение, когда мы осознаем, какую проблему решаем и каким образом наши действия вносят вклад в общий успех. 

Если я не понимаю зачем что-то делаю, для чего, какую проблему решаю, то мне становится не интересно, я теряю смысл работы. Как вы понимаете, на выходе будет и результат соответствующий. Поэтому мегаважно понимать для чего ты что-то делаешь, надо чувствовать ценность своей работы. Не бойтесь уточнять цель и назначение задачи, которую ты делаешь. Это важно! В любой задаче.

Подробнее о реализации этого принципа на примере постанализа массовых сбоев расскажет Наталья Удальцова, главный ИТ-менеджер управления ИТ-процессов IM\REQ:

Проведение анализа инцидентов, которые могут оказать влияние на наших клиентов и в результате причинить банку как материальные, так и репутационные потери, имеет для нас высокий приоритет.

Эта деятельность несет ключевое значение для развития банка и поддержания удовлетворенности клиентов. Главная цель — обеспечить стабильность и качество сервиса, чтобы клиенты оставались довольны и ценили предоставляемые услуги.

Для детального разбора инцидентов мы нашли для себя топ‑практик, которые успешно внедрили в будни поддержки ИТ, чтобы следовать цели.

  • Традиционный еженедельный ритуал — ретроспектива по значимым сбоям. Здесь мы исследуем корневые причины, триггеры сбоев, проверяем наличие мониторингов и планируем действия, которые помогут избежать повторения. Чтобы встреча была эффективной, мы приглашаем не только ответственных за решение сбоя, но и представителей ситуационного центра, комитета внедрения изменений и другие потенциально заинтересованные команды. Расширенный состав участников помогает решать вопросы не длинными переписками, а здесь и сейчас. Для случаев, когда причина сбоя неизвестна или не устранена, мы переводим сбой в плоскость Problem Management

  • По критичным сбоям мы организуем Post mortem — подробный разбор хронологии инцидента с привлечением сотрудников, устраняющих сбой, руководителей ИТ и ситуационным центром. Здесь мы анализируем моменты, в которых мы могли сократить время решения, выявляем зоны роста, а также подчеркиваем для себя удачные практики, которые помогли в моменте. Данный инструмент в нашем банке существует как на уровне всего управления ИТ, так и внутри команд поддержки.

  • Мы регулярно мониторим статусы всех задач, поставленных на ретроспективе или при проведении Post mortem, а также организовываем Problem‑борды — встречи по задачам и проблемам, которые выполняются длительное время. Это помогает не просто проговорить, а реализовать ранее поставленные задачи.

Важно, что при использовании этих и других практик мы не замыкаемся внутри ИТ‑команд, а привлекаем бизнес и не боимся обратной связи. Именно в ней мы видим зоны роста и наиболее приоритетные моменты в развитии.

Не боюсь проблем, говорю открыто

Не ошибается тот, кто ничего не делает. Мы открыто признаем, что проблемы — это неизбежная часть нашей повседневной работы. Вместо того, чтобы прятать их под ковер, мы выбрали путь учиться на ошибках. Открытость и смелость в признании проблем — это ключевой фактор, который дарит команде бесценный опыт. Поверьте, это гораздо более зрелый и взрослый подход, нежели промолчать и надеяться, что само рассосется. Надежда - плохая стратегия.

На этом принципе базируется формат мероприятий F#ckUp Review в Росбанке. О нем расскажут директор департамента ИТ-поддержки пользователей и клиентов цифровых сервисов Александр Денисов и начальник управления поддержки приложений Максим Емельянов:

В рамках нашей гильдии администраторов мы проводим встречи, где детально разбираем причины свежих инцидентов. Мы стремились сделать это в формате трагикомедии, фарса и гротеска, чтобы не только подчеркнуть важность процесса и сделать его более запоминающимся, но и чтобы спикеры не чувствовали напряжения и в непринужденной форме рассказывали об ошибках.

Цель F#ckUp Review не только обсуждение произошедшего, но и извлечение системных выводов, которые могут быть полезны и для других команд. Мы стремимся делиться нашим опытом и помогать другим извлекать уроки из подобных ситуаций. И все это в неформальной обстановке.

Как пример, на одной из встреч F#ckUp Review, посвященной очередному нестандартному инциденту спикер строил рассказ, отвечая на вопросы:

  • Как мы ждали, опасались инцидента и словили его? 

  • Как мы уходили от регламентных бэкап-ресторов и в итоге получили инцидент? 

  • Как мы не успели выполнить работы, которые исключили бы инцидент? 

  • И что нас спасло в решении?

Выводы релевантные для многих команд: тюнинг мониторинга, непрерывность контракта вендорской поддержки, а регламентные работы потому и регламентные, что их нужно делать вовремя.

Как работает инженерная культура?

Инженерная культура актуальна не только для тех, кто напрямую занимается разработкой. Ценности инженерной культуры применимы в любой области, будь то разработка, тестирование, администрирование или управление проектами. Они предоставляют общую основу, которая помогает формировать единую команду, работающую на общий результат. 

Инженерная культура Росбанка — это не статичный кодекс, а живой организм, поддающийся эволюции. Ценности, которые сегодня кажутся нам ключевыми, могут подвергнуться изменениям в будущем в соответствии с новыми вызовами, технологическими тенденциями и нашим собственным опытом. 

Важно также помнить, что без должного управления она может стать стихийной и неэффективной, упуская важные возможности и игнорируя потенциальные проблемы. Поэтому необходимо создавать благоприятные условия для развития культуры, включая установление стандартов, обучение персонала и внимание к обратной связи, чтобы она стала источником конкурентного преимущества и обеспечивала развитие.

Буду рад обсудить с вами, какие внутренние процессы увеличивают эффективность разработки в вашей компании. Welcome☺

Комментарии (4)


  1. IVNSTN
    18.03.2024 19:15

    По критичным сбоям мы организуем Post mortem — подробный разбор хронологии инцидента с привлечением сотрудников, устраняющих сбой, руководителей ИТ и ситуационным центром.

    Это же административное, не культурное. Авария - ну-ка быстро все на созвон! Механизм распространённый, но это про иерархию, обязаловку, подчиненность, доставку информации наверх. С применением такой практики лучше, безусловно, становится, если раньше ничего подобного не было. Как конкретно проводится процедура, с чем на неё приходят и с чем уходят - да, тут могут быть элементы культуры. Если все договорились руками на проде не шурудить, не деплоить в обход пайплайна и соблюдают эти договорённости - это элемент культуры. Если раньше была обратная картина, то чтобы прийти к подобному состоянию нужен серьезный культурный сдвиг. Чтобы созваниваться после аварии - не нужен. Если раньше все просто суетились и где-то что-то как-то фиксили, а после решения проблемы не могли вспомнить, где чего поменяли, какими действиями фактически устранили последствия инцидента, и в чем он заключался - это отсутствие культуры. Если все дружно стали вести в правильных местах хронологию своих манипуляций, большую часть манипуляций до возникновения инцидента и проделываемых после возникновения перевесили на автоматику, которая ведёт подробный лог, и потом это можно как-то склеить и получить ту саму хронологию - это высокий и технический, и культурный уровень. А созвониться можно и без всего этого.

    Мы регулярно мониторим статусы всех задач, поставленных на ретроспективе или при проведении Post mortem, а также организовываем Problem‑борды — встречи по задачам и проблемам, которые выполняются длительное время.

    Есть дейлик, на котором нужно озвучивать проблемы и трудности в решении задач. Есть ретро, где нужно разбирать в том числе проблемы и трудности. И потом еще отдельный регламентно-ритуальный созвон, теперь уж точно по проблемам и трудностям? "Пахнет" не очень хорошо. И точно не про культуру, а опять про администрирование.

    Мы регулярно мониторим статусы всех задач ... при проведении Post mortem

    Подозрительное совмещение в одном предложении. Тоже "пахнет" не очень.

    Цель F#ckUp Review не только обсуждение произошедшего, но и извлечение системных выводов, которые могут быть полезны и для других команд.

    Больше созвонов богу созвонов. Кросс-командное ретро/пост-мортем? Вероятно, здравое зерно есть. Может даже и не связанное напрямую с самой разбираемой проблемой. Не менее вероятным кажется и то, что некоторые заросли малины хоть и выглядят со стороны свежо и соблазнительно, выжить смогут только в присутствии уверенной руки с секатором.


  1. apoltavcev
    18.03.2024 19:15

    Спасибо за статьи, обе прочёл с удовольствием! Есть вопрос про обсуждение проблем: достаточно ли факап-ревью, чтобы в команде сохранялось спокойное отношение к ошибкам? Или как-то ещё поддерживаете нужную атмосферу?

    Спрашиваю, потому что признавать ошибки трудно. Если менеджмент собственным примером не показывает, что ошибки — это нормально, со временем команда может вернуться в естественное состояние с «отрицательным ростом»)


  1. apoltavcev
    18.03.2024 19:15

    И показалось, что пример факап-ревью выбран безопасный. Вы столкнулись с проблемами из-за ошибки, но выкатили решение — и рассказали об этом только потом. А если взять более негативный сценарий?

    Допустим, проект был переведён на технологию, которая не оправдала ожиданий — и теперь нужно выбить у бизнеса время на ещё один переезд. В этом случае будете проводить факап-ревью или другими инструментами воспользуетесь?


  1. Broter
    18.03.2024 19:15

    Как активный корпоративный клиент разных банков, с уверенностью говорю - ПО от росбанка самое наихудшее. Банк-клиенты (а их зачем-то несколько) ужасно неудобны, неиформативны, с кучей ненужных операций. Начиная с авторизации, заканчивая поддержкой. Создается впечатление, что никто из росбанка никогда не работал со стороны клиента. Поэтому вы можете хоть каждый день хвалить свою команду, но работать с вашим банком жутко неудобно.