Кино, машины и ФБР. Как добиться успеха с помощью agile-подхода Scrum
Успешные компании отличаются от остальных в первую очередь подходами, которые они используют в работе. BBC, Google, Electronic Arts, Philips, Intuit, Microsoft и даже FBI используют методологии Agile, чтобы разгонять свои проектные команды до небывалой скорости и эффективности. Продукты, которые они при этом создают, всегда сдаются раньше срока и на 100% отвечают требованиям потребителя. Сегодня вы узнаете о самом популярном agile-подходе — фреймворке Scrum и о том, как он помогает командам достигать успеха.
Agile – это семейство «гибких» подходов к разработке программного обеспечения, которые сегодня используют во многих сферах бизнеса для эффективного управления проектами. На картинке показаны наиболее известные, но далеко не все практики и методы, которые опираются на принципы Agile.
Одним из самых популярных agile-подходов является фреймворк Scrum, так называемый каркас (framework – «каркас»), который помогает внедрить agile-принципы у себя в компании.
Scrum зародился в 1993 году в ходе работы Джеффа Сазерленда в IT-корпорации Easel. Сегодня этот метод помогает достигать высоких результатов в любой сфере, где прибыль зависит от работы команд. По словам Джеффа, Scrum позволяет делать в два раза больше за вдвое меньшее время.
Scrum воплощает в себе главные принципы Agile и как метод командной работы способен буквально вытащить с того света проблемные проекты — те проекты-динозавры, на которые компании когда-то возлагали большие надежды, но сроки реализации давно прошли, львиная доля бюджета пережевана и выплюнута, а воз и ныне там. Как же работает эта методика?
Как работает Scrum?
В центре Scrum — команда максимум из девяти (лучше — семи) человек. Это скрам-команда. Ее особенность в том, что все участники команды — универсалы. Команда может справиться с проектом своими силами, не привлекая дополнительных людей. Она не имеет руководителя или начальника извне, управляется сама собой и наделена полномочиями самостоятельно принимать решения. Это абсолютно самодостаточная, автономная группа людей, объединенных общей целью.
«Нет смысла корчить из себя Ноя», — говорит создатель системы. Не нужно набирать в команду специалистов всех профилей только из-за стремления к многофункциональности. Командная динамика проявляется лишь в малочисленных группах, а если число участников более 9 человек, скорость работы падает. Исследователь Лоуренс Путнэм выяснил, что при одинаковом объеме работы группе менее 9 требуется лишь четверть усилий, которые затратит на эту работу группа от 9 до 20 человек. Поэтому — 7 человек плюс-минус двое.
Отличаются от всех участников команды только два человека. Один — это владелец продукта. Если говорить простыми словами, он отслеживает, чтобы то, что делает команда, действительно имело важность для конечного потребителя. Второй — это скрам-мастер. Он отвечает за коммуникацию внутри команды, организацию собраний и обмен информацией между участниками.
Команда работает короткими отрезками по 1-2 недели (максимум — месяц), называемыми спринтами. Цель каждого спринта — сделать работу, которую можно продемонстрировать клиенту, заказчику или руководителю. Важно, что в каждой итерации (спринте) должна быть сделана полностью функционирующая часть работы — одна функция программы, кусок крыла самолета, деталь обшивки ракеты и т. д. Что-то должно быть представлено, и это будет не черновик, а полностью работающая версия, которую уже можно протестировать. Следующий спринт — следующая часть работы из бэклога.
Бэклог — это список всех требований к продукту, расставленных в порядке приоритетности. По мере того, как продвигается работа над проектом, в бэклог могут вноситься изменения, за которые отвечает владелец продукта. Так скрам-команда может гибко реагировать и постоянно вносить изменения, сообщаясь не только и не столько с начальным планом, сколько с реальной действительностью. «Планировать — полезно, следовать плану — глупо», - говорит создатель системы. Бэклог должен быть проработан таким образом, чтобы каждый его пункт предполагал сдачу конечной работающей части продукта.
В этом главное отличие Scrum от традиционных методов управления проектами. Тестирование и улучшение продукта происходят на протяжении всех спринтов, в то время как в традиционном подходе есть разные этапы: сначала мы только планируем, потом делаем, потом — только тестируем и вносим исправления. А в конце — только удивляемся, ведь ни первоначальный план, ни установленные сроки, ни результат работы не имеют ничего общего с нашими ожиданиями.
Потратить немного времени на беглое планирование, сообщаться с реальностью и корректироваться на ходу на протяжении всего проекта — вот что предлагает Scrum. Это экономит время: согласно исследованиям, на исправление ошибки в момент, когда вся работа завершена, требуется в 24 раза больше времени, чем на исправление той же ошибки сразу же, как только ее обнаружили.
Важное место в методике имеют несколько видов собраний. Первый из них — это планирование спринта. Команда выбирает самые приоритетные задачи из бэклога и обсуждает, сколько задач она способна выполнить в ближайшем спринте. Ключевое правило: добавлять новые задачи по ходу спринта уже нельзя. Сначала выполни обязательство перед заказчиком (руководством) и покажи сделанную часть работы, а потом планируй новые задачи на следующий спринт.
Второй тип собраний — ежедневные собрания на ходу. Это короткое обсуждение, которое проводят стоя, не более 15 минут в начале дня. Каждый из участников отвечает на 3 вопроса: 1) Что ты делал вчера, чтобы помочь команде завершить спринт? 2) Что ты будешь делать сегодня, чтобы помочь команде завершить спринт? 3) Какие препятствия встают на пути у команды? Смысл этого короткого собрания в том, чтобы вся команда была в курсе, какое задание из бэклога на каком этапе работы находится сейчас и какие преграды нужно устранить, чтобы не было потерь времени.
Третий вид собраний — обзор спринта, на котором команда демонстрирует, что она сделала за этот временной отрезок. Здесь, помимо команды, могут присутствовать любые заинтересованные лица: руководители, сотрудники других команд, потенциальные покупатели и т. д.
Четвертый вид собраний — ретроспективные. Это рассмотрение только что завершенного спринта в конструктивном ключе. Важно создать атмосферу доверия, чтобы собрание не превратилось в поиск ответственных за недочеты. Что можно улучшить? Что учесть? Что исправить? Как команде сделать так, чтобы следующий спринт был еще эффективнее?
Еще одно отличие Scrum от традиционного подхода в том, что здесь задачи не оцениваются в часах. Доказано, что люди не в состоянии дать реальную оценку времени, которое потребуется на задачу. В Scrum используется оценка «средний», «малый», «большой» или оценка в баллах. Это позволяет отойти от абсолютных шкал и сравнивать задачи между собой. Когда несколько первых спринтов уже будут пройдены, у команды появится опыт, чтобы прогнозировать сроки готовности продукта.
Рассказывать о Scrum — все равно, что объяснять анекдот. В потоке слов и подробностей появляется удивительная громоздкость, тогда как в самой работе скрам-команды всё настолько просто и ясно, что никаких подробностей и не требуется. Первый рассказ о работе скрам-команды поможет вам это понять.
История №1. Как создать уникальный автомобиль за 3 месяца
Скрам-команда WIKISPEED создает автомобили, в основе которых лежит концепция модульного дизайна. Это легкие, экономные и достаточно быстрые машины. Они развивают скорость до 230 км/ч и расходуют всего около 3 литров топлива на 100 км. Вы можете прямо сейчас заказать себе такой через сайт компании.
Главная деталь мастерской WIKISPEED — большая доска во всю стену, на которой наклеено множество разноцветных стикеров. Это скрам-доска. Каждый стикер — это одна задача, которую предстоит выполнить. Все вместе стикеры — это бэклог проекта. Вся доска разделена на несколько колонок. В левой части — бэклог на текущий спринт. Правее — колонка «В работе», еще правее — колонка «Сделано». Задачи перемещаются из одной колонки в другую. Ни одна задача не окажется в колонке «Сделано», пока результат работы не будет представлен конечному клиенту.
Команда проводит собрание перед каждым спринтом, чтобы определить, сколько стикеров перекочует в колонку текущего спринта. Каждый день они решают, какие препятствия им нужно устранить, чтобы ускориться. В конце каждого спринта клиент получает готовую часть на тестирование, а после этого в продукт сразу вносятся изменения, необходимость которых в традиционном подходе обнаружились бы только после того, как сделан весь продукт.
Именно Scrum привел WIKISPEED к успеху. У компании больше сходства с Google, чем с General Electric или Chrysler.Тогда как в традиционной автомобильной индустрии на разработку новой модели автомобиля требуются годы, WIKISPEED, пользуясь преимуществами гибкой разработки, выполняет эту задачу за 3 месяца. Пока заводы GE тратят человеко-часы, включенные в стоимость автомобиля, на исправление недочетов в уже готовом продукте, WIKISPEED показывает своему покупателю автомобиль «по частям» и снижает его стоимость до уровня Camry в стандартной комплектации. К тому же автомобили WIKISPEED в прямом смысле слова каждый день становятся лучше.
Вот важные моменты, о которых повествует работа WIKISPEED:
Полная прозрачность
Каждый участник команды в курсе, чем в настоящий момент заняты остальные — число участников небольшое, а скрам-доска наглядно демонстрирует состояние работы. Это одна из принципиальных вещей для Scrum. Все делятся информацией друг с другом и получают своевременные сведения о ходе работы. Никто не делает работу зря только потому, что произошла коммуникативная потеря.
Командный дух и приверженность общей цели важны
У ребят по-настоящему вдохновляющая цель. Создавать автомобили, способные разогнаться до 230 км/ч и при этом расходующие около 3 литров топлива на 100 км, — вот что вдохновляет команду работать быстрее и эффективнее. С каждым спринтом WIKISPEED работает всё быстрее и быстрее.
Команда нужна, чтобы создавать ценность
В своей работе скрам-команда WIKISPEED мыслит не общими понятиями «целевая аудитория» или «конечный потребитель». Создавая автомобиль для каждого нового клиента, они общаются с ним напрямую, знают, чем он интересуется и какие специфические особенности важны именно для него. Таким образом, WIKISPEED не тратит время на то, что будет неважно для покупателя. Сначала создаем ценность и только потом увлекаемся побочными функциями (если они потребуются).
История № 2. Как превратить в успех эпический провал. Опыт ФБР
Наверняка вы знаете, что такое CRM. Система, в которой хранятся сведения о клиентах компании, облегчает работу и повышает эффективность продаж. А теперь представьте такую же систему, только для расследований.
Подобная всеобъемлющая система давно была нужна ФБР. Бюро работало словно в каменном веке. Ни о каких информационных технологиях и речи быть не могло: ФБР просто не умело обращаться с информацией. Чтобы выполнить примитивное действие вроде составления досье, сотруднику ФБР нужно было напечатать на ЭВМ тридцатилетней давности подробную записку, распечатать ее в трех экземплярах, одну отправить на утверждение, вторую — в архив на случай потери первой, а третью проиндексировать вручную, выделив красной ручкой ключевые слова — ведь нужно внести сведения в базу данных. Если первую записку согласовывали, на ней ставили номер. Вот и все управление расследованиями. На дворе, кстати, шел 2006 год.
В марте 2006 года ФБР приступило к разработке единой системы «Страж», которая была бы способна вывести бюро из доаналоговой эпохи в цифровую. Пользователями системы должны были стать все, кто имеет отношение к ФБР, а это более тридцати тысяч агентов, сотрудников и административных работников. Задача «Стража» — делать буквально всё. Через систему должна была проходить вся информация обо всех расследованиях, включая выплаты осведомителям, сведения об агентах, о преступлениях, террористических организациях и т. д. Разработка системы должна была закончиться к августу 2009 года. Бюджет, отведенный на проект, составил 451 млн долларов.
В марте 2010 года, когда уже было потрачено более 400 млн долларов, пришло время признать, что сделана лишь малая часть работы, и разработчик не в состоянии закончить работу раньше, чем через 6-8 лет. Правда, придется добавить еще хотя бы 350 млн долларов.
В этот момент в историю вступает Джефф Джонсон. Первое, что он сделал, изучив положение дел, — отказался от идеи найма стороннего разработчика. Джонсон заявил, что система будет завершена к осени 2011 года на остатки от первоначального бюджета.
Джонсон собрал команду для работы над проектом, выбрал самый ценный функционал, который нужно сделать в первую очередь, и пообещал скептически настроенному руководству демонстрировать законченный результат каждые 2 недели. На обзорах спринтов собиралась многочисленная публика, включая директора ФБР, генерального инспектора и начальников калибром поменьше. Демонстрация того, что «Страж» действительно делается, причем некоторые его функции можно опробовать уже сейчас, производили сильнейшее действие. В конечном счете систему внедрили в июле 2012 года. Скрам-команда за 20 месяцев и 5% бюджета сделала то, что сторонние разработчики с двух попыток не могли сделать в течение десяти лет.
Разработка «Стража» ФБР демонстрирует следующие сильные стороны Scrum:
Подробный план не нужен
На планирование и прописывание всех условий контракта уходило время, а когда реальность подкидывала необходимость вносить изменения в план, их приходилось документировать и согласовывать. Отказавшись от этого, команда Джонсона сэкономила массу времени. Всю имевшуюся документацию пришлось выкинуть, так как в ней не нашлось и крупицы смысла.
Маленькая группа эффективнее большой
Джонсон справился с проектом силами малочисленной команды, тогда как сторонние разработчики вовлекали в проблемный проект все больше людей, а результата это приносило всё меньше. Зато бюджет таял на глазах.
Демонстрация даже маленькой завершенной части проекта имеет сильное влияние
На команду Джонсона давили сроки, а скепсис руководства зашкаливал. Но как только скрам-команда стала показывать первые работоспособные части программы «Страж», положение вещей круто поменялось.
История № 3. Как оставаться актуальным, даже если DVD уже в прошлом
Видеостриминговый сервис, который сейчас насчитывает более 69 млн клиентов по всему миру, начинал свою историю в 1997 году, когда Netflix была лишь одной из компаний, занимавшихся отправкой прокатных DVD по почте. Сегодня сайт онлайн-кинотеатра собирает 35% всего интернет-трафика в США и работает в 130 странах мира.
Но это не просто онлайн-кинотеатр. Компания переворачивает всю развлекательную индустрию, кино и телевидение. В арсенале Netflix такие возможности, как анализ кадров, последовательностей фильмов или серий, после которых большинство зрителей досматривают весь сезон сериала. Даже данные о том, как именно пользователь пользуется перемоткой и ставит на паузу, сервис использует, чтобы завоевать мир.
Netflix — чемпион по быстрой адаптации. Шутка ли — не разориться после окончания эпохи DVD?! Секрет, который помогает компании изменяться и подстраиваться под самые острые потребности пользователей, — итерации, итерации, итерации. Netflix начала использовать Scrum в 2006 году, чтобы гибко улучшать свой сайт, не останавливаясь на железной конечной версии. Пока многие веб-корпорации годами корпели над новыми сайтами, чтобы в один прекрасный день представить свежий релиз публике, которая уже успела поменяться, Netflix обновляла собственный сайт каждые 2 недели. Анализируя поведение пользователей и вовремя внося изменения, Netflix все больше расширяла свой список клиентов и предоставляла самый актуальный сервис.
Принципы гибкой разработки и сегодня лежат в основе работы Netflix. Благодаря этому компания имеет следующие возможности:
Отсортировать работающие идеи
Из 10 отличных идей работать будет только одна. Узнать, какая именно, часами совещаясь в конференц-зале, невозможно. Scrum помогает Netflix быстро и уверенно откидывать то, что не приносит пользы. У вас есть 2 недели, чтобы сделать работающую версию идеи и продемонстрировать ее пользователям. Если идея не работает, у вас есть еще 9 идей и по 2 недели на каждую из них. Именно так создают инновации.
Преодолеть сопротивление изменениям
Если вы долго пользуетесь одной версией программы или сервиса, и внезапно выходит новая его версия, вам она не понравится, как и большинству пользователей. Так проявляется сопротивление изменениям, и принципы Scrum помогают его преодолеть. Когда процесс тестирования запущен постоянно, каждое новое изменение происходит все более гладко. Если вы имеете почти 70 млн пользователей по всему миру, вы не можете вносить изменения в продукт топором.
Проектировать для настоящего, а не для будущего или прошлого
Большие и сложные проекты требуют времени. Если вы планируете потратить 3-4 месяца на разработку новой функции, вас ждут плохие новости. Вы рискуете устареть еще до того, как закончите презентацию проекта, ведь в своей работе вы исходите из предположения, что проект будет востребован пользователями в будущем. На практике это означает, что через 3-4 месяца вы попытаетесь скормить им идею, которая перестала быть свежей 3-4 месяца назад. В таком молниеносно меняющемся сегменте, в котором работает Netflix, это означало бы путь к краху. Scrum предполагает, что вы не делаете далеко идущих предположений о том, что будет нужно вашему клиенту. Когда вы, наконец-то (скорее позже, чем раньше), закончите новую версию продукта, мир уже будет другим. Дайте пользователю новую работающую опцию максимум через 2 недели, и вы узнаете, была ли она вообще ему нужна.
Scrum переворачивает представление людей о том, как нужно работать на самом деле. Подход помогает выполнять проекты вовремя и достигать поставленных целей, даже если в ходе проекта требования к результату изменились не один раз. Но как внедрить этот метод в своем бизнесе? Как научиться по нему работать, чтобы стать желанным сотрудником для любой agile-компании? Возьмите в учителя лучших agile-коучей и освойте гибкие методологии в управлении проектами за 18 дней на онлайн-курсе «Методологии Agile в управлении проектами». Начните учиться бесплатно прямо сейчас.
Хотите получать статьи по теме Менеджмент?
Спасибо за подписку!
Ожидайте писем от City Business School