Z systemu obsługi zgłoszeń wyskakuje zlecenie. Dodać nową funkcję, domalować jakiś ekran a może tylko przestawić coś na istniejącym, dostukać jeszcze jeden raport, dorobić interfejs…

Stukotu-stuk, klikotu-klik, czasem łatwo i szybko, czasem z komplikacjami i trudnościami, odpowiedni kod się pojawia. Wpada w kanały dystrybucyjne i znika z pola widzenia.

Oddzielony od użytkowników

Organizacja pracy typowo stosowana przez poważny biznes generuje między faktycznymi użytkownikami kodu a programistami, którzy go tworzą, całe serie procesów, pośredników, dokumentów, opóźnień… Barier.

Tych barier potrafi być zadziwiająco wiele.

Powiedzmy – klienci regularnie mają problem z jakąś operacją i dzwonią po pomoc do call-centre. Po pewnym czasie tamtejszy kierownik zauważa nawracający problem i robi notatkę. Tuła się ona dłużej lub krócej, aż w końcu trafi do kogoś władnego zamówić zmianę. Ten kieruje ją w dół w celu opracowania specyfikacji (tu proces może fantazyjnie obiegać różne potencjalnie zainteresowane działy i osoby, zahaczać o agencję interaktywną lub podobnego podwykonawcę itp.) a następnie przerzuca do działu zamówień, który zleca jej wykonanie. Następują jakieś negocjacje cenowe (jeśli mamy granicę między firmami) albo organizacyjne (jeśli programiści są działem w firmie), jakiś analityk, jakiś kierownik, harmonogramy i już, już - sprawa trafia do programisty.

Ten najczęściej nie wie kto i dlaczego sobie danej zmiany zażyczył, komu i w czym ma ona pomóc i jaki będzie scenariusz jej wykorzystania. Koduje jak umie, oddaje kod i - o ile w późniejszych testach nie zostaną wykryte grube błędy - zapomina o sprawie.

A kod wędruje z powrotem. Zebranie pakietu zmian, przygotowanie dystrybucji, wewnętrzne testy techniczne, przekazanie kodu do zamawiającego, testy odbiorcze, różnorakie akceptacje i decyzje. Wreszcie, po rozmaitych przygodach (i - o ile sprawa nie była szczególnie pilna - czasie liczonym w miesiącach), rozwiązanie trafia na produkcję i zostaje zderzone z faktycznymi użytkownikami. Ich ewentualne uwagi trafiają do obsługi klienta, jeśli coś jest nie tak, wcześniej czy później ktoś zrobi notatkę…

Tak, człowiek który coś koduje, może nie mieć pojęcia ani po co to robi, ani jak to co zrobił jest odbierane przez użytkowników. I często trudno go za to winić.

Ach,zapomniałem przedstawiając powyższy proces, że firma otrzymująca zlecenie może nie realizować go bezpośrednio ale przekazywać do podwykonawcy. To dodaje kilka kolejnych kroków…

Oddzielony od produkcyjnej instalacji

Mniej znana, a równie szczelna bariera, dotyczy technicznego realnego świata. Jakie obciążenie generuje aplikacja. Jak wyglądają prawdziwe produkcyjne logi, jaki mają rozmiar i jak trudno coś w nich znaleźć. Ile sesji maksymalnie dajemy radę obsłużyć i kiedy to największe obciążenie ma miejsce. Ile mamy maszyn, ile kopii poszczególnych komponentów, jak są skonfigurowane bazy danych a jak middleware. Która funkcja potrafi działać bardzo wolno. Który komponent jest zwykle wąskim gardłem. Które awarie mają najgroźniejsze konsekwencje i jakie były przyczyny tej niedawnej. Itd itp…

Cała ta wiedza jest domeną zespołu utrzymaniowego, administrującego instalacją produkcyjną.

Jak wygląda kontakt w tej sytuacji? Cóż, programista oddaje kod, po pewnym czasie ktoś buduje nową wersję systemu agregującą paczkę zmian, odbywają się techniczne testy przeddystrybucyjne, rzecz zostaje przekazana do zamawiającego. Tam trafia na środowisko testowe, kontrola jakości testuje zgodność ze specyfikacją, opiekun produktu decyduje o terminie uruchomienia, rzecz trafia na środowisko przedprodukcyjne, po nim wreszcie na produkcyjne i wreszcie zderza się z rzeczywistym obciążeniem i rzeczywistymi problemami. O ile nie ma jakichś katastrofalnych błędów technicznych, dzieje się to daleko poza polem widzenia autora.

Przy tym administratorzy przeklinają kretynów-programistów nie potrafiących zrobić przydatnych logów, pozwalających konfigurować sto nonsensownych parametrów ale nie dających szansy manipulacji trzema najważniejszymi i piszących kod pożerający osiemdziesiąt nowych połączeń bazodanowych na godzinę. Programiści dla odmiany są wściekli na baranów-administratorów nie umiejących dostarczyć jakiejkolwiek sensownej diagnostyki zgłaszanych błędów, robiących afery z drobiazgów i na okrągło utrudniających wgrywanie aktualizacji. Obie strony zaś nie mają ze sobą praktycznie żadnego kontaktu.

Łączy je tylko zdziwienie, że po informacje o wydajności systemu i jego profilu wydajnościowym, „biznes” często zgłasza się do programistów.

Nie mający nic do powiedzenia

Czasem w czasie łomotania w klawiaturę u programisty budzą się wątpliwości. Przecież tekst, który mam wpisać, jest zupełnie niezrozumiały. Przecież ten formularz jest koszmarem. Przecież ta funkcja nie ma szans działać z sensem. Przecież te przypomnienia będą dla każdego kto korzysta z aplikacji częściej niż raz na miesiąc potwornie irytujące. Przecież ten sposób prezentacji danych będzie katastrofalnie obciążał system…

Gdy próbuje coś z problemem zrobić, słyszy o trudnościach obiektywnych. Specyfikacja jest uzgodniona i nie można od niej odstąpić, nawet jeśli dałoby się od niej odejść, nie stać nas na dodatkowe koszty, a poza tym i tak termin dostawy już prawie upłynął.

Jeśli się uprze i przebije trochę dalej, ma szansę usłyszeć któreś z oklepanych zdań o nerdach-programistach, nie rozumiejących użytkowników ani potrzeb biznesu.

„Biznes” też bywa odizolowany

Odseparowanie od świata rzeczywistego wcale nie dotyczy tylko programistów. Szeroko rozumiany „biznes” bywa odcięty nie mniej skutecznie.

Bardzo mi zapadło w pamięć pewne spotkanie sprzed lat. Osoby z marketingu mające promować usługę i planować jej rozwój i dwóch nerdów-programistów mających oceniać techniczną wykonalność pomysłów. I rozmowa układająca się jakoś dziwnie. Ekscytacja produktem konkurencji, który był gorszą i późniejszą kopią czegoś, co od dawna mieliśmy, dywagacje o problemach które naszego systemu nie dotyczyły, ogólniki…

W końcu spytałem wprost. Okazało się, że nasi rozmówcy nie używają własnego produktu jako klienci a wiedzę o nim mają bardzo gazetową. No i programiści-podwykonawcy poopowiadali opiekunom produktu o tym, co właściwie posiadają.

To anegdotyczna i jednak specyficzna sytuacja. Bardziej powszechna, zwłaszcza w kontaktach z pracownikami korporacji, jest wąska specjalizacja. Ktoś mający ogromną wiedzę o - powiedzmy - funduszach inwestycyjnych może tylko zgrubnie orientować się, jak właściwie wygląda interfejs przez który są sprzedawane, a już zupełnie nie mieć pojęcia o tym jak wygląda proces zakładania konta albo składania reklamacji.

Jak sobie radzić - indywidualnie

Mam głębokie przekonanie, że warto próbować się przez te mury przebijać. Choćby po to, by rozumieć, co i po co właściwie robię. No i - nawet w najbardziej toksycznie sformalizowanym procesie pojawiają się rozmaite możliwości, z których można skorzystać, by uczynić produkt trochę lepszym. O ile wie się o jego użytkownikach dość, by mieć na to pomysł.

Jak przerzucić pomost?

Być klientem

Nie ma lepszego sposobu na zorientowanie się, jak funkcjonuje aplikacja, niż używanie jej samemu – nie testowo ale naprawdę, w prawdziwych celach i bez developerskich furtek. Rzucą się w oczy i kłopotliwe cechy interfejsu, i nieoczekiwane błędy, i problemy wydajnościowe, i sytuacje bez wyjścia, i absurdalne spiętrzenia komunikatów, i trudne do kliknięcia linki… Używanie samemu jest też najlepszą metodą na poszukiwanie drobnych usprawnień (jeśli dobrze pamiętam, np. pomysł linku „Wykonaj płatność jeszcze raz” urodził się nad fakturą za prąd, pomysł przelewu 3xZUS przy jego realizacji, dbałość o nazwę sklepu w powiadomieniu o autoryzacji karcianej wprost wynikła z wątpliwości dotyczących obciążeń na karcie autora pomysłu…).

No ale przecież to dla zupełnie innych użytkowników. Owszem - tak bywa, oprogramowania elektrowni atomowej jako użytkownik nie przetestuję. Tyle że w Polsce nie ma elektrowni atomowych. A naprawdę nie ma powodu, dla którego autor sklepu internetowego nie mógłby od czasu do czasu zrobić w nim zakupów, programista bankowego interfejsu - założyć konta w tym właśnie banku i używać go do comiesięcznych płatności albo projektant aplikacji do kupowania biletów przez komórkę - raz w tygodniu zamiast autem pojechać do pracy autobusem opłaconym przy jej pomocy.

Programiści są przecież niereprezentatywni, ludzie pracują inaczej. Po pierwsze - ta różnica wcale nie zawsze jest wielka, kupując ubezpieczenie potrafię czuć się nie mniej zagubiony, niż znajomy humanista. Po drugie - to jest argument za tym, by programiści nie byli jedynymi testerami a nie za tym, by nimi nie byli w ogóle. Problemy, które zauważą, są prawdziwe (naprawdę niewiele jest spraw które bolą wyłącznie informatyków a zwykłym użytkownikom nie szkodzą).

A poza wszystkim… Jeśli pracowałem serio, jeśli czuję jakąś dumę z tego co zrobiłem, powinienem z tego korzystać. Używanie konkurencji byłoby nielogiczne!

Obserwować gdzie się da

Druga banalna metoda: warto skorzystać z każdej okazji podejrzenia, jak sobie radzą normalni użytkownicy. Żona, ojciec, brat, synowa, kolega… Mało co potrafi tak otrzeźwić, jak obserwowanie, jak ktoś męczy się i gubi w naszym wspaniałym interfejsie (a każda obserwacja osoby robiącej coś naprawdę jest więcej warta niż obserwowanie testowego scenariusza).

Zamiast dalszej argumentacji - przykład. Porządkując ostatnio stare zgłoszenia, trafiłem na notatkę, którą zrobiłem w 2008 roku.

(..) dziś przypadkiem obserwowałem krewnego (ciut po 60-ce, bez wiedzy technicznej ale biegle i od dawna używający komputera w zastosowaniach biurowych i w ramach swojego hobby, słaby wzrok i okulary, przyzwoity komputer i monitor LCD, IE7) używającego iPKO (którego używa od mniej więcej roku).
1) Przy robieniu przelewu bardzo narzekał na zbyt niewyraźne pola. Jeśli dobrze zrozumiałem, chodziło mu głównie o bardzo delikatnie zarysowane brzegi pól edycyjnych (nawigował częściowo myszą, klikając w pole które chciał edytować, i miał kłopot z trafieniem w pole bo nie widział, gdzie dokładnie ono jest), w dalszej mierze o za małą czcionkę.
2) Irytował się wpisując tytuł przelewu. Na ekranie jest pozornie bardzo szerokie pole edycyjne, które można wypełnić mniej więcej do połowy (bo potem wpada ograniczenie 35 znaków). Denerwował się, że pole wygląda na szerokie, a nagle w połowie nie może już pisać (naprawdę jest taki efekt, przy typowym tekście 35 znaków wypada ciut za połową szerokości pola), denerwowało go też, że nie może po prostu wpisać całego tytułu. Wspominał też (choć tym razem tego nie robił), że nie daje się wkleić tytułu skopiowanego z PDFa.
3) Dość bezproblemowo poradził sobie za to z poprawieniem błędnego numeru rachunku, acz zlokalizowanie pola z błędem zajęło mu ok. 10 sekund (znowu, mały kontrast). Sprawnie wpisał kod jednorazowy, zatwierdził formularz i zadowolony wydrukował sobie potwierdzenie PDF (chwaląc system za jego dostępność).
4) Ponieważ zużył 39-y kod, postanowił aktywować nową kartę kodów. Przez około 5 minut (serio!) poszukiwał, gdzie mogą się znajdować funkcje dotyczące kart kodów. Zaczął od menu "Karty", którego lewe menu szczegółowo przeklikał, nastepnie próbował chaotycznie klikać różne linki. Po tych 5 minutach miałem dosyć i podpowiedziałem, że musi użyć menu Dostęp. Nawet wtedy miał kłopot z jego znalezieniem (rozglądał się głównie po lewym menu i po lewych pozycjach górnego menu). Przy tym to nie był jego pierwszy raz, mówił że "aktywacja kart kodów to jest zawsze koszmar".
5) Po wejściu do "Dostępu" od razu zauważył, że jest tam napis o kartach kodów ale mimo to znowu stracił sporo czasu szukając gdzie może być ta aktywacja. Klikał Zamówienie kart, Karty zamówione, dopiero na moją wyraźną sugestię kliknął "Karty nieaktywne", które mu się wyraźnie nijak nie kojarzyły z tym, co miał zrobić.
6) Gdy już kliknął "Karty nieaktywne", natychmiast zauważył link Aktywuj i go kliknął. Na ile mogę ocenić, w ogóle nie spojrzał na prezentowany numer karty.
7) I tu nastąpił końcowy dramat. Wpisał kod nr 40 i kliknął Wykonaj. Dostał błąd, że nie wypełnił kodu nr 1. Znalazł to, wpisał kod nr 1, nacisnął Wykonaj. Dostał błąd, że nie wypełnił kodu nr 40. Wpisał go i nacisnął Wykonaj. Dostał błąd, że nie wypełnił kodu nr 1. Powtórzył tą sekwencję łącznie - liczyłem - 9 razy, pod koniec wpadając w wyraźną desperację. Zlitowałem się i wytłumaczyłem, że choć podświetlane jest tylko jedno, to musi wpisać oba pola. Jeszcze raz się pomylił wpisując tylko pierwsze, stwierdził "aha", wpisał oba, zatwierdził i z wielką ulgą wylogował się.

Nawet jedno takie doświadczenie całkowicie zmienia kształt dyskusji o wielkości czcionek, przydatności PDFowego potwierdzenia albo o tym, czy przy ponownym wyświetleniu strony należy przywracać poprzednie wartości pól także w przypadku kodów i haseł.

Inna sprawa, że akurat z tej notatki niewiele wynikło.

Komunikować się

Rozmawiać, słuchać, czytać, pisać, opowiadać o swoim i być ciekawym cudzego. Dyskusje przy kawie albo obiedzie mogą być niezbędnym smarem usprawniającym rozwój firmy a ploteczki przed spotkaniem potrafią być bardziej wartościowe niż ono samo.

Te miękkie techniki są dla dla wielu informatyków (dla mnie także) trudne ale warto próbować.

Są tu też sztywniejsze możliwości. Testując aplikację nie ograniczać się do własnego ekranu, odwiedzać też inne i zgłaszać zauważone błędy (a przy okazji zyskiwać wiedzę, co w tej aplikacji jest). Zerkać choć trochę na cudzy kod. Interesować się jakie zadania dostają inne osoby w projekcie.

Lubię czasem zrobić po systemie obsługi błędów zapytanie jakie zgłoszenia pojawiły się w zeszłym tygodniu i popatrzeć co się w niektórych z nich dzieje.

Czy warto rozmawiać z programistą?

Nastawienie „biznesu” do programistów bywa jakąś hybrydą lekceważącego pobłażania i … obawy. Jedno i drugie prowokuje do redukowania komunikacji i chowania się za formalizmami.

Tak, mówimy slangiem. Tak, potrafimy bagatelizować trudności jakie mają ludzie nietechniczni. Tak, podważamy autorytety, łatwo się irytujemy, bywamy trudni w kontaktach. Tak, nie lubimy krawatów, zebrań ani sztywnych hierarchii. Tak, potrafimy się upierać przy swoim zdaniu. Tak, bywa że nie mamy racji.

Zarazem jednak, jak mało kto, jesteśmy wyczuleni na drobiazgi, umiemy zauważać konsekwencje pozornie niewinnych decyzji, miewamy nowe pomysły, mamy odwagę wychodzić poza powtarzalne szablony, chętnie się uczymy. No i wreszcie – potrafimy proponować techniczne rozwiązania w miejscach, w których możliwość ich istnienia nie jest oczywista.

Mamy czasem dobre pomysły a czasem złe. Można nas przekonać a rzeczowa argumentacja potrafi zyskać nasz szacunek i późniejsze zaangażowanie.

A jeśli nasze wątpliwości, pytania czy propozycje są ignorowane albo utrącane, jest to zwykle zły znak. W końcu nadejdą prawdziwi użytkownicy. Ich zarówno milczenie, jak argument „nie znacie się, to nie wasza sprawa” - jedynie rozjuszy.

Dwa cytaty (zamiast podsumowania)

W czytanej niedawno książce znalazłem wspomnienie z wdrożenia nowego systemu wspomagania sprzedaży w sporej amerykańskiej firmie. Jako że system wiele zmieniał, nie wprowadzano go wszędzie naraz ale po kolei, w poszczególnych placówkach. A pojedyncze wdrożenie wyglądało tak:

Zespół złożony z instruktorów i programistów jechał osobiście odwiedzić wybrane biuro. (…) Zaczynaliśmy zwykle we wtorek po południu. W ciągu 90 minutowej sesji przedstawialiśmy system, pomagaliśmy wszystkim się zalogować i - jako grupa - przerabialiśmy najważniejsze operacje. Staraliśmy się przy tym pokazać, w jaki sposób system ułatwia im pracę (…); wyjaśnialiśmy, jak projekt wynikał z obserwacji ich działań. (…) Po pokazie zapraszaliśmy sprzedawców do eleganckiej restauracji – takiej, do której oni sami zaprosiliby najlepszych klientów – dając szansę, by poznali programistów i mogli z nimi porozmawiać.

Cały następny dzień spędzaliśmy ze sprzedawcami – obserwując, słuchając i udzielając pomocy w razie potrzeby. Programiści nosili słuchawki które podpinali do gniazdek sprzedawców, dzięki czemu mogli podsłuchiwać rozmowy prowadzone przez nich z klientami, zarazem obserwując, jak używają oni aplikacji. Była w tym pewna gra: każdy programista miał robić notatki i zapisać 10 możliwych ulepszeń, zwłaszcza proponowanych przez użytkowników. Mogły być duże lub małe, nie miało to znaczenia. (…)

Co kilka tygodni publikowaliśmy nową wersję z poprawkami i rozszerzeniami. Sprzedawca, który wymyślił wprowadzone ulepszenie, odbierał osobisty telefon od programisty, który je zaimplementował. Tworzyło to więź między tymi zwykle zupełnie oddzielonymi od siebie i niesłychanie różnymi grupami (…) i nadawało dużą dynamikę współpracy. (…) Osoby które widziały że ich pomysły są wprowadzane w życie, stawały się aktywnymi promotorami systemu.

Programista implementujący zmianę dzwoniący do użytkownika, który ją zaproponował…

I jeszcze inny cytat, z wywiadu o Amazonie:

Każda usługa ma swój zespół i ten zespół jest całkowicie za nią odpowiedzialny – od zdefiniowania funkcjonalności, przez zaprojektowanie i zbudowanie, po uruchomienie i utrzymanie.

(…) Przydzielenie programistom obowiązków administracyjnych znacznie poprawiło jakość, zarówno z punktu widzenia klientów, jak pod względem technologicznym. W tradycyjnym modelu programiści dostarczają swój kod do „ściany” stojącej między nimi a produkcją, przerzucają go nad nią i zapominają o nim. Nie w Amazonie. Skoro ty budujesz kod, to ty go uruchamiasz. W ten sposób programiści mają stały kontakt z codziennym działaniem kodu który tworzą. Mają też stały kontakt z klientami. Informacje od klientów są niezbędne dla podnoszenia jakości.

System gniazdowy zamiast taśmy.