Podstawy psychologiczne Ubiquitous Language

Ubiquitous Language, podstawowy składnik Domain Driven Design, kładzie nacisk na porozumiewanie się wspólnym językiem biznesowym w rozmowach z klientem i wewnątrz zespołu. Zamiast zwrotów technicznych używa się tych związanych z problemem, który rozwiązujemy. Słownictwo zgodne z domeną biznesową jest jednym z kluczowych aspektów, by projekt odniósł sukces. Pozwala budować zrozumienie w projekcie i unikać błędów związanych z innym postrzeganiem tych samym słów.

Tyle teorii. Praktyka pokazuje, że zespoły nie skupiają się na wspólnym języku między sobą a klientem - nie widzą wyraźnych powodów i jasnych faktów, które by wskazywały, że jest to ważne. „Co to niby za różnica czy powiem tablica elementów zamiast lista produktów? Czy powiem użytkownik zamiast klient? Przecież chodzi o to samo.” Niestety jest zupełnie przeciwnie, a tłumaczy nam to psychologia i zasada kategoryzacji.

Zasada Kategoryzacji - teoria

Zasada [1] została opisania w 1978 roku przez Eleanor Rosch. Mówi ona, że rzeczywistość postrzegamy przez pryzmat prototypów, z których każdy odznacza się szczególnymi dla siebie cechami. Są to:

percepcja - jak postrzegamy dany element,
funkcja - jaką funkcję spełnia dany element,
motoryka - co z danym elementem robimy, jak nasze ciało reaguje,
cel - jaki rezultat da nam operowanie / egzystowanie z danym elementem.

Następnie każdy element otoczenia próbujemy wpasowywać w ten prototyp. W zależności, które cechy spełnia i w jakim stopniu, będzie należał do tej kategorii lub nie. Proces wpasowywania się w daną kategorię nazywamy kategoryzacją.

Zasada Kategoryzacji - praktyka

Omówmy wspomnianą zasadę na przykładzie opisywanej przez Rosch kategorii krzesła. Przechodząc przez konkretne cechy:

Do tej kategorii będą wchodziły krzesła, fotele, taborety, ale także wiszące krzesła czy krzesła barowe. Nie będą spełniały one wszystkich cech np. percepcyjnych jak nogi, ale będą miały te same funkcje i elementy motoryczne.

Na podstawie tych cech jesteśmy w stanie w błyskawiczny sposób ocenić czy coś krzesłem jest czy nie.

Zasada Kategoryzacji - znaczenie

Proces kategoryzacji jest kluczowym procesem, który zachodzi w naszych umysłach cały czas. Dzięki temu możemy natychmiastowo oceniać sytuację, nie poświęcać energii na myślenie o otaczających nas obiektach, reagować na zmiany. Przykładamy nowe elementy do naszej matrycy i wiemy jak reagować - uciekać czy walczyć, iść przez czy omijać, jeść czy zostawić.

To, co jest ważne, to fakt, że każdy z nas ma inne cechy w danych kategoriach. Zależy to od naszego pochodzenia, doświadczeń życiowych, wychowania, języka itd. Jeśli weźmiemy pod uwagę kategorię czasu, to inne cechy będzie ona miała dla osób ze świata zachodu (Europa, Ameryka), a inne dla świata wschodniego (Chiny, Tajlandia) [2]:

Świat zachodu postrzega czas w sposób linearny; z przeszłością, teraźniejszością i przyszłością; mający konkretne połączenia zdarzeniowe; „Czas ucieka”
Świat wschodu postrzega czas w sposób cykliczny; odtwarzający wydarzenia w regularnych okresach; „Czasu jest zawsze dużo”

Różnice w przypisaniu elementów do kategorii - teoria

W teorii kategoryzacji ważne jest również wpasowywanie się słów w daną kategorię. Jeśli mamy słowo, które dla mnie się wpasowuje w kategorię A, ale dla drugiej osoby w kategorię B, to nie będziemy w stanie się ze sobą porozumieć. Druga osoba może:

dziwić się, dlaczego danym słowem opisujemy konkretny przedmiot / zdarzenie,
nie zrozumieć, co mieliśmy jej do przekazania,
całkowicie pominąć, co do niej mówiliśmy.

George Lakoff i Mark Johnson, w swojej książce bazującej na teorii kategoryzacji [3], opisali jak różnice w kategoriach zmuszają nas do negocjacji z drugą osobą. Piszą, że na początku dyskusji staramy się stworzyć tzw. wspólny grunt, by nasze zrozumienie rzeczywistości było spójne. Wraz z kolejnymi minutami ustalamy wzajemnie, na jakie wartości się zgadzamy, jakie są kategorie, którymi się posługujemy, które słowa należą do jakiej kategorii.

Różnice w przypisaniu słów do kategorii - przykład humorystyczny

Ciekawym, dość jaskrawym przykładem pokazującym różnice w przypisywaniu słów do kategorii, może być odmienne rozumienie słowa „pole”, uzależnione od części Polski, z której się pochodzi. Jest to niby błahostka i powód tworzenia kolejnych memów, jednak różnica jest fundamentalna.

Otóż słowo pole zalicza się do dwóch, kompletnie różnych kategorii. W zależności od miejsca zamieszkania jesteśmy uczeni do innego postrzegania tego słowa:

Obszar na zewnątrz
- percepcja - brak ścian, brak zamknięcia, niebo nad głową,
- funkcja - możliwość spaceru, jazdy rowerem/samochodem,
- motoryka - wychodzi się z wnętrza do zewnętrza przez drzwi / bramę,
- cel - dotarcie gdzieś, spotkanie się ze znajomymi.
Obszar rolniczy
- percepcja – grunty orne, rośliny, zboża,
- funkcja - możliwość uprawy, zasiewania, obsadzania,
- motoryka – kopie się, jeździ traktorem, usuwa chwasty,
- cel – produkcja żywności.

Tych kategorii uczymy się od początku naszego życia. I teraz nauka używania słowa „pole” w innym kontekście nie nadejdzie szybko. Taka zmiana jest trudna, gdyż zaburza dobrze zbudowane i pielęgnowane dopasowanie. Jako zwierzęta bardzo trudno się adaptujemy, ponieważ to zmienia nasze odruchy, praktyki, reakcje i postrzeganie rzeczywistości. Mamy zbiór [4] podświadomych odruchów, których zmiana jest bardzo trudna i wymaga dużo czasu.

Prototypy Programistyczne

Chcąc opisać przykład bardziej bliski programistom, musimy najpierw nakreślić, w jaki sposób postrzegają oni świat.

Programiści nie widzą świata w taki sposób, jak inne osoby - szczególnie podczas programowania. Dochodzi tutaj do zmiany kategorii i powiązań [5] [6], na takie, które odpowiadają światowi kompilowanemu. Chcąc programować musimy się dostosować mentalnie do warunków, jakie są wymagane, by móc pisać program. Myślimy abstrakcyjnie – ponieważ za pomocą abstrakcyjnych „klocków” budujemy aplikacje.

Przejdźmy np. po kategorii „kontener na dane”:

percepcja – ustawione koło siebie elementy, logicznie bądź fizycznie; określona pojemność,
funkcja – iteracja, wybranie pierwszego / ostatniego elementu, sortowanie,
motoryka – wrzuca się tam elementy, wyciąga je,
cel – agregacja danych w jednym miejscu.

Do tej kategorii programista zaliczyłby np. tablicę, kolekcję, listę. W naszych dyskusjach programistycznych możemy używać tych słów, jako synonimów, ponieważ należą one do jednej kategorii. Są one tożsame, przez co używane wymiennie. Język programistyczny wpływa na nasz sposób postrzegania rzeczywistości [7]. Jednak dla osób nietechnicznych, a takimi są przeważnie nasi klienci, takie postrzeganie jest kompletnie obce.

Różnice w przypisaniu słów do kategorii - przykład biznesowy

Załóżmy, że klient prosi nas o listę produktów na stronie głównej. My odpowiadamy mu, w zależności od sytuacji, o liście / tablicy / kolekcji elementów. Dla nas jest to zrozumiałe, bo należy do wspólnej kategorii – „kontenera na dane”. Niestety dla niego takie postrzeganie rzeczywistości jest obce. Mieszamy tutaj frazy mające różne funkcje i leżące w z różnych kategoriach:

I teraz nasz klient biznesowy może być zdziwiony i nie rozumieć, o czym mówimy i co mamy na myśli. Taka różnica będzie go wybijała z kontekstu, dziwiła, utrudniała przekazanie nam informacji i zrozumienie naszego przekazu. Użycie naszego slangu programistycznego w gronie osób, którym nie jest on bliski, powoduje nieporozumienia.

Proza życia klienta

Gdyby powyższy przykład był jednostkowym, to pewnie nikt nie kruszyłby tutaj kopii. Jednak, jako programiści mamy nadzwyczaj częste tendencje do używania terminów, które są w teorii wspólne, w praktyce zaś są spójne jedynie dla naszej grupy. Powyższy przykład jest jednym z wielu: użytkownik, biblioteka, funkcja, komponent, rekord, tabelka, mikroserwis itd. Mamy tendencję do przenoszenia przypadków biznesowych na znane nam elementy ze świata programowania – obiekt, klasa, serwis.

Długofalowo klient pracujący z zespołem posługującym się takim językiem będzie się czuł zagubiony. Osoby te teoretycznie rozwiązują jego problemy, a w rzeczywistości tworzą tylko więcej problemów. Nie mogąc się odpowiednio porozumieć klient będzie narzekał na współpracę lub liczył na analityka biznesowego. Ale może to również prowadzić do czegoś gorszego.

Andrzej Krzywda używa takiego zwrotu „Nauczyć klientów CRUD’a” co oznacza narzucenie klientowi programistycznego punktu widzenia. Klient nie mogąc używać języka swojej domeny biznesowej zaczyna używać języka technicznego. Co gorsze, przechodząc w świat abstrakcji myśli, że czyni dobrze dla swojego projektu i współpracujących z nim programistów. W rzeczywistości powoduje to problemy ze zrozumieniem problemów klienta, przejście na model abstrakcyjny - niebiznesowy, a w ostateczności brak odwzorowania potrzeb klienta w systemie.

Ubiquitous Language

Zasadą Ubiquitous Language jest posługiwanie się takim językiem, jakim rozmawia i myśli klient. Nie staramy się używać własnych synonimów, wymyślać nowych zwrotów, kopiować terminów ze świata programistycznego – język klienta narzuca nam sposób, jakim się porozumiewamy. Dokładnie wsłuchujemy się w terminologie klienta i to jej używamy w naszej codziennej pracy. Dbamy o to by nasz kod był spójny z postrzeganiem klienta, skupiał się na jego biznesie, a nie na technologii, której używamy.

To, co się dzieje pod spodem to nauka różnych mentalnych modeli i kategorii klienta. Widzimy jego odwzorowania i prototypy. Mamy odniesienia i nawiązania, które są bliskie światu, w którym na co dzień się porusza. Uczymy się komunikować z poszczególnymi klientami tak, jak to jest potrzebne, by mówić językiem mu bliskim.

Jest to trudne, bo jednocześnie trzeba się nauczyć korzystać z 2 typów kategorii – abstrakcyjnych i tych biznesowych. Dlatego bardzo często programiści pomijają ten aspekt, skupiając się jedynie na technikaliach. Jednak bez nauki języka nie da się zrozumieć, w jaki sposób klient postrzega swój biznes.

Podsumowanie

Powodem, dla którego warto stosować Ubiquitous Language jest większe skoncentrowanie się na potrzebach klienta, ich odwzorowanie w naszej aplikacji i w naszych modelach mentalnych. Będziemy mogli szybciej zrozumieć to, o czym klient mówi, co ma na myśli i proponować mu bardziej dopasowane rozwiązania.

Bardzo dobry przykład zysków z takiej współpracy pokazuje Wojtek Seliga w swojej prezentacji Plantacje programistów. Chcąc być bliżej klienta, być dla niego partnerem a nie podwykonawcą, potrzebujemy dobrze poznać jego potrzeby. Nie możemy tego zrobić bez posługiwania się jego językiem.