Agile дает реальные и действенные ответы на вопрос, который не дает спокойно спать руководителям: «Как оставаться успешным в быстро меняющемся и непредсказуемом мире?» Эта методология уже завоевала рынок, доказав, что является одним из лучших подходов для создания и доставки программного обеспечения. «Agile для всех» адресован практикам, из этой книги вы узнаете, как целые организации — от менеджеров по продукту и разработчиков до маркетологов и руководителей — могут использовать «гибкий» подход.Мэтт Лемей просто и без сленга объясняет, что такое Agile, и предлагает конкретные и действенные шаги, позволяющие любой команде реализовать свои задачи максимально эффективно. Вы найдете множество примеров, которые подойдут для любого типа и размера организации — от стартапов до крупных предприятий, — позволяющих реализовать Agile-подход в разных сферах деятельности.
Погружение в Agile-практики: «whoopee!»
Когда я работал менеджером продукта, у меня под рукой было множество готовых Agile-практик и фреймворков, которые я мог использовать в своей команде. Эти фреймворки относились исключительно к потребностям команд, занимающихся разработкой ПО, и были проверены на практике тысячами специалистов, многие из которых любезно поделились опытом в виде доступной литературы и постов в блогах.
Однако когда я стал работать консультантом, то не сразу смог понять, каким образом следует использовать эти методы относительно совершенно других целей новых команд. Результаты нашей работы — аналитические отчеты, полученные после месяцев долгих консультаций, семинары по формированию образа клиента — значительно отличались от программных продуктов, поскольку у нас больше не было ясного и объективного способа проверки работоспособности этих результатов. Более того, в наших ролях стерлись все границы по сравнению с ролями в команде разработчиков, поскольку теперь мы все делали общее дело, не прячась под титулами «визуальный проектировщик» или «фронтенд-разработчик».
Оказавшись в этой процедурной неразберихе, мы пытались справиться со стандартным набором проблем, которые возникают перед командами, дающими нетехнические результаты. Предмет этих результатов незаметно и неизбежно расширяется по мере работы, особенно когда мы переходили из промежуточных состояний (эскизов) к полноценным документам и презентациям. Клиентоориентированное предназначение каждого результата иногда оставалось для нас неясным, поэтому в таких случаях мы расширяли предмет исследования, чтобы ничего не «упустить». Несмотря на то что нам нравилось работать вместе, мы не всегда понимали, кто, за что, когда и почему отвечает.
Стоит отметить, что «уставные» Agile-методы не всегда идеально вписывались в структуру нашей команды или результаты, однако мы понимали, что основополагающие Agile-принципы способны удерживать нас в нужном направлении. Поэтому мы начали задавать себе вопросы, которые сформировали основу этой книги: насколько ясно мы понимаем потребности нашего клиента? Сможем ли мы устранить все рабочие недопонимания благодаря своевременному сотрудничеству? Следим ли мы за тем, чтобы внедрение новой информации в рабочий процесс не превращалось в полную переработку материала?
Мы начали задаваться этими вопросами регулярно на совещаниях по планированию и ретроспективах, меняя рабочий процесс в соответствии с нашими представлениями и ответами. Поэкспериментировав около года, мы превратили наш подход в практику WHPI (читать как «вууупии!», или «Почему, Как, Прототип, Итерация»). WHPI состоит из четырех шагов, которые приведены в табл. 6.3. Для начала вы коллегиально решаете, почему вы ставите результат на первое место, на какое воздействие рассчитываете и какую ценность получит ваш клиент. Затем решаете, как будете обеспечивать эту ценность, как будет выглядеть конечный результат. Наконец, вы поручаете одному из участников команды за ограниченное количество времени создать прототип, отражающий опыт, который вы хотите создать для клиента, после чего итерируетеэтот прототип и проверяете, смог ли он достичь целей, которые вы установили на первом шаге.
Мы обнаружили, что WHPI является мощным Agile-инструментом, который можно внедрить в любую команду вне зависимости от их задач и целей. Ниже представлено краткое описание каждого шага WHPI, а также приведены несколько советов по внедрению и использованию этих методов в рамках вашей команды.
ШАГ 1: Почему
Для этого шага мы собираем несколько ключевых участников проекта (2–4) и быстро обсуждаем набор целей или результатов по проекту. По возможности собираемся в едином физическом (или виртуальном) пространстве и прорабатываем все идеи, записанные на стикеры во время рабочего процесса. Обычно эти совещания длятся от 15 до 30 минут. Несмотря на то что подобные временные рамки могут показаться жесткими и неудобными для таких важных совещаний, они отображают одну существенную истину: если вы не способны определить основные цели за 15–30 минут, вам нужно добыть больше информации, прежде чем двигаться вперед. Несколько раз на этом этапе мы понимали, что необходимо провести базовые исследования для подтверждения наших предположений или задать нашим клиентам несколько проясняющих вопросов. Создав единый первоначальный набор «почему»-целей, мы помещали их в самый центр внимания, чтобы они направляли остальной рабочий процесс.
Например, когда мы разрабатываем аналитический отчет после какого-либо совещания, то часто пишем три основных «почему» на стикерах:
- Донести понимание движущей силы проекта высшему руководству.
- Напомнить участникам о ключевых моментах озарения на совещании.
- Пробудить интерес у сотрудников, которые не пришли на совещание.
Обратите внимание, что ни один из этих пунктов не указывает напрямую на то, каким образом мы собираемся достичь целей, — об этом далее!
ШАГ 2: Как
Установив цели проекта, мы переходим к сложной задаче определения способов их достижения. Мы зачастую называем этот шаг «определение инструментов» — то есть когда мы знаем, чем будем заниматься, нам необходимо подумать над инструментами и подходами. Я рекомендую переходить от «почему» к «как» с одними и теми же участниками совещания. Зачастую, определив «как», вы понимаете, почему как минимум одна основная цель команды из «почему» на самом деле является шагом «как» на исполнительном уровне.
В предыдущем разделе мы установили следующие «почему»: «Пробудить интерес у сотрудниках, которые не пришли на совещание». Прежде чем использовать этот метод, мы определяем аналогичную цель следующим образом: «Объяснить участникам язык и фреймворки, чтобы они могли делиться информацией со своими коллегами». Но после того как мы начали разделять «почему» от «как», мы поняли, что упустили два ключевых вопроса: почему людям важно делиться этими задачами с коллегами и как можно упростить процесс достижения целей? Разве язык и фреймворки — это то, в чем действительно нуждаются люди? Как мы успели обсудить в этой книге, первоочередное внимание к клиентам и их потребностям зачастую помогает сократить объем работы, на который мы рассчитывали, или понять, что необходимый результат значительно отличается от того, что мы планировали достичь.
Учитывая «почему» из последнего раздела, мы можем выделить следующие «как» для направления рабочего процесс:
- Создайте короткий двухстраничный аналитический отчет, который можно будет легко понять и распространить.
- Используйте запоминающиеся цитаты участников, чтобы донести понимание движущей силы высшему руководству.
- Используйте фотографии с совещаний, чтобы напомнить участникам про моменты озарения.
- Продвигайте положительные исходы и ограничивайте количество подробностей, чтобы сохранять направленность результата и вызывать широкий интерес.
Как вы видите, «как» обеспечивает схему действий или план по созданию всех необходимых условий для достижения намеченных целей. Этот шаг определяет форму нашего результата, напрямую обращается к нашим «почему» и обеспечивает ясные и подвижные границы для предотвращения потери контроля над нужными результатами. Подобный ясный план позволяет гораздо быстрее делегировать задачи по достижению результата, вне зависимости от подхода, который вы используете в следующих шагах.
ШАГ 3: Прототип
Определив «почему» и «как», мы готовы создавать ограниченный по времени прототип. Слово «прототип» может означать множество вещей в различных контекстах. В контексте данного метода мы определяем прототип следующим образом:
- Прототип — это не модель и не документ планирования; он создается в таком же формате, как нужный результат или исход. К примеру, «прототип» презентации со слайдами — это презентация со слайдами. «Прототип» печатной брошюры — это печатная брошюра.
- Прототип создается в ограниченный и установленный заранее период времени. (Создается в рамках тайм-боксинга.)
Иными словами, мы «создаем условия для достижения максимального количества целей проекта («почему»), используя одобренные подходы и инструменты («как»), в таком же формате и с такими же временными рамками, как нужный результат. В случае небольших проектов, таких как плакаты, первоначальный прототип может выглядеть как готовый результат. В случае крупных проектов, таких как сорокастраничный отчет, первоначальный прототип может представлять собой 20 полноценных страниц, сложенных пополам, скрепленных вместе и заполненных от руки (с пронумерованными страницами, заголовками, краткими итогами и местами под изображения).
Как мы обсуждали в главе 3, наша цель здесь — как можно ближе подобраться к опыту клиента за счет создания собственной версии «рабочего ПО». Вещи, которые отлично смотрятся в моделях и документах планирования, не срабатывают в презентациях, отчетах и на совещаниях. Проверка первоначальных результатов при помощи метода прототипа помогала нам проникнуться опытом клиента, снизить количество доработок и более подробно анализировать первичные предположения.
Как правило, мы назначаем одного участника команды ответственным за создание первичного прототипа. Зачастую это становится вопросом свободного времени: кто может выделить несколько часов на протяжении следующих дней, чтобы сделать первую попытку? Мы обнаружили, что два часа работы — это стандартное ограничение для создания прототипа, которое позволяет создать основу для сравнения с целями проекта и оставляет пространство для развития и итераций.
ШАГ 4: Итерация
После создания первого ограниченного по времени прототипа изначальная команда участников (или часть команды) собирается для анализа прототипа и обсуждения следующей итерации. Наши первые обсуждения проходили в формате плюсы/предложения, в котором каждый член команды рассказывает про удачные аспекты и про элементы, нуждающиеся в улучшении. (Точно такой же формат мы использовали в наших ретроспективах, поэтому быстро к нему вернулись.) Мы постепенно переделали этот формат в так называемое обсуждение «защищай, исключай, улучшай». После представления прототипа участники делятся тремя видами отзывов:
- То, что следует оставить для следующих итераций, поскольку оно максимально соответствует всем «почему».
- То, что можно исключить из следующих итераций, поскольку оно не соответствует всем «почему».
- То, что следует улучшить для следующих итераций, поскольку оно еще может способствовать достижению нужных «почему».
Ключевое различие между этим подходом и традиционным форматом плюсов/предложений является в открытом обсуждении того, что необходимо исключить из следующих итераций. Мы начали использовать этот подход после того, как обнаружили, что самые успешные изменения для итераций происходят после исключения, а не добавления, причем даже в самых крупных проектах. Открытое «исключение» во время обсуждений позволяет участникам отслеживать аспекты, которые можно убрать, что обеспечивает более точные и сфокусированные результаты. Подводя все три типа отзывов под соответствие заранее оговоренным «почему», мы решаем все потенциальные конфликты, избегаем неловких моментов и удерживаем проект в нужном направлении.
После сбора отзывов один из членов команды трансформирует эти отзывы в очередную ограниченную по времени итерацию прототипа. В некоторых случаях это приводит к полной переработке последнего прототипа (к примеру, пересмотр презентации). В иных случаях это приводит к созданию нового прототипа на основе старых прототипов (к примеру, отчет по результатам в Word на основе рукописных прототипов). Эти последовательные раунды итерации могут управляться одним человеком, который создал первоначальный прототип, или любым другим членом команды. Ко второй или третьей итерации прототип зачастую оказывается в руках того человека, кто несет главную ответственность за представление доработанного продукта. Более того, ко второй или третьей итерации прототип выглядит практически завершенным и готовым к финальной доработке.
» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок
Для Хаброжителей скидка 25% по купону — Agile
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
