Każdy z nas w jakimś stopniu bierze udział w procesie tworzenia danego systemu czy aplikacji. Jak często jednak zastanawiamy się nad tym sensem istnienia tych produktów i tego, czy spełniają oczekiwania odbiorców. O traktowaniu IT za… logicznie rozmawiamy z Patrykiem Wychowańcem, Rust Tech Lead w Anixe.
#top_oferta: Product Manager
Porozmawiajmy o empatii w IT. Dlaczego powinniśmy bardziej wierzyć naszym uczuciom, a nie założeniom, iż nasze produkty cyfrowe mają być bardzo proste w obsłudze?
Oprogramowanie tworzą ludzie dla ludzi – niby nie brzmi to odkrywczo, a jednak nie trzeba spojrzeć daleko, by znaleźć aplikacje, których obsługa przyprawia nas o ból głowy.
Aplikacje, które są nieintuicyjne; powolne; takie, które wywołują niepohamowaną frustrację na samą myśl o konieczności korzystania z nich. Na pewno każdy, kto miał przyjemność używać komputera, miał też przyjemność zetknąć się z niejednym takim programem.
I tak o ile w przypadku aplikacji poza naszym zasięgiem wpływu pozostaje nam głównie narzekanie (bardzo bym chciał, aby okienka z Messengera na Facebooku nie scrollowały mi się losowo w górę!), o tyle – odnosząc się do programistów/-tek – jest wiele rzeczy, na które wpływ już mamy.
Ok, co tak naprawdę mogą zrobić programiści w takiej sytuacji?
Pracujesz nad aplikacją, która jest wolna? Poświęć chwilę na namierzenie problemu, może akurat strzelisz w dziesiątkę.
Uważasz, iż coś jest nieczytelne lub krzywe, iż coś można opisać w lepszy sposób niż przedstawia zadanie czy mockup? Pogadaj z UX designerem/-ką, zdecydowana większość ucieszy się z ekstra feedbacku.
Wydaje mi się, iż powiązanym tutaj problemem często trawiącym głównie te większe firmy jest przesadne trzymanie się przez deweloperów/-ek reguł oraz ceremonii (np. tych dotyczących sprintu) – ale zanim ktoś dokona ekstrapolacji, spróbuję to pokazać na przykładzie:
W trakcie pracy nad zadaniem dotyczącym formularza X Jan zauważa, iż w formularzu Y przycisk jest krzywo. Jan prosi PM/-kę o założenie zadania na następny sprint o poprawę przycisku.
Brzmi niewinnie, może choćby znajomo – a dla mnie stanowi przerost formy nad treścią.
Jeśli sama poprawa formularza zajęłaby nam trzy minuty pracy, ale już założenie zadania, jego wycena i zakolejkowanie w sprincie zajmą w sumie trzydzieści (licząc pracę wszystkich zaangażowanych osób), to nie dość, iż siłą rzeczy zrobimy takich drobnych usprawnień mniej, to jeszcze często nie będzie nam się chciało ich w ogóle raportować – a bo trzeba spełnić definition of ready, a bo trzeba wybrać testera, i tak dalej.
Oczywiście reguły oraz procesy istnieją z pewnych przyczyn. Nie sugeruję, iż mamy porywać się z motyką na słońce i próbować w ramach jednodniowego szybkiego zadania zmieniać pół systemu, nie.
Ale pewne drobne rzeczy, te kamyczki w naszych butach – je powinniśmy starać się wyciągać, dla dobra zarówno naszego, jak i naszych użytkowników.
Zawsze staram się pokazać dwie strony. Nie uważasz, iż problem nie leży w pracownikach, a w managemencie? On też powinien zmienić podejście?
Oj, trudne pytanie się wylosowało – to grząski grunt.
Z jednej strony mamy tę “maszynę biznesową”, której zadaniem jest trzymanie firmy w ryzach. To ona narzuca wymóg podawania wycen, planowania zadań czy nakaz raportowania dwutygodniowych urlopów wcześniej niż gdy stoimy na płycie lotniska. Dzięki tym regułom i procesom firma może funkcjonować jako całość oraz przygotowywać się na przyszłość.
Z drugiej strony mamy realia pracy programisty/-tki, które nie zawsze pokrywają się z biznesowym postrzeganiem świata. Częstym sentymentem jest:
Niby wyceniamy zadania na S/M/L, ale biznes potem i tak mnie pyta, ile to zajmie w dniach – no to ja im na to, iż zadanie zajmie XL!
Po lewej stronie ringu mamy ludzi, którzy potrzebują znać wartość w jednostkach czasu generalnie akceptowanych na naszej planecie. Po prawej stronie stoi deweloper/-ka, którzy nie chcą składać obietnicy na mały paluszek, iż zadanie zajmie trzy dni robocze, jeżeli tak naprawdę równie dobrze może zająć jeden czy pięć.
Obydwie strony można zrozumieć.
Realistycznym wyjściem w takiej sytuacji jest kompromis: zespół stara się przygotowywać wyceny na dni, a strona biznesowa rozumie, iż nie mówimy dosłownie o n dniach roboczych, a jedynie przybliżeniu.
I podobnego kompromisu powinniśmy wypatrywać w samym procesie scrumowym. Dogadujemy się, iż mamy jakiś tam proces, którego trzymamy się tak w 95%, ale mamy też wspólne zrozumienie, iż od czasu do czasu wyrywamy się z ram i nie bijemy za to linijką po łapach.
“Potwarz!” słyszę w tle, “Scrum, honor, ojczyzna!” – ktoś ostrzy topór.
Wydaje mi się, iż każdy takie zrozumienie już ma – gdy produkcja płonie to rzucamy się ratować aplikację, a nie tworzymy zadanie “Uratować dane produkcyjne”, które następnie trafia do backlogu i czeka na wycenę. Wnoszę jedynie o to, aby podobnie podchodzić do rzeczy, które subiektywnie uważamy za “szybkie do naprawy”, za “drobny refaktoring”.
Nie chcę stawiać tutaj twardej granicy “mniej niż 15 minut, rób od razu” – raczej z czasem sami nabierzemy wyczucia, ile jeszcze jesteśmy w stanie wycisnąć, a które zadania powinny mimo wszystko trafić do backlogu, do ponownego przejrzenia za – jeżeli bóg da – pięć lat.
Czym jeszcze powinna objawiać się ta empatia w branży wytwarzania oprogramowania?
Kilka lat temu, gdy pracowałem jeszcze w software housie, miałem rozmowę z potencjalnym nowym klientem, jakąś firmą ze Szwecji. Jednym z pytań, które zadał mi wtedy ich rekruter było coś w stylu “jak zachowałbym się gdybym dostał do zaimplementowania «coś podejrzanego»”.
Mimo upływu lat przez cały czas uznaję to pytanie za równie niecodzienne, co ciekawe.
Jak, przykładowo, zachowałbym się “poproszony” o podrasowanie systemu samochodu, aby w trakcie testów potrafiło generować mniejsze emisje niż w trakcie zwykłej jazdy (słynne volkswagengate)?
Co gdybym dostał za zadanie zaimplementować do aplikacji tak zwane dark patterns, czyli fragmenty interfejsu celowo przygotowane tak, aby użytkownika mylić, zniechęcać do wybranych czynności? (każdy, kto próbował kiedyś anulować usługę online za subskrypcją na pewno miał okazję doświadczyć wielu takich patternów)
Czy byłbym w stanie postawić się przełożonemu, czy mógłbym, czy chciałbym?
Niektórzy powiedzieliby, iż są to wywody z gruntu bez sensu – iż “praca to praca”, “ja tu jestem tylko od kodowania” i tym podobne thought-terminating clichés. Inni stwierdziliby wręcz odwrotnie – iż właśnie należy powoływać się tę na swoistą “klauzulę sumienia”.
Nie pamiętam, jakiej konkretnie odpowiedzi udzieliłem te pięć czy sześć lat temu, ale wiem, iż nie byłaby ona inna od tego, co myślę teraz: o ile tylko mamy taką możliwość, powinniśmy według mnie odmawiać brania udziału w inicjatywach z którymi się nie zgadzamy oraz które uważamy, za szkodliwe.
Przykład Volkswagena jest tu oczywisty (było to, koniec końców, złamanie prawa, więc ciężko argumentować inaczej niż “don’t do that”), ale już przy tych dark patterns granica robi się rozmyta. W sumie nie łamiemy prawa, a za powiedzenie “nie” możemy przecież z pracy wylecieć. Czy powinniśmy zatem czuć dodatkowy stres związany z tym, iż tylko wykonujemy swoją pracę?
Pozwolę sobie to pytanie pozostawić otwarte, bez odpowiedzi.
Po części dlatego, iż konkretnej odpowiedzi tutaj nie ma (u każdego granica będzie leżeć w innym miejscu, zależnie od wieku, pozycji w firmie czy stabilności finansowej). Po części dlatego, iż według mnie każdy powinien zastanowić się dla samego/samej siebie: czym chcę, aby empatia objawiała się u mnie?
Dużo powiedzieliśmy o samodzielnych decyzjach. Stereotyp piwniczaka jest taki, iż pracuje w pojedynkę. Jaka jest rzeczywistość?
Obecnie kodowanie rzadko stanowi już dyscyplinę jednoosobową, a bardziej kojarzy mi się z… fraktalem!
Gdyby z lupą przyjrzeć się dowolnemu oprogramowaniu, od weekendowych ciekawostek w stylu onemillioncheckboxes.com po ogromne projekty jak przeglądarki internetowe, to dostrzeżemy, iż wszystkie te aplikacje nie powstają w próżni. Bazują na fundamentach wspólnie wypracowanych przez IT, z tysiącami rozwiązań open source przeplatającymi się ze sobą nawzajem.
Gdy spojrzymy w źródła choćby tego One Million Checkboxes to znajdziemy tam odniesienie do Google Fonts (serwisu oferującego otwarty dostęp do tysięcy czcionek, które można wykorzystać na swojej stronie internetowej). Rzut oka na kod JavaScript daje jasno do zrozumienia, iż został on poddany tak zwanej minifikacji oraz transpilacji. Zostały wykorzystane popularne narzędzia w stylu Webpack albo Babel.js, które przetwarzają kod JavaScript napisany przez człowieka dokonując jego optymalizacji oraz polepszając kompatybilność ze starszymi przeglądarkami.
Sprawa wygląda podobnie w przypadku szeroko pojętego systemu biznesowego. Z racji rosnącej złożoności otaczającego nas świata coraz ciężej wymagać od pojedynczego programisty/-tki, aby potrafili zaprojektować, zaprogramować oraz zarządzać wszystkim, od serwera po działające na nim aplikacje. Dlatego stawia się na zespoły.
W praktyce możemy to zauważyć w coraz większej granularności ról w ofertach – nie mamy informatyków, a backend developerów, frontend deweloperów, devopsów, sysadminów oraz bazodanowców; często w ogłoszeniach przeczytamy również “wymagania: zdolność pracy zespołowej, świetna komunikacja”. Jak dla mnie jest to na plus.
Większy zespół znaczy lepszy zespół?
Więcej ludzi w zespole to więcej świeżych perspektyw, świeżych par oczu, więcej okazji na to, aby ktoś podrzucił interesujący pomysł, zakwestionował status quo – ale również bezpieczeństwo. Dużo przyjemniej wiedzieć, iż gdy weźmiemy wolne to aplikacja nie spadnie z rowerka, bo będą się nią opiekowali w tym czasie pozostali członkowie zespołu (ten sławny bus factor).
Po godzinach lubię popracować samemu. Dłubiąc przy mniejszych czy większych prywatnych projektach, ponieważ nie ma co ukrywać – bywa to szybsze i wygodniejsze. Ale dostrzegam, iż ten sposób pracy ma też swoje wady. Brak feedbacku, brak możliwości odbicia pomysłów od innych osób odbija się czasem czkawką na rezultacie pracy.
Najlepiej widać to na grach – czasem napiszę sobie jakąś małą gierkę, czasem wezmę udział ze znajomym w gamejamie, i gdy potem daję coś takiego do ogrania innym to dostrzegam, iż oni poruszają się po grze zupełnie inaczej, niż sobie to wyobrażałem. Oczywiste dla mnie rzeczy stanowią dla tych moich graczy barierę nie do przeskoczenia, bo – dajmy na to – gra nie wspomniała, iż spację można nacisnąć dwa razy pod rząd.
I to jest tak samo zrozumiałe, jak i nieuchronne.
Gdy pracujemy nad aplikacją to mamy w głowie zarówno jej wysokopoziomowy sposób działania (np. o co w tej grze tak w ogóle chodzi), jak i niskopoziomowy sposób jej implementacji (naciśnięcie A+W aktywuje sekretny power-up). Dlatego trudno wyobrazić sobie jakiego rodzaju informacji będzie potrzebowała osoba po drugiej stronie ekranu, aby móc poradzić sobie ze swoim zadaniem bez dodatkowej frustracji. Nie chcemy przecież zaszumiać interfejsu informacjami w stylu “przycisk «Aktywuj produkt» aktywuje produkt”.
Zatem let’s embrace teamwork, let’s embrace feedback – w przypadku gier, sklepów internetowych, ERPów, CRMów, CMSów oraz wszystkich innych rodzajów oprogramowania.
Patryk Wychowaniec. Rust Tech Lead w Anixe, w branży od ośmiu lat; zwolennik Rusta, Nixa, wolnego systemu oraz piesków (im więcej, tym lepiej, wykładniczo). Lubię poprogramować, pograć w softball (choć dopiero od niedawna!) oraz ponarzekać na rzeczy w internecie.
