Kategoria: Projektowanie

Jeszcze niedawno pokazanie dopracowanego, rozbudowanego prototypu było pewnego rodzaju demonstracją kompetencji i zagłębienia w zagadnienie.

Nie trzeba było specjalnie tłumaczyć, że ktoś poświęcił na nią czas. Było to widać. Oczywiście nie oznaczało to, że rozwiązanie jest dobre, ale przynajmniej mogliśmy zakładać, że ktoś nad nim pracował.

Dzisiaj to założenie zaczyna tracić sens.

Mogę w ciągu jednego popołudnia stworzyć interaktywny prototyp, który wcześniej wymagałby tygodni pracy. I kiedy pokazuję go innej osobie, pojawia się problem, którego wcześniej właściwie nie było.

Które elementy świadomie zaprojektował? Które zostały zaproponowane przez AI? A które po prostu zaakceptował, bo wyglądały całkiem rozsądnie?

Osoba oglądająca prototyp nie ma możliwości tego rozróżnić.

Może więc założyć, że wpisałem trzy zdania, zrobiłem sobie kawę i wróciłem po gotowy produkt.

Co zabawne, czasami rzeczywiście można tak pracować.

Zauważam jednak ciekawą zmianę podczas prezentowania własnych projektów. Coraz większe znaczenie ma nie to, co pokazuję, ale jak głęboko potrafię wyjaśnić poszczególne decyzje.

Dlaczego proces wygląda właśnie tak? Co stanie się w nietypowej sytuacji? Jakie ograniczenia uwzględniłem? Dlaczego zrezygnowałem z pewnych funkcjonalności?

Każda świadoma odpowiedź buduje zaufanie. Każde „tak zaproponowało AI” może je osłabiać, jeżeli nie potrafię wyjaśnić, dlaczego tę propozycję zaakceptowałem.

Jest w tym pewien paradoks.

Im mniej pracy wymaga ode mnie wykonanie projektu, tym więcej muszę ujawnić własnego myślenia, żeby inni mogli zaufać jego jakości.

Być może właśnie tutaj zaczyna się istota zmiany, jaka jest rola projektanta?

Nie muszę już osobiście tworzyć każdego elementu. Tak jak architekt nie musi układać cegieł, żeby odpowiadać za projekt budynku.

Ale muszę potrafić uzasadnić decyzje, rozumieć konsekwencje i zakwestionować rezultat, nawet jeśli wygląda doskonale.

Bo samo zaakceptowanie propozycji nie czyni mnie jeszcze jej świadomym autorem.

Przez lata budowaliśmy zaufanie, pokazując, co potrafimy zrobić. Teraz coraz częściej będziemy musieli pokazywać, dlaczego zdecydowaliśmy się zrobić właśnie to.

W świecie, w którym niemal każdy może stworzyć profesjonalnie wyglądające rozwiązanie, kompetencją staje się nie tyle umiejętność jego wytworzenia, ile zdolność wzięcia za nie świadomej odpowiedzialności i zrzucenie z innych wzięcia za nią odpowiedzialność.

Zaczynam mieć dziwne poczucie, że im więcej projektuję z Ai, tym mniej czasu spędzam na samym projektowaniu.

Kiedyś stworzenie rozbudowanej makiety wymagało wielu godzin pracy. Każdy ekran, interakcję czy zależność trzeba było zbudować, przemyśleć i poprawić.

Było to czasochłonne, momentami nudne i zapewne w dużej części zupełnie niepotrzebne ale miało jedną zaletę, którą zawsze doceniałem. Tworzenie było jednocześnie procesem rozumienia i synchronizowania tej wiedzy z innymi.

Kiedy budowałem kolejne elementy rozwiązania, siłą rzeczy musiałem zastanawiać się nad ich działaniem. W trakcie pracy odkrywałem zależności, których wcześniej nie przewidziałem. Zadawałem sobie pytania, które nie pojawiłyby się na etapie samego pomysłu, a inni korygowali mój kierunek tworząc nowe powiązania.

Dzisiaj coraz rzadziej buduję poszczególne elementy. Definiuję cel, kontroluję logikę, oceniam wynik. To, co wcześniej zajmowało kilka dni, potrafi powstać w kilkanaście minut. Nie muszę już ręcznie budować wszystkiego, co wymyśliłem.

Nareszcie!

Po latach przesuwania prostokątów, wyrównywania komponentów technologia wreszcie daje pole na logikę rozwiązania. Przecież czekałem na to tak długo…

Tylko że pojawia się pewien problem.

Rozwiązania zaczynają powstawać szybciej,
niż jesteśmy w stanie je wspólnie zrozumieć.

Coraz częściej patrzę na gotowy rezultat i zdaję sobie sprawę, że więcej czasu zajmuje mi przeanalizowanie wszystkich zależności, decyzji i konsekwencji, a następnie zbudowanie tego samego zrozumienia w zespole, niż zajęło mi stworzenie tego rozwiązania.

Rozumiem ogólny zamysł. W końcu to ja go zdefiniowałem. Rozumiem podstawowe procesy i wiem, jakie problemy chcę rozwiązać, ale niekoniecznie rozumiem już wszystkie szczegóły, zależności i konsekwencje.

AI potrafi zaproponować całe fragmenty rozwiązania, których nie opisałem wprost. Uzupełnia brakujące elementy, interpretuje intencje, tworzy własne założenia. Czasami bardzo trafne. Czasami zupełnie przypadkowe.

W efekcie dostaję coś, co wygląda na bardziej kompletne, niż jest w rzeczywistości, a ponieważ całość prezentuje się całkiem przekonująco, łatwo uznać, że skoro działa, to najwyraźniej wszystko jest w porządku.

Problem pogłębia się, kiedy takie rozwiązanie trafia do zespołu. Każdy widzi ten sam prototyp, ale niekoniecznie rozumie stojące za nim decyzje. To, co dla mnie jest oczywistym założeniem, dla programisty może być jedynie domysłem, a dla osoby odpowiedzialnej za biznes, zupełnie inną interpretacją.

Możemy patrzeć na ten sam prototyp,
a rozumieć / „widzieć” zupełnie inny produkt.

Przynajmniej do momentu, kiedy ktoś zada pierwsze naprawdę dobre pytanie.

W programowaniu od lat funkcjonuje pojęcie długu technologicznego. Możemy zbudować coś szybciej, korzystając z uproszczeń, za które później przyjdzie nam zapłacić.

Każde rozwiązanie, które powstało szybciej, niż zdążyłem je świadomie przeanalizować, może pozostawić po sobie pewną zaległość. Coś, czego jeszcze nie rozumiem. Decyzję, której konsekwencji nie sprawdziłem. Założenie, którego nawet nie zauważyłem.

Wszystko powstaje tak płynnie, że trudno znaleźć moment, w którym należałoby powiedzieć: stop, teraz muszę naprawdę zrozumieć, co właśnie stworzyliśmy. Zresztą po co się zatrzymywać, skoro możemy wygenerować kolejne pięć wariantów? W końcu produktywność rośnie. Liczba dostarczanych rozwiązań również. Tylko poziom naszego zrozumienia niekoniecznie nadąża za tym imponującym wykresem.

Przypomina mi się Solaris Stanisława Lema

Ludzkość bada tajemniczy ocean pokrywający odległą planetę. Powstają teorie, klasyfikacje, obserwacje i całe biblioteki opisujące jego zachowanie. Naukowcy wiedzą o nim coraz więcej. Potrafią nazywać zjawiska, opisywać struktury i dokumentować kolejne obserwacje, a mimo to fundamentalna natura oceanu pozostaje dla nich niezrozumiała.

W tej historii zawsze podobało mi się, jak Lem uchwycił przepaść pomiędzy zgromadzoną wiedzą, a prawdziwym poznaniem. Widać tu pewną analogię.

Możemy mieć coraz bardziej szczegółowe opisy naszych rozwiązań. Coraz więcej ekranów, dokumentacji, zależności, interakcji i scenariuszy działania. Możemy nawet poprosić AI, żeby wyjaśniło nam każdy fragment tego, co właśnie wygenerowało, ale opis nie jest jeszcze zrozumieniem.

Można wiedzieć bardzo dużo o tym, jak coś działa, i nadal nie rozumieć, dlaczego powinno działać właśnie w ten sposób.

Co więcej, samo wyjaśnienie wygenerowane przez AI może być równie przekonujące jak rozwiązanie, którego dotyczy.
Dostajemy więc opis, który tłumaczy wcześniejszy opis.
A jeśli nadal czegoś nie rozumiemy, możemy oczywiście poprosić o jeszcze dokładniejsze wyjaśnienie. Ocean Lema prawdopodobnie byłby zachwycony.

Przez lata staraliśmy się skracać czas potrzebny na przejście od pomysłu do gotowego rozwiązania. Budowaliśmy narzędzia, które miały uwolnić nas od powtarzalnych czynności. Automatyzowaliśmy procesy, rozwijaliśmy biblioteki komponentów, tworzyliśmy coraz lepsze środowiska projektowe. Wszystko po to, żeby mniej czasu poświęcać na wykonywanie, a więcej na myślenie.

Teraz wreszcie mamy narzędzia, które realizują tę obietnicę w stopniu, jakiego jeszcze niedawno trudno było sobie wyobrazić.

I co robimy z odzyskanym czasem?

Jednym z najważniejszych etapów pracy projektowej jest stworzenie, już na samym początku, wspólnego „obrazu świata” zagadnienia, nad którym pracujemy.
Obrazu, który wszyscy członkowie zespołu będą interpretować w możliwie podobny sposób.

Dlaczego to takie ważne?

Świetnie obrazuje to prosty eksperyment z klockami. Jedna osoba otrzymuje gotową konstrukcję, a następnie, siedząc plecami do pozostałych uczestników, musi wytłumaczyć im, jak ją odtworzyć. Nie może pokazać oryginału ani wskazać palcem żadnego elementu. Ma do dyspozycji wyłącznie słowa.

Pierwsza próba często kończy się niepowodzeniem albo trwa tak długo, że uczestnicy zaczynają tracić cierpliwość.

Problem nie polega na tym, że ludzie nie potrafią układać klocków. Problem polega na tym, że każdy może inaczej interpretować te same komunikaty.

Co oznacza „połóż klocek poziomo”? Względem czego? Która strona jest lewa, a która prawa? Co właściwie oznacza „nad”, „obok” albo „na środku”?

Zanim zaczniemy budować, musimy uzgodnić wspólny język, czyli definicje, zasady i punkty odniesienia.

Nie wystarczy mówić o tym samym.
Trzeba jeszcze wyobrażać sobie to samo.

Ten prosty eksperyment prowadzi nas do znacznie szerszego zagadnienia, którym od lat zajmują się badacze komunikacji.

Z perspektywy projektowania prowadzi nas to do bardzo praktycznego problemu.

Kiedy podczas spotkania rozmawiamy o „użytkowniku”, „procesie”, „produkcie” czy „systemie”, możemy posługiwać się dokładnie tymi samymi słowami, a mimo to wyobrażać sobie zupełnie inne rzeczy.

Każdy z nas interpretuje zagadnienie przez pryzmat własnej wiedzy, doświadczeń i przyjętych założeń.

Nie mamy bezpośredniego dostępu do wyobrażeń drugiego człowieka. Możemy jedynie próbować je zrozumieć poprzez komunikację.

I tutaj pojawia się rola diagramu.

Nie sprawi on, że nagle wszyscy zaczniemy myśleć identycznie. Pozwoli jednak uzewnętrznić nasze wyobrażenia i stworzyć wspólny punkt odniesienia, wokół którego możemy uzgadniać znaczenia.

Diagram jest więc nie tylko narzędziem wizualizacji informacji, ale również narzędziem komunikacji.

Nie przedstawia rzeczywistości w całej jej złożoności. Przedstawia pewien model rzeczywistości, który możemy wspólnie obserwować, kwestionować i rozwijać.

Od teorii do praktyki projektowej

Teraz przenieśmy te rozważania do pracy zespołu projektowego.

Jeżeli na wczesnym etapie nie stworzymy wspólnego diagramu zagadnienia, nad którym pracujemy, możemy przez wiele tygodni prowadzić rozmowy, opierając się niemal wyłącznie na komunikacji słownej. Każdy uczestnik będzie budował własny obraz rzeczywistości, interpretując te same pojęcia przez pryzmat swoich doświadczeń, wiedzy i założeń.

W efekcie ogromna część pracy zespołu sprowadzi się do wielogodzinnych dyskusji, których rzeczywistym celem będzie nie tyle rozwiązanie problemu, ile uzgodnienie, o czym właściwie rozmawiamy.

Wprowadzenie diagramu, nawet bardzo niedoskonałego, zasadniczo zmienia tę sytuację.

Zamiast kilku indywidualnych wyobrażeń otrzymujemy jeden wspólny punkt odniesienia. Nie musi być poprawny ani kompletny. Z pewnością będzie wymagał wielu korekt, uzupełnień i uzgodnień. Ale od tej chwili wszyscy możemy patrzeć na to samo, wskazywać konkretne elementy, kwestionować zależności i wspólnie poprawiać model.

Diagram nie musi przedstawiać prawdy. Musi pozwalać nam wspólnie do niej dochodzić.

To właśnie jedna z najważniejszych funkcji wizualizacji w projektowaniu. Redukcja złożoności poprzez stworzenie wspólnego obrazu rzeczywistości.

Mechanizm pozornie oczywisty, a jednak zaskakująco często pomijany w codziennej pracy projektowej.

Ważne, aby pierwszy diagram nie próbował wyjaśniać wszystkiego.

Powinniśmy zacząć od perspektywy ogólnej Helicopter View. Pokazać najważniejsze obiekty, relacje i granice systemu. Tyle, ile potrzeba, aby uczestnicy mogli szybko zrozumieć przedstawiony model i skonfrontować go z własnym wyobrażeniem zagadnienia.

To już samo w sobie jest trudnym zadaniem.

Dopiero kiedy uda nam się uzgodnić ogólny obraz, możemy stopniowo zagłębiać się w szczegóły, czyli tzw. Deeper View.

Najpierw wspólne rozumienie całości. Potem analiza poszczególnych elementów.

Czy wiemy, z czego składa się nauka?

Wyobraźmy sobie, że chcemy zaprojektować nowy sposób nauki języka obcego.

Od czego zaczniemy?

Możemy od razu dyskutować o metodach nauczania, ćwiczeniach, aplikacjach czy wykorzystaniu sztucznej inteligencji. Każdy uczestnik projektu będzie miał własne doświadczenia i przekonania dotyczące tego, jak najlepiej uczyć się języka.

Ale zanim zaczniemy projektować rozwiązanie, warto zadać znacznie prostsze pytanie:

Z czego właściwie składa się zagadnienie, którym chcemy się zająć?

To pytanie stało się punktem wyjścia do diagramu, który przygotowałem wspólnie z Sistalks na potrzeby nauki języka angielskiego.

Zamiast rozpoczynać od kolejnych lekcji, reguł gramatycznych i pojedynczych zagadnień, spróbowaliśmy najpierw zobaczyć całość.

Jakie obszary tworzą język? Jakie są pomiędzy nimi zależności? Co musimy zrozumieć wcześniej, a czym możemy zająć się później? Jak uporządkować tak rozległą dziedzinę, żeby nie zgubić się w szczegółach?

Powstała mapa obszarów języka angielskiego.

Nie jest kompletna. Nie jest też jedynym właściwym sposobem przedstawienia tej dziedziny. Cały czas ją rozwijamy, uzupełniamy i korygujemy.

Ale spełnia swoje podstawowe zadanie, pozwala nam wszystkim odwoływać się do tego samego obrazu zagadnienia.

Dopiero na jego podstawie możemy sensownie rozmawiać o tym, jak zaprojektować proces nauki, jakie elementy są najważniejsze i w jaki sposób powinny być ze sobą powiązane.

Co ciekawe, taka mapa może być równie wartościowa dla osoby, która chce się języka nauczyć.

Zamiast przemierzać kolejne lekcje bez świadomości tego, gdzie właściwie znajduje się w całym procesie, otrzymuje obraz dziedziny, którą próbuje opanować.

Może zobaczyć, co już zna, czego jeszcze nie rozumie i jakie obszary pozostają do odkrycia.

Ten sam diagram staje się więc zarówno narzędziem projektowym, jak i narzędziem poznawczym.

Najpierw zobaczmy całość

Ten sposób myślenia można zastosować niemal wszędzie.

Projektując usługę, możemy zacząć od mapy jej uczestników i zależności. Projektując organizację, od obrazu procesów, odpowiedzialności i przepływu informacji. Próbując zrozumieć nową dziedzinę, od mapy jej najważniejszych pojęć.

Nie chodzi o stworzenie idealnego diagramu. Chodzi o stworzenie pierwszego diagramu, który będziemy mogli wspólnie kwestionować i poprawiać.

Zanim zaczniemy rozwiązywać problem, spróbujmy wspólnie zobaczyć świat, w którym ten problem istnieje.

Nie dlatego, że diagram da nam wszystkie odpowiedzi.

Ale dlatego, że bez wspólnego obrazu możemy przez długi czas udzielać różnych odpowiedzi na pytania, których nigdy tak naprawdę wspólnie nie uzgodniliśmy.