ENG

Перейти в Дзен
Технологии, Финансы, Это интересно

«Аджайл» — как это работает в Сбербанке

На одной из недавних конференций управляющий директор Департамента развития корпоративного бизнеса Сбербанка Дмитрий Трофимов (кстати, победитель конкурса «Лидеры России») раскрыл карты, как конкретно Сбербанк работает по технологии Agile.

«Аджайл» — как это работает в Сбербанке 

Сам Дмитрий Трофимов назвал целью выступления:

«Поделиться культурным кодом, проводником которого наша компания является и который лежит в основе нашей цифровой трансформации».

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

Что такое Agile и DevOps

— За терминами Agile и DevOps лежит простой принцип. Аgile подразумевает, что лица, занимающиеся бизнесом, сидят за одним столом с разрабатывающими для них продукт айтишниками. А DevOps подразумевает, что эти айтишники делятся на тех, кто непосредственно пишет коды, и на тех, кто потом будет сопровождать этот софт. И, по сухой статистике, Agile намного эффективней, чем ведение проекта в формате Waterfall — по каскадной модели…

О прошлом без ностальгии

— Года три назад, чтобы «открыть» проект, мне надо было «запилить внушительную презенташку», написать паспорт проекта, выйти и защитить бюджет на заседании комитета. Причем история с защитами на заседаниях многоуровневая. Но в рамках новой культуры такая пошаговая структура запуска проектов не нужна. Она была нужна лишь прежде, чтобы некто не начал разрабатывать что-то ненужное за двести миллионов. Но когда в компании все задают вопрос «зачем?», этому «некто» банально не дадут такой проект открыть. Чтобы мне сейчас открыть проект, я просто иду с идеей к руководству, обсуждаем и, если соглашаемся «да, это работает», вместе идем к самому высокому руководству. На следующий день выпускаем распоряжение, формируем команду и через три дня уже идет работа…

Организация процесса

— Сбербанк как компания, естественно, построен в виде многоуровневой иерархичной структуры. И я являюсь представителем конкретного подразделения, занимающего в этой структуре конкретное место. Но когда я хочу реализовать некую идею, мне не нужно в своем подразделении выделять соответствующую структуру. Я собираю нужных мне специалистов, говорю, что есть такая-то идея, и в возникшей проектной команде мы начинаем реализацию. Впрочем, не все проекты Сбербанка реализуются в Agile, в Waterfall мы тоже работаем…

О новых ролях руководства

— В Agile это доверие и делегирование полномочий. То есть когда проект уже запущен, руководство не отслеживает результаты в ручном режиме. Две недели мы отрабатываем заявленный отрезок проекта, потом — релиз, обсуждение результатов. Причем задача выбирается самой командой, в которой нет статусных лиц выше начальника отдела. Иначе говоря, 90% разрабатываемых в Сбербанке продуктов на рынок выводят сотрудники на невысоких должностях. Это лидеры команд в 10–15 человек…

Что прибавляет головной боли эйчару

— Используется кросс-функциональный командный тайминг. Если вы для разработки нового продукта будете создавать на долгий срок проектный отдел, то окажетесь вынуждены заранее определять штатные единицы. Допустим, этот отдел должен включать двух юристов и трех айтишников. Через пару лет юристы и айтишники перестанут быть юристами и айтишниками. Компетенции размоются. Поэтому в Сбербанке под проект создается структура с учетом того, что сразу же после завершения проекта сотрудники вернутся на свои прежние рабочие места. Ротация происходит непрерывно.

Еще один принцип — это full time работы над задачей в одной команде. Нет такого, чтобы кто-то отделался парой советов и вернулся к своим делам. Задача должна решаться.

И последний очень важный принцип — в Agile мы не стремимся получить идеальный результат и готовы довольствоваться получением минимально жизнеспособного продукта. Но каждые две недели происходит спринт, и каждый спринт должен заканчиваться результатом. То есть взят принцип из тайм-менеджмента:

«Если у нас есть слон, его нужно есть по частям».

Задача команды — не сделать что-то идеальное, а просто выйти на работающий продукт. Пусть пока он будет с минимумом функций. Ну а далее этот уже работающий продукт можно совершенствовать, обтачивая под клиента…

Чем отличается Waterfall от Agile

— Каждый этап Waterfall требует получения ста процентов результата. И если вы работаете по такому принципу, то каждый день рискуете всем проектом. А в Agile вы рискуете результатом двух недель. То есть каждые две недели вы формируете задачи на спринт. И если впоследствии что-то не получилось, вы возвращаетесь на две недели назад и просто ставите другие задачи. При руководстве принципами Agile вы вряд ли при неудаче потеряете весь проект.

Кроме того, при Agile фиксируется бюджет и сроки, но содержание проекта команда вправе менять. И если мы постоянно общаемся с заказчиками, и заказчик решает отказаться от определенного функционала, а объявит важным что-то, ранее не учитывавшееся, в рамках Agile смена приоритета возможна. В рамках Waterfall — нет. У вас зафиксированы параметры результата, от чего не уйти. И итоговый продукт может не соответствовать ожиданиям изменившегося рынка и конкретного клиента…

Ценности Agile

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

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

Что такое Agile технически

— Аgile — это команда с костяком в 10–15 сотрудников. Под конкретные задачи случается расширенный набор и до 80 человек, но многие подключаются только на определенном этапе. Еще когда задумывался проект, пишется product backlog, который может содержать и триста задач. Сама команда регулярно планирует спринт. То есть объявляет две-три задачи, которые берется решить за эти ближайшие две недели.

Еще проводится ежедневный стендап, где каждый член команды берет на себя определенную подзадачу: «Я сегодня сделаю это»; «А я сегодня встречусь с таким-то таким-то» и т. д. Также на стендапе все участники процесса делятся, что в решении задач получается, а что — нет. И в решении проблемы иногда принимает участие вся команда. Кстати, сам стендап не длится более получаса. Каждые две недели демонстрируются результаты командной работы. Конкретный участник команды может обмануть коллег на первом-втором спринте. Но постоянно обманывать невозможно — все увидят, что продукт не работает. Соответственно, нужно менять конкретных критических людей в команде…

Лайфхаки

  • Бизнес и IT лучше взаимодействуют, когда работают рядом.
  • Не нужно тратить время на бюрократию, сопровождающую вывод продукта на рынок.
  • Скорость внедрения. Недавно мы создавали решение для ряда клиентов — виртуальная полка продуктов в облачной платформе. В эту полку собираемся встроить алгоритм, который будет для клиентов формулировать задачи. То есть если вы станете нашими клиентами, мы, исходя из ваших данных в арендованном у нас облаке, начнем формировать лиды для вашего отдела продаж. Благодаря Agile работающий продукт появится всего через полгода. Правда, у нас уже есть «подвязанный» к восемнадцати базам данных алгоритм, которым сотрудники пользуются внутри банка и который мы готовим к выводу на рынок.
  • Гибкое управление требованиями и ресурсами. То есть когда вы в Agile, то каждый день можете принимать решения о перераспределении задач между участниками команды. Аgile не предусматривает какой-то жесткой структуры…

Зачем?

— Без «зачем» нет Agile, нет громких проектов и серьезных трансформаций. Agile призван помочь нам обойти типичные заблуждения. Первое заблуждение — люди всегда недооценивают тренды. Широко известно, например, исследование, в ходе которого американцы опрашивались, повредит ли гражданам их страны глобальное потепление. Ответили «да» 80–90% граждан. Но на вопрос, повредит ли потепление лично им, положительно ответили менее 5%. Примерно такое же соотношение мы встретим, если будем изучать подходы специалистов к новациям. Большинство опрошенных будут отвечать, что «какие-то новые технологии — это не про меня, у меня простой рынок: производи — продавай». Но на самом деле никуда от нового не деться.

Вторая история — мы всегда, можете спорить или нет, переоцениваем результат. Абсолютно всегда. Как вы оцениваете свои водительские навыки по сравнению с другими участниками дорожного движения? Правда ведь, все вокруг не умеют ездить, «опять поворотник не включил» и т. д. В итоге более 90% водителей считают, что они как минимум относятся к лучшей половине участников движения. То есть почти все, худших нет.

Или такая история. Одна из известных компаний Силиконовой долины провела опрос инженеров компаний высокотехнологичного сектора, относит ли конкретный опрошенный специалист себя к 5% лучших. Результат нетрудно предугадать — 42% опрошенных отнесли себя к лучшим. Мы тоже все считаем себя лучшими на рынке, у нас лучший продукт и лучшая команда. Даже если мы какой-то параметр проекта завалим, найдем оправдание.

Третья слабость — это откладывание на завтра всего тяжелого и серьезного. Мозг работает у всех одинаково. Чуть ли не крупнейший специалист по нейроэкономике и поведенческой экономике Дэвид Лейбсон (David Laibson) вывел достаточно сложную формулу. Представим условную шкалу на 10 делений. Все, что с вами происходит негативного, засчитывается в минус. Позитивного — в плюс. И, допустим, я собрался заняться спортом, представив себя с кубиками на животе и раскачанными плечами. И этот образ в собственной оценке, допустим, тянет на плюс восемь. А то, что оторвавшись от привычных занятий, мне сегодня придется пойти в спортивный зал, тянет, например, на минус шесть. Сегодня я стопроцентно испытаю минус шесть, а плюс восемь получу в лучшем случае через год. Поэтому восемь мы делим надвое. И полученные плюс четыре оказываются меньше минус шести. Но если я решу идти в зал завтра, пополам делим уже минус шесть. И плюс четыре минус три получается плюс один. И это «завтра» повторяется каждый день.

Единственная возможность бороться с этими слабостями — учитывать их существование.

Записал Игорь Чубаха

Следите за нашими новостями в удобном формате
Перейти в Дзен

Предыдущая статьяСледующая статья