Термин 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 и lean.
Почему бы не смотреть эти результаты (если они интересны) непосредственно в системе или в рассылке? Зачем их ежедневно копировать на флипчарт?
В конце концов, для каждого есть информация важная и всё остальное.
Фокусировка - статистики у маркетологов много - а кол-во лидов - это измеримый результат работы (информационное табло), также это табло видят и другие участники команды - которые не отвечают за лиды - но являются частью команды - что также влияет на общий командных дух и наконец прозрачность.
Я много задач решал, но вывод один - вешать табло (это касается большинства нефинансовых показателей) в отделы/департаменты и подразделения - вы для примера спросите какой-нибудь важный показатель у сотрудника - только чтобы он вам сразу без запинки ответил - если ответит значит вам табло не нужно или не так актуальны показатели для работы.
Очевидная воронка. Почему бы не набрать больше разработчиков? Все заказчики - внутренние, объём работы можно прогнозировать.
Вот это предмет дисскусий - если подразделение/филиал/департамент на своей рентабельности и себестоимости - то желающих оплачивать и содержать доп. косты - нет. Объем работы, не удается прогнозировать - как и писал много заказчиков - и если все хорошо - идут в плане, то и решим спокойный, а если нет то тут и начинаются "авралы", тестирования "гипотез" и т.д. Т.е. лаг для несрочных задач - месяц - не так уж и много.
У такого рода мини-проектов есть менеджеры? Кто платит за банкет? Тестирование большого количества гипотез невозможно сделать быстро и бесплатно, а ресурсы, как указано, ограничены, и за них идет борьба.
Рук-ль разработки менеджерит проекты (группа разрабов и дизайнеров), все делится на стоимость лида, в конечном итоге. Какие то гипотезы проверяются силами маркетологов, ведь пост написать, поставить зщадачи копирайтерам и добавить ключевики - т.е. гипотезы разные и все-таки изначально идут по hadi с минимальными тратами, если гипотеза подтверждается то закатывают в спринт и т.п.
Пока я вижу не очень формальный итеративный процесс разработки и еще менее формальный процесс подготовки требований. Понятно, что более опытные сотрудники допускают меньше простых ошибок, не уверен насчет прочих ошибок - как и их последствий.
Ну требования все собраны в рабочем порядке, далее утверждение спринта на неделю - это для разработчиков, у маркетологов и seo и дизайнеров - свои задачки, их то же приритезируют на спринты, но в отличии от разрабов к ним в течении недели придлетают новые задачки- которые нужно делать в рамках этой же недели. Например: Компания разработало новую услугу: Импортозамещение ПО, продуктовые маркетологи - декомпозируют свои тезисы, общий маркетинг свои - в итоге получается концепт, того что должно появиться на сайтах с какими формами обратной связи - далее летит в копирайтинг, в дизайн и заканчивается задачей в разработку с подготовлеными вводными. Ну тут наверное еще куча нюансов - но мне они не интересны.
Еще одно узкое место?
Кто владеет бюджетом разработки (или бюджетом проекта)?
Узкое - да! но писал выше - платить за полноценного интернет-маркетолога не все могут - стоимость лида будет зашкаливать. Владет бюджет - владелец продукта/рук=ль офиса - рук-ль направления, в конечном итоге - рук-ль офиса, поскольку бенефециары (выручка) от продаж идет в офисы.
Вы в данном примере - это кто?
Ответственный за продукт/направление
Евгений, не все просто, но нужно понимать, что разработка - это внутренних ресурсов, внешняя разработка и внедрения для клиентов осуществляют группы не связанные с маркетингом и работают по своим шаблонам. Есть ярые приверженцы скрама - которые не берут клиентов не готовых к внедрению по скраму - от слова совсем, есть смешанные группы, есть группы которыне работают только по проектной технологии (условно стандартной).
Все-таки стендапы можно воспринимать как зарядку или бег по утрам. Как недавно ответил мне знакомый на вопрос "а зачем ты бегаешь по утрам"? Да если не пробегу свои 2 км, то и день не тот и завтрак не вкусный да и настроения особо нет.
Любой каприз. Не хватит 100 - можно и 1000. Тема пока горячая, а завтра нам придумают новые. Сообщество вежливо попросим, кто-то согласится и внесет свою лепту. Кто-то что-то мог видеть и готов поделиться. Краудсорсинг.
Но интересна не компиляция примеров из литературы, которые мы не можем проверить, а личный опыт и ощущения от проделанной работы.
Могу только сказать, что фундаментальные проблемы управления проектами не решаются простой заменой методологии. В Вашем примере речь скорее о бизнесе и общей организации работ, там свои очевидные проблемы и трудности.
Agile PM в каком угодно варианте никак не гарантирует, что проект будет успешным, причины провалов крупных проектов практически одни и те же десятилетиями. Хуже, когда меняются только названия и отдельные термины - к примеру, летучки и планерки с понедельника мы называем спринтами. Но хорошо то, что все эти проблемы известны, и их можно держать под контролем - если есть на то воля и желание.
Одна собака средних размеров или покрупнее полностью решит проблему вкуса завтрака, лишнего веса, пониженного аппетита и пр.. С ней, кстати, тоже можно тренировать agility. Двойная польза.
то, в чём Руководитель/Собственник Компании ничего не понимает....внедрить невозможно.
Ох, как Вы правы.
По моему автор следует модному в последнее время принципу упомянутых им же инфоцыган, накидать модных фраз для объема текста, что скорее свидетельствует о том что он очень хочет это применить но не сильно понимает как именно... :)
Согласен с мнением в дискуссии, что Agile это там где высока неопределенность, т.е. проекты и разработка, и это не методология в общем-то, а религиозно-подобный набор принципов.
Роман. Добрый день) Уж поверьте, как раз напротив старался сократить объем текста, чтобы уложиться в правила публикации. Если я что-то "очень хочу", то делаю это. А делаю потому что прекрасно понимаю что и как). Дело в том, что нельзя однозначно сказать "как именно", т.к. в мире нет двух одинаковых объектов. И каждый раз это уникальный опыт и лишь понимание "матчасти" способствует успешной реализации. Именно к этому я и призываю уважаемых руководителей и видимо Вас - учите матчасть))
Основная причина - привычка работать так, как ранее. Ведь все же работало!