Термин Agile означает «гибкость», появился как более совершенный метод разработки ПО в 2001 году, став плодом встречи 17 людей из мира IT. На той же встрече был сформулирован знаменитый «Agile-манифест», закрепивший принципы и ценности Agile.
Методы Scrum, OKR, Kanban по сути являются разновидностями Agile-подходов и каждый из них имеет своих адептов, последователей и почитателей, благодаря которым методы доказали свою эффективность, и вышли далеко за пределы IT-сферы.
И действительно, каждый в отдельности и все вместе эти методы великолепны, они просты, понятны и эффективны:
- Scrum – это формула 3-5-3: три роли, пять мероприятий, три артефакта.
- OKR (Objectives and Key Results) – это четыре суперсилы: приоритизация и обязательства, синхронизация и прозрачность, мониторинг, стремление к выдающимся результатам.
- Kanban – это 9 ценностей: прозрачность, баланс, сотрудничество, клиенториентированность, поток, лидерство, понимание, согласие, уважение.
Конечно, это общее представление. Внутри методов все это раскладывается на различные практики, способы и инструменты, тем не менее, выглядит достаточно простым. Казалось бы, вот она пресловутая «волшебная палочка», которая раз и навсегда решит все проблемы компании.
И как это бывает, на зарождающемся хайпе пышным цветом расцвело «инфоцыганство», появилось множество консультантов, специалистов и «экспертов» по внедрению, с одной стороны. С другой, любознательные сотрудники хороших компаний, прочитав одну-две книжки по теме, или прослушав курс от «инфоцыган», добросовестно пытаются что-то изменить в компании. Это в любом случае хорошо, учиться всегда хорошо. Плохо, что неудачные попытки вызывают разочарование, отторжение и, в лучшем случае, откат к привычным схемам работы.
Две рекомендации для начинающих изучать Agile-подходы
- Не стоит отчаиваться. Даже отцы-основатели Agile-методов прямо говорят, что далеко не всегда все получается с первого раза. И это нормально.
- Учите матчасть.
Если с первой рекомендацией все в принципе понятно, то вторая требует комментариев. Нужно абсолютно ясно понимать, что внедрение любого подхода Agile – это не просто смена инструмента, это изменение всего способа ведения дел, изменение архитектуры компании как системы. Наиболее продвинутые понимают это, но, как правило, допускают одну из ошибок: проводится либо попытка радикального внедрения (сломать все и сразу), но получаются руины, либо внедрение пилотного проекта, но при этом проекту подчинены все ресурсы (часто это даже не замечается), и потому мультиплицировать опыт не удается.
Причины провалов Agile-подходов
Если говорить в контексте подходов Agile, прочтение всех книг и прохождение всех курсов по теме совсем не гарантируют результат, хотя и не отменяет возможность успеха. Авторы и разработчики Agile-методов безусловно умные и талантливые люди, методы эффективны и просты, множество компаний по всему миру успешно используют их в работе. Но так ли все просто на самом деле?
Никто из авторов методик не отрицает, что в их основе лежат так называемые «бережливые технологии». К сожалению, в России сформировалось очень узкое представление о том, что это такое. Во многом благодаря вошедшему в деловой обиход термину «бережливое производство», который резко сужает фокус восприятия на одной отрасли. Между тем это полноценная философия и концепция управления, имеющая в качестве фундамента строго научную основу. Компания Toyota, например, которая ассоциируется с термином «бережливое производство», на этом фундаменте построила свою уникальную систему управления.
Сами японцы искренне недоумевают, когда многочисленные жаждущие последователи пытаются изучить и скопировать инструменты и методы, которые каждый раз были разработаны для конкретной и всегда уникальной ситуации. И при этом не пытаются понять сути.
Нет цели пускаться в теоретические философствования и описание концепции бережливого способа ведения дел. На эту тему имеется масса источников и достаточно много (но очень мало для России) специалистов. Вдумчивый читатель даже при беглом серфинге источников увидит, как много общего между Agile-подходами и lean-технологиями. Но основная концепция все же была сформулирована именно в lean manufacturing и даже научно обоснована.
Бережливые технологии также раскладываются на бесчисленное множество способов, методов, инструментов. Проблема в том, что каждый раз это уникальная история, поэтому простое копирование с учебника или с реальной, но чужой ситуации не гарантирует успех. Это одинаково справедливо как для бережливых технологий, так и для Agile-подходов.
Можно возразить: если не пробовать, то никогда и не получится. Это справедливо и правильно. Но просто делать что-то, пусть даже с энтузиазмом, не понимая, что ты делаешь, это дорога в никуда. Все советы типа «просто возьми и сделай это» хороши разве что на этапе стартапа. При управлении компанией этот принцип хорош, когда хотя бы один человек (в бережливых технологиях его называют «агент перемен») не просто знает, что нужно делать, а понимает – почему.
Носители знаний – люди. Источник инноваций – люди. Из всех трех элементов, которыми следует управлять (люди, процессы, технологии), люди – наиболее уязвимый, проблемный, но и самый ценный актив. Поэтому, поддавшись веянию моды или осознав необходимость перемен, проведите экспресс-аудит своего основного актива, прежде чем что-то внедрять.
Аудит перед внедрением гибких методологий
- Руководителям высшего звена стоит начать с себя и предельно честно ответить на вопрос – готовы ли лично вы меняться, потому что просто мониторить не получится. Готовы ли вы не сломаться при возможных многократных неудачах и не дать приказ отступать.
- Какими знаниями обладает компания. Есть ли внутренний «агент перемен» или вы нашли внешнего? Это должен быть человек, который не просто знает спецтермины и по памяти может перечислить все принципы и ценности, а который на глубинном уровне понимает и принимает их. Тут сложно. С одной стороны, нет, наверное, таких методов оценки, чтобы выявить такие компетенции, с другой, даже наличие опыта еще ничего не гарантирует. Но если вы точно готовы меняться, то просто поймете – ваш человек или нет.
- Оцените потенциал своей команды, каждого сотрудника. Вам понадобится стартовая команда из людей, которым как минимум не все равно.
- Оцените ресурсы. Внедрение любого метода, как правило, малозатратно, но даже небольшие вложения, например, покупка магнитно-маркерных досок, иногда вызывает сложности.
Подобных списков в разных вариантах может быть множество, но только обладая знаниями, готовностью, командой и ресурсами (во всех смыслах), можно рассчитывать на успех.
Собственно, это и есть обратная сторона провалов и неудач. Если компания не обладает знаниями, она просто не знает, что и как делать, в лучшем случае пытается скопировать чужой опыт. Если не готовы руководители, то вообще не стоит ничего начинать. При этом не следует путать декларации с реальной готовностью. Если дела настолько плохи, что нет людей, искренне заинтересованных в развитии и переменах (или вы их просто не видите), то в одиночку вы скатитесь либо до административно-командного стиля (если ваше положение в компании достаточно высокое) и будете насиловать систему, пытаясь что-то изменить, либо станете «белой вороной» и поводом для иронии и насмешки. С ресурсами все не так плохо – их можно создать, но многие причины провалов часто обусловлены отсутствием ресурсной поддержки.
Учите матчасть
Общая идея этой статьи такова: если вы пытаетесь внедрить Agile-подходы, учите матчасть. А матчасть в данном случае – это бережливые технологии и их фундаментальная основа. Это сформирует необходимый уровень знания и экспертизы, которые резко увеличит шансы на успех. Не поддавайтесь искушению простотой, если бы все было так просто, то все компании были бы успешны и счастливы. Не бойтесь экспериментировать, не бойтесь привлекать внешних специалистов – это всегда свежий взгляд на способ вашего ведения дел. Полагайтесь на людей!
Также читайте:
Есть и ТРИЗ, есть и ТОС, есть и ещё много чего. Я не отрицаю и не ругаю ни один из существующих методов. Думать надо, что, как и когда применять))
Алексей, отнеситесь к вашей задаче-проблеме творчески.
Если видите проблему только в стендапах, переформатируйте их во что-то другое. Спросите себя чем отличается стендап от "типичного" производственного совещания... Подумали??? Зачем выбрана такая форма совещания??? Зачем такая атрибутика?
Реальные отличия заключаются только в демократичности процесса + скорости проведения + еще в атрибутике для поддержки первого и второго в этом списке.
Атрибутика - это часто только внешние :) признаки принадлежности к чему-либо.
Андрей, это все понятно, я же пишу про практику - есть ли примеры? Личный интерес именно к этому атрибуту (стендап)
Я же пишу - что не представляю такие стендапы - но это не ограничение применение подходов.
В случае с работой ОМ применима ассоциация с баскетбольной командой (про ассоциацию бизнеса с футболом и кейсом применения писал в статье: Бизнес как футбол, или Как увеличить выручку на 100%, поскольку речь идет от нескольких сотнях и иногда и тысячах лидов в день. В упрощенной форме описываю работу ОМ и использования в нем agile-подходов.
Вводные: Отдел (департамент) интернет-маркетинга состоит из 20+ штатных сотрудников интернет-маркетологи, smm – щики, seo-шники, web-дизайнеры, event-маркетологи и разработчиков и саппотеров продуктовых страниц и сайтов компании. Дополнительно, в компании есть разрозненные по офисам (филиалам) и продуктам компании – маркетологи направлений/продуктов/филиалов. На стендапах присутствуют – интернет-маркетологи, event, smm, руководители: разработки, дизайнеров, копирайтеров, seo
Основная задача департамента: На департамент декомпозируются с учетом конверсии (исходя из планов продаж) целевые показатели по лидам в квартал/месяц.
Дополнительные вводные: 30% дохода интернет-маркетолога привязана к кол-ву плановых лидов, интернет-маркетолог как правило ведет несколько проектов/продуктов у которых есть свои владельцы, отвечающие за конечные продажи, управление департаментом маркетинга осуществляет директор по маркетингу (играющий тренер), но задачи в том числе прилетают от офисов/продуктовых маркетологов/ рук. проектных команд и т.д. Соответственно, возникают сложности с приоритизацией задач, с ограничениями производственных возможностей разработчиков/дизайнеров/копирайтеров и т.п.. Платят за весь интернет-маркетинг – заказчики, т.е. простыми словами у каждого лида есть стоимость (проектные лиды, региональные лиды, лицензионные лиды и т.п.) – и это еще одно ограничение. Заказчики – территориально в городах и регионах и физичечески не могут «дотянуться» до интернет-маркетологов, а иногда им этого очень хочется :)).
Решение: внедрение agile-подходов
Результат: Заказчики через инструменты командной работы видят все свои задачи и их статус, маркетологи ежедневно видят свой прогресс по лидам (их декомпозируют с кварталов/месяцев на недельные), разработчики формируют недельные спринты – и все знают, что если задачка попала в спринт – то вероятность исполнения – 95%, происходит «борьба» за попадание в недельный спринт.
На стендапах решается как раз «Что мешает» добиться – из-за этого возрастает и скорость, второе – несмотря на средний стаж 2-3 года, непосредственно интернет-маркетологи редко переваливают за 2 года, поэтому инструмент стендапов и спринтов – существенно сокращает сроки ввода новых сотрудников. И важно – все понимают, чем заняты и почему и из-за чего могут возникнуть сложности, что в свою очередь позволяет и заказчикам быть в курсе всего…
Не все гладко, но в целом - оценка eNPS высокая.
Коллектив, большинство 20+, руководители бывают 30+, 40+ уже очень редко, 50+ - "динозавры", возможно они есть, но не встречал.
Про примеры внедрения и сравнения lean и agile, можно найти информацию на хабре, там же ребята и компании активно могут поделиться кейсами (про поделиться - предположение).
Льзя (даже нужно), это ядро системы, вокруг которого можно строить нормальные расширения. При отсутствии - броуновское движение в сторону светлого будущего, по полю граблей.
Про скрам такого не сказать, это да ))
Не представляю, что основная проблема в стендапах ...
В IT у нас не было таковой. В начале была небольшая комната на всех, на подобных стендапах сидели на стульях (не стояли) люди разных возрастов от 60+ и меньше. Потом была другая территория и несколько комнат - на стендапах сидели на пуфиках - Главное отличие сидели, а не стояли, потому что приходилось работать и ночью.
А работники 60+? - Куда вы денетесь, когда наступает кадровый голод и кругом полная безграмотность?
У вас есть большая проблема - нужен ли вам agile или какую платформу agile выбрать.
Меня исключительно интересовал процесс стендапа - ничего более.
Правильно ли я понимаю из ответа что никах сложностей реализации стендапов для 50+ не возникает: люди - действительно активны, стремятся высказаться и не воспринимают это больше как для галочки?
Александр - ЛИДЫ. Ответил развернуто в ответе Евгению в предыдущих комментариях.
Вы же их нанимаете :) Я так и не понял из статьи и длинной дискуссии какая у вас платформа agile или вы только её выбираете. Слово "тренер" прозвучало в статье.
Если вам подошли спецы 50+ -- 60+, надо найти тренера который понимает, что не надо их бояться, что они тоже будут работать как и более молодые. Но что это не безграмотная шпана - можно не объяснять как и что делать.
Алексей, мне понравилась ваша статья и наглядная схема в виде игроков на поле. Но мне представляется, что если вы переставите "игроков" на другие места, то проблемы станут понятнее.
У вас "Нападающие" - это продажники, они пасуют мяч "Полузащите" – в вашей статье - это отделы внедрения и проектные отделы, внедряющие продукт или оказывающие услугу клиенту. Вы ещё где-то писали, что клиенты мечтают общаться с маркетологами - тогда маркетологи - это нападающие с мячом, которых вы не пускаете к воротам.
В вашей схеме несколько нападающих (продажники) могут пасовать одному полузащитнику (маркетологу) одновременно несколько мячей - пусть в вашем футболе будет много мячей. Это узкое место по Голдратту.
Т.е. с чего я и начал - Если переставите местами нападающих и полузащиткников в вашей схеме - будет более понятно, где искать проблемы. Если нагрузка увеличится, то они и полезут со всех сторон.
И что-то я задумался в сомнении о возможности применения у вас scrum. По схеме это больше напоминает процессный подход, и он выдержит большую нагрузку чем scrum.