Принципы — это те рельсы, которые направляют людей по жизненному пути. Международный Институт Бизнес-Анализа (IIBA) определил 7 главных принципов, которые указывают бизнес-аналитикам как работать приносить больше пользы команде и клиенту, делая меньше работы с большим коэффициентом полезности. Статья будет полезна как начинающим бизнес-аналитикам, так и тем коллегам, кто хочет глубже погрузиться в Agile или подготовиться к сдаче экзамена AAC.

Статья написана с точки зрения бизнес-аналитика, однако описывает те принципы Agile, которыми следует руководствоваться всем участникам Agile-команд для улучшения своей работы.

Статья является переработкой тех параграфов "Agile Extension to BABOK Guide", которые говорят про принцы Agile бизнес-анализа, и содержит небольшие дополнения и пояснения.

See The Whole

Первый принцип — видеть картину целиком — направляет бизнес-аналитиков к тому, чтобы создавать в команде коллективное видение ценности, которое решение принесёт бизнесу. Использование этого принципа поможет бизнес-аналитику ответить на вопрос "почему": "Зачем клиенту нужен этот продукт?", "Почему делаем такую систему?"

Используя этот принцип, БА помогает клиентам принимать решения, какие опции выбрать. Если принцип используется правильно, то между участниками команды (как со стороны разработчика, так и со стороны клиента) возникает цельное понимание целей, которые ставит организация или проект.

Что такое Big Picture и как её создавать

Говоря о Whole важно пояснить, что это за зверь. Whole — или Big Picture — это контекст в котором происходит изменение (создается продукт, проект). Контекст создается не одним бизнес-аналитиком. Тут важно участие лидеров инициативы: проектного менеджера, Product Owner, Product Manager. 5 причин, ради которых БА создаёт общее понимание контекста:

  • чтобы команда знала куда и зачем идет проект;

  • чтобы было легче валидировать с заказчиком само решение и подходы к нему; 

  • чтобы было легче управлять созданием решения и запросами на изменения, быстро и точно трассировать изменения в требованиях и видеть как изменения влияют на цель инициативы.

Раздробленное видение негативно влияет на команду. Отсутствие контекста говорит о том, что разработчикам все равно, какие у клиента потребности; в команде нет налаженных процессов коммуникации, а сама команда не понимает, зачем и куда идёт проект.

Think As a Customer

"Думай как пользователь" поможет аналитику и команде услышать голос тех, кто использует продукт. Аналитик начинают с высокоуровневого понимания того, кто пользователь решения. Понимание усиливается по мере взросления инициативы, обрастая деталями того, какие нужды пользователей или бизнеса удовлетворяет команда создавая проект.

Пользователем — это не только человек. Опытные коллеги вспоминают проекты, где пользователем выступали коровы. В таком случае бизнес-аналитик обязан услышать в му запрос на требования, которые команда обязана выполнить. Главное в выполнении этого принципа — это ценность. Концентрация на ней укажет организации, какие ставить цели, какие функции разрабатывать.

В Agile-планировании этот принцип поможет аналитику, организации и команде не сделать ерунду. Наверняка читатель помнит о Waterfall и о том, что там планирование занимает месяцы и годы и не учитывает меняющиеся потребности пользователей.

Принцип "Think as a customer" включает в себя изучение реакции пользователей на решение. В книге "Lean Startup" Эрик Рис писал о ускорении feedback loops. То есть о том, что важно понимать пользователей и то, как они используют продукт, быстро. IIBA пишет, что фокус на пользователе поможет организации принимать верные решения о продолжении или отмены инициативы и распределении ресурсов.

Analyze To Determine What Is Valuable

Чтобы команда приносила ценность клиентам, бизнес-аналитик должен безостановочно проверять беклог и то, какие задачи в лежат наверху. Согласно этого принципа, наибольшим приоритетом обладают те задачи, которые несут наибольшую ценность пользователям и клиенту. Чтобы правильно приотезировать задачи, аналитик должен:

  • понимать смысл требований, которые приходят для анализа;

  • быть уверенным, что решение и компоненты даёт нужные бизнесу;

  • использовать последние данные: верные решения, принимаемые исходя из устаревшей информации, в итоге будут ошибочными.

Agile — это ответ на постоянно меняющиеся запросы. Ценности и нужды пользователей постоянно меняются. Использование этого метода позволит организации понять, что важно по мере расширения контекста, в котором работает организация.

Get Real Using Examples

Этот принцип схож с "генти генбуцу" — принципом из "Дао Тойота", который заставляет продакт-менеджеров "выходить из офиса", чтобы понять запрос пользователей. "Get Real Using Examples" помогает аналитикам в создании общего понимания запросов, которые удовлетворит решение.

`Examples` поступают постоянно из любого взаимодействия с пользователями — жалобы в поддержку, фидбек-тикеты от лидеров инициативы, аналитики или интервью с пользователями. Команда прорабатывает разные решения, которые удовлетворят запрос, создавая совместное понимание того, как решение удовлетворит нужды.

Бизнес-аналитик может использовать полученные примеры использования для создания критериев приёмки, разработки решения (чтобы ответить на вопрос что мы делаем?). Также они могут выступать как основа для создания тест-кейсов командой тестирования.

Understand What Is Doable

Этот принцип поможет бизнес-аналитику понять, какое решение применимо для удовлетворения нужды в контексте, где работает команда. Каждый раз задавая вопрос "Можно ли это сделать?" мы отвечаем и на вопросы "Есть ли смысл делать сейчас?" и "Надо ли вообще это делать?" Контекст включает в себя:

  • ограничения технологий, используемых в проекте;

  • навыки команды;

  • время за которое команда обязана доставить решение пользователям.

Учет контекста помогает переоценке приоритета задачи. Например, если из-за некоторых технических ограничений добавить на сайт кнопку займёт 3 месяца, то приоритетность кнопки упадёт и лидеры продукта предпочтут использовать время команды на задачи проще — так выше вероятность доставить больше ценности клиенту. Используя этот принцип, бизнес-аналитик выступает как советчик, который помогает лидерам принимать решения, основанные на качественной информации, оценивая качество и релевантность входящей информации.

Stimulate Collaboration and Continous Improvement

Этот принцип побуждает аналитика строить в команде среду постоянного обмена знаниями, мыслями. Такая среда помогает добиться общего понимания ценности, которую команда несет клиенту и создания постоянного улучшения, которое невозможно, если без постоянного общения, так как информация будет оседать среди части команды. Постоянное общение поможет команде:

  • быть открытыми к изменениям (если между людьми много общения, то они и общаться начинают открыто, доверяя друг другу);

  • безостановочно искать способы улучшения процессов, построенных в команде.

Для организации важно создавать среду, которая позволит сотрудникам разных отделов обмениваться мнениями и информацией о целях, миссии, проектах. Так же как и друг с другом, сотрудники компании должны открыто общаться с клиентами. Открытое общение ускорит появление фидбека и ускорит обучение — организация будет в силах создать продукт, который несет больше ценности.

Avoid Waste

Хоть и кажется, что этот принцип о мусоре, на самом деле он о лишней работе и помогает аналитикам делать меньше, создавая больше ценности. "Avoid Waste" постулирует: "More outcome with less output".

Waste может появиться двумя путями:

  1. при помощи работы, которая создаёт ценность косвенно;

  2. при помощи работы, которая вообще не создаёт ценности.

Используя этот принцип, аналитик сводит к минимум первый способ создания waste и избавиться от второго. Чтобы избежать лишней работы, бизнес-аналитик должен:

  • использовать простые методы донесения требований (например: диаграммы вместо текстов);

  • не создавать слишком рано требования и тикеты в Jira (это грозит переполенным беклогом, который команда не выполнит);

  • создавать детализированные требования как можно ближе к моменту, когда разработчик сможет взять их в работу, чтобы избежать переделок и изменений;

  • использовать только свежие данные для коммуникации возможных решений (решения, принятые на плохих данных — это waste).

Заключение

Хотя принципы Agile бизнес-анализа и кажутся несложными, но в действительности ими тяжело пользоваться в практике. Коллеги, помните, что Agile из тех навыков, которые easy to learn, difficult to master и пользуйтесь мудростью IIBA, чтобы создавать больше ценности за меньшее количество действий.

Комментарии (12)


  1. sshikov
    20.11.2021 10:53

    Принципы-то вроде нормальные, но при чем тут Agile? Точно таким же принципам можно следовать, работая по более «жестким» процессам. Разница наверное будет, но на первый взгляд — несущественная.

    >создавать больше ценности за меньшее количество действий.
    Ну это вообще очевидно. И обозначает просто, что нужно работать эффективно.


    1. tortique Автор
      20.11.2021 11:03
      +2

      Мне видится, что Agile — это не столько про формальность или неформальность процессов, сколько про открытость к изменениям и обучение из фидбека. Эти принципы об как раз об этом: учись из опыта, слушай пользователей, работай без излишков и строй открытую коммуникацию с коллегами.


      1. sshikov
        20.11.2021 11:16
        +1

        Ну, в общем да, в широком смысле. Но если вы работаете не по Agile (а бывают такие проекты, где это прямо противопоказано) — вы разве не слушаете пользователей, или не учитесь из опыта? То есть, слушать и учиться и строить коммуникацию — это просто нормальная практика для любого профессионала, который старается стать чуть лучше. Если у кого-то в проекте не Adgile — это тоже применимо.


        1. tortique Автор
          20.11.2021 11:21
          +1

          Вы правы, учиться из фидбека итд следует работая по любым методологиям и философиям, иначе не выйдет эффективности или хорошего продукта.


        1. burzooom
          20.11.2021 12:50

          К примеру, вы разрабатываете мобильную версию сайта. Модель waterfall.

          Все опросы пользователей приводят к необходимости вносить изменения и в самом сайте тоже. А заказчик не просил изменять сайт, там все работает хорошо. Просто срочно нужна мобильная версия.


          1. sshikov
            20.11.2021 13:12

            >К примеру, вы разрабатываете мобильную версию сайта. Модель waterfall.
            Я для начала вижу тут другую проблему. Зачем разрабатывать продукт, который, на первый взгляд, требует гибкости, по модели, которая такую гибкость не предполагает?

            И потом, а в чем вы видите противоречие? Вы проводите опросы, и слушаете пользователей (заказчик кстати тоже ваш пользователь, скорее всего), а еще учитесь на своем опыте. И в общем-то waterfall этому не помеха.

            А уж что делать раньше — менять сайт, или делать мобильную версию, это вопрос не сильно зависящий от выбранной модели разработки. Он в любой модели может стоять. У вас всегда может быть (и бывает) больше хотелок, чем вы можете сделать за отведенное время. Они всегда конфликтуют между собой за ресурсы.


    1. beskov
      20.11.2021 11:51
      +2

      притом, что IIBA паразитирует на трендах, пытается доказать, что они не устарели


  1. beskov
    20.11.2021 11:50
    +3

    начинайте сначала, а как дойдёте до конца — заканчивайте


  1. Stasia_AgileCoach
    21.11.2021 17:49

    Позитивная статья, вот только этим занимается не бизнес-аналитик в Agile-команде, а всё таки Владелец продукта, у него должны быть эти компетенции


    1. SamXYZ
      21.11.2021 21:16

      Все ответы верны, автор дал вводные: простые истины для начинающих... в целом для начинающих. Чем глубже погружаюсь в тему менеджмента, тем больше школ и подходов изучаю и тем больше люблю сухую математику с аналитикой.
      "фактам плевать на ваши чувства"


  1. meirinkun
    22.11.2021 10:59
    +1

    Интересно, чем в момент применения этих принципов бизнес-аналитиком занимаются лидеры инициативы: проектный менеджер, Product Owner, Product Manager? И еще интересно сколько они при этом зарабатывают и сколько "полезности" приносят в рамках инициативы.

    1. See The Whole - Product Owner, как, в общем и написано в описании принципа - должны принимать активное участие лидеры инициативы.

    2. Think As a Customer - так должна думать вся команда, при планировании.

    3. Analyze To Determine What Is Valuable - аналогично, проверять беклог должна вся команда при планировании. Понимать смысл требований - тут вообще без комментариев.

    4. Get Real Using Examples - это должен делать Product Owner.

    5. Understand What Is Doable - это делаяет вся команда и это очень похоже на принцип Analyze To Determine What Is Valuable.

    6. Stimulate Collaboration and Continous Improvement - опять же это либо PO, либо некий "скрам-мастер-фасилитатор и тп.". Я себе плохо представляю как БА приходит в аджайл-команду (саморганизованную, готовую к изменениям, работе с заказчиком и пр.) и начинает всех стимулировать к работе и взаимодействию. Этим точно бизнес-аналитик должен заниматься?

    7. Avoid Waste - это всех касается.

    К автору статьи претензий нет. А вот к пониманию IIBA необходимости бизнес-аналитика в agile-команде есть вопросы.


  1. Leonid1511
    22.11.2021 20:10
    +1

    Очень свежая информация :)
    © BABOK Agile extension Version 1.0 published in 2013.

    © BABOK Agile extension Version 2.0 published in 2017.