Pytanie nie jest łatwe – bo po co nam w ogóle programiści w trakcie projektowania architektury informacji, makiet lub funkcjonalności jakiegoś systemu? W tym procesie nie ma kodowania, kompilowania tylko rysowanie tymczasowników i składanie ekranów w całość. Jak już mają się lenić to niech lepiej to robią w czymś co należy do ich codziennych obowiązków.
Na to pytanie nie ma też precyzyjnej odpowiedzi, bo o jaki projekt AI chodzi? – prosta strona web, duża aplikacja stand alone czy może system transakcyjny banku? Jest jednak pewien klucz, którym jak zauważyłem od niedawna zaczęły kierować się zespoły projektujące AI – przynajmniej te, w sąsiedztwie których znajduje się zespół programistów.
Co najmniej jeden
Na pierwszym polskim zjeździe Architektów Informacji Polish IA Summit, kilka miesięcy temu, w jednym z paneli dyskusyjnych zadałem podobne pytanie światowej sławie architektom informacji (Eric Reiss, James Kalbach, Andrea Resmini, Carsten Schmitt, Wojciech Kuśmierek). Wszyscy jednym głosem potwierdzali:
„zawsze, do każdego projektu AI wciągamy co najmniej jednego programistę”.
Ale dlaczego?
Na to pytanie goście polish IASummit również odpowiadali podobnie.
- Ma świeże techniczne spojrzenie na projekt,
- W jednej chwili powie nam co jest technologicznie osiągalne w danym budżecie a co będzie wymagało większych zasobów,
- Niczym wilk na polowaniu momentalnie zauważy wszystkie przypadki użycia, których projekt nie obsługuje i jak hiena będzie się nad nimi (nami) pastwił.
„A jak ten projekt zareaguje gdy użytkownik doda 200 przyjaciół a nie czterech??? Hmmm…. No…. Nie wiem…. faktycznie…. nie pomyślałem o tym. Myślisz, że doda?”.
To pytanie zadałem nie bez kozery. Od lat zastanawiało mnie czy to tylko firma, w której mam przyjemność pracować – jest taka pro, że stosuje strategię współpracy projektantów i programistów we wszystkich swoich projektach, czy może inne firmy/specjaliści AI na świecie też zauważyły korzyści z wzajemnej współpracy?
Nie można jednak od tak po prostu wpuścić programisty do zespołu AI, nieumiejętne posługiwanie się programistą grozi poważnym uszczerbkiem na zdrowiu psychicznym.
Ustal zasady współpracy (sam ze sobą)
Jeśli już zdecydujesz się na ten krok – to warto przyjąć pewne zasady wzajemnej współpracy (np. obiecaj sobie, że nie będziesz agresywny):
- Nie wciągaj programisty na cały etat w projektowanie – będzie się nudził i w efekcie wymyśli takie funkcjonalności, o których nie śniłeś a będziesz musiał je narysować – nie chcesz tego.
- Pozwól mu zaopiniować projekt na tyle wcześnie, przed oddaniem do klienta aby starczyło Ci czasu na uspokojenie się i wprowadzenie części zmian. Zalety opiniowania są dwie: 1. dostaniesz solidny feedback od umysłu ścisłego, 2. sprawisz, że programista poczuje się doceniony. Wada jest jedna – będziesz miał jeszcze trochę pracy.
- Wybierz programistę, który jest komunikatywny i asertywny (to jeden z najtrudniejszych punktów)
- Nie pytaj go: „Co sądzisz o tym projekcie?” – on ma ciekawsze rzeczy do roboty stąd osąd pewnie będzie brzmiał „jest ok”. Daj mu zadanie: „Stary, zobacz, zrobiłem tu taki projekt – czy mógłbyś mi pomóc i wskazać rzeczy, których w nim brakuje?” albo (to jest ryzykowne) „gdybyś miał to wdrażać to jakie byś miał do mnie pytania?”.
- Staraj się nie pytać o opinię programisty, który będzie zajmować się w przyszłości wdrożeniem tego projektu – dzięki temu możesz liczyć na jego kreatywność i nowe pomysły. Świadomość, że ma się to coś wdrażać, a co gorsza jeszcze znajomość czasu tego wdrożenia mocno zmieni jego opinię na temat niektórych funkcjonalności, z których jesteś taki dumny.
- Nie rób z nim warsztatów – chyba, że masz moce nerwy, dystans i dużo samokrytyki. Wprowadź go w projekt, krótką rozmową a potem uciekaj i daj mu trochę czasu na krwawą ucztę.
- Nie tłumacz się programiście, że coś tam jest jeszcze nie dorobione i żeby nie zwracał na to uwagi – to jest człowiek dwustanowy – albo coś działa albo nie działa – pozwól mu na swobodę. Sam sobie potem oddzielisz i poukładasz jego uwagi.
- Jak już skończy (bóg jeden wie ile może to potrwać – zazwyczaj kilka minut) warto omówić z nim jego notatki, mocno ciągnąc za język w kwestiach takich jak: sensowność niektórych rozwiązań, wady, zalety i możliwe alternatywy technologiczne itp…
Druga strona medalu
Zalety współpracy projektantów i programistów dla projektu i dla klienta na etapie projektowania AI widać jak na dłoni (nie tej zwiniętej w pięść – tylko tej otwartej): projekt jest bardziej spójny, lepszej jakości, przystaje do rzeczywistości i ma więcej stron.
Jest jednak coś czego warto być świadomym, a co dzieje się nieco później, niejako w następstwie etapu projektowania AI – czyli na etapie wdrożenia. I dopiero wtedy ujawniają się pełne zalety wzajemnej współpracy, bo nagle okazuje się że:
- Zespół programistów, którzy wdrażają projekt AI znajduje w nim odpowiedzi na większość swoich pytań (oszczędzamy im czas i nerwy).
- Projekt nie wraca do przeprojektowania do działu AI, jego wdrożenie jest realne a on sam przystaje do rzeczywistości (jak by wrócił na warsztat do działu AI to pół biedy – gorzej jakby musiał po drodze zahaczyć o klienta mówiąc mu, że ten trójwymiarowy pasek postępu to chyba nie był najlepszy pomysł – o zgrozo).
- Jeśli z jakiś niewyjaśnionych względów zespół programistów oponuje przed wdrożeniem którejś z funkcjonalności – trzymasz w ręku niezły argument – „przecież Wasz kolega z piętra wyżej powiedział, że to można z łatwością wykonać jako moduł szyfrujący AES do silnika skryptowego w technologii RC5.1”. „No tak… hmm… faktycznie – możemy to tak zrobić”.
o autorze:
Paweł Maciszewski – Od ponad 5 lat zajmuje się tematyką użyteczności od strony przeprowadzania wdrożeń zaprojektowanych systemów zarówno webowych jak i stand alone. Z wykształcenia informatyk, wiedzę zdobywał m.in. w trakcie studiów w Holandii i Polsce oraz pracy w jednostkach UE. Jego zainteresowania krążą w okół tematów takich jak: programowanie, bazy danych, serwery, zarządzanie projektami IT, płeć piękna w firmie, hodowla zwierząt futerkowych, ciemne piwo i świat dysku TP.
