Унификация
Last updated
Last updated
Называйте идентичные по смыслу поля и их значения в разных каталогах одинаково.
Спроектированная на Бипиуме система состоит из нескольких каталогов со своим собственным перечнем полей. При этом в каждом каталоге могут встречаться поля, которые имеют аналоги в других каталогах.
Паттерн унификации обязывает давать одинаковые наименования полям с одним и тем же значением в разных каталогах. Это упростит поиск информации в системе и облегчит жизнь сотрудникам путем введения единой терминологии.
Вместо таких наименований: Используйте такие:
Запросы | Задачи | Запросы | Задачи |
---|---|---|---|
В качестве примера можем рассмотреть демо-вариант таск-трекера, собранного на Бипиуме. Таск-трекер состоит из поступающих запросов и задач, необходимых для их решения.
Так выглядит карточка запроса, при проектировании которого паттерн унификации не соблюдался:
Следствием несоблюдения паттерна унификации могут быть следующие проблемы:
Неочевидная фильтрация записей в каталогах
Отсутствие единой терминологии у сотрудников
Из-за несоответствия наименований полей в каталогах значительно усложняется процесс фильтрации записей из панели фильтров: увеличивается время для поиска нужного поля и его значения.
Например, необходимо найти все запросы и задачи, которые ещё не были взяты в работу. То есть в обоих каталогах нужно определить поле со статусом записи и выставить в нем соответствующее значение.
При настройке фильтров в каталоге “Задачи” проблем нет — находим поле “Статус” и проставляем в него значение “Новая”:
При настройке аналогичных фильтров в каталоге “Запросы” сталкиваемся с проблемой: в каталоге нет поля “Статус”.
Путем проведения аналогии понимаем, что за определение статуса запроса отвечает поле “Этап”.
Открываем набор значений этого поля и видим, что они тоже названы по другому:
Через сопоставление полей с “Задачами” понимаем, что значению “Новая” из каталога “Задачи” соответствует значение “Создан” из каталога “Запросы”. При этом на сам процесс сопоставления наименований между каталогами затрачено некоторое время.
С увеличением каталогов и полей в системе ситуация обостряется: найти нужное поле в панели фильтров становится сложнее.
Важно понимать, что каждое новое наименование в системе — это новый термин в мире работающего в ней сотрудника. Если в системе работает только один сотрудник, то он понимает назначение каждого из них, но когда в системе работают несколько сотрудников —начинаются проблемы с коммуникацией.
Сотрудники работающие в разных частях системы неизбежно столкнутся с моментом, когда они перестанут понимать друг друга.
Один из сотрудников знает, что такое “Статус”, но не понимает, что такое “Этап” и наоборот.
Так же, как и с проблемой фильтрации — вероятность того, что сотрудники в очередной раз не поймут друг друга будет расти с увеличением полей и каталогов в системе.
Следствием проблемы расширяющейся терминологии также является обучение новых сотрудников. Вместо того, чтобы быстро “влиться” в рабочий процесс новый сотрудник будет путаться в обилии всех терминов, которые используются в системе.
Рассмотрим эту же систему спроектированную с использованием паттерна унификации. Теперь карточка “Запроса” выглядит следующим образом:
Решить ту же задачу с поиском записей, которые ещё не были взяты в работу, теперь можно гораздо проще.
Так выглядит фильтрация в каталоге “Задачи”:
И практически идентично выглядит фильтрация в каталоге “Запросы”:
Процесс сопоставления наименований не занимает времени, так как он больше не нужен. По мере роста количества каталогов и полей в системе время на фильтрацию данных значительно сократится в сравнении с первым вариантом реализации.
Также решена и проблема с отсутствием единой терминологии. Все сотрудники работающие в системе понимают, что такое “Статус”, потому что они сами регулярно сталкиваются с этим термином в своей работе.
Этап
Статус
Статус
Статус
Детализация
Описание
Описание
Описание
Срок выполнения
Дедлайн
Дедлайн
Дедлайн
Проверяющий
Ответственный
Ответственный
Ответственный