Простое определение термина "требование" - что должно быть доставлено для обеспечения ценности (value)
Основной причиной "ползучести (creep) требований" является принципиальное различие между бизнес и системными требованиями
Суть этого различия заключается в том, что интересующие технических специалистов требования буквально и фигурально не являются требованиями, интересующими представителей бизнеса
Продукт может работать именно так, как написано в системных требованиях. Но при этом он может не доставлять бизнесу value, так как не соответствует бизнес-требованиям
|
Бизнес-требования |
Системные требования |
|
Бизнес/пользовательский взгляд/язык |
Взгляд/язык продукта |
|
Концептуальные |
Конкретные, высоко-уровневый дизайн продукта |
|
Какие бизнес-результаты должны быть доставлены для обеспечения value |
Как продукт должен функционировать (с внешней точки зрения) чтобы работать в соответствии с дизайном и предположительно доставлять ожидаемый бизнес-результат |
|
Уже существует внутри бизнеса |
Определяется кем-то |
|
Много разных путей для достижения |
Один возможный путь для удовлетворения бизнес-требований |
Тестирование должно включать: выполнение теста; получение реального результата; сравнение полученного результата с ожидаемым.
Если мы просто выполняем тест и получаем результат, но не сравниваем с желаемым - это не тестирование
Ревьювер должен нести ответственность за результаты своей работы и после того, как он подтвердил адекватность требований, по сути он становится их соавтором
15. Ambiguity (двусмысленность)
Эту технику можно применять к нескольким требованиям из одной темы. И если в результате мы понимаем, что эти несколько требований нам не нужны, то может быть можно не анализировать и всю тему - вдруг она вся не нужна. Таким образом мы можем сэкономить время, не тратя его на остальные требования темы.
Представители бизнеса основную часть своего времени заняты не размышлениями над требованиями, а выполнением своих рабочих обязанностей. Но даже когда они заняты выявлением требований, они думают о своей работе, а не о требованиях.
Выработать конкретное решение конкретной проблемы намного проще, чем сформировать требования к этому решению. Но данное решение не будет отражать реальных требований и может не принести value.
Мы часто отбрасываем реальные требования, потому что нам кажется, что то, что сказал пользователь, не является требованием.
Block 2 - Measure now - значения критериев, на основе которых было принято решение о том, что проблема действительно имеет место
Люди, которые полагаются на прототипирование, не отдают себе отчет в том, что прототипирование имеет минусы и носятся с идеей прототипирования с религиозным рвением
Прототипы могут быть отличным инструментов, особенно при разработке дизайна, но их роль в выявлении бизнес-требований преувеличена и может быть даже контпродуктивной при неправильном использовании.
Рекомендуется начать проводить интервью с самого высокого уровня иерархии, постепенно опускаясь до непосредственных исполнителей. Потому что сотрудники на высоких должностях могут обеспечить необходимый контекст и подсказать, кого еще надо проинтервьюировать.
1. Спускаясь сверху-вниз описать бизнес-языком конечные результаты/выходы бизнес-модели TO BE, опираясь на комплексный подход