Вход с паролем
Через соцсеть

Вебинар Карла Вигерса «10 ловушек в бизнес-анализе, которых следует избегать»

30.01.2017

Карл Вигерс – величина в мире бизнес-анализа известная и постоянная. Консультант в сфере разработки ПО, тренер, автор многочисленных статей. Его книгу«Разработка требований к ПО», в 2013 году переизданную в третий раз в соавторстве с Джой Битти, называют «Библией бизнес-анализа», и она обязательна для прочтения всем, кто имеет отношение к этой сфере деятельности. Кроме работы, у Карла Вигерса есть несколько занятных хобби. Среди своих увлечений гуру бизнес-анализа называет игру на гитаре и запись песен, оригинальных и каверов, интерес к военной истории и хорошему вину. Кроме того, он успевает заниматься благотворительностью, участвуя сразу в нескольких программах. Поэтому бесплатный вебинар от Карла Вигерса, пусть даже и с дальним прицелом на потенциальных слушателей его платных тренингов, стал приятной неожиданностью.


Карл начал вебинар с традиционного краткого самопредставления. Фото, имя, должность, обложки нескольких написанных им книг, тут же телефон, e-mail, 2 ссылки — на блог и сайт.
Далее Карл без долгих предисловий перешел к теме вебинара, слайд за слайдом разбирая ловушки, которые могут подстерегать каждого бизнес-аналитика в ежедневной работе, и предлагая пути их решения. Давайте пройдемся по ловушкам, выделенным Карлом Вигерсом.


Ловушка 1. Путаница с термином «требования»

Признаки:

  • Заинтересованные лица обсуждают требования, не называя их тип.
  • Спонсор проекта описывает высокоуровневую концепцию продукта, считая ее требованиями.
  • Части пользовательского интерфейса рассматриваются как требования, без указания их типа и предназначения.
  • Пользователи описывают требования, но разработчики по-прежнему не знают, что разрабатывать.
  • Требования описывают только функциональные возможности системы.

Пути решения:

  • Адаптировать шаблоны документации для трех уровней требований:
  1. бизнес-требования (Документ концепции и границ);
  2. пользовательские требования (Документ пользовательских требований);
  3. функциональные требования (Спецификация требований к ПО).
  • Отличать функциональные требования от нефункциональных: атрибуты качества, ограничения, требования к внешним интерфейсам, бизнес-правила.
  • Группировать требования заказчика по типам.
  • Различать идеи решения проблемы заказчика от требований.
Ловушка 2. Нерациональное вовлечение заказчика в процесс разработки

Признаки:

  • Некоторые классы пользователей остаются неохваченными.
  • Некоторые классы пользователей вовсе не представлены (не вовлечены в проект).
  • Один пользователь пытается говорить за всех пользователей.
  • Разработчикам приходится принимать множество решений, связанных с требованиями.
  • Заказчик отказывается от продукта, когда впервые его видит.

Пути решения:

  • Определять различные классы пользователей.
  • Определять сторонников продукта как представителей различных классов пользователей.
  • Определять ответственных за принятие решений по требованиям.
  • Просить пользователей оценить прототипы.
  • Просить пользователей проверить описанные требования.
  • Просить пользователей определить критерии приемки.
Ловушка 3. Неопределенные и неоднозначные требования

Признаки:

  • Требования интерпретируются по-разному.
  • В требованиях не хватает информации для разработчиков.
  • Соответствие решения требованиям невозможно проверить.
  • У разработчиков постоянно появляется множество вопросов.
  • Разработчики вынуждены «гадать на кофейной гуще».

Пути решения:

  • Изучать требования вместе с командой.
  • Писать приемочные тесты для разработанных требований.
  • Моделировать требования, чтобы заполнить информационные пробелы.
  • Использовать прототипы, чтобы представить требования наглядно.
  • Объединять термины в словарь.
  • Избегать неоднозначных слов в требованиях: минимизировать, максимизировать, оптимизировать, быстрый, ориентированный на пользователя, простой, интуитивный, надежный, современный, улучшенный, эффективный, идеальный, гибкий, несколько, и/или, и т.д., включать, поддерживать, отвечающий требованиям.
Ловушка 4. Требования не приоритизируются

Признаки:

  • Реализация всех требований критична.
  • Заинтересованные лица интерпретируют требования по-разному.
  • После приоритизации реализация 95% требований по-прежнему критична.
  • Разработчики не хотят признавать, что не в состоянии выполнить все.
  • Непонятно, реализацию каких требований можно отложить в случае нехватки времени.

Пути решения:

  • Соотносить функциональные требования с высокоприоритетными пользовательскими требованиями.
  • Соотносить функциональные требования с бизнес-требованиями.
  • Четко определять категории приоритетов.
  • Аналитическим путем определять и предлагать приоритеты для независимых требований.
  • Распределять реализацию требований по релизам и итерациям.
  • Динамически менять приоритет разработки тех или иных требований в резерве проекта (backlog).
Ловушка 5. Разработка функциональности, которая никому не нужен

Признаки:

  • Пользователи «не отделяют зёрна от плевел».
  • Пользователи требуют конкретную функциональность, но потом ее не используют.
  • Предложенная функциональность не решает бизнес-задач.
  • Разработчики добавляют функциональность, потому что «пользователям наверняка понравится».

Пути решения:

  • Выделять функциональные требования из пользовательских требований.
  • Отслеживать связь каждого функционального требования до его источника.
  • Определять заинтересованных лиц, которым реализация функциональности принесет пользу.
  • Приоритизировать требования или функциональность:
  1. попросить заказчика определить ценность (выгоду и недостатки реализации);
  2. попросить разработчиков оценить стоимость и риски;
  3. избегать требований с высокой стоимостью и низкой ценностью.
Ловушка 6. Аналитический паралич

Признаки:

  • Разработка требований продолжается бесконечно;
  • Новые версии спецификации требований к ПО выпускаются постоянно;
  • Требованиями не управляют.
  • Требования каждый раз по-разному моделируют.
  • Дизайн и разработка не могут быть начаты, так как разработка требований не завершена.

Пути решения:

  • Помнить: продуктом является ПО, а не требования.
  • Выбирать подходящий цикл разработки ПО.
  • Решать, когда требования достаточно хороши для реализации:
  1. существует приемлемый риск при продолжении разработки;
  2. требования рассмотрены бизнес-аналитиком, заказчиками, разработчиками, тестировщиками.
  • Моделировать только сложные или сомнительные части системы.
  • Не включать финальный дизайн пользовательских интерфейсов в спецификацию требований к ПО.
Ловушка 7. Неконтролируемое разрастание границ проекта

Признаки:

  • Новые требования постоянно добавляются:
  1. при этом времени на разработку не добавляется;
  2. не выделяются дополнительные человеческие ресурсы;
  • Объем работ не определен четко.
  • Требования приходят, уходят и возвращаются.
  • Изменения в требования «прокрадываются исподтишка».
  • Одобрение версии требований – простая формальность.

Пути решения:

  • Определить основные причины неконтролируемого разрастания проекта.
  • Задокументировать видение и границы проекта.
  • Определить границы системы и интерфейсы.
  • Следовать процессу внесения изменений в случае появления любых изменений.
  • Улучшить методы выявления требований.
  • Создавать срезы требований (baselines)
  • В случае изменения требований пересмотреть процесс внесения изменений.
Ловушка 8. Нерациональный процесс внесения изменений

Признаки:

  • Процесс внесения изменений не определен.
  • Некоторые сотрудники пренебрегают процессом внесения изменений.
  1. пользователи общаются с друзьями в команде разработчиков;
  2. разработчики вносят изменения, которые были отклонены;
  3. изменения вносятся прежде, чем они были одобрены.
  • В процессе тестирования выявляется новая функциональность.
  • Непонятен статус запроса на изменение.
  • Информация об изменениях не доносится всем заинтересованным лицам.
  • Непонятно, кто принимает решения о внесении изменений.

Пути решения:

  • Определить практический подход к процессу внесения изменений.
  • Создать совет по контролю за изменениями.
  • Использовать специальный инструмент для сбора, отслеживания и донесения информации о внесении изменений.
  • Помнить: инструмент – это не процесс!
  • Создать свод правил и пользоваться ими для контроля изменений.
Ловушка 9. Неэффективный анализ влияния изменений

Признаки:

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

Пути решения:

  • Анализировать потенциальное влияние каждого предложенного изменения на систему:
  1. рассмотреть возможные осложнения при принятии изменений;
  2. определить возможный дополнительный объем работ;
  3. оценить влияние изменений на затраты и сроки.
  • Отслеживать требования.
  • Определить затраты и возможную выгоду прежде чем принимать решение.
Ловушка 10. Неразумное использование контроля версий

Признаки:

  • Одобренные изменения не отражены в требованиях.
  • Невозможно различить различные версии спецификаций.
  1. разные версии спецификации имеют один и тот же идентификационный номер;
  2. идентичные спецификации имеют различные идентификационные номера;
  • Сотрудники работают с разными версиями спецификаций.
  1. внедряется функциональность, реализация которой была отменена;
  2. приложение тестируется на основании неверных требований.
  • История изменений и более ранние версии документации утеряны.

Пути решения:

Отражать изменения в требованиях.
Адаптировать систему контроля версий для документации.
Контролировать версии документов, содержащих требования.
Доносить информацию о пересмотре документации всем заинтересованным лицам.
Использовать инструмент управления требованиями.
○ сохранять историю изменений каждого требования;
○ документ со спецификацией требований может быть отчетом из базы данных.
В качестве подведения итога вебинара, Карл предложил несколько ключевых факторов для написания качественных требований:
Обученные разработчики, менеджеры и заказчики.
Квалифицированные, опытные бизнес-аналитики.
Тесное партнерство заказчиков и разработчиков.
Понимание различных типов требований.
Итеративная, инкрементальная разработка требований.
Использование шаблонов документации.
Формальная и неформальная проверка требований.
Написание тестов к требованиям.
Разумная, динамичная приоритизация требований.
Практичный и эффективный подход к управлению изменениями.

Источник: http://analyst.by/articles/vebinar-karla-vigersa-1...


Теги:

Статья была полезной?

Подписка
на материалы
Мы присылаем интересные материалы и ничего больше

По общим вопросам, предложениям по проекту пишите нам на почту:

или звоните по будням
мы работаем с 10:00 до 19:00

Мы рады делиться с вами новостями на разных социальных площадках: