О том, как менять компанию размером в сотни тысяч человек
В Сбербанке работает около 300 тысяч человек, по размеру он больше какого-нибудь министерства. Управление изменениями — это в принципе сложная штука, даже на маленьком объёме. А как вводить изменения и контролировать их в такой махине? Профессор Гарвардской школы бизнеса Джон Коттер описывает восемь шагов, следуя которым можно изменить что угодно. Если понимать, как это работает, система вполне масштабируется.
Инженеры обычно интроверты. Если мы сделали классную штуку, нам кажется, что всем должно быть очевидно, какая она классная. Мы не задумываемся о том, как о ней узнают люди и как начнут ей пользоваться. Так погорело немало хороших IT-решений.
При планировании любого изменения самое главное — понять, кто будет проводником ваших идей. О нововведениях сотрудники должны узнать от тех, кому они доверяют. Желательно, чтобы эти проводники были включены в процесс создания новой системы — рассказывали о том, каких инструментов им не хватает, имели возможность давать обратную связь, принимать какие-то решения. Люди должны участвовать в изменениях, а не получать информацию о том, что они необходимы, сверху — как снег на голову.
Об IT-компании с банковским бэк-офисом
Во всех выступлениях Германа Грефа звучит мысль о том, что традиционный банкинг умер. Мы хотим быть IT-компанией с банковским бэк-офисом, а это требует мощных структурных изменений. Прежде у нас были обычные департаменты, или так называемые функциональные колодцы. В одном подразделении сидели люди одной специализации — департаменты разработки, аналитики, продаж, договоров с клиентами, бухгалтерия и так далее. Теперь мы хотим, чтобы все пересели в маленькие команды, в каждой из которых будет полная цепочка специалистов, которые смогут предоставить клиенту готовый продукт. Это одно из ключевых изменений, случившихся со Сбербанком за последний год.
Прежде разработка программного обеспечения делалась по традиционной модели: к вам приходили продакт-менеджеры, собирали требования, описывали их максимально детально, подписывали с вами техническое задание и отдавали в разработку. В разработке нужно было установить, кто это будет делать, и зарезервировать нужные ресурсы. В каждом подразделении на каждую задачу — по аналитике, разработке, тестированию — выделяли Петрова (10 % занятости), Иванова (20 % занятости) и так далее. Спустя полгода начинали приёмо-сдаточные испытания, но тут выяснялось, что всё не так. Вы говорили: «Я вообще просила вас совсем другое». Разработчики отвечали, что работали строго по ТЗ. И начинались скандалы, чтение технического задания и выяснение, кто что на самом деле имел в виду.
Сегодня очевидно, что все эти 10–20 % занятости не приводят ни к чему хорошему, потому что люди постоянно переключаются с одной задачи на другую и у них нет чувства сопричастности к результату. Мы пересадили значительную часть людей в продуктовые команды: теперь разработчик, аналитик, тестировщик и заказчик сидят вместе. Это команда постоянная, сработавшаяся, слаженная, мотивированная и полностью отвечающая за результат. В новой системе та же задача решается следующим образом. К вам точно так же приходят собирать требования, но вы их не описываете детально, а создаёте перечень самых важных из них и расставляете приоритеты. Дальше вы работаете вместе с командой разработки. Примерно раз в две недели с вами вместе пересматривают приоритеты и прорабатывают детальные требования на тот объём, над которым вы будете работать две недели. Как только готова очередная новая задача, вам её сразу показывают и уточняют, правильно ли выглядит эта экранная форма, удобно ли вам её заполнять. Как только вы принимаете какие-то части продукта, они сразу идут в эксплуатацию.
Таким образом, к назначенному сроку у вас уже есть готовая и принятая система, которая сделана вместе с вами с учётом ваших потребностей, а не нечто, основанное на том, как понял ТЗ какой-то абстрактный программист. Такой принцип работы называется инкрементальным — то есть мы действуем короткими операциями, в результате каждой из которых продукт обзаводится новыми возможностями и полезными функциями.
Сейчас командное обеспечение в банке разрабатывают две тысячи команд, в каждой из которых около десяти человек. Большая часть разработчиков работает в Москве, хотя крупные центры есть и в Питере, и в Новосибирске, и в других городах.
О том, что такое scrum
Как только появилась разработка программного обеспечения, тут же стали придумывать методы, как сделать эту работу удобнее. В середине 1990-х Джефф Сазерленд и Кен Швабер написали Scrum-guide. Термин scrum пришёл из регби: это момент наивысшей концентрации команды на мяче. Scrum говорит, что IT-продукт должна разрабатывать команда из пяти-семи человек. В неё входит владелец продукта, который знает рынок, понимает своего клиента и может описывать требования, разработчики, которые непосредственно занимаются созданием продукта, и так называемый scrum-мастер — человек, который помогает команде быть эффективной и договариваться друг с другом.
Команда работает «спринтами», то есть бросками. Каждый спринт начинается с его планирования — какой будет цель спринта и какие требования. Затем команда каждый день встречается на короткую встречу, буквально минут 10–15, где обсуждается, как прошёл день и нужна ли кому-то помощь. В конце спринта проходит его обзор, где показывают результаты, собирают обратную связь и понимают, что можно было бы сделать лучше. За счёт постоянной прозрачности, пересмотра того, что мы делаем, как мы это делаем, и постоянного развития получается всё более сильная команда и лучший продукт. Авторы scrum стали одними из создателей системы agile.
О том, что такое agile
Само слово agile появилось в 2001 году, когда 17 видных IT-практиков собрались покататься на лыжах и обсудить свой опыт: «Мы сделали кучу IT-проектов. Давайте подумаем, что помогало нам быть успешными?» Они написали так называемый манифест разработки программного обеспечения, назвали его Agile-манифестом. В нём описаны четыре основные вещи. Во-первых, что люди и их взаимодействие важнее процессов и инструментов. Во-вторых, что работающий продукт важнее исчерпывающей документации. В-третьих, что сотрудничество с заказчиком важнее согласования условий контракта. И в-четвёртых, что готовность к изменениям важнее следования первоначальному плану. К этому они дописали ещё 12 принципов. Например, о том, что работающий продукт — единственный показатель прогресса. Что работающий продукт должен поставляться как можно чаще, желательно раз в две недели. Что лучшие решения находят самоорганизующиеся команды. Что работать должны мотивированные профессионалы, главное — просто не мешать им работать. Что инвесторы, заказчики и разработчики должны работать вместе как можно плотнее, чтобы одинаково понимать, ради чего всё делается. Что на первом месте должен быть клиент. Что должна быть очень высокая техническая зрелость, потому что без неё никакая гибкость невозможна — вы не можете быстро меняться, если это требует от вас кучу приседаний и поворотов.
Позже на основе этого манифеста появилось много разных методов и практик. И сейчас в Сбербанке мы занимаемся тем, что придумываем, как эти практики применить к нашим процедурам и процессам.
О мобильном приложении Сбербанка
Новый метод только вводится, но у нас уже есть успешный и вдохновляющий опыт работы agile-команд. Например, мобильное приложение Сбербанка. Его первые версии создавались традиционными методами и имели в App Store оценку 2,5 звезды и множество гневных отзывов. Когда появились agile-команды, работающие короткими операциями и инкрементами, мы стабильно вошли в 20 лучших приложений App Store, а наш рейтинг колеблется между 4,5 и 5.
О возможностях развития в Сбербанке
Моё поколение привлекают не столько карьера и красивые должности, сколько возможность делать вещи, которые интересны и мотивируют. Я пришла в банк в 2011 году студенткой четвёртого курса прикладной информатики и попала аналитиком в первую экспериментальную agile-команду, которая делала «Клиент.Сбербанк» — систему дистанционного банковского обслуживания для юридических лиц. За семь лет, которые прошли с тех пор, я три раза меняла сферу работы. В Сбербанке нормально относятся к тому, что сотрудник хочет радикально сменить сферу деятельности: если опытный работник хочет меняться и развиваться, лучше, чтобы его знания оставались в компании, а не уплывали вовне.
Нашему поколению важна автономность, возможность работать самостоятельно, без жёсткой иерархии и пошагового контроля. И это главное открытие, которое я сделала, когда пришла работать в Сбербанк, — я совсем не ожидала такой степени свободы, доверия и возможности себя проявить.
Для тех, кто не в отрасли, слова «я работаю в Сбербанке» вызывают ассоциацию с работой в отделении. И их очень огорчает, когда они узнают, что я такой же идиот в вопросах получения кредита и открытия счёта и что я понятия не имею, в чём отличие между платёжными системами Visa и Mastercard. Но те, кто в индустрии, реагируют совсем иначе. Представители компании Boeing однажды сказали: раньше Сбербанк ездил к нам учиться, а теперь мы приезжаем учиться у Сбербанка.
Я работаю в компании, которая хочет быть лучшей и при этом трезво оценивает себя, понимая, что она далека от совершенства. И не перестаёт прикладывать все человеческие и нечеловеческие усилия для того, чтобы стать лучшей в мире. Такой была установка семь лет назад, и за эти годы она только усилилась.
О чувстве внутренней правды
Я изменяю процесс разработки программного обеспечения, то есть перевожу людей на новую технологию работы. И конечно, найти решение и перевести на него 20 тысяч человек — совсем не то же, что маленькую компанию в сто человек. Среди тысяч человек всегда найдутся обиженные, несчастные, те, кто скажет: «Вы нам не рассказали, со мной не обсуждали…» — и будет вам противодействовать. В этом смысле мне в своё время дали хороший совет.
Изменения — это очень неблагодарная работа, зато очень интересная. Это не то занятие, в котором стоит рассчитывать на общественное признание и любовь. Но есть такая штука, как чувство внутренней правды. И вот если его настроить, то ты сам всегда знаешь, сделал ли что-то хорошее или нет. Этому чувству я и стараюсь следовать.
