Гибкие методологии управления проектами появились в 90-х годах XX века. И за три десятка лет Agile-методы обросли стереотипами и суевериями, которые часто мешают внедрять в работу принципы и инструменты гибких методологий. В статье разберемся с пятью распространенными мифами, узнаем, откуда они берут корни и почему так прочно прижились в сознании людей.
Миф 1: Agile — это только для IT
В самом начале, когда появлялись первые гибкие методологии разработки, они были предназначены только для сферы IT. Но принципы Agile — это не только про разработку ПО. Это, в первую очередь, про адаптацию к изменениям рынка, обратную связь от клиента, постоянное повышение качества. А это, согласитесь, уже стандарт не только в IT, но и в других отраслях.
Приведем несколько примеров, чтобы показать актуальность гибких методологий для разных направлений деятельности. Agile используют в сферах:
- финансы — «Сбер», «Тинькофф»;
- производство — Bosch, Tesla;
- торговля — «М.Видео», Amazon;
- телекоммуникации — МТС, Netflix.
Миф 2: Гибкость означает хаос и отсутствие контроля
Руководители с авторитарным подходом держат под контролем все бизнес-процессы в компании: от постановки стратегических целей до написания должностных инструкций для рядовых сотрудников. Последовательность, иерархичность и подчинение — вот принципы, на которых держится менеджмент авторитарных управленцев. Гибкость бизнес-процессов в Agile-методах на фоне четкой иерархии и строгого планирования кажется полнейшим хаосом.
На самом деле в гибких методологиях зачастую бывает больше контроля за процессами, чем в традиционном подходе. Авторитарные руководители ставят цель и ждут результат. В то время менеджеры, которые используют Agile-методы, непосредственно участвуют на каждом этапе работы. Они всегда в курсе всех промежуточных результатов, готовы адаптировать методы достижения целей к любым изменениям условий. В Agile всегда четко распределены роли, процессы и цели — это помогает сохранять прозрачность всех процессов. Поэтому руководителю легче сохранить контроль над работой.
Посмотрим, как контроль осуществляется в методологии Scrum. Компания занимается разработкой продукта, параллельно над задачей работает несколько специалистов. Чтобы быть в курсе целей и прогресса, руководитель группы внедрил регулярные встречи и разбил работу на недельные спринты. Команда всегда собирается на ежедневную короткую встречу, а также планирование, обзор и ретроспективу спринта. В результате сотрудники всегда могут вовремя решить возникшие трудности команды и скорректировать рабочий процесс.
Миф 3: Agile — это методология без плана и структуры
В каскадных методологиях при планировании проекта известны дедлайны и последовательность каждого этапа. Но не каждый бизнес-процесс можно заранее измерить, и не все риски и изменения можно предугадать. К тому же иногда при каскадной модели приходится делать много лишней работы: команда завершила проект, а результаты не устроили заказчика, приходится переделывать. Чтобы избежать этого, можно использовать гибкое планирование.
В Agile акцент ставится на краткосрочном планировании — например, на один недельный или двухнедельный спринт вперед. Это позволяет адаптировать долгосрочные планы под внешние изменения и внутренние особенности работы, а также не делать ненужной работы.
Например, у Scrum-спринта может быть конкретный план, цели и дедлайны. Но так как в процессе участвуют заинтересованные лица, например, заказчики, они могут повлиять на рабочий процесс: внести правки, уточнения, пожелания. Руководитель команды разрабатывает план на следующий спринт в соответствии с новыми данными. С традиционным планированием было бы невозможно добиться такой адаптивности к условиям. Любые изменения привели бы к срывам дедлайнов, пересмотру плана.
Миф 4: Гибкие методологии подходят только для небольших команд
Еще одно заблуждение, которое берет истоки в сравнении с традиционной иерархической структурой больших корпораций. Многие считают, что Agile эффективен только для малых команд, а с большими коллективами методология не справляется.
Но крупные компании тоже могут внедрять и применять гибкие методологии. Это доказывают примеры корпораций:
- Facebook.
- Amazon.
- Microsoft.
- «Авито».
- «Яндекс».
- VK.
- X5 Group.
В Agile есть специальные фреймворки для крупных команд, например, Scrum of Scrums, Large Scale Scrum, Scaled Agile Framework. С их помощью можно организовать работу любой группы.
Agile — это дорого и сложно внедрить
Любая масштабная модификация бизнеса — это затратно и требует времени. Но если вносить изменения постепенно, то можно сократить расходы и увеличить отдачу от новой методологии управления.
На скорость и стоимость внедрения Agile-методов влияет то, какая именно методология будет положена в основу бизнеса. Например, Kanban практически не нуждается в дополнительном финансировании и кардинальных изменениях.
Scrum внедрить сложнее. Нужно сформировать отдельную команду, которая будет работать по этой методологии. Вначале это может быть отдел или связанные с конкретным проектом сотрудники. Пилотная команда должна иметь достаточную мотивацию для того, чтобы перейти на новый формат работы. На каждом шагу будут чувствоваться существенные улучшения в работе, если проводить внедрение Scrum поэтапно:
- обучение сотрудников принципам Agile;
- адаптация фреймворка Scrum под нужды команды;
- постепенное внедрение agile-практик, например, начать можно с планирования спринтов и ежедневных встреч;
- анализ метрик, в том числе затраченного времени и качества работы.
Постепенно можно расширять подход Agile и другие отделы, проекты, направления деятельности. Поэтапное внедрение — более безопасный, но не менее эффективный способ перехода на работу по гибким методологиям управления проектами.
Мифы об Agile часто далеки от реальности. Изучайте гибкие методологии, экспериментируйте и внедряйте их в своей работе. Это ключ к успеху в современном мире, где изменения — это норма. А если вам нужна помощь при внедрении Agile, можете пройти наш курс по гибким методологиям управления проектами. С ним вы научитесь строить работу по Scrum и Kanban с максимальной эффективностью для команды.
