Когда работала в заказной разработке, то заинтересованные стороны по сути назначались. Кого выделили поговорить от заказчика, с тем и говоришь. Аналитик не был допущен к внутренней кухне настолько, чтобы понять, какой вес в компании имеет этот «назначенный». Когда оказалась во внутренней разработке, первое время двигалась привычным путем. Кто принес запрос, у того искала требования. Кто чаще приходит и громче кричит, того требования важнее. Начала различать характеристики заинтересованных сторон только когда поняла, что требования почему‑то сложно согласовываются и вообще превращаются в полнейшее «не то».

Иногда приходится сталкиваться с мнением, что «нет проблем пойти и узнать, чего хочет бизнес». Проблем нет. Есть навыки, которые нужны как и в любом другом деле. Хочу показать несколько типичных ошибок, которые бывают очень заметны. Такие ошибки могут сделать бесполезной работу по выявлению требований, а заодно и всей команды, которая будет работать работать по этим требованиям.

С момента появления бизнес-анализа как отдельной дисциплины роль БА изменилась вместе с процессам ИТ-индустрии. Кроме того эта роль обросла разными представлениями по мере поиска “входа в ИТ” представителями других сфер знаний. О некоторых таких почти мифических представлениях мне стало интересно порассуждать.

Задавать вопросы — это основной способ сбора информации и один из важных навыков аналитика. Существуют разные виды вопросов. Наиболее простая классификация выделяет вопросы: закрытые и открытые. Открытые вопросы начинаются с вопросительных слов: "кто", "что", "где", "когда", "как", "почему". Они помогают получить развёрнутые ответы и новые знания, в отличие от закрытых вопросов, на которые можно получить только односложный ответ (Да или Нет). Чем больше открытых вопросов будет задано в интервью, тем больше информации можно получить.

Это выглядит совершенно базовым знанием (а так и есть), при этом знать и иметь навык совсем не одно и то же. Когда вы сидите перед респондентом и у вас несколько секунд, чтобы сформулировать вопрос, легко ли вам выбрать именно открытый вопрос? Я знаю за собой такую черту — я быстро сбиваюсь на закрытые вопросы, если я устала, волнуюсь или что-то отвлекло. Это потому, что навык открытых вопросов даже за много лет применения еще не стал совсем базовым в моей голове. В ИТ очень долго было принято задавать закрытые вопросы, чтобы быстрее подтвердить ожидаемое решение и заказчик «не придумал лишнего». Это приемлемо, если вам нужно подтвердить уже обсужденные договоренности, но совсем не годится для понимания контекста задачи и потребностей заинтересованных сторон.

Привет! Хочу поделиться парой мыслей о представлении нефункциональных требований в формате User Story. Вы наверняка помните самый распространенный шаблон для историй. В шаблоне есть три части «кто», «хочет что», «чтобы что». Чтобы соблюдать такой формат, важно выделить действующие роли и цели для каждой истории. Для нефункциональных требований это бывает непросто и я часто думаю: «А нужно ли?».

Майк Кон в своем блоге пишет, что нефункциональные требования хорошо ложатся в стандартный шаблон пользовательской истории и что такой шаблон позволяет не забыть, почему это требование появилось. В статье «Нефункциональные требования как пользовательские истории» (Non-functional Requirements as User Stories) приведены кейсы, среди которых есть несколько «синтетические». Например, на мой вкус странно выглядит история вида «Как человек, говорящий на одном из латиноамериканских языков, я, возможно, когда-нибудь захочу запустить ваше программное обеспечение». Как работать с такой историей в бэклоге? Сможет ли команда адекватно ее декомпозировать на атомарные задачи?

Обычно бывает интересно почитать не только саму статью в блоге, но и комменты к ней. В комментариях к статье Майка Кона как раз есть похожие вопросы:

Если в словарях поискать значение слова «допущение», то найдется не меньше трех значений. Пара устаревших: «допущение людей в город», «добился допущения к экзаменам» и более современное «из сделанного допущения вытекают следующие положения». В работе аналитика всегда сложно даются ситуации, когда из допущения «вытекают» решения и нередко они «вытекают» сразу в бэклог. Допущение здесь — это предположение, которое нуждается в проверке. BABOK говорит, что «ограничения, допущения и зависимости могут анализироваться на предмет наличия рисков и, иногда, сами должны управляться как риски». Когда команда спешит решить задачу может получаться так, что именно то, что должно управляться как риски, становится основой для выбора решения и на выходе вместо закрытой потребности получается еще больший риск.

Пример. В бытовом контексте можно предположить, что если пользователь больше года не обновляет папку с загруженными файлами, то они ему уже не нужны и, так как дисковое пространство ограничено, то лучше помочь пользователю и старье удалить. Так звучат советы «если вы год не доставали какую-то вещь из шкафа, то можете ее смело выбросить или отдать». Такое допущение может не работать. Например, в папке хранятся чеки на оплату по договорам, по которым срок исковой давности 5 лет. Пользователь хранит эти файлы, чтобы исключить риск оказаться под следствием или проиграть в суде в случае спорных вопросов. В результате удаления файлов через год могут повыситься ставки, при этом инфрастуктурный риск подменится юридическим.

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

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