Решение проектных задач в стиле Agile

 

Вчера участвовал в очередном семинаре по AGILE/SCRUM (организатор — Кейс-клуб) и поймал себя на мысли, что я все-таки консервативен в своих профессиональных взглядах на методы развития организаций.

Первый вопрос, который у меня возникает на подобных обсуждениях — «чем AGILE и SCRUM отличается от лучших практик управления проектами и LEAN-методологии?» Все те же «быстрые результаты» и вовлечение заказчика на ранних стадиях проекта, все те же кроссфункциональные команды, работающие вне стандартных форматов и постоянно ищущие новые подходы к реализации  задач, все тот же канбан и визуальный менеджмент и т.д. и т.п. Да, появляется scrum-мастер, который выступает внутренним модератором и «решалой», но эту функцию выполнял либо PM, либо Аккаунт, либо Куратор проекта. Да, теперь не этапы и фазы проекта, а спринты, которые можно делать параллельно с ценностью для потребителя на выходе. Но никто не отменял задач, лежащих на критическом пути, т.е. требующих только последовательного выполнения.

Так в чем же фишка этой AGILE-методологии? Или это очередная модная «обертка» для уже известных всем методов? 

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

К примеру,

В начале 2000-х годов мы одни из первых в России внедряли систему сбалансированных показателей на крупном предприятии. И, как вы наверное догадываетесь, делали это в первый раз в своей консультационной практике(!!!) И заказчик и мы до конца не понимали образа конечного результата и шли к нему по этапам, каждый раз уточняя следующий шаг и формируя план действий. И это дало свои плоды. Система BSC до сих пор успешно функционирует на предприятии. А что если тогда заказчик не поверил бы в нас? Или мы пытались бы придумывать конечные результаты с виртуальными сроками реализации? Скорее все это закончилось бы срывом сроков, бюджетов и расторжением сотрудничества и обе стороны только потеряли  бы от этого.

Еще пример из личной практики:

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

И вот после таких кейсов мне стало более очевидным необходимость обособления AGILE как идеи и SCRUM как подхода к ее реализации

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