Agile-трансформация крупного разработчика платежных сервисов

Inpas Soft — крупный российский разработчик платёжных сервисов для банковского сектора и ритейла, работающий с 1995 года. Решениями и услугами компании пользуются ЦБ РФ, Банк Русский Стандарт, Банк «Открытие», «Почта России», X5 Retail Group и многие другие.

В 2018 году Inpas приступил к Agile-трансформации процессов планирования, разработки, тестирования и выпуска своего продукта. Помогали проводить эту трансформацию специалисты ScrumTrek.

Об этом кейсе мы поговорили с Алексеем Лаврухиным, генеральным директором компании Inpas Soft.

Почему компания Inpas решила внедрять Agile? Какие проблемы должна была решить Agile-трансформация? Какие цели вы перед собой ставили?

Осенью 2018 года, мы поняли, что компания перестала справляться с входящим потоком задач, поэтому я инициировал процесс внедрения новой методологии разработки — Agile. Как я предполагал, у Inpas были три ключевых проблемы:

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

В итоге, аудит показал все слабые стороны, связанные со старыми процессами планирования, разработки и тестирования продуктов. C аудитом и изменением компании мне помогал Виктор Несытов, который имеет богатый опыт работы в Agile. Кроме того, после аудита мы установили ряд целевых показателей, связанных со скоростью поставки продукта на рынок и себестоимостью разработки; проработали показатели SLA-реакции на изменения; определили процессы, которые мы готовы менять, и решили, как мы их будем менять.

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

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

Как проходил процесс внедрения Agile?

Agile-трансформация шла по довольно стандартной схеме.

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

Каждую команду — численностью по 5-7 человек — планировалось укомплектовать продукт-менеджером, аналитиком, тестировщиками и группой разработчиков. Найм отдельных Scrum-мастеров не планировали по соображениям экономии времени и денег.

Затем провели обучение: каждая команда определила для себя цели, сформулировала проблемы и распределила роли. И уже после этого стартовали.

Как много времени заняла Agile-трансформация? И можно ли сказать, что этот процесс завершён?

С момента старта прошло 9 месяцев, но я не считаю, что процесс Agile-трансформации уже завершился: скорее, завершился предварительный этап, в ходе которого мы в полной мере ознакомились с Agile.

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

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

Какие изменения, которые уже произошли на этот момент, вы могли бы отметить?

Все, кто связан с разработкой программного обеспечения, работают по Agile — в одних проектах и офисах мы используем Scrum, в других — Kanban. Но главное, что в целом нам удалось:

• Сократить срок средней доставки релиза до заказчика с 4,5 месяцев до 2.
• Сократить в 2 раза количество ошибок в продукте.
• Поменять психологию компании: сейчас у нас главный приоритет — «не мучить» клиента, а помочь ему, при этом самим получить удовольствие. Это повлияло и на внутреннюю атмосферу: в общении произошел переход от парадигмы «Отвали» к парадигме «Давай помогу». Даже есть ощущение, что стало больше неформальных встреч и тусовок.
• Оптимизировать штат сотрудников на 10%.

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

Как сотрудники восприняли изменения? Долго ли адаптировались к новым подходам?

Это, наверное, один из самых болезненных вопросов.

Продукт-менеджеры и сотрудники, проработавшие в компании менее 3 лет, встретили перемены положительно. Они понимали, что выбор простой: или мы меняемся — или нас ждет болото. Таких было 50%.

30% были настроены нейтрально, но были не прочь и сохранить статус-кво — чтобы не выходить из зоны комфорта. И ещё 20% выступали против или боялись изменений.

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

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

В итоге, чтобы эти 30% начали приносить пользу, мы перешли с ними на Kanban-доски с сохранением контроля со стороны руководителя отдела: это помогло познакомить их с Agile, не сильно выводя из равновесия, и повысить их производительность.

По прошествии 9 месяцев можно сказать, что все сотрудники успешно адаптировались к Agile.

Какую поддержку оказала компания ScrumTrek?

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

Коллеги из ScrumTrek не только проводили тренинги у нас, но и обучили ряд наших сотрудников в своей школе Agile. После этой подготовки они заняли позиции Product Owner или Scrum-мастер.

Кроме того, многие разработчики, аналитики и руководители по-прежнему с удовольствием посещают конференции, которые организует ScrumTrek. На одной такой конференции мы узнали много полезного от докладчиков из МТС, Raiffeisen Bank и Сбербанка, после чего, например, полностью переделали ряд процессов в Jira.

Почему вы выбрали именно ScrumTrek?

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

В случае со ScrumTrek все было совсем иначе, и здесь я бы хотел отметить Ивана Селеверстова: в том, что мы выбрали ScrumTrek, есть его большая заслуга.

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

Какие у вас планы по дальнейшему развитию?

Работы еще очень много — нам еще только предстоит более тесно «‎подружиться» с Agile.

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

В ближайшее время планируем окончательно утвердить KPI компании и команд, проработать мотивацию компании, скорректировать workflow по некоторым процессам и усовершенствовать работу с Jira.

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

Что бы вы порекомендовали компаниям, которые только задумываются о внедрении Agile?

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