Rozmawiając z nieinformatykami często napotykam na trudne do przezwyciężenia problemy pojęciowe i to w momentach, kiedy w ogóle bym się tego nie spodziewał. Ale pewnie znają je Państwo dobrze - nie chodzi bynajmniej o terminy (mogę się spodziewać, że nie wszyscy rozumieją słowa firewall, patch i codec), ale o pewne fundamentalne zagadnienia z ontologii i taksonomii informatyki.

Jednym z takich pojęć jest "reprezentacja". Niedawno próbowałem wytłumaczyć nieinformatykowi dlaczego dokument tekstowy przygotowany na platformie Windows nie może być od razu wykorzystany na platformie Unix. Powiedziałem zdanie w rodzaju: "reprezentacja znaków na obu platformach jest inna".

A potem popełniłem duży błąd, bo usiłowałem wyjaśnić znaczenie słów "znak" i "reprezentacja znaku" (a w szczególności różnicę między nimi). Zagmatwało to całkowicie w głowie mojego rozmówcy i musiałem się poddać - nie można i już.

Zwróćmy uwagę, że wyjaśnienie pojęcia "reprezentacji" w technologii cyfrowej wcale nie jest łatwe. Pozostańmy przy przykładzie znaku: literka "z" może być reprezentowana albo przez liczbę 122 (ASCII), albo przez sekwencję 122 i 0 (Unicode). Może jednak zostać potraktowany jako grafika i wtedy wchodzimy w reprezentacje grafiki - mapa bitowa, mapa z kompresją, krzywe Beziera, fraktale... możliwości jest wiele. Niby sprawa czysto techniczna, a jednak nie do końca, bo każda reprezentacja ma swoje konsekwencje biznesowe. Kiedyś musiałem bardzo długo wyjaśniać, że e-mail da się łatwo i tanio wysłać faksmodemem, za to przekształcenie faksu do e-maila tekstowego (nie zaś załączonego pliku graficznego) jest kłopotliwe i program, który to robi sprawnie, będzie musiał być bardzo drogi.

I tak doszliśmy do sedna problemu: jak ludziom, którzy nie rozumieją subtelności informatyki i nie chcą rozumieć, wyjaśnić je w sposób wystarczający, by zrozumieli ograniczenia wynikające z technologii? Wierzę, że przed tym wyzwaniem stają wszyscy informatycy - prędzej albo później, bardziej albo mniej, ale jednak wszyscy. Podobno jesteśmy jako grupa zawodowa uważani za niekomunikatywnych dziwaków. Pora więc podzielić się technikami, które pozwalają mimo wszystko skutecznie się porozumiewać.

Pierwszą z technik stosowaną przeze mnie na co dzień jest analogia. Porównuję budowę systemu do budowy domu, standardy informatyczne do ustaw, odwirusowanie systemu do wysprzątania mieszkania, Internet do telewizji i... jakoś się dogadujemy. Analogie są jednak tyle użyteczne co zdradliwe - pewnego razu musiałem "odkręcać" analogię między bazą danych a magazynem, bo w oparciu o nią nijak nie dało się wyjaśnić mechanizmu zapytań SQL z klauzulą where, a na dodatek mój klient był zaniepokojony, że będzie musiał płacić za każdy dostęp do danych ("pobranie towaru z półki").

Równie chętnie co analogię stosuję prostą wizualizację. Czasem zestaw paru opisanych kółek, prostokątów i strzałek między nimi wyjaśnia więcej niż cała opowieść. Mój znajomy z USA, informatyk z czterdziestoletnim stażem, zwykł mawiać, że podczas całej swojej kariery nie poznał lepszego narzędzia do analizy i projektowania systemów niż tablica i zestaw kolorowych pisaków.

Trzeci mechanizm komunikacyjny, bodaj najefektywniejszy, to mówienie do niespecjalistów o korzyściach, a nie o detalach. Mówię "zastosujemy tutaj architekturę trójwarstwową", po czym zaraz uzupełniam "...co pozwoli nam w przyszłości bardzo ograniczyć koszty koniecznych zmian oraz integracji z innymi systemami" - i potem nie muszę dodawać nic więcej. Język korzyści biznesowej rozumie każdy.

A Państwo jak sobie radzą?