В современном менеджменте «гибкую» модель управления рассматривают в трёх разных контекстах, которые (каждый по-своему) и определяют, что такое Agile.
Содержание статьи
Три объёма значения Agile
В первом, более узком значении, этот термин стал с начала 2000-х использоваться в сфере разработки программного обеспечения, когда в американском штате Юта, на горном курорте, собрались отраслевые специалисты, чтобы обсудить методики и практики создания программных продуктов, востребованных конечным потребителем. Результатом той встречи стал Манифест (Agile Manifesto) разработки программных продуктов, с 12-ю принципами, которые, в первую очередь, касались узкой сферы деятельности авторов, но потенциально могли быть распространены и на некоторые другие бизнес-проекты.
Во втором, более широком, значении термина принципы Agile применяются к ведению почти любого бизнеса и в качестве составляющих используются, например, в концепции «бережливого стартапа» (Lean Startup). В этом значении под Agile-моделью (Agile Model) понимают следование гибкой методологии развития проекта, проходящей по характерной схеме в несколько шагов.
- Работа над проектом ведётся итерациями – короткими циклами (спринтами). (В случае с разработкой программного обеспечения продолжительность этих циклов составляет от 1 недели до 1 месяца).
- По завершении каждого цикла выходит продукт, который уже можно применять в бизнесе. Для программного обеспечения таким продуктом может стать приложение или только его часть, однако даже «сырой» софт уже можно и нужно пробовать в деле.
- Продукт проверяется заказчиком или пользователями, которые поддерживают с разработчиками постоянную обратную связь. Клиентоориентированный подход применяется в течение всего проекта (всех итераций).
- Любые замечания быстро включаются в доработку, а изменения, позволившие сразу по ходу подправить разработку продукта, – приветствуются, поскольку это позволяет не накапливать глобальные ошибки системы.
В третьем, ещё более широком значении, Agile – это часть модели управления, применяемого на заводах «Toyota» и теперь – одна из базовых составляющих менеджмента почти любого успешного производства. Основы Agile в этом контексте схожи с основами понимания технологии в других контекстах.
Быструю обратную связь в настройке конечного формата производства на заводах «Toyota» обеспечивал любой рабочий, который мог стать инициатором остановки конвейера и автором корректировок по донастройке производственного цикла. В масштабах всего производства Agile-трансформация может повлечь за собой переналадку производственной деятельности в целом, если продукт становится результатом живого отклика на текущие потребности клиента. Так, если фабрика выпускала пластиковые тазы, а обратная связь с клиентом демонстрирует потребность в вёдрах, то быстрая адаптация с параллельной корректировкой нюансов (формы ручки, величины, цвета) будет как раз в стиле Agile management (если соблюдены и остальные принципы).
Принципы Agile-управления
Agile в управлении проектами как модель управления бизнес-процессом применяется тысячами команд во всём мире, и везде присутствуют следующие отличительные черты этого подхода:
- Решающее значение для настройки продукта имеет потребитель и степень его вовлеченности в создание результата.
- Для принятия решения команды должны быть высокоэффективными и сплочёнными.
- Поэтапная и цикличная работа становится основой процесса. Проект делится на мелкие части, которые завершаются к определённому сроку до завершения проекта в целом.
- Фокус оценки результативности направлен на частые представления промежуточных состояний проекта.
- В работе коллектив опирается на закон Парето, по которому 20% усилий дают 80% эффективности, что позволяет не доводить каждый отдельный цикл до совершенства перед представлением результата потребителю. Продукт совершенствуется естественным образом с каждой новой итерацией.
- Предполагается обязательное завершение одного этапа перед переходом к следующему.
«Гибкий» подход стал базовым для целого ряда методологических практик, которые отличаются между собой, но включают идеи Agile: Scrum, Kanban, Lean, Crystal и др. Методология Scrum, например, практически всегда рассматриваются в связке с Agile как единая система управления проектами по разработке программного обеспечения.
Метод Scrum демонстрирует, как «гибкий подход» может быть применён на практике в конкретных операциях. Так, например, работа с требованиями по проекту реализуется с помощью четырёх «артефактов»:
- Product backlog предполагает формирование списка требований, созданного по единому шаблону (User Story) и отсортированного по приоритетам. Если требований нет, проект завершается.
- Sprint backlog – это требования ближайшего спринта (этапа), разделённые на задачи без возможности добавлять новые требования в течение спринта. Обязательство на ближайший этап, взятые командой с типом управления Agile, записываются на доске (т. н. Kanban).
- Sprint Goal – общая цель спринта – ориентир при принятии альтернативных решений.
- Sprint Burndown Chart – «диаграмма сгорания». Она показывает насколько продвинулась команда в течение этапа.
Формат Agile-управления проектами подходит не всем и не всегда. Государственные структуры, деятельность которых базируется на неизменном законодательстве и консервативна по своим целям и реализации, не нуждаются в такой оптимизации.
Характерные ошибки внедрения Agile и недостатки подхода
Тот же фактор, который считается в одних случаях сильной стороной подхода, в других может приводить к возникновению проблем. Так «гибкость» нередко становится причиной размывания фокуса. При отсутствии методологической основы возникает потеря ориентиров, и подмена первичного вторичным. Для предотвращения подобных «перекосов» используют готовые методологии или собственные разработки, более строго регламентирующие содержание и последовательность операций по ходу воплощения проекта. Тем не менее, и в этом случае в Agile-management возможны ошибки.
К распространённым ошибкам внедрения относятся следующие:
- Ограничение командной свободы со стороны руководства. Руководитель проекта не всегда готов отпустить команду, дав ей самостоятельно решать, что делать. Для эффективной работы необходимо реальное расширение возможностей и прав каждого участника процесса. Руководство не должно ставить мелкие задачи исполнителям и проверять выполнение каждого действия. Но иногда право решения передаётся исполнителю частично и в ограниченном виде, что снижает эффективность общего процесса.
- Отсутствие доверия внутри команды и старые привычки. При внедрении подхода Agile в уже сложившихся коллективах с классической иерархией команде сложно бывает отказаться от патерналистских установок. Даже сознательно соглашаясь с новыми правилами игры, работники реализовываются в рамках ранее сформированных навыков взаимодействия. Чтобы изменить навыки, такие коллективы проходят специальные тренинги работы в команде. Но и это не застраховывает от мелких конфликтов. Нововведения редко проходят абсолютно гладко. Считается, что, в среднем, до 30% персонала так и не переходят на новый формат работы, что влечёт либо проволочки, либо серию увольнений.
- Нарушения в обратной связи. Иногда обратную связь от клиентов могут просто игнорировать, мотивируя это тем, что клиент хуже знает, что ему на самом деле надо. Тут важно отдавать себе отчёт в том, что именно заказчик – заинтересованная сторона.
- Недостаточное тестирование. Иногда тестирование прекращают после запуска первой рабочей версии продукта. Так же минуют стадию обсуждения в конце итерации.
Отсутствие у топ-менеджеров чёткого понимания целей внедрения новой системы с гибким подходом и отсутствие методологий. Как правило, цели с цифрами заменяются лозунгами или слоганами (например, «Быть всегда впереди конкурентов»), а вместо методологий описываются идеи, а не операции.- Внедрение подхода на одном участке. Для эффективности обычно советуют переформатировать деятельность всех сфер компании, начиная с бухгалтерии и отдела продаж и заканчивая производством и маркетингом.
- «Остывание». Процесс перехода на новую систему работы может занять несколько месяцев. Иногда нужно произвести переоборудование (установить новые станки или ПО и обучить сотрудников), иногда – полностью изменить тип мышления в рамках рабочего процесса. Поскольку со временем люди устают от перемен, процесс перехода на новую модель начинает надоедать на полпути. Теряется мотивация, а с ней уменьшается и вероятность успешного внедрения.
- Разочарование после первых итераций. Иногда после первых этапов исполнители просто недовольны результатом, но нередко это недовольство выливается в неконтролируемое стремление довести продукт до почти идеального состояния. А правильное совершенствование продукта происходит именно в процессе многократной шлифовки с разделением на соответствующее потребностям число итераций. Частично это решается грамотным планированием, при котором пропускная способность одной итерации одной командой оценивается адекватно (без пере- и недооценки).
При всех сложностях внедрения гибкого подхода в целом он эффективнее традиционных «неповоротливых» производств, если речь идёт о быстром создании нового клиентоориентированного продукта. Пока традиционное производство вязнет в бюрократических проволочках, Agile-подход обеспечивает естественное движение сразу после запуска проекта.