Почему я ушел из «Сбербанка» работать по Agile на аутсорсе — Колонка руководителя проектного офиса студии разработки Phobos

Руководитель проектного офиса студии разработки Phobos Алексей Прокопенко написал для vc.ru колонку о том, почему он перестал руководить ИТ-проектами в «Сбербанк-технологиях» и ушел работать по Agile на аутсорсе. Автор также рассказал, почему система Agile не приживется в крупных банках.

Герман Греф съездил на экскурсию в Калифорнию и привез картошку Agile в Россию. Стоит заметить, что Россия идет с большим отставанием в вопросе разработки, внедрения и эксплуатации технологий. Причины очевидны — климат для бизнеса и инноваций в стране отсутствует. Но одна из главных причин — это непонимание скорости развития технологий.

Мы знаем много случаев создания революционных продуктов небольшой группой людей. Например, команда, создавшая первую версию OS Android, состояла из пяти человек. Dropbox и вовсе придуман одним Дрью Хьюстоном в автобусе. Для появления инноваций на западе есть развитая инфраструктура — хакатоны, акселераторы, инкубаторы, бизнес-ангелы, венчурные инвесторы, фонды, крупные компании и прочее, которые удовлетворяют спрос на технологии мира.

Сейчас технологии развиваются с фантастической скоростью. Количество научных статей за месяц только по data science превосходит человеческие возможности по их изучению. Это приводит к тому, что действительно прорывные технологические компании находятся в состоянии самой жесткой в мире конкуренции. Чтобы поддерживать свое лидерство, они должны быть быстрыми и мобильными. В современном мире невозможно стимулировать рост технологий, увеличивая количество людей и затрачиваемого капитала.

Мы строили, строили…

Я руководил ИТ-проектами в составе «Сбербанк-технологии». При его создании руководство «Сбербанка» имело четкую цель — централизовать ИТ-команду в отдельном подразделении. Банку нужно было делать разработку продуктов быстрой, а систему гибкой. Но работая в «Сбертехе», мы подчинялись самому «Сбербанку» и вынуждены были согласовывать каждый свой шаг.

Бесконечные заполнения документов, отправка их на согласование и ожидание ответа — все это замедляло процесс создания проекта и не давало стимула работать. Даже самого сильного специалиста с крутой идеей погубит осознание того, что эту идею не донести. Бюрократический ад не позволяет создавать продукт быстро. Государственный банк — большая неповоротливая монополия, которой трудно «перевернуться».

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

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

Но и в крупных коммерческих банках не идеальная картина, хотя и намного лучше. До «Сбертеха» я работал в ИТ-департаменте «Альфа-банка», где создавал большой проект. В ходе процесса разработки появлялись идеи, новые решения. Команда разработчиков устраивала брейн-штормы и, как тогда казалось, двигала процесс. Но коммерческий банк с собственным ИТ-подразделением страдал все теми же проблемами, что и государственный.

Срок создания проекта был рассчитан на месяцы, но внутренние процессы в самом «Альфа-банке» растянули его на годы. В течение такого большого промежутка времени с разработкой может произойти все что угодно. Мы делали одну систему, описывая стостраничные документы, а через месяц руководство понимает, что нужна совершенно другая. Проект теряет актуальность уже во время разработки, потому что бизнес-процесс меняется быстрее, чем его могут реализовать. Руководство начинало понимать, что если их банк хочет стать передовым, то нужно создавать проекты быстро. Вот только пошли они не тем путем.

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

Большие проекты и маленькие команды

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

Тот Agile, который хочет ввести Греф в «Сбербанк-технологии» (Sbergile) по щелчку пальца, не может быть гибким из-за самой структуры банка. Руководство государственного банка никак не может понять того, что для быстрого создания продукта нужна не только методология, но и разработка небольшими компаниями. Agile — это методология, которую нельзя надеть на всю структуру банка, как шапку на голову.

Хороший пример: для создания проекта «Сбербанк-онлайн» на Android компания наняла отдельную команду дизайнеров. Специалисты работали обособленно от остальных и смогли сделать действительно хороший продукт. Им просто никто не мешал. Команде не мешали внутренние согласования, подписание бумаг, ожидание комиссии. Дизайнерам не нужно было лезть во всю структуру банка. Благодаря этому они смогли создать проект быстро и качественно.

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

Поработав в крупных компания, я увидел большую разницу в том, какой подход применялся для реализации той или иной поставленной цели. Я понял, что создание реальных проектов быстро, возможно лишь при помощи гибкой Agile-системы, и ушел в Phobos. Это agile-outsource компания, которая специализируется на подборе проектной команды для реализации конкретной задачи. Команды, у которой есть опыт в реализации продуктов, а не написания документаций и согласования процессов.

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

Каким будет аутсорс завтра

В «Альфа-банке» мы создавали проект по каскадной модели разработки: сначала пишется документация, затем она проходит согласование, далее идет процесс создания. Изначально при оценке проекта была допущена ошибка в сроках. В итоге за три месяца до дедлайна оказывается, что половина бумаг не согласована, а разработка вообще не начата. Половина сотрудников, удобно просидев на мягком кресле, начала бежать в появившиеся тогда «Сбербанк-технологии».

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

В маленьких аутсорс-компаниях все иначе. Не за кого прятаться. Если ты что-то не сделал, то будет понятно, кто подвел команду. Кроме того, если это Agile-аутсорс, то на согласование не затрачиваются месяцы, а разработчики могут показать результат работы очень быстро. Если в проекте будут неточности, например, со сроками — их легко изменить.

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

Эту простую методологию хотят сделать сложной различные «Agile-эксперты», создавая для себя прибыльный бизнес. Посмотрите доклад Дейва Томаса — одного из составителей Agile-манифеста. Увы, понимание этого в больших компаниях приходит очень поздно.

Теги

Статьи по теме

©  vc.ru