Зарплаты айтишников
Привет, Хабр! Меня зовут Сергей Путятинский, я зампред МКБ, отвечаю за технологии.
Сейчас Agile используют почти везде. По крайней мере, декларируют. Все уже расписано, разжевано, показано с картинками и примерами. Нужные слова все уже более-менее выучили. Целые команды коучей за несколько лет побывали во всех крупных организациях — и в нашем банке тоже. Однако, когда я пришел, то увидел, что на практике ничего не работает.
Я сам был разработчиком много лет и хорошо знал об этих проблемах. И поэтому смог донести до команд реальную ценность Agile без «шелухи».
Сейчас Agile используют почти везде. По крайней мере, декларируют. Все уже расписано, разжевано, показано с картинками и примерами. Нужные слова все уже более-менее выучили. Целые команды коучей за несколько лет побывали во всех крупных организациях — и в нашем банке тоже. Однако, когда я пришел, то увидел, что на практике ничего не работает.
Я сам был разработчиком много лет и хорошо знал об этих проблемах. И поэтому смог донести до команд реальную ценность Agile без «шелухи».
Цифровизация лучше бумажной бюрократии
Многие топ-менеджеры, как и я, раньше работали в небольших, но успешных командах. Им запомнился давний опыт — два-три человека быстро делают то, на что сейчас целые подразделения тратят уйму ресурсов. И теперь, когда корпорации становятся неповоротливыми, топы с ходу говорят: «Надо внедрять Agile», — думая, что стоит научить команду паре умных слов, привить несколько практик, и все заработает, как суперскоростной стартап. Но за навязыванием ритуалов они забывают про суть, и все остается на своих местах.
Я пятнадцать лет работаю в финансовом секторе. До этого у меня были проекты в нефтянке, с государственными заказчиками, в сфере образования, в промышленной автоматизации. Это сформировало определенную гибкость, теперь погружение в новую предметную область происходит быстро.
Сейчас мы работаем над цифровизацией в МКБ. Это не просто проект — это огромный вызов.
— В бэк-офисе мы избавляемся от бумаги, увеличиваем возможности электронного взаимодействия: от подбора кадров до логистики. Например, с помощью сложной математики можно определить, сколько наличности надо закладывать в банкоматы. Или оптимизировать маршруты инкассаторов.
— Мы внедряем речевую аналитику в контакт-центр для контроля качества взаимодействия с нашими клиентами и для большей эффективности в удаленных продажах. Первоначально это технология speech-to-text. Весь массив разговоров превращается в текст, и начинается большая аналитика. Мы ищем сотрудников контакт-центра, которые наиболее эффективны, ищем корреляции между тем, как они говорят, и их результатом. Это одновременно технологическая и творческая работа — выяснить по тексту, почему одни сотрудники успешнее других, и научить правильным подходам всех.
— Еще одна история — подключение чатов и создание многоканальной платформы. Здесь мы в начале пути. Когда в чатах накопится большой объем текста, его тоже надо будет проанализировать, создать чат-бота, и часть вопросов клиентов решать с его помощью.
— Но наш самый успешный кейс — это обновление мобильного приложения. За год мы поднялись на восемь пунктов в Mobile Banking Rank, у нас увеличился трафик в полтора раза и примерно на столько же — количество активных клиентов. Причем мы не делали дорогой рекламной кампании, а добивались эффекта созданием полезной функциональности, переделкой интерфейса и повышением удобства.
“
Это получилось, в первую очередь, благодаря тому, что мы устранили иерархические барьеры между подразделениями и создали единую продуктовую команду.
Общение важнее иерархии
Раньше у нас были не команды, а то, что я бы назвал феодальными княжествами. Например, отдельная команда программистов, они не общались ни с аналитиками, ни с бизнесом, или общались только через начальника, очень формально.
Одна из команд разработки находится в тверском офисе. Очень классные позитивные ребята. Но до определенного момента остальная команда ни разу их в глаза не видела. Хотя Тверь — это не Владивосток. Можно за пару часов доехать на электричке и сломать все коммуникационные барьеры.
Понятно, почему этого не делалось — мешала иерархия. Когда люди знакомы и периодически общаются лично, уровень доверия и взаимопонимания всегда намного выше. Поэтому мы сломали старые установки и бюрократические препоны и собрали команду в одном пространстве.
Раньше у нас было много разных отделов, но не было единой команды, которая отвечала за конечный результат. Каждый скидывал ответственность на других. Работа над проектами — особенно большими — могла идти очень долго и не всегда качественно.
С новым подходом мы сразу видим, что вся команда ответственна за результат. Каждое звено теперь работает на всех.
С новым подходом мы сразу видим, что вся команда ответственна за результат. Каждое звено теперь работает на всех.
Дмитрий Бобылев
разработчик
Год назад у нас была просто большая тусовка человек из сорока. Теперь же есть четкое продуктовое деление: люди, которые занимаются депозитными продуктами, кредитными, которые отвечают за разработку бэк-офисных систем. Сотрудники поделились на команды сами и поняли, что так эффективнее. Теперь процессом разработки дирижируют владельцы продуктов, а не начальники департаментов.
Раньше мне просто давали какую-то часть продукта в разработку, а для чего она нужна, что пользователь с ней будет делать — я не знала. Сейчас команда всегда собирается, все обсуждает, и у меня все встает по полочкам, все банковские процессы. Я понимаю, что и для кого мы делаем. Смысл задач стал понятен.
Амалия Алирзаева
разработчик
Но сломать иерархию и перемешать всех в один пул — недостаточно. Нужны определенные организационные мероприятия и инструменты.
Ценности важнее ритуалов
Иногда я сталкивался с сопротивлением, внедряя Agile в корпорации. Сталкивался и с тем, что люди из-за этого уходили. Когда происходят большие изменения, нарастает напряжение, начинаются изменения в кадровом составе. Хотя на деле процессы могут не меняться радикально, просто люди начинают думать по-другому.
Agile — это только система ценностей, то, что написано в манифесте, ни больше ни меньше. Там нет никаких ритуалов, лишь набор аксиом. Они ничего не говорят о методологии разработки и ведении проектов. Можно разделять ценности Agile и работать в Waterfall.
“
Основная ценность — работа на результат. Можете брать любую методологию — результат важнее процесса. Иногда людям тяжело это принять. Поэтому главное — объяснять, в чем ценность, а не насаждать ритуалы.
Ритуалы, обряды и описания процесса находятся в методологиях. Поэтому очень часто люди путают Scrum c Agile. У меня есть знакомые, которые говорят: «Аджайл равен cкраму, cкрам должен насаждаться сверху, на всех сразу. Просто делим людей на скрам-команды по семь человек, и вперед. А если у вас нет стендапа каждый день, значит, у вас не cкрам, не аджайл, и работать вы не умеете».
Я не фанат жесткой привязки к обрядам и ритуалам и позволяю командам выбирать практики самим, особенно хорошо это работает на начальном этапе внедрения. Только через год-полтора надо смотреть, кто показал большую эффективность, и устраивать внутренний обмен опытом, тиражировать успешные решения.
Когда мы собрались и начали планировать реализации, то поняли, что нам не подходит Waterfall. В нем все происходит последовательно, а нам нужно иногда остановиться, сделать шаг назад, шаг в сторону.
На первом этапе у нас были недельные спринты, но спринтами мы это называем условно. Мы не делали релиз, а собирались и обсуждали, кто что выполнил и чем займется дальше.
Чтобы понимать бизнес, наши аналитики постоянно сами ездили к заказчикам, обсуждали продукт непосредственно с теми людьми, которые будут им пользоваться. Затем аналитики шли к разработчикам и вместе решали, что из этого мы можем сделать и как.
На первом этапе у нас были недельные спринты, но спринтами мы это называем условно. Мы не делали релиз, а собирались и обсуждали, кто что выполнил и чем займется дальше.
Чтобы понимать бизнес, наши аналитики постоянно сами ездили к заказчикам, обсуждали продукт непосредственно с теми людьми, которые будут им пользоваться. Затем аналитики шли к разработчикам и вместе решали, что из этого мы можем сделать и как.
Инга Антонова
руководитель проектов
После этого можно перевести всех на одну методику, адаптированную под особенности компании. В такой метод внедрения я верю — когда не дядя-начальник заставляет всех «завтра же перейти на скрам», а команды сами доходят до лучших решений, делятся практиками и инструментами.
Кстати: как я «придумал» Agile, не зная, что это такое
Работать по специальности (а я заканчивал факультет компьютерных наук и информационных технологий в Саратовском государственном университете) я начал еще во время учебы. В 2004 у нас была команда из трех человек, и мы получили заказ от министерства труда и социального развития. Важные люди пообещали, что первого мая будет торжественный запуск продукта, сотрудникам раздадут компьютеры, принтеры, и тут же начнется работа. Дата была утверждена на министерском уровне, сдвинуть ее было уже нельзя.
Сейчас интеграторы берут за подобное десятки миллионов рублей, закладывают пару лет и набирают огромную команду. Мы разработали систему втроем за пять месяцев. Отказались от идеи какого бы то ни было ТЗ и уже через две недели принесли заказчику прототип. Он печатал нам скриншоты, делал на них правки от руки. Мы встречались два раза в неделю и приносили очередную версию. Фактически работали спринтами.
В итоге готовая система работала автономно, не падала, не просила колл-центра, не требовала первой, второй и третьей линий поддержки. Данные собирались по райцентрам и регионам, агрегировались на федеральный уровень — все это сопровождалось работой одного человека, даже не IT-специалиста.
Мы дошли до этого подхода сами, ничего специально не изучая. Конечно, начитались книжек про экстремальное программирование — тогда эта тема только набирала обороты. Все остальное пришло интуитивно. Квалифицированные и мотивированные люди сами выбирают правильные методы чутьем.
Уже потом мы с коллегой проанализировали подход и поняли…
“
Это было то самое, что сейчас называют Agile. Хотя тогда мы даже слова такого не знали.
Качество важнее скорости
Выше я рассказал про свободу в нашей команде. Но, конечно, есть несколько обязательных правил и установок, которые я требовал соблюдать:
— Все должны жить в общем таск-трекере. Один мой коллега утверждал, что невозможно заставить всех жить в едином трекере, что каждая команда рано или поздно уходит в свой. Но у нас получается.
— Необходимость трекинга времени. Мы управляем стоимостью — считаем, дорого ли нам стоят новые фичи, считаем time to market. Без общих правил делать такие вещи не получится.
— Обязательная для всех и примерно одинаковая структура работ, общий подход к декомпозиции. Например, большие задачи надо оценивать без декомпозиции и постановки. Эти оценки нужны даже с высокой погрешностью, чтобы соотносить потребности заказчика и количество людей в IТ. Нельзя оказываться в ситуации, где у бизнеса есть план на сто проектов, а мы можем разработать только десять.
Команде не всегда нравятся ограничения, которые я спускаю и от которых не готов отказаться. Периодически я получаю критику. Больше всего ребята хотят убрать «тайм-шитинг» или отказаться от жесткой структуры работ. Хотят вести только спринты, и не заводить таски на всю структуру.
Может, это несколько цинично с моей стороны, но я сказал, что готов отменить большинство ограничений для тех, кто покажет без них лучший результат с точки зрения качества продукта. И «процессные костыли» — предохранители, которые не дают качеству упасть, когда команда гонится за новыми достижениями.
До этого я работал в трех банках, и впервые вижу настолько короткую дистанцию до зампреда, который курирует IТ. Настолько короткую, что можно просто взять и написать ему в мессенджере.
Дмитрий Бобылев
разработчик
Я тоже работала в крупном банке, и у нас считалось, что общение с зампредом — это не для уровня простых смертных. А здесь у меня есть все телефоны, и на протяжении всего проекта я могу звонить, писать и задавать любые вопросы — обязательно будет ответная реакция.
Инга Антонова
руководитель проектов
Команда понимает, что они идут первыми, идут по тонкому льду. Когда ты делаешь что-то новое, очень важно ощущение безопасности, чтобы соседние команды не показывали пальцем: «Сейчас у вас ничего не получится, и вас всех расстреляют».
“
Должно быть четкое понимание, что они идут первыми, могут ошибаться, и ничего плохого с ними из-за этого не случится. В них верят и их поддерживают.
Эффективность лучше обязаловки
Мы перешли на удаленку гладко, даже обогнали многих коллег по банковской сфере. В конце марта все, кто мог работать удаленно, уже работали из дома. Мы вовремя осознали, что организация удаленного доступа — это критичный объект инфраструктуры, его надо защищать и выделять на это дополнительные мощности.
Сейчас все топ-менеджеры радуются — оказывается, ничего не сломалось. Для меня, как для IT-руководителя, радости мало. Ведь это означает, что мы уже владели инструментарием, который повышает нашу эффективность, делает нас более гибкими, позволят нанимать людей за пределами привычных нам городов — и не пользовались им.
“
Потребовался коронавирус, чтобы мы осознали, какой огромный потенциал есть в наших руках. И сразу возникает вопрос — а где такой потенциал есть еще?
Да, все оказались изолированы, хотя раньше многие сидели в опенспейсе без кабинетов. Когда вы все были собраны в хорошем общем офисе, а потом разошлись по углам — определенно что-то теряется. Но есть и плюсы. Мы тратили по три часа на дорогу. А сейчас можем уделять больше времени и работе, и себе.
Я не говорю, что всем навсегда теперь надо уйти на удаленку. Но использовать этот инструмент в дальнейшем нужно обязательно. Просто надо подходить к нему без фанатизма. Сохранить опенспейсы и возможность собираться, но уже без обязаловки, как раньше.
Я заметил, как увеличилась динамика разработки. Но появилась необходимость и быстрее учиться, получать новые знания, чтобы все успевать. Приходится разрабатывать гораздо больше объектов, расти в интеграции, во фронте. Это хорошо — из-за этого у меня прилично выросли разработческие скилы. Если бы я работал от начала до конца по документации, не было бы такого скачка.
Никита Илюхин
разработчик
Задачи стали решаться намного быстрее. В случае нестандартной ситуации можно сразу собраться с аналитиком и разработчиком и ускорить процесс поиска ответов на вопросы. Близость к разработке помогает осваивать новые тулзы, что тоже влияет на скорость работы. Сам тоже прокачиваешься быстрее.
Юлия Комарова
тестировщик
Людям, которые не верят в Agile или говорят, что это не подходит крупным организациям, важно помнить — это просто набор ценностей, который работает, если сохранять разумность и уметь договариваться с бизнесом.
Когда мы внедряем Agile, то стремимся к двум вещам:
Первая — это внутренняя эффективность. Есть очень много процессов, которые мы автоматизировали и будем автоматизировать. Но не для красоты, не просто, чтобы всем было удобно нажимать на кнопки. Технологии — этот способ оптимизировать процессы и быть менее затратными. Потому что когда мы смотрим на автоматизацию поддерживающих функций, мы всегда думаем об экономике.
Вторая цель — сделать IT-подразделение полноценным партнером для бизнеса, который приносит идеи, помогает зарабатывать. Для владельцев продукта вклад в технологии ради результата — основное. Мы это понимаем и хотим дальше жить в этой парадигме, когда IT-блок не просто отрабатывает спущенные сверху заказы, а выступает партнером и приносит идеи зарабатывания денег.
“
Лучшие айтишные мозги должны думать над развитием бизнеса, а не над технологиями на его службе.
Комментарии 18
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.