Привет! Эта статья о неоднозначных терминах, которые могут обнаружиться в предметной области ИТ-задач. В ней разобраны пара примеров, чтобы бизнес-аналитики реже попадались в ловушки разных интерпретаций одних и тех же названий.

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

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

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

Есть слово «клиент», которое в разном контексте приобретает разные оттенки. Для юриста это человек, с которым заключен договор, а операционист может так назвать любого обратившегося по какому-либо вопросу. Фраза «оформить профиль клиента» может означать и «внести данные договора в систему» и «внести данные нового потенциального клиента» в зависимости от того, кто ее произносит. При проектировании системы это может быть важным различием и есть риск понять разницу только после внедрения, если не уточнить значение термина.

Представьте, что вы проектируете экранную форму для колл-центра. Запрос заказчика звучит как «выведите на экран ID клиента». Вы вывели на экран идентификатор записи клиента, а оказалось, что заказчик имел в виду номер телефона. Придется переделать.

Для участников ИТ-команд выглядит абсурдной ассоциация между «ID клиента» и «номер телефона». Часто к слову «идентификатор» прибавляется слово «уникальный», и так как номер телефона может меняться, он ни в коем случае не может уникально идентифицировать запись клиента. Это совершенно верно в контексте ИТ-решения.

Что если обратить внимание на данные экранных форм в решениях для колл-центров? Чаще всего на рабочем месте оператора колл-центра и при входящем звонке, и при исходящем обзвоне, единственная легко читаемая информация, на которую можно опереться — номер телефона. Если в таких системах есть интеграция с CRM, то могут быть подтянуты данные из договора клиента и его номер в реестрах компании, но это не всегда удобно, ведь большинство списков на экране и в том числе окошко входящего звонка точно содержат номер телефона и не обязательно данные из CRM. Так возникает ситуация, когда оператор колл-центра значение номера телефона назовет «ID клиента», не вникая в нюансы уникального соответствия между клиентом и его номером телефона.

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

????Если вы слышите термин впервые, проговорите его с заказчиком в явном виде, даже если думаете, что вам все понятно. Лучше показаться дотошным чудаком, чем заставлять команду переделывать функционал.

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

????Если макет не применим и речь не об экране, а о логике функционала, то на примере проговорите ожидаемую логику и/или покажите как вы понимаете пример данных до и после ее применения.