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

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

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

 

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

Признаки:

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

 

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

• Адаптировать шаблоны документации для трех уровней требований:

○      бизнес-требования (Документ концепции и границ);

○      пользовательские требования (Документ пользовательских требований);

○      функциональные требования (Спецификация требований к ПО).

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

 

Ловушка 2. Нерациональное вовлечение заказчика в процесс разработки

Признаки:

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

 

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

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

 

Ловушка 3. Неопределенные и неоднозначные требования

Признаки:

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

 

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

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

 

Ловушка 4. Требования не приоритизируются

Признаки:

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

 

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

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

 

Ловушка 5. Разработка функциональности, которая никому не нужен

Признаки:

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

 

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

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

○      попросить заказчика определить ценность (выгоду и недостатки реализации);

○      попросить разработчиков оценить стоимость и риски;

○      избегать требований с высокой стоимостью и низкой ценностью.

 

Ловушка 6. Аналитический паралич

Признаки:

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

 

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

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

○      существует приемлемый риск при продолжении разработки;

○      требования рассмотрены бизнес-аналитиком, заказчиками, разработчиками, тестировщиками.

• Моделировать только сложные или сомнительные части системы.
• Не включать финальный дизайн пользовательских интерфейсов в спецификацию требований к ПО.

 

Ловушка 7. Неконтролируемое разрастание границ проекта

Признаки:

• Новые требования постоянно добавляются:

○      при этом времени на разработку не добавляется;

○      не выделяются дополнительные человеческие ресурсы;

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

 

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

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

 

Ловушка 8. Нерациональный процесс внесения изменений

Признаки:

• Процесс внесения изменений не определен.
• Некоторые сотрудники пренебрегают процессом внесения изменений.

○      пользователи общаются с друзьями в команде разработчиков;

○      разработчики вносят изменения, которые были отклонены;

○      изменения вносятся прежде, чем они были одобрены.

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

 

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

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

 

Ловушка 9. Неэффективный анализ влияния изменений

Признаки:

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

 

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

• Анализировать потенциальное влияние каждого предложенного изменения на систему:

○      рассмотреть возможные осложнения при принятии изменений;

○      определить возможный дополнительный объем работ;

○      оценить влияние изменений на затраты и сроки.

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

 

Ловушка 10. Неразумное использование контроля версий

Признаки:

• Одобренные изменения не отражены в требованиях.
• Невозможно различить различные версии спецификаций.

○      разные версии спецификации имеют один и тот же идентификационный номер;

○      идентичные спецификации имеют различные идентификационные номера;

• Сотрудники работают с разными версиями спецификаций.

○      внедряется функциональность, реализация которой была отменена;

○      приложение тестируется на основании неверных требований.

• История изменений и более ранние версии документации утеряны.

 

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

• Отражать изменения в требованиях.
• Адаптировать систему контроля версий для документации.
• Контролировать версии документов, содержащих требования.
• Доносить информацию о пересмотре документации всем заинтересованным лицам.
• Использовать инструмент управления требованиями.

○      сохранять историю изменений каждого требования;

○      документ со спецификацией требований может быть отчетом из базы данных.

 

В качестве подведения итога вебинара, Карл предложил несколько ключевых факторов для написания качественных требований:

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

 

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

 

В статье были использованы изображения, взятые с сайтов blog.smartbear.com, dancingwithhappiness.com, image.freepik.com, firsttimehomebuyersnetwork.com, spunspero.files.wordpress.com, extremeuncertainty.com, s-media-cache-ak0.pinimg.com, pcquest.com, i.stack.imgur.com

 

Автор:

Анна Чернуха