W klasycznej logice zasada podziału brzmi prosto: na jednym poziomie hierarchii dzielimy zbiór według jednej i tej samej cechy (fundamentum divisionis). W prezentacji na warsztacie każdy się z tym zgadza. W produkcyjnej bazie danych niemal każde drzewo kategorii łamie tę zasadę już na pierwszym lub drugim poziomie.

Wystarczy spojrzeć na typowe menu w intranecie, katalogu produktów albo repozytorium raportów: obok siebie, jako rodzeństwo na jednej liście rozwijanej, stoją „Raporty kwartalne” (format i rytm publikacji), „Bezpieczeństwo” (temat), „Dla zarządu” (odbiorca) oraz „Pilne” (status w obiegu). Dopóki dokument jest nudną notatką o niczym szczególnym, wszystko wydaje się działać. W chwili, gdy pojawia się pilny raport kwartalny o bezpieczeństwie dla zarządu, system wymusza wybór jednej szuflady kosztem pozostałych trzech.

Skąd się bierze sklejone drzewo

Sklejone osie podziału rzadko wynikają z niewiedzy projektanta. Najczęściej są osadem historii organizacji:

  • Pierwszy zespół potrzebował podziału według przedmiotu (czym rzecz jest).
  • Drugi zespół dopisał do tej samej listy trzy pozycje według zastosowania (do czego rzecz służy), bo formularz w CMS-ie miał tylko jedno pole kategorii, a dodanie drugiego wymagało prac programistycznych.
  • Trzeci zespół dorzucił kategorię opartą na częstości lub popularności („Kluczowe”, „Rynkowe”, „Trendy”), bo chciał mieć gotowy filtr na stronę główną.

Po roku lista ma dwadzieścia pozycji, które na ekranie wyglądają jak równe sobie kategorie, a w rzeczywistości są czterema różnymi słownikami wrzuconymi do jednego worka.

Jeśli dwie kategorie na tym samym poziomie nie potrafią odpowiedzieć na to samo pytanie zaczynające się od „według czego dzielimy?”, to nie są sąsiadami w jednym drzewie — są wartościami z dwóch różnych wymiarów.

Dwa wyjścia: rozkład fasetowy albo kaskada bramek

Kiedy audyt wykrywa sklejone drzewo, do wyboru są dwie czyste konstrukcje — zależnie od tego, jak z taksonomii korzysta docelowy system:

  1. Rozbicie na niezależne fasety (wieloosiowość). Jeśli obiekt naprawdę ma kilka niezależnych wymiarów, które są równocześnie ważne dla wyszukiwania lub analizy, dajemy każdemu wymiarowi własną oś z krótką, zamkniętą listą wartości. W taksonomii gier i metod psychologicznych oddzielenie kategorii (czym obiekt jest) od mechanizmu (dlaczego działa) natychmiast zlikwidowało spory o to, gdzie umieścić zjawisko łączące grę interpersonalną z błędem poznawczym. Z kolei w modelu śmierci gwałtownej zastąpienie jednej etykiety sześcioma osiami (jednostka analizy, sprawstwo, intencja, zgoda, mandat, miejsce w łańcuchu przyczyn) pozwoliło bez sprzeczności opisać przypadki graniczne, na których jednowymiarowe klasyfikacje pękały od XIX wieku.
  2. Kaskada leksykograficzna z regułami tak/nie. Bywa jednak tak, że system docelowy (np. nawigacja, adres URL, główny właściciel procesu) naprawdę wymaga jednego głównego typu na końcu. Wtedy zamiast udawać, że cechy są rozłączne z natury, ustala się jawny porządek starszeństwa bramek. W taksonomii projektów webowych taką rolę pełni klucz N > P > O > R: najpierw pytamy, czy wartość zależy od sieci autonomicznych uczestników (N); jeśli nie — czy wymaga trwałej przestrzeni roboczej między sesjami (P); jeśli nie — czy wiąże operatora zobowiązaniem realizacji (O); jeśli nie — czy dostarcza interaktywnego środowiska sesji (R); w pozostałych przypadkach domyślną rodziną jest publikacja. Obiekt posiadający kilka cech trafia zawsze do pierwszej bramki, którą otwiera, a pozostałe cechy są jawnie odnotowane jako kontrakty wtórne zamiast ginąć.

Szybki test diagnostyczny na własnym słowniku

Weź dowolne pięć kategorii stojących obok siebie na tym samym poziomie Twojej taksonomii i spróbuj zbudować zdanie: „Każdy obiekt w tym zbiorze różni się od sąsiadów wyłącznie pod względem [X]”. Jeśli w miejsce [X] musisz wstawić spójnik „albo” („według tematu albo formatu albo działu firmy”), masz przed sobą sklejone drzewo.

Kontakt

Porozmawiajmy o projekcie

Od diagnozy istniejącej struktury, przez projekt, po zasady, które utrzymają ją w ruchu.