В сотый раз объясняешь коллеге, о какой экранной форме идёт речь в требованиях, если этих форм - почти идентичных на вид - больше двух? В ходе совещания разразился скандал из-за того, что из формулировки в баге не ясно о какой форме идёт речь, а попытки понять выглядят как общение с иностранцем? Все эти проблемы поможет решить Глоссарий!

🕵️ Шифровка в Центр

В своей практике я уже взяла за правило: максимально кодировать внешне схожие экранные формы шифрами в требованиях в confluence. И могу сказать, не было ещё раза, чтобы этот подход себя не оправдал!

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

🔹Dashboards.Operational.Pump

Мы буквально берём и записываем этот ключ в страницу требований к данной экранной форме. Затем, в Стори на разработку мы чётко прописываем, что реализовать необходимо экранную форму "Dashboards.Operational.Pump". Теперь, при любом баге, при любом онлайн созвоне с тестировщиком или разработчиком, мы по этому шифру легко определяем - в каком разделе данная экранная форма расположена, и что она отражает. И нет никакой надобности объяснять на пальцах, нет никаких ошибок восприятия типа "а я думал, что ты про форму с двигателем говорила!" и тому подобного. Всё чётко и однозначно.

💬 Мы не понимаем друг друга!

Наверное, одним из самых моих первых дел в роли системного аналитика было составление глоссария. И главной целью было не только начать понимать о чём говорят члены команды, но также дать возможность всем нам начать говорить на одном языке. Непонятные аббревиатуры, многозначные термины - всё это благодатный материал для размещения в Глоссарии проекта. Прийти к единому словарю просто необходимо, т.к. это значительно облегчает коммуникацию. То есть главная задача заключается к том, чтобы Глоссарий не был "документом ради документа", а стал живым словарём технических терминов проекта и предметной области, вокруг которой данный проект реализуется.

А как у вас обычно решается проблема разноголосья на проекте? Делитесь в комментариях! 👇