Опыт внедрения Agile в компании Ticketland
2026-02-21 09:06 Diff
https://skillbox.ru/media/management/agile_ticketland/

Опыт внедрения Agile на примере живого кейса крупной компании — отличный пример, который сможет помочь вам понять, как начать работать по этой методологии.

ВРЕМЯ ПРОСМОТРА

 1ч. 32 мин.

Попытки создать идеальную систему управления данными начались еще в середине девяностых годов прошлого века. Даже ФБР попыталось придумать что-то новое для замены каскадной модели управления (Waterfall), но, потратив600 млн долларов, отказалось от этой затеи. Почему же за 10 лет так ничего и не удалось сделать? Проблема была в самой методике работы «по каскадам» (ступеням), когда следующий этап запускается только после того, как реализован предыдущий: если останавливался один из этапов, то замирал весь проект.

В 2001 году появился «Манифест гибкой методологии разработки программного обеспечения» (англ. Agile Manifesto), и ситуация изменилась. За счет итерационной модели удалось наладить непрерывную работу всех участников проекта, и проклятье Waterfall исчезло. А пример ФБР и выброшенных на ветер 600 млн долларов научил всех.

Важно!
С помощью старых подходов нельзя решать современные задачи.

На примере кейса компании Ticketland попробуем выяснить, как применять методологию Agile, чтобы минимальными деньгами и ресурсами эффективно справляться со сложными проектами.

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

  • Устаревшее программное обеспечение, заменить которое казалось практически невозможным из-за сложной работы сервиса.
  • «Сакральные» знания о проекте сосредоточены в руках нескольких сотрудников. Это делало их практически незаменимыми: когда люди уходили, компания сталкивалась с трудностями.
  • Низкая скорость разработки и низкое качество продуктов.
  • Отставание от конкурентов в технологическом плане и потеря ключевых клиентов.
  • Текучка среди разработчиков. Молодые специалисты зачастую уходили, не проработав в компании даже года. Это проблема всего рынка.

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

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

Agile — это гибкая методология в разработке ПО. В ее основе лежит 4 принципа:

  1. Люди и взаимодействие важнее процессов и инструментов.
  2. Работающий продукт важнее исчерпывающей документации.
  3. Сотрудничество с заказчиком важнее согласования условий контракта.
  4. Готовность к изменениям важнее следования первоначальному плану.

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

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

В Agile как таковых руководителей нет, но у каждой команды есть ответственное лицо — Product Owne

Они оказались не нужны в чистом виде. Им нужно было или быть разработчиками, или становиться Product Ownerʼами.

Важно!
В Agile нет иерархии — нет человека, который говорит, как нужно делать ту или иную задачу, и все контролирует. Есть команда, в которой все контролируют друг друга. Здесь работает социальная ответственность.

При этом члены команды периодически показывают готовые продукты клиентам. Таким образом, контроль они осуществляют сами перед собой и перед будущими пользователями.

Например, сервис отчетов, которым пользуются клиенты компании, устарел; решили создать новый и красивый. Раньше руководитель мог отдать приказ: сделайте новый сервис отчетов. Но теперь в компании стали работать иначе. Сперва Product Owner обсуждает с клиентами разные гипотезы — например, как может выглядеть новый сервис отчетов. То есть осуществляет сбор пожеланий пользователей.

Дальше команда делает маленькие шаги. К примеру, принимает решение сделать backend — разобраться, как эти данные будут храниться и показываться, как будет выглядеть меню. То есть разрабатывается простой, примитивный продукт, с которым тем не менее уже могут взаимодействовать пользователи. После этого приступают к следующему шагу разработки.

Это дискуссия о том, что пошло не так и что можно улучшить. Важно, чтобы она была командной, чтобы все участвовали и каждый мог поделиться своим мнением.

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

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

То есть если разработчики говорят, что надо работать над фичей, они должны объяснить, как эта фича принесет компании деньги.

В Agile нет места хаосу, каждое нововведение должно быть четко обосновано

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

Это, в свою очередь, сэкономит деньги на инфраструктуре и повысит надежность в случае падения системы. Таким образом, новый сервис отчетов мог принести прибыль, поэтому было принято решение о его внедрении.

Человек должен объяснить, почему хочет работать в компании. Если у него нет никакой цели в жизни, никакого плана — это плохой знак, его надо будет «качать».

Среди ценностей Ticketland есть получение удовольствия от работы. Если новичок мрачный (очень многие IT-специалисты мрачные, брутальные, суровые), не реагирует на шутки, не может адаптироваться к изменению ситуации, то, наверное, ему и всей команде будет трудно, даже если он отличный специалист.

Для разработчиков есть специальные тесты и отдельные люди, которые задают нужные вопросы.

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

Схематическое отображение t-shape

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

Важно!
Scrum-команды и люди в Scrum-командах должны быть специалистами в том, что они делают, и интересоваться смежными сферами.

Это человек, который умеет находить общий язык с людьми, работать в команде, понимает технологии и знает, как с ними взаимодействовать. Product Owner — связующее звено между бизнесом, разработчиками и пользователями. Таких специалистов на рынке труда сейчас мало, поэтому многие компании выращивают их самостоятельно.

Положение Product Owner в бизнес-процесса и в команде

Ключевые навыки Product Owner:

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

То есть каждое обновление рассматривали не только со стороны бизнеса, но и со стороны пользователя.

Схематическое отображение пользовательской истории

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

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

Разница между монолитной архитектурой проекта и использованием микросервисов

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

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

преимущества

недостатки

Независимое обновление

Сложно выкатывать

Масштабирование

Сложно тестировать

Возможность экспериментов

Респределительная система

Простота

Сложно эксплуатировать

Поддержка любым разработчиком

Несогласованная БД 

Все поставленные задачи были решены. Сервис Ticketland вошел в двадцатку Forbes, компанию оценили в 84,2 млн долларов. Для бизнеса такого рода это отличный результат.

Agile — это большая трансформация, которая идет во всем мире уже д авно. Кто-то скажет, что Scrum и Agile — просто модные слова, оттюнингованный менеджмент и искусственный бум. Но есть классический кейс ФБР, где было потрачено 600 миллионов долларов, а результат появился только после перехода к гибкой методологии управления проектами.

Есть кейсы других крупных компаний. Посмотрите на них и задайте себе вопрос: «Зачем ездить по асфальту на коньках, если можно ехать на BMW?» Для современных проектов лучше работают современные работающие методологии.

Больше узнать про Agile и другие актуальные методологии управления процессами, применяемые в IT, маркетинге и медиа, вы сможете, пройдя наш курс «Управление digital-проектами».