Принципам agile: Основополагающие принципы Agile-манифеста

Разное 

Содержание

Принципы гибкой методологии управления проектами Agile: почему люди важнее бюрократии

Аджайл (Agile) – философия, определенный образ мышления с системой ценностей. Сторонники аджайла верят, что создать идеальный продукт или запустить проект могут самостоятельные команды из профессионалов. Замредактора Теплицы Наталья Баранова попросила менеджера «Альфа-банка» Артема Молчанова прокомментировать основные принципы, написанные в манифесте гибкой разработки Agile.

Разработчики и практики новых подходов разработали манифест гибкой разработки программного обеспечения (Agile Manifesto) в 2001 году. В нем они обозначили 12 постулатов и заявили, что люди, продукт, готовность к изменениям и сотрудничество с заказчиками гораздо выше бюрократических документов, долгих согласований и плана.

В it-подразделении банка «Альфа-лаборатории» четыре года используют принципы, описанные в манифесте. Подразделение из 300 человек поделено на 29 команд, все занимаются разработкой и улучшением интернет-банка и другими it-продуктами. Артем Молчанов убежден, что благодаря новым подходам увеличилась скорость создания продуктов, а сотрудники стали лучше понимать запросы клиентов.

Принцип 1: «Люди и взаимодействие важнее процессов и инструментов»

Многие интерпретируют этот принцип так: «Люди – важно, а инструменты – неважно». Это неверно. Важны и люди, и инструменты. Но в приоритете то, как люди взаимодействуют между собой. Например, в классическом подходе работы в компаниях фокус смещен далеко не на людей. «Идем по головам, чтобы достигнуть результата» – таков принцип. Но в аджайл все наоборот: важнее развивать потенциал людей и работать сообща. В итоге сотрудники работают командами, отвечая за результат не в одиночку, а вместе.

Еще по теме: Как управлять проектом с помощью методов Agile, Scrum и Kanban

Принцип 2: «Работающий продукт важнее исчерпывающей документации»

90% людей до сих пор приходят ко мне и говорят: «Мы же работаем по аджайл, у нас нет документации, как понять этот принцип?». Дело в том, что в аджайл тоже есть документация и договоры, просто эти компоненты на втором плане. Важнее конечный продукт, которым клиент будет пользоваться.

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

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

Принцип 3: «Сотрудничество с заказчиком важнее согласования условий контракта»

Об этом принципе многие забывают, но он дополняет самый первый – про важность взаимодействия людей. В классическом подходе работа над проектом выглядит так: it-подразделение и бизнес-подразделение работают отдельно. Бизнес в роли заказчика придумывает, закидывает тему разработчикам, через полгода приходит и спрашивает результат. Но за этот срок ничего не сделано.

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

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

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

Еще по теме: Scrum в деталях

Принцип 4: «Готовность к изменениям важнее следования первоначальному плану»

Этот принцип зачастую интерпретируют неверно: «Что бы ни произошло – это изменения». Этим тезисом очень легко манипулировать. Допустим, владелец продукта понял, что не учел что-то важное и все пропало. Он экстренно обращается к команде и говорит: «Мы все переиграли, будем делать вот так». Команда в недоумении: «Мы же так не договаривались», а владелец пожимает плечами и аргументирует: «Ну, извините, у нас аджайл». Но этот принцип вовсе не о подобном хаосе в работе.

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

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

Управление проектами на основе принципов Agile

Под редакцией руководителя программы Лорели Маллек

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

Среди первых, кто освоил принципы Agile-разработки, были в основном небольшие изолированные команды, работающие над маленькими отдельными проектами. Они доказали жизнеспособность модели Agile на радость и во благо создателям программного обеспечения из разных стран мира. В последние годы крупные организации стремятся вывести методику Agile за рамки отдельных команд и проектов. Они ищут способы применить ее к целым программам. Методика Agile распространилась за пределы команд разработчиков ПО и теперь используется в командах по ИТ, маркетингу, коммерческому развитию и многих других.

Что такое управление проектами по методике agile?

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

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

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

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

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

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

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

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

  • Управление блокерами и зависимостями. При управлении проектом в традиционном стиле часто опираются на понятие «критического пути». Его суть в том, что работу над проектом нельзя продолжать, пока не будет устранена проблема-блокер.
  • Сложность проверки пригодности продукта и сбора обратной связи от пользователей. Конечный пользователь сможет «потрогать» продукт, только когда он будет полностью завершен, поэтому все серьезные проблемы в исполнении продукта и коде становятся явными только после релиза.

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

Итеративный подход к выпуску релизов открывает множество возможностей для команды.

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

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

Более значимое преимущество заключается в том, что участники команды разработчиков обладают общим набором навыков. Как следствие, работа становится более открытой к изменениям во всех частях базы кода команды. Так усилия и время не окажутся потраченными впустую, если изменится направление проекта. (Подробнее об этом читайте в нашей статье о создании успешной Agile-команды.)

Принципы Agile

  • Agile-проект делится на множество небольших шагов с регулярными циклами обратной связи.
  • Требования к проекту разделяются на мелкие части, которым затем присваивается определенный приоритет.
  • Подход способствует совместной работе (особенно с клиентом).
  • Процесс регулярно корректируется для удовлетворения потребностей клиента.
  • Интеграция исполнения и планирования позволяет команде эффективно реагировать на изменение требований.

Факторы, которые необходимо учитывать при переходе на модель Agile

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

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

Давайте посмотрим, за счет каких механизмов в agile-программах работа упорядочивается, движется и структурируется в виде итераций.

План действий

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

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

Требования

Каждая инициатива на дорожной карте подразделяется на ряд требований. В методике Agile требования представляют собой упрощенные описания необходимых функциональных возможностей (никаких документов на 100 страниц, характерных для традиционных проектов). Со временем требования развиваются, впитывая коллективные знания команды о клиенте и требуемом продукте. Agile-требования остаются лаконичными, пока в команде идет постоянный обмен информацией и взаимодействие для выработки общего понимания. Требования начинают обрастать более точными деталями лишь незадолго до реализации.

Бэклог

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

Метрики agile

Показатели в Agile определяют успех команд. Ограничения незавершенной работы (WIP) позволяют команде (и компании в целом) сосредоточить основные усилия на более важной работе. С учетом диаграмм Burndown и контрольных диаграмм команда может прогнозировать график поставки, а с помощью диаграмм непрерывного процесса — выявлять проблемные места. Эти показатели и артефакты поддерживают общую сосредоточенность на больших целях и формируют уверенность в том, что команды способны выполнить намеченную работу.

Agile строится на доверии

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

Заключение

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

Подробнее об управлении agile-проектами. Кроме того ознакомьтесь с рекомендациями по внедрению Agile-подхода в командах разработчиков ПО при помощи инструментов Agile.

Поделитесь этой статьей

Dan Radigan

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

Agile методологии управления проектами

Agile – это термин, который объединяет ряд способов реализации проектов, основанных на гибком, неформализованном подходе. В статье разберем основные принципы Agile и дадим рекомендации по применению инструментов гибких методологий.

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

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

Вы наверняка слышали такие термины как SCRUM, Crystal, DSDN, Extreme programming – все это подмножества множества Agile, есть и другие agile-методики, которые упоминаются не так часто.

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

Как возник Agile

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

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

На тот момент в ходу был метод «водопада» (waterfall) – последовательной разработки программного продукта из шести стадий:

  1. Формирование системных и программных требований.
  2. Анализ требований, существующих процессов и т.п.
  3. Дизайн архитектуры программного обеспечения.
  4. Непосредственно написание программного кода.
  5. Тестирование и исправление ошибок, выявленных тестерами.
  6. Внедрение и исправление ошибок, выявленных пользователями.

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

Но в конце 70-х годов особенности метода последовательной разработки стали ее недостатками: отсутствие гибкости в ответ на изменение условий; жесткость в отношении этапов проекта; зарегламентированность / бюрократия – все это мешало разработке массового программного обеспечения.

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

Гибкие методы появлялись органично в ответ на условия конкуренции:

  • если нет определенности в отношении финальных параметров продукта, не нужны жесткие спецификации – используем список пожеланий к продукту (back-log), который может меняться и дополняться по мере развития проекта;
  • если данные о требованиях рынка противоречивы, и единственное решение – как можно быстрее показать конечному клиенту или начать продавать, то делим продукт на части, которые сразу можно использовать или выпускаем MVP – минимальный жизнеспособный продукт (minimum viable product).
  • если сроки «жмут», надо поставить график перед лицом, а для наглядности заменить его доской «Канбан» (см. также про бережливое производство). И так далее.

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

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

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

О принципах Agile четко и ясно

Все основные принципы гибкой разработки изложены в одном документе – Манифесте (Agile Manifesto, 2001). Выше я уже несколько раз упоминал отдельные принципы, лежащие в методологиях объединяемых Agile.

Основные постулаты:

  1. Люди и взаимодействие важнее процессов и инструментов – акцент на людях и отношениях между ними, как основном факторе успешности проекта. Люди руководят и применяют необходимые им процессы и инструменты, а не работают под управлением заранее принятого регламента. Именно поэтому agile-методики предполагают отбор в команду мотивированных профессионалов, с универсальными навыками. Тогда не потребуется внедрять изощренные методы поощрений и штрафов, люди смогут подменять другу друга, участвовать в дискуссии о продукте осознанно и эффективно. Взаимодействие между членами команды может строиться с помощью любых удобных инструментов, но не документов, регламентов и инструкций.
  2. Работающий продукт важнее исчерпывающей документации – менять, адаптировать, корректировать легче то, что уже существует и работает, а не то, что подробно и исчерпывающе описано в бумагах. Сначала надо сделать что-то простое и работающее, чтобы затем, оценив и апробировав сделанное, внести коррективы или отказаться от реализованного в пользу иного варианта исполнения. Но в итоге либо продукт есть и работает (пусть и требует корректировок, дополнений и доработки), либо есть проверенная гипотеза, от которой надо отказаться. В противном случае в большинстве случаев будет реализован проект, точно соответствующий описанию на бумаге, но не соответствующий рынку, производству, и главное реальным нуждам клиента.
  3. Сотрудничество с заказчиком важнее согласований условий контракта – в сложившейся реальности заказчик – а им может быть и соответствующее подразделение внутри компании – не всегда может четко сформулировать требования к продукту, зачастую у него есть только профиль клиента и проблема, с которой тот сталкивается. Заказчик может оценить реализованный продукт с точки зрения соответствия его ожиданиям, но не формализовать их. Ему легче потратить время и деньги на версии продукта, чем на всестороннее и исчерпывающее описание, причем такое описание может оказаться более дорогим, трудоемким и затратным по времени, чем гибкая разработка. Методом оптимизации в данном случае как раз и будет сотрудничество с заказчиком, вовлечение его в работу проектной команды.
  4. Готовность к изменениям важнее следованию первоначальному плану – это, наверное, самый противоречивый постулат. С одной стороны легче и проще менять все по ходу реализации, с другой — процесс такой разработки может затянуться на неконтролируемое время и привести к неожидаемым результатам.

Ключевые принципы гибкой разработки, изложенные в Манифесте:

  1. Удовлетворение клиента за счет ранней и бесперебойной поставки ценного программного обеспечения. Данный принцип относится не только к программному обеспечению. Согласно этому принципу работу над продуктом следует разделить так, чтобы по завершении каждого цикла (спринта клиент получал рабочую версию продукта.

    На примере калькулятора для анализа проекта:

    • по завершении первого спринта вычисляется NPV в Microsoft Excel – все основные формулы работают, ошибок нет, выдается только финальная цифра – рассчитанный NPV;
    • по завершении второго спринта NPV рассчитывается также как по итогам первого спринта, но добавляется функциональность – комментарий о полученном значении, расчет IRR и других критериев – для более полной картины;
    • по завершении третьего спринта на основе разработанной в первых двух спринтах логики и формул, выверенных и согласованных с заказчиков текстов готовится десктопная версия продукта;
    • по завершению четвертого спринта готовится мобильная версия продукта и… вуаля! Продукт готов к использованию для задач заказчика.
  2. Изменения требований приветствуются. Разработка продукта ведется в быстроменяющейся конкурентной среде, когда по завершении цикла разработки уже может измениться рынок, например, вышел аналог. Тогда, чтобы не выкинуть в мусорную корзину реализованный проект, его дорабатывают, кстати, можно использовать опыт уже вышедшего на рынок конкурента. Поэтому в рамках гибкого подхода изменения требований продуктов даже в конце разработки – приемлемы и приветствуется.
  3. Частая поставка рабочего программного продукта. Важность этого принципа все в том же – мир быстро меняется и чем короче цикл поставки, тем точнее финальный продукт будет соответствовать ожиданиям.
  4. Погружение заказчика в работу над проектом на протяжении всего времени его реализации. Заказчик в этом случае является единственным участником команды, носителем знания, «как надо», соответственно его заключение о соответствии продукта ожиданиям и его удовлетворение от результата – ключевой критерий. Чем чаще ожидания заказчика сопоставляются с работой команды проекта, тем, естественно, выше соответствие ожиданий и результата.
  5. Проектом занимаются мотивированные личности, которые обеспечены соответствующими условиями работы, поддержкой и доверием. Этим принципом проблемы мотивации выводятся за рамки работы над проектом. Предполагается, что на этапе формирования команды, необходимо отбирать только мотивированных профессионалов, самодостаточных личностей, которых не надо подгонять, уговаривать и т.п. Задача сведется только к созданию условий, не препятствующих реализации их потенциала в этом проекте: инструменты связи, возможности для взаимодействия, оборудование и материалы и др.
  6. Рекомендуемый метод коммуникации – лицом к лицу. Это спорный принцип в цифровую эпоху, когда многие компании развивают сетевое взаимодействие и внедряют удаленную работу в свои процессы. При этом личное взаимодействие имеет ряд преимуществ, которых нет у других видов коммуникации: например, скорость решения вопросов, невербальные сигналы (эмоции, жесты), мотивация (можно похвалить, выделить, поставить «на место»). В любом случае манифест акцентирует на этом внимание и заявляет, как один из ключевых принципов.
  7. Работающее программное обеспечение – лучший измеритель прогресса. Перенося этот принцип на более общую систему координат, работающая версия продукта — лучший критерий успешности и прогресса проекта. В большом числе случаев этот принцип реализуем и понятен, а там, где не применим Agile.
  8. Разработчики, а также их куратор и заказчик должны быть готовы сохранять заданный темп в разработке в течение не определенного (читай — неограниченного) времени. Надо понимать, что в такой парадигме срок разработки финальной версии продукта не известен, более того, финальной версии может и не быть, что мы видим на примере постоянно шлифуемых и дорабатываемых версий десктопного программного обеспечения и мобильных приложений.
  9. Краеугольным камнем Agile-разработки заявляется стремление к техническому совершенству и качеству планирования спринтов. Этот принцип призван сбалансировать возможный негативный эффект на качество разработки от других принципов, например, частой поставки рабочего продукта. Можно разными методами добиваться частой поставки в условиях отсутствия или недостатка спецификаций продукта, например, использовать готовый, но некачественный код разработанный «индийскими программистами» и пренебречь тестированием. Личные качества, профессионализм разработчиков и коллективная ответственность – заложенные в принципе «стремления к техническому совершенству» требуют более высокого уровня ответственности.
  10. Простота и минимизация лишней работы. Этот принцип надо бы применять во всех проектах, но в качестве ключевого принципа он заложен только в Agile-методиках. Приоритет отдается тому, что делается быстро с минимальными затратами. Отказываемся от ненужных работ как в процессах, так и в отношении продукта, например, консалтинговая компания обычно готовит многостраничную презентацию по выполненным работам и предполагаемым шагам, но если клиент интегрирован в команду, то ему формальная бумага не нужна, ему важнее то, что уже идет в работу – те самые два-три слайда, которые уже готовы для финальной презентации. В отношении продукта – можно стремиться реализовать все задумки в отношении функционала сразу до первого релиза, однако так уже никто не делает, в каждой итерации продукт совершенствует в соответствии с требованиями рынка, что может подразумевать как добавление нового функционала, так и удаление каких-то фич, не «принятых» клиентами.
  11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Речь идет не об анархии, а о высокой внутренней дисциплине в команде, четком распределении ролей и высоком уровне профессионализма каждого участника. Если вы не можете самоорганизовываться – не работайте в концепции Agile.
  12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Этот принцип подчеркивает, что вся полнота ответственности за проект и его продукт лежит на всех членах команды, никто со стороны не вносит корректив и не анализирует эффективность – все делают участники внутри своего коллектива в интересах проекта и результата.

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

Области применения Agile

Agile в своем максимальном объеме применим и эффективен при создании продуктов, которых:

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

Таким образом, применение agile-методов оправданно в следующих сферах бизнеса:

  1. Программное обеспечение для массового сегмента, в том числе мобильные приложения, игры и т.п.
  2. Стартап-проекты – это идеальная почва для внедрения гибких методологий.
  3. Интернет-порталы и СМИ.
  4. Медицинские проекты – тело человека до сих пор в значительной мере «терра инкогнита», что создает высокую долю неопределенности в медицине.
  5. Образовательные продукты и проекты. Если мы говорим о чем-то новом, а не о компиляции старых методов и практик, то образовательные проекты – стартапы на неизведанной территории, все ищут новые методы цифровой эпохи на замену старым технологиям индустриального мира.
  6. Консалтинг – любой проект в этой сфере требует применения большинства принципов Agile Manifesto. McKinsey однозначно используют методику соответствующую указанным принципам.
  7. Разработка финансовых и страховых продуктов (индустрия финтех), так как финансовые компании сегодня, это в большой степени ИТ-компании, а финансовый продукт уже стал в значительной степени ИТ-продуктом или применяет результаты работы ИТ-проектов/продуктов.

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

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

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

10 принципов гибкого планирования в бизнесе

Изучите основные принципы гибкого маркетинга, чтобы выжать из него максимум пользы:

1. Тщательное изучите целевую аудиторию

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

2. Приготовьтесь быстро внедрять новые инструменты

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

3. Не бойтесь наступать на грабли, но обходите их в следующие разы

Принимая решения быстро, вы точно будете ошибаться. Сработают далеко не все инструменты agile-маркетинга. Но нужно понимать, что не ошибаются только те, кто ничего не делает. Главное делать правильные выводы и учиться на своих проколах.

4. Откажитесь от перфекционизма

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

5. Создавайте краткосрочные маркетинговые планы с быстрым сроком реализации

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

В 2016 году сервис Periscope от Twitter Inc. очень быстро набрал популярность. Десятки тысяч русскоязычных пользователей ежедневно пользовались приложением для прямых трансляций с мобильных устройств. Тогда это было в новинку. Олесь Тимофеев тут же создал свой канал и начал вести эфиры. Даже не разбираясь толком с принципами использования платформы.

С помощью правильного продвижения Олесь быстро привлек целевую аудиторию в течение минимального времени:

Как сделать маркетинг эффективнее по принципам Agile | Академия Лидогенерации | Официальный сайт

Термин «Agile-маркетинг» все чаще встречается в статьях и исследованиях. Что это такое и как Agile может помочь в работе? Давайте с этим подробно разберемся.

Чем Agile отличается от традиционных подходов к маркетингу

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

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

Вот главные отличия этого вида маркетинга от традиционного:

  • Постоянное тестирование и опора только на факты. Мнение специалистов — не безусловный аргумент, все гипотезы нужно проверять на практике. Только практика — критерий истины.
  • Максимально быстрая реакция на любые изменения. Каждый месяц или неделю нужно собирать обратную связь и вносить необходимые изменения в работу.
  • Тесное коллективное сотрудничество. Важно работать вместе и развивать потенциал каждого члена команды. За конечный результат тоже отвечают все специалисты вместе.
  • Персональный подход. Каждый проект уникален. А значит, в каждом случае нужно глубоко разбираться и подбирать оптимальные инструменты под конкретные задачи.
  • Фокусировка на пользователе. Тесное сотрудничество с клиентами обязательно — это напрямую влияет на результат.

Разберем каждое из этих отличий на конкретных примерах.

Тестирование и факты

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

  • Была ли протестирована идея?
  • Какие получены данные?
  • Правильно ли составлены метрики?

Российский метапоисковик авиабилетов Aviasales еще в 2013 году решил сделать редизайн сайта. Для этого он провел А/В тестирование, и результат превзошел ожидания — новый формат поиска билетов стал привлекать на 73% больше посетителей:

А вот «Кинопоиск» в похожей ситуации не стал углубляться в тестирование. В итоге попытка обновить дизайн в 2015 году провалилась. Новый сайт раскритиковали, и пришлось вернуться к старому дизайну.

Реакция на любые изменения

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

Хороший пример — стихийные интернет-флешмобы. В 2017 году владелец Telegram Павел Дуров опубликовал пост: «7 вещей, от которых я отказался»:

В этот же день бренды сделали аналогичные публикации, сопроводив их хэштегом #7вещей. Среди них были:

Dodo Pizza

Билайн

И даже МЧС России

Не отставали и маленькие компании. У большинства получилось не очень. Но были и интересные креативы — например, у московского каршеринга Belka Car:

Если бы бренды выпустили только запланированные картинки и тексты вместо креативных постов, это вызвало бы куда меньший отклик.

Сотрудничество

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

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

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

С помощью Agile можно объединить людей, а чтобы это не доставляло им неудобств — упростить взаимодействие между ними. Для этого Agile-команды используют несколько методик — например, Kanban и Scrum.

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

  • Физические — обычные или магнитные доски с клеточками. Для задач используются листки-стикеры, которые можно передвигать из клетки в клетку. Например, в компании Билайн это выглядит так:

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

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

Кроме специалистов, команда scrum включает владельца продукта и мастера, организующего всю работу. Задачи мастера:

  • Отвечать за соблюдение методологии
  • Замечать скрытые проблемы
  • Устранять все препятствия, которые мешают работе
  • Вести собрания

Владелец продукта определяет ход ведения проекта. Этот человек устанавливает приоритет каждой задачи. В конце дня вся команда отвечает на вопросы:

  • Что уже сделано?
  • Что осталось сделать?
  • С чем возникли проблемы?

Персональный подход

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

К примеру, можно написать чат-бота и внедрить его в собственный сервис, чтобы искусственный интеллект собирал информацию о клиентах. Согласно совместному исследованию компаний SAP Hybris и Forrester Consulting, только 16% маркетологов понимает желания потребителя. Боты помогают увеличить этот показатель.

По такому принципу уже работают многие компании. Например, российский бренд интернет-рекрутинга Head Hunter внедрил бота по поиску вакансий. Робот помогает пользователям и собирает данных о них. Он умеет:

  • Подбирать для клиента желаемую вакансию
  • Выбирать определенных работодателей
  • Подсказывать ответы на интересующие вопросы.

Можно поступить и иначе — как агентство интернет-маркетинга InWeb. Агентство внедрило методики Agile в отдел платного трафика. Дело в том, что раньше время запуска одной рекламной кампании составляло от 2 до 4 недель — а ведь у предпринимателя может быть сезонный бизнес, поэтому все нужно организовывать быстрее. Тут и пригодились методы Agile-маркетинга.

Сначала в агентстве собрали и визуализировали всю необходимую информацию. Затем сформировали «карту состояний»:

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

  • Время выполнения одного проекта снизилось до недели
  • Сотрудники стали ощущать прямую причастность к успеху общего дела
  • Исчезла проблема «забытых» проектов
  • Специалисты повысили свой профессиональный уровень

Фокусировка на пользователе

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

В Сбербанке еще 5 лет назад использовали Agile-маркетинг при разработке мобильного приложения. Нужно было сделать его удобным для пользователей, поэтому банк заранее опросил тысячи своих клиентов. В анкетах они указывали, что хотят видеть в приложении. Результат получился таким:

С ростом доверия к продукту растет и число клиентов компании

Сложности использования Agile

Главная проблема — стереотипы. Многие предпочитают работать по старым методикам, так как считают, что Agile «никому не нужен и никогда не заработает». Пока еще Agile-маркетинг — нечто новое и непривычное.

Обычно Agile внедряют поэтапно:

  1. Выбор методики. Сперва нужно определиться с целями, задачами, сроками, количеством сотрудников и т. д. Затем — найти систему управления проектом, которая отвечает всем требованиям.
  2. Демонстрация Agile. На этом этапе приглашенный специалист показывает, как работает методика, рассказывает о правильном взаимодействии между командами, объясняет роли каждого участника.
  3. Обучение персонала. Сотрудники должны понимать, для чего им нужен Agile. На этой стадии можно понять, готов ли коллектив к изменениям, и подойдет ли вообще компании метод гибкого планирования.
  4. Создание команды. Распределяются обязанности и задачи, создается график встреч. Кто-то из сотрудников может перейти работать в другой отдел, если это поможет общему делу.

 

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

Как может выглядеть Agile на уровне специалиста-маркетолога

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

Утром Коля приходит в офис и узнает, что сегодня пора приступать к новому проекту. Руководитель собирает сотрудников — в течение получаса происходит разбор текущей ситуации. Отслеживать рабочий процесс договариваются на двух канбан-досках: обычной и электронной (будет использоваться Trello).

Николай предлагает свои варианты карточек на досках. К нему прислушиваются, так как он старший маркетолог. Зафиксировав «нулевую отметку» по основным показателям, сотрудники делятся на несколько команд по 5-7 человек.

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

День подходит к концу. Руководитель проекта созывает всех на совещание — еще утром его назначили на 18:00. Каждый предлагает новые идеи, которые появились во время работы. Самые интересные варианты руководитель заносит в Trello и формирует список задач на завтра.

Запомнить

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

Расскажите, а вы используете Agile-маркетинг? Поделитесь своими методиками в комментариях

Как применить принципы agile в маркетинге

Политика публикации отзывов

Приветствуем вас в сообществе читающих людей! Мы всегда рады вашим отзывам на наши книги, и предлагаем поделиться своими впечатлениями прямо на сайте издательства АСТ. На нашем сайте действует система премодерации отзывов: вы пишете отзыв, наша команда его читает, после чего он появляется на сайте. Чтобы отзыв был опубликован, он должен соответствовать нескольким простым правилам:

1. Мы хотим увидеть ваш уникальный опыт

На странице книги мы опубликуем уникальные отзывы, которые написали лично вы о конкретной прочитанной вами книге. Общие впечатления о работе издательства, авторах, книгах, сериях, а также замечания по технической стороне работы сайта вы можете оставить в наших социальных сетях или обратиться к нам по почте support@ast. ru.

2. Мы за вежливость

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

3. Ваш отзыв должно быть удобно читать

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

4. Отзыв не должен содержать сторонние ссылки

Мы не принимаем к публикации отзывы, содержащие ссылки на любые сторонние ресурсы.

5. Для замечаний по качеству изданий есть кнопка «Жалобная книга»

Если вы купили книгу, в которой перепутаны местами страницы, страниц не хватает, встречаются ошибки и/или опечатки, пожалуйста, сообщите нам об этом на странице этой книги через форму «Дайте жалобную книгу».

Недовольны качеством издания?
Дайте жалобную книгу