Как использовать Agile-методы в бизнесе: 9 приемов и кейсы

Agile-метод «узаконен» манифестом февраля 2001 года. Предпосылками к его появлению стал видимый разрыв между ростом стоимости компании и скоростью выведения на рынок IT-продуктов малыми стартами и признанных «монстров» IT-разработки.

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

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

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

Итак, вот какие приемы использовали компании, которые перешли на Agile.

1. Всегда ориентируйтесь на клиента

Заказчик всегда в приоритете со своими требованиями и пожеланияvb.

Эксперт образовательного проекта EdMarket, экс-сотрудник «Европлан», РЖД и «Росатома» Елена Денисова описала кейс:

«Тогда это еще не называлось эджайлом, но это была самая гибкая, самая клиенториентированная история в сочетании как раз с автоматизацией, с процессами и полным отсутствием документации на эту тему, четких договоренностей и контроля результатов. Это была работа с независимым Интернет-провайдером в Москве. У меня была достаточно амбициозная цель укомплектовать компанию сотрудниками на сдельную оплату труда. Под эту цель нужна была команда, которая состояла бы из 16 рекрутеров».

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

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

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

2. Отдавайте предпочтение рабочему программному обеспечению, а не документации

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

Если в системе заказчик подтверждает наличие кандидата, мы его акцептуем, он вводится в систему, позиция считается закрытой. Когда у тебя есть задача подобрать от 300 до 600 человек в месяц – такой подход очень важен. И пока ты будешь писать бумаги, а у тебя бизнес-процесс гибкий, он может устареть».

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

3. Выстройте гибкую и оперативную работу с бизнес-процессами и персоналом

Как достичь гибкости и оперативности? Самое главное – постоянное взаимодействие с персоналом: 15-минутные встречи с каждой из групп, операционная встреча общего характера раз в неделю со всеми группами с целью целеполагания на месяц. Еженедельный контроль результата. И 15-минутки в случае изменений с каждым из руководителей групп.

«В случае, если нам было необходимо перебросить ресурсы, мы это делали, – говорит Елена Денисова. – Это было очень мягко, удобно, потому что все сотрудники находились рядом в одном пространстве, слышали друг друга и могли поддержать руководство в этом плане».

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

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

4. Зафиксируйте четкий промежуток времени (спринт), в течение которого должны выполняться задачи

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

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

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

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

5. Создайте самоорганизующиеся команды

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

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

6. Измените должностные инструкции

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

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

7. Используйте Lean подход

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

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

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

8. Выстройте эффективные коммуникации между сотрудниками, клиентами и руководством

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

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

9. Предоставьте людям самостоятельность, творчество. Используйте к ним индивидуальный подход

«Людям начинают давать возможность влиять на процессы, быть активными участниками того, что они делают, – говорит генеральный директор компании  «Управед» Борис Тунников. – Принципиально новое в том, что сейчас происходит – это переход от управления через иерархию, к управлению через создание среды. Иерархия – это когда из людей вытачивают шестеренки и пытаются загнать в некие рамки. Стало очевидно, что когда этот подход масштабируется, мы получаем крайне инертную неповоротливую систему, которая не работает в современных условиях».

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

«Важно наличие общей цели, желательно хоть как-то коррелирующей с их личностными ожиданиями, – говорит Борис Тунников. – Также важно не только ставить задачи соответствующего уровня, но и предоставлять соответствующие полномочия. Причем, достаточно принципиальные – например, полномочия на изменение бизнес-процессов. Если круг сотрудников говорит, что им удобно работать в определенных условиях, то существующие надо поменять».

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

Что нужно сделать в части HR для внедрения Agile?

  1. Лидеры (оставшиеся руководители) должны стать носителями Agile-принципов – Обучите их.
  2. Стирайте классические границы «начальник-подчиненный». Функции планирования и контроля переходят командам, у начальника остается обучение, коучинг, недопущение и разрешение ситуаций «неуспеха».
  3. Примите решение, в каких процессах, проектах и подразделениях будет применяться непосредственно Agile-разработка, а в каких – принципы принятия решений, коммуникации и действий Agile.
  4. Организационная структура должна отражать «самый короткий путь» создания основных продуктов компании. Уменьшите количество уровней управления, уберите контролеров, создайте постоянно действующие рабочие команды, создающие ваш продукт.
  5. Команда должна быть вместе – Организуйте рабочие места для команд.
  6. Agile-метод должен стать «родным» для компании – адаптируйте Agile на нескольких небольших тестовых проектах-пионерах. Создайте свой Манифест.
  7. Каскадируйте свой Agile на все команды через внутреннее обучение.
  8. При найме сотрудников отбирайте тех, кто понимает и разделяет принципы Agile.
  9. Гордитесь успехами Agile-команд! Делитесь этими успехами, используя разные каналы коммуникации и корпоративные мероприятия.
  10. Поощряйте подход «проблема – это возможность» для достижения лучшего результата.
  11. «Работающий продукт — основной показатель прогресса».

Дорогу осилит идущий!

Читайте также:

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

это да.. 

Но обычно, хотя може быть я и не прав, в ТЗ указываются итоговые требования к ПО, или "окончательные требования будут уточнены на этапах .... "  Ну и это может быть трактовано довольно широко.. 

Researcher, Москва

Решил процитировать себя на эту тему:

Agile: как сделать гибкой всю вашу компанию | Executive.ru (e-xecutive.ru)

 

О статье:

Что ж делать?.. Речью неискусной
Занять ваш ум мне не дано...
Все это было бы смешно,
Когда бы не было так грустно… (М.Лермонтов)

Смешно - когда ради рекламы и чтоб "прокукарекать" консультанты цепляются за любое звучное слово/термин.

Грустно что такие статьи серьезно обсуждаются …

Agile как идеология родилась в недрах информационных технологий как подход к решению проблемы взаимодействия команды разработчика ПО (программного обеспечения) и ЗАКАЗЧИКА из бизнес-среды.

А сама проблема заключалась в том, что ЗАКАЗЧИК не мог четко и однозначно сформулировать ТРЕБОВАНИЯ к ПО. Неоднозначность ТРЕБОВАНИЙ вызывала необходимость делить всю разработку на этапы и согласовывать каждый следующий этап после передачи ЗАКАЗЧИКУ предыдущего.

Понятно, что при планировании каждого следующего этапа, при коллективной разработке, требуется согласование действий каждого из разработчиков. Ведь они все! должны закончить этап ОДНОВРЕМЕННО и передать ЗАКАЗЧИКУ.

Я это описал к тому что ОСНОВНОЙ игрок - ЗАКАЗЧИК, основная цели проекта УДОВЛЕТВОРЕНИЕ заказчика, задача команды разработчиков ОРГАНИЗОВАТЬ свой труд согласно цели!!.

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

Поэтому я считаю, что нет Заказчика с неопределёнными требованиями к продукту -- НЕТ И AGILE.

При утвержденном ТЗ (техническом задании) никакого Agile не нужно.

Руководитель, Москва
Валерий Овсий пишет:
При утвержденном ТЗ (техническом задании) никакого Agile не нужно.

Я бы еще добавил, если внешние условия меняеются не очень сильно. 

IT-менеджер, Москва
Валерий Овсий пишет:
Организация труда разработчиков ПО - это и есть методы управления, и они могут быть самые разные

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

Если не ошибаюсь, Михаил Кузнецов писал, что есть только один метод управления - цикл PDCA.

Но если их много, значит можно перечислить эти методы управления?

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

это да.. 

Но обычно, хотя може быть я и не прав, в ТЗ указываются итоговые требования к ПО, или "окончательные требования будут уточнены на этапах .... "  Ну и это может быть трактовано довольно широко.. 

Обычно все проще - если следовать логике и требованиям к содержанию ТЗ, которое подробно описано в стандарте.

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

Сугубые детали реализации (!) этих требований должны быть представлены в будущих документах на этапах проектирования и создания продукта. Это честно.

Генеральный директор, Москва
Валерий Овсий пишет:

Решил процитировать себя на эту тему:

Agile: как сделать гибкой всю вашу компанию | Executive.ru (e-xecutive.ru)

Если Ваше мнение по обсуждаемым вопросам с тех пор не изменилось ...

Agile как идеология родилась в недрах информационных технологий как подход к решению проблемы взаимодействия команды разработчика ПО (программного обеспечения) и ЗАКАЗЧИКА из бизнес-среды.

Если мы про идеи Agile Manifesto - это не идеология, скорее методология. Многие из авторов - профессионалы высокого полета, работавшие над своими вариантами (XP, Scrum ...) подходов к созданию крупных программных систем.

А сама проблема заключалась в том, что ЗАКАЗЧИК не мог четко и однозначно сформулировать ТРЕБОВАНИЯ к ПО. Неоднозначность ТРЕБОВАНИЙ вызывала необходимость делить всю разработку на этапы и согласовывать каждый следующий этап после передачи ЗАКАЗЧИКУ предыдущего.

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

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

Стандартизованный подход к проектированию систем ПО и методология Waterfall предполагали согласование и фиксацию требований к ПО до начала разработки. Никаких пороков в таком подходе нет, но в крупных и долгих проектах это слишком часто приводило к ситуации, при которой требования заказчика через какое-то время менялись (по любым причинам), а разработку нельзя было останавливать. Этапность, кстати, совершенно естественна для проекта и никому не мешала.

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

Понятно, что при планировании каждого следующего этапа, при коллективной разработке, требуется согласование действий каждого из разработчиков. Ведь они все! должны закончить этап ОДНОВРЕМЕННО и передать ЗАКАЗЧИКУ.

А можно как-то иначе? Действия разработчиков не нужно согласовывать?
И не каждый этап проекта предполагает передачу результатов разработки заказчику.

Я это описал к тому что ...  основная цели проекта УДОВЛЕТВОРЕНИЕ заказчика ...

Совершенно верно.

Поэтому я считаю, что нет Заказчика с неопределёнными требованиями к продукту -- НЕТ И AGILE.

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

При утвержденном ТЗ (техническом задании) никакого Agile не нужно.

Посмотрим на весь проект.

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

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

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

Но увы. В настолько детерминированном мире мы пока не живем.

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

это да.. 

Но обычно, хотя може быть я и не прав, в ТЗ указываются итоговые требования к ПО, или "окончательные требования будут уточнены на этапах .... "  Ну и это может быть трактовано довольно широко.. 

Совершенно верно - зависит от требований.

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

Генеральный директор, Москва
Валерий Овсий пишет:

Я это описал к тому что ОСНОВНОЙ игрок - ЗАКАЗЧИК, основная цели проекта УДОВЛЕТВОРЕНИЕ заказчика ...

FYI ... получил в утренней рассылке несколько слов и ссылок по поводу проекта по расчистке второго в мире (после Чернобыля) захоронения токсичных отходов.

Если коротко: там в полный рост использовали XP (eXtreme Programming) для разработки некой сложной и полностью заказной системы ПО задолго до волны разговоров и массового применения Scrum.

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

 

 

Researcher, Москва
Евгений Равич пишет:
Если мы про идеи Agile Manifesto - это не идеология, скорее методология. Многие из авторов - профессионалы высокого полета, работавшие над своими вариантами (XP, Scrum ...) подходов к созданию крупных программных систем.

Если пожонглировать терминами, то можно и так. 

У нас, по крайней мере в группе компаний мне знакомых по разработке ПО, называют Agile - идеологией, а Scram - технологией разработки. 
Как назвать ЭТО есть  мало значимая проблема по сравнению с той - как использовать и Agile и Scram.

Евгений Равич пишет:
Такой проблемы. насколько я понимаю, вообще никогда не было.

Я не знаю Ваш опыт и Ваших заказчиков. Наверное у Вас так.

Я уже здесь как то рассказывал случай (реальный) из моей  опыта:
Меня представили (1991год) одному пред.правления регионального банка и после моего увлекательного ;-) рассказа что мы умеем он сказал!!:
" Ну хорошо. Я согласен! Сделайте что-нибудь!" 

Вот так, с таким ТЗ, мы написали свою первую сетевую программу по автоматизации банковской деятельности. Как показала практика начало оказалось ОЧЕНЬ удачным. То, что у нас тогда был Agile никто не мог даже догадаться т.к. до официальной публикации Agile Manifesto понадобилось еще 10 лет.

Мы не являемся теоретиками, и не считаем себя первооткрывателями, мы жесткие практики работаем за деньги и ради денег. А наш действия были ЕСТЕСТВЕННЫМ вынужденным подходом к решению задачи. Мы, как группа разработчиков, практически НИЧЕГО не знали о деятельности банка и банковских технологиях. А сотрудники банка вершиной автоматизации считали калькулятор. 
То что это идеология (или по вашему - методология) никто не знал и не думал.

 

Генеральный директор, Москва
Валерий Овсий пишет:

Я уже здесь как то рассказывал случай (реальный) из моей  опыта:
Меня представили (1991год) одному пред.правления регионального банка и после моего увлекательного ;-) рассказа что мы умеем он сказал!!:
" Ну хорошо. Я согласен! Сделайте что-нибудь!" 

Вот так, с таким ТЗ, мы написали свою первую сетевую программу по автоматизации банковской деятельности. Как показала практика начало оказалось ОЧЕНЬ удачным. То, что у нас тогда был Agile никто не мог даже догадаться т.к. до официальной публикации Agile Manifesto понадобилось еще 10 лет.

Пример понятен.

Сделайте что-нибудь - есть и такой подход. Заказчик всегда прав. ТЗ и прочие формальности - только зря время тратить.

Но при чем тут Agile? 

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Кто в России ищет работу активнее всех

Сервис HeadHunter провел исследование и выяснил, кто и где ищет работу наиболее активно.

Мировой рынок труда потерял около 255 млн рабочих мест в 2020 году

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