Agile по-русски: глубинные ценности и здравый смысл в разработке
руководитель направления PR и контента "Девелоники" (ГК Softline)
Во времена зарождения современных языков программирования разработка выглядела примерно так: заказчик и программист собирались вместе и обсуждали, чего хочет заказчик. Программист слушал его, понимающе кивал и уходил в разработку на полгода с отчетами раз в месяц о проделанной работе. На выходе получалось «нечто», которое неизбежно имело недоработки или ошибки, или вообще работало не так, как предполагал заказчик. После сдачи начинался сериал с чередой исправлений, доработок и внедрения того, что заказчик забыл упомянуть в первую встречу. Не говоря уже об отсутствии проектировщика, тестировщика и дизайнера, функции которых брал на себя программист. Да, это олдскульный “Code & Fix”, который сегодня уже воспринимается как ночной кошмар.
Потом пришла последовательная “каскадная модель”, похожая на конвейер с четко описанными стадиями: сбор требований, проектирование, конструирование, тестирование, инсталляция, поддержка. В проектах появились просчитываемые и понятные зоны ответственности, этапы, бюджеты, сроки. Появилась прозрачность и порядок. Но и эта схема не стала универсальной. Уинстон Ройс, разработчик методологии, отчетливо видел ее ограничения - она подходит только для последовательных ИТ-проектов, в которых требования и документация не меняются на всем протяжении проекта. Но даже это условие не гарантировало получения именно того результата, который хотел заказчик. Этот риск заложен в самой методологии – если на первых стадиях была допущена ошибка, то выявлена она будет только в самом конце.
Последовал процесс глубинных трансформаций этой модели. Авторы стремились изменить методологию так, чтобы обнаруживать и корректировать ошибки на более ранней стадиях: «каскадная модель с подпроектами», «sashimi», итеративно-инкрементальная модель, спиральная модель Боэма, XP, RAD, DCDM…
Так бы все и продолжалось, пока в 2001 году Роберт Боб Мартин не собрал 17 известных разработчиков, авторов книг, учебных пособий по указанным выше методам. Выяснилось, что несмотря на различия подходов, методов и инструментов, все присутствующие разделяют единые мировоззренческие постулаты и ценности. Так появился Agile-манифест, описывающий ключевые ценности, и 12 принципов, ставшие базисом для становления особого вида культуры разработки.
4 ценности Agile:
- Люди и взаимодействие важнее процессов и инструментов.
- Рабочее программное обеспечение важнее всеобъемлющей документации.
- Сотрудничество с клиентами важнее переговоров по контракту.
- Реагирование на изменения важнее следования плану.
Культура разработки и культура управления
Если сравнить культуру Agile с типами организаций по эволюционному уровню (Фредерик Лалу «Открывая организации будущего»), то можно увидеть очень много симметричных черт между Agile и “бирюзовыми” структурами.
Agile | “Бирюза” |
Люди и взаимодействие важнее процессов и инструментов. | Сотрудники — личности, а не инструменты. |
Рабочее программное обеспечение важнее всеобъемлющей документации. | Эволюционная цель, которая меняется вместе с компанией. |
Сотрудничество с клиентами важнее переговоров по контракту. | Открытый обмен информацией. |
Реагирование на изменения важнее следования плану. | Организация – живой организм, который меняется каждый день. |
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. | Высокий уровень свободы и личной ответственности, само мотивация на основании ценностей. |
Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. | Открытый обмен информацией. |
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Отсутствие классической иерархии. |
Нет должностей и отсутствует иерархия; распределенная структура и работа в командах. Роли и обязанности постоянно перераспределяются по согласованию с коллегами. |
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. | Коллегиальное обсуждение проблем, поиск лучшего ответа общими силами. |
Похожи они еще и тем, что очень редко встречаются в чистом виде. На сегодня в России пока две-три бирюзовые организации: сеть «ВкусВилл» и АНО «Уход по соседству».
В них реализованы основные принципы: не прибыль является целью, а эволюционная цель; глубокая целостность сотрудников, а не функциональный подход, самоуправление и самомотивация. И уже первый принцип звучит радикально, ведь бизнес оперирует именно понятиями прибыльность. Всех экономистов этому учат. Но Agile и «бирюза» показывают, что можно по-другому.
В «Уходе по соседству» эволюционная цель вообще направлена на сокращение количества обращений клиентов в компанию! Нонсенс для классических моделей бизнеса, живущего под лозунгом «быстрее, выше, сильнее».
В «Уходе по соседству» так выстроена работа, что патронажный уход клиентам нужен всё меньше. Одна из причин — глубокая целостность медбратьев и медсестёр. Им максимально упростили работу, убрав какие-либо планы по интенсивности работы, графику и запреты по продолжительности нахождения дома у пациентов.Также освободили от написания отчетов! Получается, что не они работают на офис, а офис работает для них, помогая ещё эффективнее обслуживать пациентов. В итоге всего 50 офисных сотрудников поддерживают около 14 тысяч медсестёр и медбратьев.
Полное самоуправления как в офисных подразделениях, так и в командах на местах позволяет компании продолжать расти по всему миру.
Долгосрочное планирование, жесткие сроки и бюджеты, на которых стоят «желтые» и «оранжевые» компании, несовместимы с Agile. Для бизнеса это неприемлемо. Годовые планы развития, планирование бюджетов и продаж являются опорными точками.
Поэтому Agile-подход скорее является ситуационным решением. Если условно разделить деятельность компании на «проекты» и «продукты», то когда речь идет о продукте, именно Agile позволит добиться лучших результатов: сначала MVP, а потом итерационные улучшения короткими спринтами. Это формат Time&Material – заказчик платит за время и уровень компетенций специалистов, а не за конкретный результат, который в начале может быть не определен из-за инновационности разработки.
Продукты можно сравнить с экспериментом: на начальном этапе есть понимание, что хотим получить, но в ходе разработки в игру вступают новые вводные, и требования начинают меняться. Это про неопределенность и постоянный поиск.
«Эджайл хорош для стартапов, ноу-хау-разработок, когда команда делает то, что никто никогда не делал. Быстрый результат и понимание направления поиска» - Павел Машков, руководитель проектного офиса “Девелоники” (ГК Softline).
«Проект с нуля по эджайлу не построить. Будет разорванная картина. Допустим, делаем MVP и итерациями улучшаем. Если есть заказчик, который четко формулирует, что он хочет. Но чаще заказчик как раз плохо понимает, что хочет. Не поверю, что в большой компании все полностью на эджайле. Либо у вас один продукт и вы работаете с ним 30 лет. А если у вас 50 команд, 25 продуктов, то только дозированно, локально. Ни один бизнес не сможет выжить без планов. И в принципе наследие плановой экономики – хорошая школа» - Владимир Михайленко, бизнес-аналитик управления бизнес-решений “Девелоники” (ГК Softline).
И Agile, и «бирюза» - пути не быстрые, потому что много требуют: смены мышления, ценностей, переосмысления базовых понятий – свобода, ответственность, лидерство. А это про эволюцию как отдельного человека, так и сообщества.
«Эту культуру надо воспитывать. Когда я начал внедрять процессный подход в ИТ, ушло 2 года на приучение людей к соблюдению правил. Сопротивление было огромное. Мы постоянно меняли правила, адаптировали, делали удобнее. Люди начинали понимать, зачем они ходят на работу, что от них хочет руководство, какие беды есть у пользователей. В итоге команда с 32 человек сократилась до 10, потому что, когда отстроили все процессы, стали видны перекосы, дублирование функций, избыточность и экономическая нецелесообразность» - Владимир Михайленко.
Особенности национального эджайла
К чему эта предыстория? К тому, что Agile не очередная отвертка в комплекте управленческой команды и разработчиков, но полноценная культура, которую нельзя просто взять и внедрить волевым усилием, вдохновившись очередным бестселлером или тренингом.
Любая культура основывается на очень глубинном слое психике – ценностях, до которых дозревают, на лекции-семинаре их не выучить. И здесь каждая страна и каждая компания проходит свой путь, обусловленный большим количеством факторов: от географического положения, национального состава, до политического устройства, зрелости рыночных отношений между субъектами и отношения к труду специалистов.
Вокруг Agile сегодня много маркетинга. Коучи, разработчики и скрам-мастера предлагают собственные авторские походы. Но суть этой культуры именно в том, что она адаптируется и подстраивается и под команду, и под проект. Это не свод правил, которому нужно следовать буквально. В этом гибкость подхода. Недостаточно ли манифеста и принципов? Зачем нужны переложения и толкования? Возможно, это связано с начальной стадией проникновения культуры на рынок, когда есть сильный скепсис, сопротивление, и много новоявленных “мессий”, подхвативших модный флаг.
«У нас сейчас ситуация такая, что, во-первых, профессиональных Agile-команд очень мало, и стоят они дорого. Во-вторых, большинство тех, кто якобы работают по эджайл, на самом деле самоучки. Чем это плохо? Формализмом. Зачем учиться, когда можно почитать статьи в инете и перейти на новые модные рельсы. Такие команды начинают неотступно работать по букве закона: исполнять дословно манифест, все принципы и ритуалы. Сейчас многие пишут, что работаю по эджайл, но по сути забивают гвозди микроскопом и ходят строем» - Павел Машков.
С 2018 года в России проводится ежегодное исследование культуры Agile в компаниях, выборка составляет чуть больше 1К человек. Подробный отчет и описание методологии можно скачать здесь (https://www.develonica.ru/blog/issledovanie-agile-v-rossii-2021). При этом больше половины респондентов работает в Москве и Санкт-Петербурге, так что можно экстраполировать результаты на всю страну.
Почему так происходит? Ведь видится, что культура Agile помогает избавиться и прививает иммунитет от многих корпоративных болезней: политические игры, процедурная бюрократия, совещательная безответственность, непрекращающийся анализ ради анализа, секретность, игнорирование проблем и нереалистичность целей, невозможность быть самим собой, бумажная волокита и далее так.
Но к такому слому парадигмы готовы немногие, как показывает реальная практика. Многое из перечисленного настолько въелось в картину мира, что стало нормой, которая принимается без критического анализа. Здесь аукается наследие советского прошлого с его плановой экономикой, историческая приверженность модели лидера-царя и сильное влияние государства на бизнес. Согласитесь, что не получится владельцу холдинга объяснить, что жесткая иерархия должна уйти из организации, ему даже представить это как гипотетическую возможность будет сложно.
«В России велика доля «огосударствленного» бизнеса – собственно госсектор и компании с госучастием. А это всегда про долгосрочное планирование, жесткие сроки и бюджеты, и это классический «каскад». Та же ситуация с холдинговыми структурами, производственным сектором, где срок и бюджет ставятся во главу угла» - Дмитрий Садков, бизнес-аналитик «Девелоники» (ГК Softline).
А между тем, отсутствие иерархии классической или руководителя – один из базовых принципов культуры Agile, и вот здесь уже начинает раскрываться загадочная русская душа.
«У нас в головах ещё очень прочна вертикальная модель начальник-подчиненный. Кто-то непременно должен контролировать работу иначе начинается хаос. Мотивация кнутом и пряником настолько привычна, что другой вариант даже не рассматривается. Бывает так, что люди предпочитают уйти из компании, если она переходит на agile» - Павел Машков.
«В других странах люди очень внимательно относятся к правилам, инструкциям. Они не задают вопросы – «зачем» и «почему», написано - исполняем. Мы же сразу начинаем думать и философствовать, анализировать: а зачем это делать, что будет, если этого не делать, а что можно сделать вместо этого и далее так. И представьте, что так рассуждает каждый член команды, и получается в итоге классическая «лебедь, рак и щука». Это особая черта национального характера – пренебрежение правилами. А без следования правилам и процедурам не получится внедрить ни Agile, ни другую «гибкую» методологию. Поэтому российскому Agile нужен руководитель» - Владимир Михайленко.
Для Agile критически важно, чтобы заказчик был полноправным, действующим членом команды. Это значит, что он ежедневно, еженедельно участвует в процесс разработки. Ведь именно благодаря такой постоянной обратной связи снижается неопределённость конечного результата, это гарантия того, чтобы вместо планируемого корабля он не получит дирижабль. Но и с реализацией этого принципа у нас всё непросто. Я заплатил, и хочу получить результат. А идея того, что помимо «заплатил» нужно еще инвестировать свое время, пока приживается плохо.
Без этого условия неосуществим первый и главный принцип культуры – «наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения».
«Заказчики чаще не готовы сменить роль «приемщика работы» на «участника». Не готовы погружаться в подробности, в процесс разработки продукта. И назначенный руководитель проекта со стороны заказчика в самом начале еще как-то вникает, но убедившись, что исполнители работают, а не «груши пинают», переключается на свою рутинную работу с эпизодическими встречами. И Agile остается за скобками таких проектов» - Павел Машков.
Над проектом должны работать мотивированные профессионалы. “Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им» - гласит один из принципов. Это значит, что мотивация достижения KPI ради премии или начисления баллов в копилку авторитета не работают. Люди объединяются вокруг идеи, вокруг интересного проекта, и не нуждаются в подогревании интереса. Их цель, как профессионалов, сделать качественно, и более того, постоянно рефлексировать и совершенствовать результат.
Важным мотивирующим фактором становятся особые отношения внутри команды - «семейные». Именно эта особенность agile-команд приобретает аутентичные черты в каждой национальной и культурной среде. Например, ритуалы.
«Многие методологии геймифицированы. В этом мне видится некоторая «детскость», избыточность. Для меня во главе угла здравый смысл, то есть понимание, что любой ритуал должен быть настроен под конкретную команду. В одном проекте ежедневные митапы – трата времени, в другом – необходимость, диктуемая самим продуктом. И ретроспективу проводить еженедельно может быть избыточным. Следовать формально букве манифеста – значит не понимать суть культуры» - Дмитрий Садков.
Семейные отношения – это про открытость, доверие и безопасность, но и про иерархию. Как обстоят дела с лидерством, свободой, на которой держится принцип самоорганизации, когда команда решает, как организовать работу, и что, собственно, делать.
Классическая иерархия – прямое подчинение руководителю, выполнение поручений, отчетность – не работает. Но это в манифесте. На практике, как мы выяснили, российскому эджайлу, оказывается нужен руководитель. Но не только из-за привычного- царя и нелюбви к правилам. Отношение к ответственности у нас специфическое, сложно признавать свои ошибки и тем более провалы.
«Мало людей, готовых взять и признать свою ответственность за провал. Везде я сталкиваюсь с обратной ситуацией, перекладыванием. Да, мы можем не бояться начальника, но страх ошибки вшит с детства, со школьной скамьи» - Владимир Михайленко.
Памятка
Рецептов построения “успешного Agile” не существует. Есть опорные принципы и широкое поле для экспериментов с их реализацией в конкретном проекте с конкретными людьми. Можно расписывать выгоды от внедрения, но приживется ли эта практика в России или нет, покажет время, ведь речь не об отвертках. Зато можно точно сказать, чего не надо делать, развивая эту культуру в своей команде.
Выгоды внедрения Agile
6 смертных грехов эджайла
- Навязывать свою точку зрения.
- Не учитывать этапность принятия изменений: отрицание-гнев-торг-депрессия-принятие.
- Не слушать мнение других участников, не реагировать.
- Давить авторитетом.
- Брать ответственность только на себя, не разделяя ее с командой.
- Не выполнять правила и договоренности, принятые всеми.