[БЕЗ_ЗВУКА] Бизнес-анализ agile-проектов. Теперь, когда у нас есть команда с правильно сформированным отношением к гибкой работе, мы можем взяться за детали и начать описывать в различных форматах, что же требуется сделать. Почему в различных форматах? Разве недостаточно получить так называемое техническое задание"и начать по нему работать? В проектном менеджменте есть одно правило — garbage in, garbage out — что переводится как «мусор на входе приводит к мусору на выходе». Имеется в виду, что невозможно получить качественный продукт, если на стадии его описания неправильно или не в полном объеме сформулировать к нему требования. Давайте рассмотрим классическую иллюстрацию: что хочет заказчик и что получает. Вот как заказчик объяснил свои потребности. Вот как их понял руководитель проекта. Вот как на основании описанных требований их спроектировал дизайнер. Так их реализовал программист. При этом бизнес-консультант описал их вот так. Классика жанра — как был задокументирован проект. В итоге, вот что было сделано. А вот, за что клиент платил. Так обычно характеризуют уровень поддержки. А реально заказчику нужно было вот это. Почему же так получается? Не всегда, но довольно часто техническое задание представляет собой многостраничный документ, где очень много общих фраз и мало конкретики. Мне не раз доводилось встречать ТЗ из более, чем ста страниц, и при этом реально работать, как исполнителю, надо было лишь с несколькими из них. Многие просто теряются в таком объеме документации. Не случайно, как описывал Джефф Сазерленд в своей книге «Scrum: Революционный метод управления проектами», одной из ключевых идей при создании методологии Scrum послужил его опыт работы над крупным государственным проектом, который был уже неоднократно провален по срокам. Сазерленда пригласили в этот проект в качестве консультанта и дали добро на эксперименты с его новой методологией. Изучив всю имеющуюся документацию и проведя переговоря с командой, Джефф прямо на общем собрании начал буквально ножницами разрезать толстый том технического задания на доступные для восприятия исполнителей небольшие карточки. Мы с вами уже знаем, что таким образом он сформировал бэклог. Разрезав таким образом все ТЗ, на карточках дописали недостающие элементы визуализации требований, сфокусировав внимание на ценности для конечного пользователя, чтобы каждому участнику команды было предельно понятно, ради чего выполняется та или иная функция. И угадайте, что? В этот раз проект был сдан вовремя. Конечно, дело тут не только в этом примере с разрезанием технического задания, но и остальные нововведения, использованные на тот момент Сазерлендом, тоже были тесно взаимосвязаны с современными ценностями и принципами Agile. Зачастую заказчик не совсем корректно воспринимает ценность конечного продукта для реального потребителя. Задача Agile-команды — с помощью определенных инструментов бизнес-анализа открыть ему глаза на реальную картину, подать информацию в таком виде, чтобы он мог трезво оценить свои первоначальные планы и внести изменения на основе полученных в результате экспериментов данных. Для правильного восприятия той или иной функции подходят разные форматы визуализации данных. Неспроста говорят, что картинка стоит тысячи слов. Мало того, что схемы воспринимаются совсем иначе, чем текстовые описания. Сами по себе форматы схем могут кардинально изменить ваше восприятие проблемы. Мой совет: не бойтесь перекладывать требования из одного формата в другой и экспериментировать. Когда вы рассматриваете проблему с разных точек зрения и, соответственно, разных форматов описания требований, ваш мозг интерпретирует информацию из разных источников и, тем самым, как бы синтезирует ее, получает общую, целостную картину. Поэтому хорошо будет потренироваться описывать одни и те же исходные данные в абсолютно разных форматах. Итак, перечислим основные цели фиксирования требований: создать всесторонне прозрачные и понятные формы описания задач, визуализировать потребности клиента в lo-fi (то есть низкоуровневых) прототипах, максимизировать эффективность взаимодействия с клиентом и адаптироваться к последующим изменениям требований. В работе с требованиями выделяют следующие ключевые этапы: выявление (или сбор) требований, выражение требований, приоритизация требований, анализ требований и управление требованиями. По типам, которые мы подробнее рассмотрим в последующих уроках, требования подразделяются на бизнес-требования, бизнес-правила, пользовательские требования, функциональные требования, нефункциональные требования, внешние интерфейсы, физические требования и ограничения. Ключевые форматы, которые используются в Agile для формулирования требований, это: сценарии использования или use cases; раскадровки или storyboards; каркасные макеты — это те самые низкоуровневые прототипы, которые также еще называют wireframes; и уже известные нам пользовательские истории, или user stories. Перечисленные форматы мы рассмотрим подробно в следующих уроках. Однако не стоит пренебрегать и любыми другими классическими форматами описания требований, если они придают смысл и упрощают процесс коммуникации. Детально разобрать такие типы схем в рамках данного курса мы не успеем, но вы можете самостоятельно изучить их для расширения своего аналитического арсенала. Вот самые популярные из них: схема отношений, «карта памяти», системная карта, схема влияния, схема функциональных потоков, схема последовательности действий, схема информационных потоков, «содержательная картинка», схема поля сил, схема «входа-выхода», причинно-следственная схема, схема контура управления и уже известная нам диаграмма Ганта, сетевой график и схема анализа критического пути. С наиболее полным списком методов для описания требований, на мой взгляд, можно ознакомиться в книге «Свод знаний по бизнес-анализу» BABOK, а также недавно вышедшему к нему дополнению по Agile. Итак, подведем итог, что полнота и качество анализа требований играют ключевую роль в успехе всего проекта. Поэтому руководителю agile-проекта крайне важно хотя бы в общих чертах иметь представление об основных инструментах бизнес-анализа и уметь оценить качество предоставляемых аналитиками материалов. Вопросы о том, как аналитики работают с выявлением требований, мы разберем в следующих уроках.
