Можно ли применять Agile в управлении бухгалтерским отделом? В юридической компании? Работает ли Agile в банках или в строительстве?
Agile это множество различных методик, объединённых одними и теми же принципами, описанными в манифесте.
Если посмотреть на эти принципы, становится ясно, что изначально Agile появился в разработке программного обеспечения. Это так. Но с тех пор Agile далеко вышел за пределы IT. Тем не менее, исходя из этих принципов, можно и определить границу применимости Agile. Рассмотрим некоторые их них.
Принцип: изменение требований — это нормально и приветствуется
- Важно ли это в разработке программного обеспечения?
- Важно ли это в проектировании зданий?
- Важно ли это в бухгалтерии?
- А в финансовом консультировании?
Принцип: на протяжении всего проекта исполнители и заказчики должны ежедневно работать вместе
Поначалу этот принцип кажется не применимым ко многим областям. Ну как, например, может крупный девелопер постоянно работать с каким-то небольшим проектным бюро? Но давайте на стадии оценки применимости Agile подумаем пока не о физической возможности реализации этого принцип (скажу пока только, что это возможно), а о том: «если бы получилось его применить — была бы польза?». Попробуем:
- В проектировании зданий — полезно?
- В разработке программного обеспечения?
- В бухгалтерии?
Что уже можно сказать о применимости Agile?
Не буду рассматривать остальные принципы, ибо всё это давно уже сделано, я лишь хотел проиллюстрировать откуда вытекают ограничения применимости Agile. Сразу покажу результаты:
Внедрение Agile оправдано, если соблюдаются следующие условия:
- сфера работ — интеллектуальная, не молотком стучим, а в основном думаем
- работа проектная, а не процессная, то есть делаем не однообразные повторяющиеся действия на конвеере (или по составлению отчётов), а каждый раз хоть в чём-то — но уникальное творение.
- работа командная — то есть не 1 человек делает проект самостоятельно
Но, позвольте, я слышал, что на конвеерах Toyota тоже Agile используют!
Здесь подходим к хорошему вопросу терминологии.
Agile — пошёл от IT. Но в то же время на заводах Toyota задолго до Agile использовали другой подход. Не вдаваясь в исторический экскурс о TPS и Lean, обобщённо называем его Lean — бережливое производство. Оно же «бережливая разработка» или «бережливое проектирование» итп.
В свою очередь принципы Lean:
- Целостное видение всей системы создания ценности
- Акцент на уменьшение времени поставки заказчику
- Исключение потерь
- Предельно отсроченное принятие решений (иначе «принятие решений на основе фактов, а не предположений»)
- Акцент на обучении
- Мотивация команды
- Постоянное интегрирование (имеется в виду, что постоянно нужно иметь результат труда, который можно испытать, а не какие-то обрывки результата в разобранном виде)
Когда можно применять Lean?
- проектная и процессная (в особенности) работа
- практически любая сфера работ (мне не приходят в голову сейчас какие-то ограничения)
И что, Lean лучше Agile?
Нет, весь этот экскурс нужен был чтобы объяснить: иногда то, что называют Agile ближе по своей идеологии к Lean.
Из зарубежного источника очень правильная картинка:
Видно, что множества Agile и Lean пересекаются.
По сути, процесс, внедряемый в конкретной компании, может брать часть своих особенностей из Lean, часть из Agile. Именно это я делал, когда внедрял Agile в строительной компании, и когда ставил процесс по разработке сценариев игр в своей компании Questoria.
Применимость или не применимость Agile и Lean в компании зависит не от слов "внедряем Agile" или "внедряем Lean", а от конкретного перечня практик Agile или Lean, которые внедряются в данной компании.
Чем отличается работа по Agile или Lean от «просто работы»?
И та и другая группа методик содержит определённые установки, цель которых трансформировать культуру компании.
Например, в одна из таких установок в Lean: «ожидания — это ВСЕГДА зло». ВСЕГДА.
Любыми способами устраняем ожидания. Отправили документ на «согласование» и взялись за другую работу, и «ждёте» его согласования несколько дней? Плохо! По Lean так не делают. Надо заняться согласованием лично — ускорить его. Не должно быть потерянного времени на ожиданиях и заниматься в это время другой работой — это не «эффективность», а прятание проблемы с долгим согласованиями под ковёр.
В Agile одна из установок «поговорив о задаче, можно сэкономить кучу времени на её решении».
Начал делать что-то и считаешь, что сам знаешь как лучше? А вот нет — всё равно поговори с коллегами. И неожиданно коллега, который совершенно не разбирается в твоей области, вдруг подкинет свежую мысль и ты поймёшь, что эту задачу можно сделать вполовину проще, если в другом отделе сделают одно нововведение.
Когда такие установки входят в культуру компании и в кровь сотрудников: «ожидание — всегда зло», «общение по задаче всегда ценность», тогда мы и говорим о внедрении Agile или Lean.
А установки сопровождаются конкретными процессами
Как вы увидели Agile и Lean — просто набор принципов. А вот конкретное их применение называется процеcсом управления (или разработки). По принципам Agile или по принципам Lean построены десятки разных систем: Scrum, Kanban, TPS, XP, Scrumban и прочим. То есть:
Внедрение Agile или Lean — это внедрение установок и процесса, позволяющего выявлять проблемы и решать их в соответствии с установками.
То есть прежде, чем говорить, подойдёт или нет Agile вашей компании нужно понимать, что Agile и Lean огромны — и какая-то часть ТОЧНО очень хорошо ляжет на процессы вашей компании и поможет вам сделать их лучше. Но не стоит хвататься за первый услышанный процесс. Подумайте какой подойдёт лучше. Или спросите меня
