Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

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

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

3 1ч. 32 мин.

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

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

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

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

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

9 <ul><li>Устаревшее программное обеспечение, заменить которое казалось практически невозможным из-за сложной работы сервиса.</li>

10 </ul><ul><li>"Сакральные" знания о проекте сосредоточены в руках нескольких сотрудников. Это делало их практически незаменимыми: когда люди уходили, компания сталкивалась с трудностями.</li>

11 </ul><ul><li>Низкая скорость разработки и низкое качество продуктов.</li>

12 </ul><ul><li>Отставание от конкурентов в технологическом плане и потеря ключевых клиентов.</li>

13 </ul><ul><li>Текучка среди разработчиков. Молодые специалисты зачастую уходили, не проработав в компании даже года. Это проблема всего рынка.</li>

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

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

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

17 <ol><li>Люди и взаимодействие важнее процессов и инструментов.</li>

18 <li>Работающий продукт важнее исчерпывающей документации.</li>

19 <li>Сотрудничество с заказчиком важнее согласования условий контракта.</li>

20 <li>Готовность к изменениям важнее следования первоначальному плану.</li>

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

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

23 В Agile как таковых руководителей нет, но у каждой команды есть ответственное лицо - Product OwneОни оказались не нужны в чистом виде. Им нужно было или быть разработчиками, или становиться Product Ownerʼами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

41 Положение Product Owner в бизнес-процесса и в командеКлючевые навыки Product Owner:

42 <ul><li>обладает видением продукта;</li>

43 </ul><ul><li>является владельцем бэклога продукта;</li>

44 </ul><ul><li>умеет расставлять приоритеты;</li>

45 </ul><ul><li>управляет ожиданиями заинтересованных лиц;</li>

46 </ul><ul><li>представляет пользователя;</li>

47 </ul><ul><li>взаимодействует с командой;</li>

48 </ul><ul><li>принимает продукт.</li>

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

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

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

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

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

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

55 недостатки

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

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

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

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

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

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

62 Простота

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

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

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

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

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

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

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