Что такое Agile-подход в бизнесе

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

Коллеги, простите.

Сразу предупредим: у нас тут не Википедия, а скорее уютненькое Луркоморье. Мы не претендуем на истину в последней инстанции, а рассказываем про наш опыт и стараемся «на пальцах» разобрать для новичков подход, о котором трубят из каждого утюга. Если вы с чем-то не согласный и какие-то вещи в статье вызывают у вас жжение ниже поясницы, пожалуйста, почитайте наши другие материалы.

Аджайл — не методология, а система ценностей. Да, мы тут в Oko все читали про agile software development как гибкую методологию разработки программного обеспечения. И про Аджайл-манифест тоже читали. И вот мы пришли к выводу, что на самом деле это не какая-то конкретная методология, а некий собирательный образ. Мы с командой решили, что аджайл — это комбинация подходов и методик управления, система ценностей, которая:

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

Тут вы можете сказать: — «А чего такого то, у нас в компании все эти принципы тоже работают. Подумаешь, аджайл…»

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

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

По аджайлу все члены команды равны. Какой-то четкой иерархии нет. У разработчика, менеджера и редактора, дизайнера и тестировщика полностью равные полномочия. Каждый сосредоточен на выполнении своей задачи. Если кто-то косячит, ломается работа всей команды — чем тебе не мотивация. Плюс, в команде есть product owner — человек, который фокусируется на ценности для клиента и решает, какие изменения мы будем внедрять в первую очередь.

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

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

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

Agile включает две методологии: Scrum и Kanban. Первая предполагает фиксированные по времени итерации — спринты, по результатам которых команда выполняет какой-то объем приоритетных работ, пока ресурсы спринта не исчерпаются. Вторая заточена на выполнение как можно большего объема работ и непрерывные релизы. Кстати, по принципу канбан-доски мы построили модуль «Сделки» и воронку продаж в OkoCRM.

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

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

В кругах разработчиков есть мнение, что agile — методология разработки. А вот и нет! Люди так характеризуют аджайл по аналогии с другими методологиями и подходами к разработке софта — RAD, RUP, XP и другими. Но тут есть кое-какие принципиальные отличия.

Аджайл — это 4 базовые ценности и 12 ключевых принципов. И все. А, например, те же RUP и XP — это десятки страниц технической документации, конкретные приемы, правила, инструменты и алгоритмы действий. Если нарушать эти правила, методология поломается, о какой-то гибкости речи не идет. Многие из таких методологий пытались упрощать и сокращать. Например, OpenUP более гибкая и простая в сравнении с RUP, но до agile ей далеко.

Вот Scrum — это уже методология. У него есть четкое распределение ролей в команде, конкретный набор мероприятий и алгоритмов, нарушение которых поломает работоспособность команды. А у agile нет конкретных процессов, элементов и правил. Есть высокоуровневые ценности и общие принципы.

В agile нет конкретных процессов, алгоритмов и жестких правил. Есть только ценности и принципы. Поэтому agile — не методология.

Всего их 4. Ценности системы сформулировала группа разработчиков еще в 2001 году. Позже их упаковали в единый манифест. Ценности аджайла сформулированы так, что есть X, который всегда важнее Y. Разработчики акцентируют внимание: важность Y нельзя отрицать, но X все-таки важнее.

Собственно, вот эти 4 ценности.

Люди и взаимодействие важнее процессов и инструментов

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

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

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

Это про работу на клиента. Чтобы люди были довольны, им нужна конфета. Пусть она будет некрасивая, но вкусная. Людям нужен работающий продукт, который закрывает их потребности. Пусть даже сырой и составленный не по рецепту.

Фокус команды нужно сосредоточить на выпуске продукта, которым получится как можно быстрее воспользоваться. А не составлении графиков и отчетов перед заказчиком.

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

Сотрудничество с заказчиком важнее согласования условий контракта

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

Компания «Ковка-штамповка» получила заказ на изготовление гаражных ворот для автомобильного кооператива. В договоре четко указали: 100 ворот, размером 2м х 4м, без дверей. Представитель компании выехал на место монтажа, пообщался с водителями, произвел замеры и выяснил: водителям нужны двери в воротах, а размер на самом деле нужен 2,3м на 4,2м. Чтобы выполнить заказ и удовлетворить потребности аудитории, компании нужно перезаключать договор. Или выпускать заведомо нежизнеспособный продукт — по условиям в договоре.

Чтобы продукт приносил ценность, заказчик должен быть в плотной коммуникации с исполнителем в процессе выполнения работ. Только так получится оперативно отработать изменения и внести нужные правки. В иной ситуации разработка затянется. Или продукт будет не очень.

Готовность к изменениям важнее, чем следование плану

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

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

Заказчик должен понимать: если речь идет о новых важных возможностях, можно и пожертвовать своими планами. Готовность клиента жертвовать чем-то запланированным тем более важна, когда у команды возникли проблемы и сроки уже сорваны. Если идти дальше по плану, есть риск сделать только хуже. Такова правда.

Вообще этих принципов 12 и они тоже есть в манифесте. Но вы помните, что agile — это не методология, а система ценностей без жестких правил (по крайней мере, в нашей интерпретации). Так вот из этих 12 мы выделили 8, которые важны именно для нас. Вот эти принципы.

1. Готовность легко менять техническое задание. Изменение требований приветствуется, даже если это происходит на поздних стадиях разработки. Можно смотреть на изменения как на «все пропало, косячим, аврал, нужно срочно переделывать» и прочее бла-бла-бла. У нас в Oko иное мнение. Мы рассматриваем изменения как способ обеспечить клиенту конкурентные преимущества. Даже если потребность в них выявлена на финальных стадиях.

2. Сдача проекта частями. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. Это вот как раз про итерации и расстановку приоритетов. Если выдавать результат по частям, есть возможность чаще вносить изменения в ТЗ, тестировать продукт и быстрее выдавать готовый результат.

3. Обратная связь от клиента на каждом этапе. Чтобы грамотно расставлять приоритеты и своевременно вносит изменения. А то вдруг мы придумаем себе одно, а клиенту на самом деле нужно что-то другое.

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

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

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

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

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

У аджайла есть преимущества и недостатки. Некоторые покажутся вам пустяками. А некоторые могут вызвать армагеддон в офисе и заблокировать работу команды на неделю. Чтобы вы могли сразу оценить риски внедрения этой системы, мы собрали преимущества и недостатки аджайла, основанные на нашем опыте. Итак.

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

Достаточно просто тихо следовать этим принципам, вот, как команда OkoCRM. Или заморочиться и придумать на основе этой философии свою систему. Вот, как Сбебанк — там придумали свой Sbergile, разработали набор инструментов для гибкого управления любой организацией и теперь продают его как отдельный продукт. Хитрые.

Аджайл давно вышел за пределы айти и разработки. Вот исследование от 2019 года. Оно говорит, что информационные технологии уже три года назад потеряли монополию на использование Agile-подхода. Из общего числа тех, кто его внедрил, лишь 41% айтишников. Остальные — банки и торговые сети, страховые компании и телекомы, промышленность и энергетика.

Из общего числа тех, кто внедрил agile, лишь 41% айтишников.

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

Когда стоит внедрять Agile-подход в управление бизнесом:

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

Когда НЕ стоит внедрять Agile-подход:

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

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

1. Аджайл называют методологией гибкой разработки софта. Но мы в Oko считаем, что это скорее философия — потому что в ней нет четких правил и условий, есть только высокие ценности и принципы. И их можно применять далеко за пределами разработки ПО
   
2. В аджайле работают короткими итерациями: собирают команду, которая раз в две-три недели выдает жизнеспособный результат. Сразу же его тестируют, оценивают эффективность и при необходимости меняют подходы — чтобы не тратить время зря
3. Agile ставит на первое место клиента и его потребности. Продукт должен нравиться ему и решать его задачи. Поэтому всю работу строим как раз на том, что сначала выясняем, что же нужно нашему конечному пользователю
4. Agile строится на 4 ценностях и 12 принципах. Каждый из них полезен по отдельности, поэтому на них стоит обратить внимание, даже если вы в целом не планируете внедрять Agile-подход
5. Agile внедряют далеко за пределами информационных технологий. Присмотритесь к этой системе, если ваша работа предполагает проектное управление. Неважно, это ритейл, легкая промышленость и страхование. Agile подойдет всем