Является ли ответственность Junior QA за сбор требований от клиента и создание документа с областью?

Я младший QA с 2-летним опытом работы в качестве ручного
тестера. В моей компании работает 1 BA, 1 Project Manager и 2
менеджера по маркетингу. Однако никто не хочет собирать требования
от клиента; они просят меня сделать это и создать документ с
областью.

У меня нет опыта в этом. Я попросил моего BA и PM сделать это;
они сказали: «Это твоя работа, а не наша». Это верно?

Я хочу знать, кто, как правило, является правильным
человеком/должностью для сбора требований от клиентов и
преобразования их в документ области.

Также, если какой-либо член команды задает любой вопрос
BA/PM/человеку, который собрал требования, должен ли человек
попросить разрешить эти запросы или ответить «напрямую поговорить с
клиентом»? Когда член команды задает вопрос клиенту, который он уже
очистил, к человеку, который собрал это требование, клиент получает
разочарование. Что должен делать человек в этом случае?

Правильно, у вас есть пара проблем.

Первая проблема, которую я вижу, заключается в том, что никто не
считает своей ролью говорить с клиентом и понимать это требование.
Обычно это роль [владельца продукта](https://www.scrum.org/resources/what-is-a-product-owner) (или PO ), которого у
вас нет.

Роль ПО должна взаимодействовать с заинтересованными сторонами и
гарантировать, что то, над чем вы работаете, всегда является самой
ценной частью работы. Если ваша команда не имеет кого-либо,
выполняющего эту роль, то как у всей команды есть уверенность, что
их усилия не будут потрачены впустую?

Предполагая на минуту, что ваша компания не собирается нанимать
новых людей или повторять существующие, у вас есть пробел. Это не
непреодолимо ...

В качестве QA у вас действительно неплохая позиция. Ваша задача
- обеспечить, чтобы все, что было построено, не только работало, но
и соответствовало требованиям ваших клиентов. Если требования
неясны, то это будет очень сложно для вас!

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

Специальная коммуникация с клиентом не плохая вещь, на самом
деле это очень хорошо! Однако похоже, что это немного
неструктурировано. Я бы предложил пару вещей:

* Демонстрация вашей работы клиенту каждые две недели (я
намеренно избегаю слова sprint здесь, поскольку это не похоже на
то, что вы особенно ловко). Это даст клиенту возможность дать
обратную связь, и вы сможете задать любой вопрос.
* Поощряйте ВСЕ, чтобы поговорить с клиентом, я не говорю о
официальных письмах - я говорю о построении отношений и
общении.
* Чтобы избежать повторения одних и тех же вопросов снова и
снова, убедитесь, что запросы сначала передаются внутри, а
зарегистрированные вопросы/ответы добавляются в документацию (или
только журнал вопросов).

Увидите это как возможность улучшить взаимодействие вашей
команды и клиента, не считайте это «вашей работой» или «моей
работой».



Как правило, существует четыре критерия распределения ресурсов:
1) обладание надлежащими знаниями, навыками и способностью
выполнять работу; 2) доступное время для выполнения работы; 3)
отсутствие конфликта интересов между различными ролями, которые
можно было бы принять; и 4) назначается ответственным лицом.

Похоже, вам не удалось выполнить только один критерий.

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



> 
> Правильно ли это?
> 
> 
> 

Это полностью зависит от ситуации. Правильно ли это во всех
ситуациях? Нет. Правильно ли это в *yours* ? Может быть.

Там *есть несколько* совпадений между Business Analyst
(BA) и персоналом Quality Quality (QA). Я был когда-то в команде,
где один человек был официально BA и неофициально QA; он работал
достаточно хорошо.

Независимо от того, имеет ли смысл в *ваша* ситуация
зависит от нескольких факторов. Важно то, как выглядит ваша
иерархия?

Является ли PM/BA вашим прямым начальником? Если это так, то
ответ Дэвида Эспины о повышении рисков для них, а затем принятие их
решения является прочным подходом.

Вы разделяете непосредственного начальника? Если это так, вам
следует подумать о том, чтобы пойти к этому начальнику и попросить
разъяснить роли. Прямо сейчас, каждый из вас думает, что это
ответственность других за сбор требований. Это несогласие вызывает
путаницу и, следовательно, должно быть выяснено.

> 
> Также, если какой-либо член команды спрашивает [...], клиент
> получает разочарование.
> 
> 
> 

Это кажется отдельным вопросом для меня (на самом деле, я не
уверен, как «BA/PM не будет собирать требования», «что делать,
когда BA/PM просит меня собирать требования после того, как они
собрали их он сам ...), но я все равно отвечу.

Первое, что вам нужно выяснить, это *why* , это
происходит. Почему BA/PM хочет, чтобы вы сразу обратились к клиенту
- снова? Действительно ли он/она *фактически* получает это
требование раньше, просто что-то вроде *похожее* ? Он забыл?
Он ленив? Считает ли он, что QA необходимо более непосредственное
участие в работе с клиентом? Был ли он инструктором начальника
действовать таким образом? Клиент запросил это?

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



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

для меня, я думаю, нет, это не младшая обязанность QA вызывать
требование. он должен быть BA, а для PM - расширить сферу
деятельности с заинтересованными сторонами. Получение требования и
анализ его требуют очень отличных хороших навыков. Как упоминал
Дэвид Эспина, они рискуют.

Кроме того, на пластине QA уже есть много вещей.