Корпоративное обучение Lean Startup и Customer Development
group 15 equalizer 5

Что такое Agile? — Методология управления проектами, ценности, принципы и манифест

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

Agile (англ. – проворный) – это семейство «гибких» подходов к разработке программного обеспечения.

Корпоративное обучение методологии запуска стартапов из кремниевой долины — Lean Startup и Customer Development
Lean Startup Customer Development Юнит–экономика Jobs To Be Done AARRR MVP & RAT Диффузия инноваций Проектирование бизнес–модели Разработка ценностных предложений Agile Scrum Kanban OKR Growth Hacking Design Thinking Business Agility
  • Тренинг Lean Startup Professional и бесплатные мероприятия — в Москве.
  • Вы получите навык запуска инноваций и вывод стартапов на рынок — сделаете первые продажи методом бережливого стратапа сразу на тренинге.
  • Мы — практики, а не инфоцыгане. У нас десятки кейсов запуска новых продуктов в рамках крупных компаний — финтех–стартапы, маркетплейсы, классифайды, включая международные проекты на рынках США и Китая.

Многим до сих пор непонятно это слово. Давайте разберёмся и поймём, что это не страшно, а даже классно и полезно.

Agile – не методология!

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

На стадии инициации проекта нужна большая часть информации о производстве продукта. Чем ближе к нулю времени, тем больше гипотез и меньше результата.

Что такое Agile

"Водопадный" подход описывает метафора автономной подводной лодки, которая уходит в плавание в Северный Ледовитый океан. Загрузили команду, продукты, отдано боевое задание. Всё готово, инструктаж проведён, и лодка ушла под лёд на 3 месяца. Там она что–то делает–выполняет без всякой связи с внешним миром. Через 90 дней экипаж прибывает обратно и отчитывается о проделанной работе.

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

Нам проще и быстрее понять, что нужно сделать по–другому

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

Мы привыкли мыслить водопадными проектами

Хотя они основаны на мнимой вере в результат. Нам кажется, если мы за один раз сделаем всю работу, и больше к ней не будем возвращаться, то так будет лучше. Но у Вселенной не всегда такие же планы, как у нас. Поэтому нам нужны соответствующие инструменты решения задач, которые учитывают (по крайней мере, всеми силами пытаются это сделать) переменные факторы.

Что такое Agile

Концепция Agile предлагает: «Давайте не тянуть до последнего, чтобы увидеть результат, а будем действовать разумно. Разобьём всю длину проекта на недельные интервалы, будем создавать план работы на будущий отрезок, выполнять поставленные задачи и смотреть, что получилось. А потом принимать решение, куда двигаться дальше».

Совсем не обязательно в конце одной маленькой итерации отдавать клиенту что–то работающее. Смысл в получении обратной связи. Можем показать просто упаковку без продукта внутри. За счёт отклика клиента появится множество возможных вариантов что–то исправить.

И за те же деньги заказчик получит результат в разы лучше, чем при классическом способе работы. Он останется крайне доволен соотношением «стоимость–качество», а вы заслужите репутацию достойной фирмы.

Поговорим о некоторых тонкостях внутри Agile

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

Вот кейс на примере реальной жизни. Промышленной IT–компании нужно было создать интернет–магазин сопутствующих товаров, а они никогда такого не делали. Каким бы был ваш первый шаг?

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

Обратная связь – самое важное, что нужно получать как можно быстрее. Какие бы проекты мы не делали.

Cтруктурная составляющая проекта

В традиционной команде есть руководитель проекта, который за него отвечает. У него есть исполнители, которым нужно раздать задачи: что и в каком объёме сделать. Но не существует управленцев, которые могут создать идеальный план, который будет точь–в-точь совпадать с реальностью.

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

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

У команды должен быть тот, кто её вдохновляет, направляет к цели и говорит, куда и зачем они идут. В Agile–сообществе он часто называется Product Owner (владелец продукта). С ним "люди–руки" становятся "людьми–головами". И для них ВП создаёт такие условия, в которых они могут договариваться. Никто в Agile не отменяет бюджеты проекта, его сроки. Пусть люди ежедневно встречаются по 10 раз и решают, кому и чем лучше заняться сейчас, чтобы был максимальный результат.

У Agile–команды чаще возникают неорганизационные вопросы

Её интересуют вопросы по продукту, который они будут совместно делать. И ответы знает человек, который понимает, что они создают.

Представьте, что нужно внедрить SAP (автоматизацию бизнес–процессов) и получить на выходе какую–то бизнес–ценность: уменьшить количество ошибок или операций.

Как мы привыкли поступать?

Сначала описываем все требования и отдаём их на разработку подрядчику. Он у себя что–то делает, тестирует и возвращает нам. Готовый результат мы тестируем уже у себя, потом внедряем. Внести изменения в него в случае неудовлетворённости уже сложно, потому что деньги уже уплачены.

Как применить Agile в этом случае?

Очень просто! Есть огромное количество бизнес–процессов, которые можно автоматизировать. Мы даём подрядчику недельный план, в котором указываем, что наиболее важно в данный момент.

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

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

Как быть, если не хватает бюджета на единовременный контракт?

Мы можем договориться с подрядчиком о передаче специалистов в наш офис. Пусть они на месте делают автоматизацию бизнес–процессов. А мы будем платить не по fix-price контракту, а месячную зарплату.

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

Почему это сложно сделать в крупной компании?

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

Например, мы Agile–команда. Мы понимаем, что получим согласование на разработку продукта через 2 недели. Тогда пытаемся командно придумать, как получить одобрение быстрее.

Как правило, есть возможность ускорить реализацию за счёт личных взаимоотношений. Поверьте, это возможно сделать и в Сбербанке, и в Газпроме – компаниях с очень сильной бюрократией. "Люди–руки" получат ответ только через 2 недели, поэтому они не могут конкурировать в эффективности с "людьми–головами".

Как же переходить на новый подход?

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

В Сбербанке было так: Герман Греф однажды пришёл в офис и прокричал «Всем Agile!». Идея отличная, только люди были к ней не готовы. Поэтому процесс её внедрения сильно растянулся и сейчас почти не двигается. Лучше, когда есть пилотные команды внутри организации. Они начинают работать по–другому и заражают этим методом всех остальных.

Но есть и обратная сторона. Корпоративная культура ест Agile–процессы на завтрак, как говорится в поговорке. Поэтому нужна сильная поддержка менеджмента.

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

Agile – история про здравый смысл, а не про регламентированность

Все мы хотим делать то, что считаем правильным. Поэтому надо подбирать подходящих нам людей и использовать принципы Agile там, где это необходимо. Есть люди, которым трудно постоянно друг с другом общаться, пытаться быть лучше. Им необходима чёткая и точная задача, иначе они не дадут никакого результата. А есть те, кто на дух не переносит рутину. И Agile – то, что им крайне необходимо.

Самый большой минус

Удалённость, она мешает коммуникациям.

«Но мы же живём в мире быстрого и безлимитного интернета!» – можете возразить вы. Опираясь на наш опыт, заявляем – это всё равно хуже. Причём удалённость даже в масштабе двух этажей и соседних комнат уже снижает эффективность. Если люди находятся далеко от вас, то они становятся странными и неясными для нас, даже если это друзья–сотрудники из другого филиала. Появляется недопонимание. А когда они сидят рядом с нами — они часть нашей команды, мы видим их деятельность, они "свои".

Как реализуется agile в управлении проектами? Для agile–подхода к проектному менеджменту характерно несколько ключевых элементов.

Они по разному реализуются, в зависимости от конкретного фреймворка. Здесь мы рассмотрим все базовые особенности проектного менеджмента в agile.

Фокус на взаимодействие людей

Многие вопросы могут быть решены в результате человеческих взаимоотношений. Agile поощряет открытую коммуникацию.

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

Фокус на ценность продукта

Работая по agile, нас интересуют прежде всего не дедлайны и “правильность” рабочих процессов, а работоспособность и ценность итогового продукта, который получит клиент/заказчик.

Все внимание agile–команды направлено на работоспособный продукт.

Принцип инспекции

Для проектного менеджмента в духе agile важно находиться в контакте с новой поступающей информацией (например, новые конкуренты, новые технологии, изменение ситуации на рынке). Реализовать такой контакт с реальностью позволяет принцип инспекции.

Реализуя agile мы регулярно отслеживаем те изменения, которые происходят как внутри команды и в командных процессах, так и в “среде” — на рынке.

Принцип адаптации

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

Для реализации принципа адаптации в проектном менеджменте важно, чтобы все члены команды были открыты новому опыту и изменениям. Как правило в agile–команде есть человек, который отвечает за то, чтобы новые изменения были встречены позитивно (например, Скрам–мастер в Scrum).

Инкрементальный и итеративный подход

Реализуя управление проектами по agile, мы стремимся к тому, чтобы максимально часто и быстро давать заказчику результат.

Такой подход позволяет получать обратную связь чаще, и за счёт этого — еще лучше адаптировать реализацию проекта под заказчика, гибко подстраивать реализацию проекта в соответствии с обратной связью.

Планирование всей командой

Команда несет общую ответственность за результат.

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

Оценка при этом дается не в днях и часах, а условно — относительно относительно других задач, что позволяет принимать решения о том, что делать в следующую очередь в проекте, несмотря на неопределенность.

Резюме

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

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

Внедрение Agile в вашу проектную работу может снизить затраты на проект, повысить итоговую бизнес–ценность, позволит внести в процессы прозрачность и сделать результат более предсказуемым.

Подведём итог

Agile–философия подходит вашей компании, если:

  • над проектом работает опытная, высококвалифицированная команда
  • вы работаете над стартапом
  • нужно быстро получить рабочую версию продукта
  • заказчик выступает в качестве партнёра, а не инвестора
  • продукт разрабатывается в сфере, подверженной постоянным изменениям

И не подходит, если:

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

Главный пункт здесь – бюджет. Нам кажется, что мы тратим чуть больше денег, чем при классическом подходе. Но это лишь кажется, поверьте. На деле же мы получаем продукт, который нас удовлетворяет на 120%. И в итоге мы даже экономим!

Автор:
Коломенский Андрей из LeadStartup
Андрей Коломенский
— Мы в LeadStartup за прошлый год завершили 16 кейсов по росту прибыли и выводу новых продуктов на рынок.
Треть — убыточны, лучший кейс: 99% годового плана за полтора месяца. География рынков: Россия, США и Китай.
Если вы руководитель и отвечаете за деньги — давайте общаться. Дадим конкретику, как можно вырастить прибыль вашего продукта и релевантные кейсы.
Корпоративные программы LeadStartup
Корпоративные программы
Корпоративное обучение методологии запуска стартапов из кремниевой долины — Lean Startup и Customer Development
Lean Startup Customer Development Юнит–экономика Jobs To Be Done AARRR MVP & RAT Диффузия инноваций Проектирование бизнес–модели Разработка ценностных предложений Agile Scrum Kanban OKR Growth Hacking Design Thinking Business Agility
  • Тренинг Lean Startup Professional и бесплатные мероприятия — в Москве.
  • Вы получите навык запуска инноваций и вывод стартапов на рынок — сделаете первые продажи методом бережливого стратапа сразу на тренинге.
  • Мы — практики, а не инфоцыгане. У нас десятки кейсов запуска новых продуктов в рамках крупных компаний — финтех–стартапы, маркетплейсы, классифайды, включая международные проекты на рынках США и Китая.

Ответим вам по электронной почте в течение 1 часа
По телефону — мгновенно, ежедневно с 9:00 до 20:00