Web-studio46.ru

Обучение и образование
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Agile менеджмент это

Agile

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

История зарождения Agile

Изначально термин Agile относился к ИТ-индустрии и употреблялся в контексте гибких методологий разработки программного обеспечения: экстремального программирования (XP), Crystal Clear, DSDM, Feature driven development (FDD), Scrum, Adaptive software development, Pragmatic Programming, быстрая разработка приложений (RAD) и других адаптивных методов, суть которых состоит в ускорении процессов создания продукта путем микропланирования, коротких производственных циклов и оперативного реагирования на изменения. Ключевой смысл этих Agile-практик отражен в манифесте гибкой разработки программного обеспечения (Agile Manifesto), который был выпущен инициативной группой программистов в феврале 2001 года в американском штате Юта [1]. Эта дата считается началом повсеместного распространения эджайл как практики управления проектами и организации бизнес-процессов не только в ИТ-отрасли, но и в других прикладных областях. Дополнительным драйвером развития Agile-подходов является микросервисная архитектура приложений, когда весь проект состоит из набора независимых слабосвязанных модулей, которые взаимодействуют друг с другом через открытые API-интерфейсы [2]. Популярность облачных технологий (SaaS-, PaaS-, IaaS- и других сервисных моделей) также стимулирует распространение эджайл.

Гибкость против жесткости: Agile vs Waterfall

В отличие классического Project Management (PM), когда проект жестко регламентирован заранее установленными требованиями (контрактами), Agile предполагает быстроту реагирования, а также гибкую адаптацию к внешним и внутренним изменениям. Это достигается с помощью итеративной разработки продукта и эффективного межличностного общения. В водопадной (каскадной) модели PM, которая считалась стандартом де-факто, проект состоит из функциональных задач, где каждая последующая работа четко регламентирована и начинается строго после окончания предыдущей, например, тестирование начнется только после того, как написан весь код. Жесткая определенность и обилие регламентирующей документации обусловливают длину производственного цикла. При этом продукт считается готовым лишь после выполнения всех этапов [3].

Waterfall — водопадная (каскадная) модель разработки ПО

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

Гибкая разработка ПО серией итераций

Основные идеи и принципы

4 ключевые идеи Agile сфокусированы на гибкости и адаптивности этого подхода:

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

Ключевые идеи Agile

Эти идеи раскрываются в 12 принципах Agile Manifesto [1]:

  1. работающий конкурентоспособный продукт, удовлетворяющий заказчика — лучший показатель прогресса и измеритель эффективности;
  2. оперативная и бесперебойная поставка продукта, удовлетворяющего заказчика;
  3. адаптивность продукта к новым требованиям, которые могут повысить его ценность и конкурентоспособность (возможность внесения изменений на любом этапе разработки);
  4. простота и прозрачность технических решений, документации, процессов и инструментов, чтобы не создавать лишней работы;
  5. частая поставка функционирующего продукта (раз в месяц/неделю или ещё чаще);
  6. постоянный темп работы всех участников проекта на протяжении всего его срока;
  7. минимизация организационных и информационных барьеров, лучший путь передачи информации — это личный разговор лицом к лицу;
  8. тесное и ежедневное общение исполнителей с заказчиком в течении всего проекта;
  9. мотивация участников проекта и обеспечение их всеми необходимыми условиями работы, поддержкой и доверием;
  10. самоорганизация и самоконтроль команды проекта;
  11. непрерывное улучшение профессиональных компетенций команды проекта;
  12. систематический анализ и постоянный поиск возможностей оптимизации командной и индивидуальной работы.

Главные принципы Agile

Преимущества и недостатки

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

Недостатки Agile являются прямым следствием его достоинств:

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

Главные преимущества эджайл

Методы и средства реализации

Наиболее популярными Agile-подходами считаются Scrum (скрам) и Kanban (канбан).

В Scrum над проектом работает команда профильных технических специалистов (например, аналитик, программист, тестировщик, администратор) вместе с владельцем продукта (product owner) и модератором (scrum-мастер). Product owner аккумулирует бизнес-требования, соединяет команду исполнителей с заказчиком и следит за развитием проекта. Scrum-мастер управляет процессом организации разработки по Agile-принципам: проводит общие собрания (meetings, митинги), мотивирует и поддерживает команду.

В Scrum рабочий процесс делится на равные периоды от 1 до 4-х недель (спринты), в зависимости от проекта и команды. Перед стартом каждого спринта на митинге формулируются его задачи, а в конце обсуждаются результаты. Краткосрочность и измеряемость спринтов позволяет эффективно управлять проектной деятельностью, не перегружая участников проекта авралами [4].

Спринты в Scrum

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

Канбан, как и другие практики бережливого производства, пришедшие из Японии, направлен на достижение баланса и выравнивание нагрузки исполнителей. Эффективность работы оценивается по среднему времени жизни задачи, от начальной до конечной стадии. Если задача прошла весь путь быстро, то команда проекта работала продуктивно и слаженно. Иначе – необходимо решать проблему: искать, где и почему возникли задержки и чью работу надо оптимизировать [4].

Задачи на Канбан-доске

Сегодня наблюдается некоторое слияние Scrum и Kanban, например, канбан-доски стали практически обязательным элементом популярных систем управления проектами (Jira, Trello, Битрикс.24, Basecamp, Мегаплан и т.д.), которые, в том числе, поддерживают методологию скрам [5].

Где, как и кем используется Agile

Сегодня эджайл применяется не только в управлении ИТ-проектами, а используется как эффективная практика организации труда небольших групп и творческих команд вместе с либеральными и демократическими методами менеджмента [1]. В частности, одной крупной телеком-компании благодаря внедрению Agile-практик в процессы кросс-функциональное взаимодействия всего за 3 месяца удалось достичь следующих результатов [6]:

  • рост от продажи устройств на 45%;
  • сокращение сроков запуска рекламных кампаний в 2 раза;
  • рост плановой ежемесячной выручки от разработки продуктов на 20%;
  • в 1,5 раза больше запущено рекламных кампаний по направлению В2В.

Гибкие практики управления также активно применяются и в банковском секторе. Например, за год в проектном офисе ЦентроБанка в 2 раза увеличилась скорость достижения результатов, повысилась вовлеченность сотрудников, улучшилась прозрачность и управляемость изменений [7]. Подобным опытом делится Райффайзен-Банк [8] и Сбербанк [9]. Предприятия нефтегазовой промышленности также активно используют Agile для повышения эффективности своих бизнес-процессов, открывая новые офисы и выстраивая работу филиалов по адаптивным принципам [10]. Кроме того, в рамках государственных проектов цифровизации, идеи и принципы эджайл используются в бюджетных и правительственных организациях [11]. В частности, правительство Новой Зеландии, Норвегии и США изучали методы Scrum для внедрения в своих министерствах [12].

Мода на agile. Чем полезен новый метод организации офисного пространства

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

Разные сферы трактуют методы agile по-своему. Для программистов это гибкая методология разработки программного обеспечения, для управленцев — эффективная практика организации труда небольших групп, для инвесторов — возможность из стартапа сделать «единорога» — компанию с капитализацией в $1 млрд. В недвижимости agile сегодня трактуется как некая гибкость офисного пространства, где в плотном взаимодействии работают участники создаваемой под проект группы. Современные офисы меняются вслед за мировыми трендами, а офисный рынок, в свою очередь, должен оставаться максимально гибким и готовым к трансформациям.

Читать еще:  Профессия трафик менеджер

Офисы на перепутье

Уже в 2016 году, по данным Аналитического центра Национального агентства финансовых исследований, каждая пятая российская компания имела в штате хотя бы одного сотрудника, работающего удаленно. Некоторые организации решились на частичное использование незакрепленных рабочих мест. Освободившиеся «излишки» офисной площади стали распределяться на многофункциональные зоны — к примеру, переговорные, к функционалу которых добавился и кабинет руководителя: начальники департаментов покинули кабинеты и переместились в open space, а потребность в конфиденциальных встречах или совещаниях успешно реализовалась в увеличенном количестве переговорных зон разного формата.

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

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

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

Философия agile — это система менеджмента «бирюзовых» компаний, в основе которой лежат самоорганизация, самостоятельность профессионалов, гибкий подход к созданию продуктов. Концепция пришла к нам от IT-корпораций, которые используют проектный подход и распространяют эту логику на все процессы. К примеру, в свое время по такому пути пошел знаменитый Microsoft. Трансформируя пространство и сокращая площади для закрепленных рабочих мест, такие компании распределяют место для многофункциональных зон, тем самым делая офис более комфортным и эффективным для групп разного количественного состава, работающих над проектами.

Модное явление

За последние годы мы отмечаем рост запросов заказчиков на организацию «гибких» пространств. Agile привлекает компании и просто как модное явление. Потребность быть в тренде есть у всех, но далеко не каждый готов разбираться в тонкостях организации гибкого офиса, привлекать специалистов и проводить серьезный анализ. Чаще всего в итоге создается классический офис с элементами гибкого пространства. Такие изменения тоже дадут плюс к комфорту и положительно скажутся на эффективности. Стоит признать, что, копнув глубже отдельных элементов, компании нередко сталкиваются с трудностями внедрения основательных изменений. Это происходит потому, что agile-офисы — сложные механизмы, и просто копирование отдельных свойств не приведет к нужному результату и эффекту. Для внедрения agile необходимо не только перестроить пространство офиса, но и провести глубокую аналитику со сбором большого количества данных и их анализом, а также подготовить команду для внедрения новых процессов.

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

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

Расчет пиковых загрузок офиса при этом достаточно прост: к примеру, если в компании 500 сотрудников, но при расчете пиковых значений оказывается, что максимально одновременно в офисе присутствует 450 (ввиду отсутствия людей в командировках, по причинам болезни или отпусков), то появляется возможность уменьшить офис на 10-15% или выделить освободившиеся площади для создания дополнительной офисной инфраструктуры и повышения уровня комфорта сотрудников. Если же расчетное значение в какие-то дни будет превышаться, то у администраторов офиса должна быть возможность организовать дополнительные рабочие места для сотрудников в неформальных зонах: благодаря их правильной организации риск превышения расчетных значений загрузки будет минимизирован.

Кусочки мозаики

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

Самые популярные в гибких офисах решения — неформальные рабочие зоны: как правило, это комфортные кресла и диваны для работы с ноутбуком и стихийных совещаний. Это уже настоящий must have для современных компаний, без них сегодня не обходится ни один новый офис.

Аккуратнее, но также активно компании используют такие новинки, как диваны с акустическими спинками, поглощающими внешние звуки: в таких мини-переговорных удобно проводить внутренние встречи, организовать conference call.

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

Agile по-русски

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

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

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

Как создаются программы по методологии Agile

Аспирант «Нетологии» Максим Пименов рассказывает про Agile — гибкую методологию разработки программного обеспечения.

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

Чтобы процесс создания программы шел правильно, программисты используют методологии. Методология — это набор стратегий и способов создания продукта. Их много и новичок не знает, что выбрать: RUP, XP, Scrum, Waterfall или другой набор букв.

Agile — это молодая семья гибких и демократичных методологий. Её лозунги привлекательны как «Свобода, равенство и братство», а принципы даже кажутся утопичными.

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

«Слово «agile» становится популярным во всем мире и, слава тебе Господи, в нашей стране, потому что мы, как и в других случаях, приходим к нему последними. Переход в Agile — это самый большой вызов, который сегодня стоит, в том числе, перед нами и перед всеми большими организациями».

И пошло-поехало: все дробят штат на команды по 5—9 человек, рисуют скрам-доски и проводят ежедневные стендапы.


Agile-доска в офисе «Яндекс.Картинок»

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

Старые методы разработки слишком громоздки

До появления Agile IT-компании использовали каскадную модель разработки (она еще известна как водопадная, потому что по-английски называется Waterfall). Чтобы стало чуть яснее, что́ с ней не так, скажу, что методологию сформулировали в 1970-м. Её суть в том, что работа над проектом состоит из жесткой последовательности этапов:

Анализ требований

Проектирование

Реализация

Тестирование

Интеграция

Поддержка

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

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

Читать еще:  Смм менеджер спб

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

Риск потерять уйму денег — хороший повод поразмыслить. В 2001 году практикующие айтишники собрались на горнолыжном курорте в Юте. Официальный сайт преподносит событие так: «…seventeen people met to talk, ski, relax, and try to find common ground — and of course, to eat». Итогом стала Библия Agile — Agile Manifesto.

Agile — простая и симпатичная философия

Если вы думаете, что авторы Agile Manifesto написали сборник советов о работе над проектом, вы немного ошибаетесь. Манифест включает в себя 4 ценности, 12 принципов и 0 практик.

Начнем с ценностей, потому что именно они соль Agile:

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

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

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

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

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

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

Разработка делится на спринты

Авторы Agile сделали основой методологии старую шутку «— Как съесть слона? — По кусочкам». Уже в этой части гибкий подход отличается от каскадного.

Месяцами «пилить» проект, запустить его по готовности.

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

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

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

Перед первым спринтом команда и заказчик проводят совещание. Заказчик — условная роль, им может быть и член команды. Он определяет задачи, которые команда решит за спринт.

Здесь появляется первая сложность. Согласно философии Agile, после каждого спринта продукт должен быть:

полезным для пользователя;

более совершенным, чем до спринта.


Agile-подход к разработке продукта.

Результатом первых недель работы должен стать продукт, готовый к выходу на рынок. Такой продукт называют минимально работоспособным (Minimum Viable Product, MVP).

Запуск MVP — важная точка проекта. Удачный MVP либо сразу привлекает пользователей, либо сразу проваливается и показывает нежизнеспособность идеи.

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

Этот MVP приносит пользу: лэндинг покажет, насколько наш магазин интересен аудитории, а потенциальные покупатели получат скидку. Это удачный MVP. Подробнее про суть минимально работоспособного продукта хорошо написал инвестор Аркадий Морейнис.

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

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

Пары «план — спринт» идут одна за другой, пока живет проект.

Команда работает как захочет

Внутренние и внешние связи agile-команды максимально демократичны. Одна из причин, по которым методология практически не работает в России — руководители не понимают, как можно «до такой степени распускать коллектив». Согласно Agile, команда — это самоорганизующаяся единица. Никто не имеет права указывать, как она решает задачи внутри спринта. Если хотят, пусть хоть на головах ходят.

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

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

На самом деле не все любят Agile

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

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

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

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

Если забыть о философии, ничего не выйдет

Есть еще одна проблема, в которой авторы Agile не виноваты: методология стала слишком популярной и даже попсовой. Люди говорят, что работают по Agile, даже не понимая её сути. Они разбиваются на небольшие команды, нарезают проект на небольшие задачи, планируют спринты, регулярно релизят, но убогих проектов не становится меньше.

Помните, в начале статьи я говорил про принципы? Несмотря на их наивность, принципы — самое ценное в Agile. Сначала нужно осознать их и только потом браться за инструменты и практики.

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

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

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

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

Люди бездумно следуют инструкциям, забывая, что Agile — это идеология и философия. А забывать нельзя: если не проникнуться духом методологии, сквозь нее пробьется «водопад» пополам с анархией и бюрократией.

Agile — мировоззрение, а не набор советов. Примите Agile, и только потом беритесь за практику.

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.

Как внедрить Agile в производственной компании

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

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

Один из вызовов, которые встают перед производителями – это организация потока эксклюзивных (единичных) продуктов. Причем это относится в равной степени к производственным, торговым и компаниям, оказывающим услуги. В этой статье мы сосредоточимся на производственном секторе.

Что пришло на смену Lean production, Just-in-Time, Kanban и другим системам организации предприятия? Теперь повсеместно говорят об Agile. Главный вопрос, который задают себе руководители: применимо ли все это на практике моей компании и с чего же все-таки начать? Многие топ-менеджеры также не понимают, что на самом деле означают гибкие производственные системы.

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

Читать еще:  Бесплатный кризисный менеджер

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

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

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

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

Что заставляет компании применять аgile-методологии

  1. Высокая конкуренция. Подход, описываемых треугольником «быстро/качественно/дешево», уже не работает. Клиенты хотя сразу качественно, быстро и дешевле, чем у других. Как сказал на «Встрече лидеров» Герман Греф: «На самом деле, нет никакой конкуренции товаров, продуктов или услуг. Есть конкуренция моделей управления».
  2. Долгосрочные прогнозы больше не сбываются. Темп изменения экономической среды настолько высок, что неизвестно что будет актуально на рынке. Ваш конкурент выпустил новый инновационный продукт, установив новые стандарты в отрасли – и вам приходится подтягивать свою компанию. Иначе вы останетесь за бортом. Сегодня ваш клиент захотел один продукт, а завтра такой же, но с перламутровыми пуговицами.
  3. Затянутость и сложность принятия решений, неповоротливость компаний. В больших компаниях с бюрократией, доведенной до абсурда, решения не принимаются, а растворяются.

Основные принципы аgile-методологий

  1. Ориентация на результат. Работающий продукт — основной показатель успеха. Максимально уходим от жесткого документирования и регламентирования процессов, оставляем необходимый максимум. В главном фокусе остаются скорость и эффективность.
  2. Постоянное внимание к техничности и инновационности процесса разработки продуктов.
  3. Сокращение сроков выпуска. Это достигается благодаря разработке продуктов за счет использования современного многофункционального обрабатывающего оборудования, ПО для планирования производства, ПО для моделирования и разработки продуктов, эффективных коммуникаций сотрудников, не обремененных регламентами, процедурами и т. д.
  4. Работа в условиях постоянных изменений. Способность управлять agile-процессами добавляют компании уникальное преимущество по сравнению с ее конкурентами.

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

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

А среди тех, кому жизненно важно быть гибкими, следующие производственные компании:

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

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

Семь ошибок во внедрении Agile

  1. Отсутствие у топ-менеджеров и собственников понимания и целей внедрения. Необходимо максимально точно понимать, что мы хотим получить в результате, какие у нас есть сроки и бюджет. Причем цели, сформулированные как «Повысить эффективность» или «Стать лидером отрасли», это не то. Оставьте красивые слоганы для миссии компании. Цели должны быть оцифрованы. Например: «Достигнуть оборота в 2018 году $2 млрд», «Сократить срок разработки продукта до двух месяцев», «Сократить срок исполнения заказов с трех месяцев до 15 дней».
  2. Неправильный диагноз. Обычно, компания, внедряя Agile, стремится решить конкретные проблемы: высокая себестоимость, низкое качество продукции. Но, не разобравшись в чем заключается проблема, менеджмент просто начинает внедрять Agile, считая, что это кардинально все поменяет. В таком случае, он получит еще более низкую эффективность.
  3. Внедрение Agile только на отдельном участке бизнес-процессов. Эта третья ошибка является логическим продолжением второй. Она связана с непониманием того, в чем кроется причина проблем. Изменения должны затрагивать все сферы компании: производство, маркетинг, продажи и даже бухгалтерию. Иначе ничего не выйдет. Если мы проведем революцию только на производстве, то никакого эффекта не будет, и скептики обязательно скажут потом: «Не работает ваш Agile».
  4. Занижение важности вовлечения всего персонала. Если у вас не будет команды союзников в лице ваших коллег – лучше сэкономить ресурсы и время и не начинать ничего. Agile требует мобилизации, инициативности и ответственности всех участников процесса или, как минимум, менеджеров среднего и высшего звена. При условии, что они являются сильными и властными руководителями, которые будут обеспечивать высокую дисциплину выполнения задач и новых правил работы. Как показывает наш опыт, 85% компаний не имеют профессиональных сильных управленцев.
  5. Иллюзия, что все можно сделать за счет человеческих усилий. Да, большая часть эффективности лежит в плоскости персонала, его компетенций и мотивации. Но не менее важно техническое оснащение компании, ПО, которое позволяет эффективно управлять и планировать деятельность. Поэтому инвестиции в оборудование, станки, прикладные программные продукты неизбежны.
  6. Нежелание проводить кадровые замены. От персонала зависит 90% успеха, поэтому его необходимо обучать, развивать и правильно мотивировать. Многие люди внутренне не готовы работать в agile-среде, они хотят четких и стабильных бизнес-процессов, не хотят осваивать новые знания. В среднем, 25-30% персонала не хотят работать и зарабатывать, с такими необходимо расставаться. Выявление слабых звеньев – довольно сложный процесс, которого HR-менеджеры пытаются избежать.
  7. Потеря интереса и участия топ-менеджеров. В среднем проект по внедрению занимает от восьми до 16 месяцев. В 70% случаев, уже через три месяца участники проектной команды по внедрению теряют драйв и отстраняются от участия. Такие проекты обречены на провал.

Шесть правил, ведущих к успеху

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

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

– на основании этого плана формируйте ежемесячные планы задач (эти планы должны выполняться не менее, чем на 90%);

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

  • Вовлекайте в проект и информируйте о нем весь персонал. Важно, чтобы все сотрудники, даже те, которые не выполняют проектные задачи, понимали и разделяли то, чего хочет достигнуть компания, и какие действия необходимо выполнить для достижения этих целей.
  • Периодически, один-два раза в месяц, проводите встречи с командой по внедрению. Это необходимо для того, чтобы вырабатывать решения задач и проблем, своевременно корректировать план, в случае возникновения трудностей с внедрением. В тоже время, решение острых конфликтных ситуаций не стоит откладывать до плановой встречи, которая состоится через 2 недели, а решать их оперативно.
  • Не отказывайтесь от проекта, если видите, что он приносит отрицательный эффект. Как правило, отрицательный эффект – это недовольства сотрудников, которые вынуждены выйти из привычной зоны комфорта и попасть в творческую среду. Помните, первые результаты, как правило, будут измеримы после того, как будет пройдено 80% пути.
  • Не бойтесь расставаться с неэффективными сотрудниками и теми, кто не Agile.
  • Не пытайтесь с первой итерации сделать все идеально. 95% эффективных и внедренных решений и инструментов были достигнуты путем многократной шлифовки, то есть, через несколько итераций.
  • Ссылка на основную публикацию
    Adblock
    detector