Ответ
Создание требований — это совместный процесс, которым обычно руководят Бизнес-аналитик (BA) или Продуктовый менеджер (PM).
Основные роли и их вклад:
-
Бизнес-аналитик / Системный аналитик — ключевая роль.
- Собирает и анализирует потребности стейкхолдеров (заказчиков, пользователей).
- Формализует их в документы: User Stories, Use Cases, спецификации требований к ПО (SRS).
- Проясняет неоднозначности и разрешает противоречия.
-
Продуктовый менеджер — определяет что и зачем.
- Формирует видение продукта и роадмап.
- Расставляет приоритеты функций (фич) на основе бизнес-ценности и стратегии.
- Пишет высокоуровневые требования (Epics, Features).
-
Технический лид / Архитектор — уточняет как.
- Детализирует нефункциональные требования (производительность, безопасность, масштабируемость).
- Оценивает техническую реализуемость.
-
Команда разработки и QA — участвуют в ревью.
- Разработчики оценивают сложность реализации.
- Тестировщики проверяют требования на тестопригодность, полноту и отсутствие противоречий.
Пример User Story (формат Connextra):
Как [роль пользователя],
Я хочу [выполнить действие],
Чтобы [получить пользу/результат].
Критерии приемки (Acceptance Criteria):
- Дано: Пользователь на странице входа.
- Когда: Он вводит валидные email и пароль.
- Тогда: Происходит редирект на личный кабинет.
- И: Отображается приветственное сообщение.Ответ 18+ 🔞
О, смотри-ка, классика жанра! Собрались тут все умные, чтобы бумагу портить. Ну ладно, давай разберем эту кашу, кто тут главный по тарелочкам.
Вот представь картину: сидит Бизнес-аналитик (BA), этакий главный переводчик с языка бизнеса на язык программистов. Его задача — вытащить из заказчика, чего он хочет на самом деле, а не то, что он бормочет. Собирает все эти «хотелки», а потом превращает их в бумажки: User Stories, Use Cases и прочую SRS-хрень. По сути, он тот парень, который не даёт всем передраться на почве «а я думал, ты имел в виду вот это!».
Рядом — Продуктовый менеджер (PM). Этот вообще витает в облаках. Он думает не о коде, а о деньгах и стратегии. Решает, что и зачем мы вообще делаем. Нарисует красивый роадмап, накидает Epics и Features, а потом говорит: «Вот это вот — овердохуище важное, делаем в первую очередь, а это — похуй, на потом». Ценность бизнеса — его конёк, хотя иногда кажется, что он её просто с потолка берёт.
А потом приходит Технический лид / Архитектор. Смотрит на все эти красивые фичи и начинает материться. Потому что он должен понять, как это всё воплотить в жизнь, чтобы не развалилось на второй день. Он про нефункциональные требования: «А выдержит ли это 10 тысяч пользователей?», «А как с безопасностью?», «А на каких серверах это всё будет висеть, на моём стареньком ноуте?». Если BA и PM — это про «хочу», то этот товарищ — про «можем, но будет больно».
Ну и куда же без команды разработки и QA? Их обычно зовут на аутсорс, когда всё уже почти придумали. Разработчики смотрят на требования и начинают чесать репу: «Ну, за неделю сделаем… если не спать». А тестировщики — те вообще самые вредные. Они берут документ и начинают искать дыры: «А что будет, если юзер вместо логина введёт DROP TABLE users;? А если он нажмёт все кнопки разом? А если у него интернет отвалится в самый ответственный момент?». Их задача — добить документ так, чтобы он был тестопригодным, то есть чтобы по нему можно было понять, работает фича или нет.
А теперь, чтобы не быть голословным, вот тебе пример этой самой User Story, в которую все должны тыкать пальцем и кивать.
Как [зарегистрированный пользователь],
Я хочу [войти в систему],
Чтобы [получить доступ к своему личному кабинету].
Критерии приемки (Acceptance Criteria):
- Дано: Пользователь находится на странице входа.
- Когда: Он вводит валидные email и пароль и нажимает "Войти".
- Тогда: Система перенаправляет его на страницу личного кабинета.
- И: На странице отображается сообщение "Добро пожаловать, [Имя пользователя]!".Вот и вся магия. Кажется, просто, да? А попробуй собрать этих всех упырей в одной комнате и добиться, чтобы они согласовали хотя бы этот кусок текста. Волнение ебать! Каждый будет тянуть одеяло на себя: PM скажет, что приветствие не нужно, BA будет настаивать, что «это важно для юзер-экспириенса», разработчик спросит, откуда брать имя пользователя, а тестировщик потребует прописать, что будет, если ввести email с пробелами. И так по каждой строчке, блядь.
В общем, создание требований — это не про написание текста. Это про переговоры, компромиссы и постоянное чувство, что все всё поняли неправильно. Терпения ноль ебать к концу процесса. Но без этого — вообще пипец, потом получится хуй в пальто, а не продукт.