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

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

Многие считают, что agile — это просто хайповая тема, за которой не стоят реальные практики. Но это не так. Об успешном кейсе agile рассказал Алексей Лаврухин, генеральный директор INPAS SOFT.

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

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

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

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

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

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

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

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

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

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

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

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

Это, наверное, один из самых болезненных вопросов.Продукт-менеджеры и сотрудники, проработавшие в компании менее 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, или потому что вы видите в этом пользу? Ответ на этот вопрос поможет вам внедрять новый подход более осознанно и с пониманием того, какой ваша компания должна стать после этой трансформации.