Обновление 2: Другим названием этой статьи могло бы быть "Продуктовые команды против Delivery-команд". Это потому, что с момента публикации этой статьи, я написал статьи, описывающие разницу между продуктовыми командами и фиче-командами, а также разницу между продуктовыми командами и командами проектирования. И в этих статьях я ссылался на модель, описанную здесь, как на delivery-команды.
Обновление 1: Хочу уточнить, что я никоим образом не связан ни с одной из различных Agile-организаций или альянсов. Мы не получаем и не предоставляем никаких средств никому из них. Это наша твердая политика в SVPG. Мои мысли, изложенные ниже, сформулированы исключительно в духе помощи компаниям в их осознанном выборе процессов или инструментов, которые могут наилучшим образом удовлетворить их потребности.
Впервые я познакомился с методами Agile около 15 лет назад, когда впервые столкнулся с некоторыми продуктовыми командами, которые экспериментировали в области новых способов создания программного обеспечения. Я давно изучаю процессы и инструменты для разработки продуктов, и поскольку изначально эти методы зародились в мире пользовательских решений/проектов, меня сразу же спросили, что я думаю о том, как использовать их на практике.
В первую очередь мое внимание привлекли несколько основных принципов Agile, поскольку они пытались институционализировать несколько из тех черт, которые я считал наиболее важными для лучших продуктовых команд.
В любом процессе существует множество различных процедур, суть Agile, с моей точки зрения, применительно к продуктовым командам, сводится к двум вещам:
Первая, привлекающая наибольшее внимание, — это идея о том, что для нас и наших клиентов лучше осуществлять непрерывный выпуск небольших релизов — как правило, раз в неделю или две (чем чаще, тем лучше).
Для компаний, которые раньше выпускали релизы ежемесячно или даже ежеквартально (такое было нормой), это подразумевало серьезные преобразования в том, как они создавали, тестировали и выпускали свои продукты. Хотя для многих команд это стало нетривиальным препятствием, что означало, как правило, необходимость инвестировать в автоматизацию тестирования и выпуска; в итоге они оказались в выигрыше.
Второй, менее очевидный, но, на мой взгляд, наиболее глубокий момент заключается в том, что Agile дает возможность команде на самом деле найти способ решения проблемы. Это может показаться очевидным, но в те времена все было не так. Вместо этого стейкхолдеры давали командам довольно конкретные списки функций, которые необходимо было реализовать (т.е. дорожные карты), а затем менеджеры проектов очень четко назначали и отслеживали задачи для определенных людей и сопровождали выпуск релиза в продакшн (выход).
Итак, если первое изменение представляло собой существенную разницу в том, как на самом деле создавалось и выпускалось программное обеспечение, то второе больше касалось того, как работают и решают проблемы команды, и кто берет на себя ответственность за результат.
Первое изменение не сильно обеспокоило большинство компаний. Порой их маркетологи сталкивались с гораздо более частыми выпусками, а клиенты преодолевали чувство утомления от перемен, но для борьбы с этими побочными явлениями появились хорошие методы.
Однако второе изменение — это совсем другая история. Внутренняя политика компаний стала более определенной.
Многим из стейкхолдеров было некомфортно передавать ответственность продуктовым командам, особенно если в них были плохо подготовленные "владельцы продуктов", которые больше занимались процессом и бэклогом, и гораздо меньше — глубоким пониманием клиентов, данных, рынка и отрасли, необходимых для того, чтобы команда могла эффективно решать сложные проблемы способами, которые работают на бизнес.
Поэтому тогда — да и сегодня — в большинстве компаний заинтересованные лица по-прежнему предоставляют командам дорожные карты с описанием того, какие функции и проекты, по их мнению, лучше всего реализовать. Даже если команды используют Agile методы, они не обладают полномочиями и ответственностью в том смысле, который я описываю. Их задача — реализовывать.
Но помимо того, что они по-прежнему получали дорожные карты, в основном команды смогли самоорганизоваться и управлять своими коллективами так, как посчитали нужным, что, безусловно, дало значительные преимущества, в том числе с точки зрения производительности и морального духа участников.
Но в большинстве компаний существовала еще одна структура, которая была решительно недовольна Agile.
Во многих крупных компаниях в до-Agile времена работала довольно мощная организация под названием "PMO", что означает "Офис управления программами" (управление программами — это, по сути, менеджмент проекта при реализации очень больших задач).
Это группа менеджеров проекта, которые отвечают за всю работу (продукт, дизайн, проектирование, QA, эксплуатация и т.д.) и обеспечивают выполнение дорожных карт "вовремя и в рамках бюджета". Они олицетворяют собой организации с проектным майндсетом.
Когда большинство компаний перешли на Agile, данная PMO-группа была намеренно отодвинута на второй план. В качестве аргумента приводился довод, что продуктовые команды должны взять на себя ответственность за это направление.
В некоторых компаниях должности PMO были фактически ликвидированы, а у других они были отодвинуты в сторону от работы над программным обеспечением и занимались чем-то вроде организации переездов из одного здания в другое.
Можно представить, что это не очень понравилось всем PMO-организациям, но импульс к внедрению Agile была чрезвычайно велик, а разочарование от старых методов работы оказалось настолько ощутимым, что они провели почти десятилетие, пытаясь понять свое новое положение в мире технологий.
Но они вернулись.
За последние несколько лет ряд компаний интересовались моим мнением о таком понятии, как процессы, ориентированные на "Agile at Scale". Наиболее активно рекламируемым (если отчасти судить по количеству спама, который я получаю) является SAFe (Scaled Agile Framework).
Теперь я должен кое-что прояснить.
Обычно я пишу только о тех процессах и методах, за достоверность которых могу поручиться лично. Проблема в том, что мне не известна ни одна ведущая технологическая компания, использующая SAFe.
Поэтому, хотя я читал официальные документы, смотрел видео, разговаривал со многими людьми, которые прошли обучение и были вынуждены использовать SAFe, все, что мне известно об этом, я знаю только понаслышке.
Все примеры, которые я нашел, относятся к крупным ИТ-компаниям, организациям с проектным майндсетом — крупным банкам и страховым компаниям, а не предприятиям, ориентированным на технологические продукты; поэтому это не тот тип организаций, с которыми я обычно работаю.
Также признаюсь в сильной предвзятости. Из всего, что мне довелось прочитать и услышать, сделал вывод: я бы не хотел работать в компании, использующей подобный процесс. Не представляю себе ни одну из известных мне ведущих компаний, занимающихся разработкой технологических продуктов, которая решила бы перейти на SAFe, а если по какой-то причине они это сделают, не сомневаюсь, что после такого их ведущие специалисты уйдут.
В настоящее время люди, стоящие за этим процессом, действуют весьма сообразительно. Вместо прямого наступления на Agile, они используют маркетинговую стратегию "принять и расширить", так что вы обнаружите все наиболее популярные выражения из мира Agile и Lean, включая Scrum, Kanban, XP, Lean Startup, Lean UX, Continuous Delivery и DevOps.
Но это лишь маркетинговая стратегия. В основном они просто переопределяют значение этих терминов, чтобы скрыть их назначение. Epic становится "мини бизнес-кейсом"; концепция управления звучит не столь обременяюще, если называется "бережливым управлением"; а управление программой может вызвать меньше раздражения, если позиционируется как "гибкое управление программой". Постоянные разговоры об итерациях и agile заслоняют от нас то обстоятельство, что эти "Agile Release Trains" в основном происходят каждые 10 недель.
Можно продолжать и дальше, но, надеюсь, суть ясна. Основные плюсы Agile и Lean теряются. Точнее, если вы будете придерживаться этого процесса, думаю, будет невозможно достичь основных преимуществ инноваций, которые могут быть получены в результате эффективного использования методов Agile и Lean.
Пару лет назад я писал о первопричинах неудач в продуктовых компаниях и определил по этому поводу список из десяти ключевых атрибутов метода Waterfall и проектного мышления. Сейчас я вновь прошелся по нему от и до, сравнивая с SAFe. Оказалось, что буквально все те же десять проблемы присущи и данному фреймворку. Можно утверждать, что они свойственны данному процессу.
Самое главное, критически важное определение выделенной команды по продукту (она же сквад) было сведено на нет. В SAFe этот принцип настоящей продуктовой команды был принижен и умален, и сейчас основной концепцией является Программа, имеющая нисходящую модель, состоящую из продакт-менеджера, архитектора и менеджера по подготовке релизов, которые принимают все ключевые решения, а также несколько команд разработчиков с низкоуровневым продакт-оунером, которым поручается выполнение различных задач.
Существует несколько вариантов SAFe в зависимости от величины вашей компании и от того, как много функций управления и контроля вы хотите внедрить. Но если бы вы были старомодным PMO, и вам не хватало классического портфолио, управления программами и проектами, скорее всего, вам бы это понравилось.
Суть в том, что SAFe — это в значительной степени нисходящая, наемническая модель; роль дизайна и особенно проектирования не так сильна, как должна быть; главное — отдача, а не результат; и реальным следствием этого являются препятствия для непрерывных инноваций.
Справедливости ради, стоит отметить некоторые сценарии, в которых подобный процесс может быть уместен (или, по крайней мере, он не намного хуже альтернативных вариантов):
организация, где большинство, если не все, инженеры работают на аутсорсинге, используя агентство или подрядчиков
большая работа по преобразованию платформы (при условии, что команда заранее грамотно определила подходящую архитектуру и стек технологий)
организация без настоящих продакт-менеджеров или продакт-дизайнеров, а также с очень слабыми или неопытными разработчиками
Я понимаю привлекательность возврата к модели управления и контроля для крупных организаций с проектным майндсетом, но компании, которые зависят от последовательных инноваций и критической роли инженерии в сфере изобретательства, а не только кодирования, по моему мнению, сделают серьезный шаг назад.
Когда я впервые услышал об этом процессе от человека, который работал в компании (крупном банке), внедрившей его, то сказал ему, что это похоже на предсмертные муки метода Waterfall. Но на самом деле их идея, похоже, нашла отклик в организациях с проектным майндсетом, и то, что это может вызвать аллергическую реакцию в Кремниевой долине, не означает, что она не получит распространения в других местах.
В частности, почти каждая крупная компания доинтернетовского периода сегодня имеет какую-то "инициативу по цифровой трансформации", но большинство из них не понимают, что суть этой трансформации заключается в переходе от проектного майндсета к продуктовому.
Если объединить привлекательность месседжа "использования современных концепций Agile и Lean" с вполне реальными проблемами, возникающими при масштабировании, нетрудно понять, как крупные компании могут стать жертвой этой маркетинговой стратегии, по иронии судьбы часто прикрывающейся девизом цифровой трансформации.
Рост числа подобных процессов ясно показывает мне, что значительная часть представителей широкой отрасли все еще не понимает разницы между проектным и продуктовым мышлением, и поэтому они не видят реальной ценности Agile или Lean, либо имеют об этом настолько поверхностное представление, что их легко переубедить.
Поэтому я собираюсь удвоить свои усилия, помогая разъяснить эти моменты. Ждите еще несколько статей на эту тему о различиях между командами и организациями с проектным и продуктовым мышлением.
Примечание: После публикации этой статьи я получил много вопросов и опубликовал продолжение: Scaling Agile FAQ.
Обновление сентябрь 2020 г.:
Эта статья была опубликована более двух лет назад и получила широкое распространение в отрасли. Сотни людей лично связались со мной, чтобы рассказать, что к сожалению, такая ситуация является реальной и проблемы с SAFe оказались такими же серьезными, как я описал.
Интересно, что до сих пор ни один человек не сообщил мне, что их опыт был намного лучше. Я узнал об одной компании Fitbit, занимающейся продажей реальных продуктов, которая в какой-то момент попыталась использовать SAFe. Однако когда я связался с кем-то из своих знакомых, мне сказали, что они отказались от этого процесса, а человек, который убедил компанию попробовать его, покинул эту организацию. Мой друг был удивлен, когда узнал, что на маркетинговом сайте SAFe они все еще числятся как референтный клиент этого процесса. Очень показательно. В итоге я описал их опыт здесь.
Материал подготовлен в рамках курса «Системный аналитик. Advanced».
Всех желающих приглашаем на бесплатное demo-занятие «Как аналитику выжить при цифровой трансформации». На занятии обсудим:
- Что такое цифровизация.
- Чем она отличается от автоматизации.
- Как аналитик может повлиять на процессы при цифровой трансформации.