Antropolog High-Tech

Na codzień zajmujesz się tworzeniem oprogramowania dla innych ludzi. Ale czy kiedykolwiek sam używałeś aplikacji, w której tworzeniu uczestniczysz? I nie mówię tu o frontendowcu czy testerze, który podczas dewelopmentu mniej czy bardziej systematycznie wyklikuje dostępne funkcjonalności. Mówię o prawdziwym użytkowniku i realnym wykorzystaniu aplikacji na codzień. 

Czy ta aplikacja naprawdę działa?

Raczej rzadko się zdarza, że jesteś w grupie celowej projektu, który realizujesz. Skąd zatem możesz być pewny, że tworzysz dobry software? Czy sam musisz używać produkowanej aplikacji, żeby wypuścić dobry, funkcjonalny produkt? Przecież zbierasz wymagania, opisujesz typowego usera, tworzysz persony, a nawet przeprowadzasz badania fokusowe, żeby najlepiej jak to możliwe poznać swojego odbiorcę. Czy wykorzystanie wszystkich tych UX’ów, UI’ów, User Center Design’ów nie załatwia sprawy? Czy to wszystko nie wystarcza?

Praktyka pokazuje, że nie zawsze. Już sam fakt, że pojawiają się wątpliwości, że szukamy nowych sposobów odwzorowania użytkownika, powienien nas alarmować, iż temat nie jest jednoznacznie zamknięty. Czegoś brakuje. Albo kogoś…

…i tu na scenę wkracza nowa rola w teamie softwarowym – Antropolog High-Tech. Zanim jednak o nim, pozwolę sobie nieco nakreślić kontekst.

Softwarowe bańka informacyjna

Każda firma softwarowa pracuje w swego rodzaju bańce informacyjnej. Za długo przebywamy z projektem, za dobrze go znamy. Nasz obraz tego co robimy jest pokawałkowany, w danym momencie skupiamy się na określonej funkcjonalności, którą akurat dewelopujemy. Brak nam spojrzenia całościowego.

Jesteśmy też nieco spaczeni swoją wiedzą informatyczną, Widzieliśmy dziesiątki aplikacji mobilnych i webowych, schematy ich działania znamy na pamięć, a z rozwiązaniami w nich wykorzystanymi zetknęliśmy się już wiele razy. Nasze postrzeganie jest nieco inne niż prawdziwego usera. No i jak to informatycy, ponoć myślimy bardzo analitycznie, skupiamy się na detalu, brak nam syntetycznego spojrzenia. W firmie software’owej każdy jest trochę informatykiem 😉

Docelowy użytkownik to zupełnie co innego. On patrzy praktycznie: czy aplikacja mi w czymś pomaga? czy łatwo się jej używa? czy jest ładna? No i niech “nie każe mi myśleć”*.

Usera, na przekład, nie interesują szczegóły systemu walidacji w formularzu rejestracyjnym. On chce, żeby ten system był transparentny, tak jak to możliwe, żeby pomagał, a nie przeszkadzał w rejestracji. Celem walidacji powinno być poinformowanie usera, że się przez przypadek pomylił wprowadzając dane, a nie wymusić wprowadzanie ich w określonym formacie, wygodnym dla nas. To trochę jak z captchą. Niektórzy twierdzą, że wykorzystanie captchy to przerzucanie na usera zadania zabezpieczenia formularza, które powinno należeć do nas. Ja niestety się z tym zgadzam.

Jak zatem wyrwać się z tej bańki z informacjami? Jak spojrzeć z boku na projekt? Jak zebrać jeszcze więcej informacji o użytkowniku? A może to nie jest kwestia ilości danych, tylko ich jakości? Może powinniśmy wyjść z biura i zobaczyć prawdziwego usera w realnym świecie? Albo wysłać do usera nowego członka naszego teamu – Antropologa High-Tech?

Who is who?

Kto to w ogóle jest antropolog? Definicji jest wiele, ale najogólniej mówiąc antropolog zajmuje się obserwowaniem człowieka w jego naturalnym środowisku, w realnych sytuacjach i interakcjach z otoczeniem.

A Antropolog High-Tech? On też zajmuje się obserwacją, ale tym razem użytkownika naszej aplikacji. Jego zadaniem jest zebranie tak wielu dodatkowych informacji o użytkowniku jak to możliwe, o jego nawykach i codziennej praktyce, możliwościach i ograniczeniach. Antropolog High-Tech ma obserwować naszego usera i wyciągać wnioski na jego temat w kontekście realizowanego projektu.

Potęga obserwacji

Jak to działa w praktyce?

Pewna amerykańska firma softwarowe’a** dostała zlecenie na przygotowanie aplikacji tabletowej dla sieci samochodowych stacji diagnostycznych. Końcowym userem miał być diagnosta, który używa aplikacji, żeby wyklikać na niej konkretne informacje. Zebrano wymagania od klienta, przygotowano dokładny opis usera, proces produkcji ruszył. Następnie zaś, żeby jeszcze bardziej uszczegółowić dane o userze, do jednej ze stacji wysłano antropologa. Gdy ten zjawił się na miejscu, już w ciągu pierwszych 15-stu minut swojej pracy zauważył fakt, który mógł stać się krytycznym elementem projektu. Otóż pierwszą rzeczą jaką robił diagnosta po przyjściu do pracy było założenie gumowych rękawic, które miały chronić jego ręce przed kontaktem z niebezpiecznymi substancjami. I tu nagle okazało, że produkowana aplikacja będzie zupełnie bezużyteczna, a co najmniej bardzo trudno będzie jej używać. Za każdym razem, gdyby diagnosta chciałby użyć apki, musiałby ściągać rękawice, wyklikiwać niezbędne dane w aplikacji i ponownie zakładać rękawice. Wysoki próg wejścia. Aplikacja, która miała być ułatwieniem, nagle tak mocno miała ingerować w codzienną rutynę usera, że stawała się utrudnieniem.

Firma szybko zmieniła założenia. Zamiast rekomendowanych ekranów dotykowych, wdrożono urządzenia reagujące na nacisk i projekt został uratowany.

Informacja o rękawicach, choć kluczowa dla projektu nie znalazła się w wymaganiach. I nie miała szansy się tam znaleźć, bo wynikała z rutyny stanowiska pracy. Nikt nie wpadł na to, żeby wspomnieć o takim fakcie na spotkaniach z firma IT. I pomimo, że wszystkie inne elementy procesu produkcji aplikacji zagrały – powstała szczegółowa specyfikacja, wspaniałe makiety UX i designy, przygotowany został świetny flow – bez udziału antropologa projekt zakończył by się fiaskiem.

Podsumowanie

Z jednej strony firmy IT chcą wypuszczać coraz lepsze produkty i szukają nowych źródeł informacji o użytkowniku. Z drugiej strony użytkownik ma coraz większy wybór i coraz mniej czasu na poznanie nowej aplikacji. Decyzja “czy używać?” zapada w ciągu kilkudziesięciu sekund – instaluję –> pozywtne pierwsze wrażenie –> zaczynam korzystać. Zawiedziony user nie wróci do aplikacji, poszuka alternatywy. Nie bardzo możemy sobie pozwolić na takie wpadki jak opisana powyżej. To proste błędy, które w sumie łatwo wyeliminować. Nie traćmy zatem okazji do jeszcze lepszego poznania użytkownika, do poszukania wymagań u źródła, do wydania klientowi jeszcze lepszego produktu. Antropolog High-Tech może nam w tym pomóc.

Źródła:
*https://helion.pl/ksiazki/nie-kaz-mi-myslec-o-zyciowym-podejsciu-do-funkcjonalnosci-stron-internetowych-wydanie-iii-steve-krug,nieka3.htm#format/d 

**http://menloinnovations.com/joyinc/

Ile Dev’a w PM’ie?

Czy PM z branży IT w ogóle musi mieć kompetencje w zakresie technologii webowych? Jeśli tak, to jakich i na jakim poziomie? A może to wiedza zbędna? Może lepiej skoncentrować się na umiejętnościach miękkich i organizacji pracy w projekcie?

Jak zwykle w życiu nie ma recepty na wszystko. Wielu PM’ów i teoretyków twierdzi, że wiedza techniczna jest niepotrzebna, aby sprawnie prowadzić projekt technologiczny. Od czego mamy specjalistów w zespole? Przecież na każde pytanie techniczne ktoś z teamu odpowie. Jeśli klient zada podchwytliwe pytanie, zawsze można się skonsultować i wrócić z odpowiedzią. Być może nawet specjalista poczuje się dzięki temu bardziej dowartościowany, a zespół dzięki temu zyska. To są argumenty. Po co zatem obciążać sobie głowę nadmiarem nierozumiałych terminów i pojęć? Po co śledzić nowinki techniczne i trendy w dewelopmencie? To też są argumenty.

A jednak jest i inne podejście, moim zdaniem mające więcej zalet. Tak dużo wiedzy technicznej jak to możliwe, im więcej technologii, narzędzi, bibliotek webowych tym lepiej. Oczywiście nie chcesz zostań deweloperem, więc nie musisz wchodzić na poziom ekspercki. W większości wypadków wystarczy ogólna wiedza o możliwościach i ograniczeniach poszczególnych technologii. Przyda się wiedza pozyskana od praktyków na temat problemów, na które projekt może natrafić, jeśli wybierzemy konkretne rozwiązania technologiczne. Ale także lektura portali branżowych, czy kursy bootcampowe na pewno się przydadzą. Nie przegap żadnej okazji do powiększenia swoich kompetencji technicznych.

Jakie korzyści przyniesie ci takie podejście? Co możesz zyskać?

Pracujesz efektywniej

Masz wiedzę techniczną = masz o czym pogadać z Devami. Jako PM musisz wspierać cały zespół, także deweloperów. Jeśli środowisko, w którym się obracasz, nie jest zafiksowane na jedną technolgię (np. tylko Java), albo jeden typ klienta (np. tylko e-commerce oparty na Magento), jest duża szansa, że także dla Devów wybór nowej technologii lepiej dopasowanej do konkretnego projektu będzie wyzwaniem. Dyskusja zawsze jest tu mile widziana, wiedza o dostępnych technologiach potrzebna, a wiedza o ich możliwościach i ograniczeniach bezcenna.

Powtarzam, nie chodzi o poziom ekspercki. Nie musisz dyskutować nad wyższością Javy nad Pythonem, ale proponowanie rozwiazań, kreatywność w dyskusji, czy przynajmniej wiedza o czym jest mowa, powoduje, że szybciej podejmiesz decyzje, łatwiej zakomunikujesz je klientowi, trafniej dobierzesz zespół. Ergo będziesz działał bardziej efektywnie. Gdy projekt startuje, już trochę późno na naukę. Tu trzeba analizować, decydować, działać.

Budujesz relacje eksperckie z klientem

Wiedza techniczna pozwala Ci budować większe zaufanie u klienta. Niejako przy okazji stajesz się dla klienta ekspertem, pierwszym kontaktem, gdy ten chce skonsultowania swoich pomysłów, albo gdy napotka problem. Jeśli jeszcze jednocześnie budujesz z klientem relacje personalne, sukces murowany.

Jeśli klient jest zorientowany w kwestiach technicznych, możecie rozmawiać bezpośrednio bez potrzeby umawiania spotkań w zespołem specjalistów, co bywa najwygodniejszym wyjściem, a czasem z powodu obłożenia devów obowiązkami jedynym możliwym. Oczywiście i tak w którymś momencie będziesz zapewne musiał skonsultować szczegóły z zespołem, ale im większa techniczna, tym szerszy zakres twoich wstępnych dyskusji z klientem i tym większe prawdopobieństwo zaproponowania rozwiązania już na tym etapie. Potem wystarczy pomysły zweryfikować z zespołem.

Jeśli klient “techniczny” nie jest, możesz zdobyć większa zaufanie klienta, pokazując mu, że wspólpracuje z kimś, kto jest w stanie wyłapać znacznie więcej ryzyk projektowych, kto pomyśli o takich aspektach projektu, które jemu nie przyszłyby do głowy, kto w końcu zdejmie mu z głowy sporo problemów, bespośrednio dogadując wiele spraw technicznych bezpośrednio z deweloperami czy specjalistami po stronie klienta. Taki PM to skarb.

Budujesz autorytet w zespole

Jako PM często jesteś też liderem projektu. Nie wiem czy to poprawne podejście, ale faktem jest, że często się zdarza. Zaś będąc liderem musisz budować swój autorytet, żeby skutecznie kierować zespołem. Duże kompenetencje techniczne na pewno w tym pomagają. Jako lider siłą rzeczy stajesz się także pewnym punktem odniesienia, do ciebie przejdzie deweloper, który pracuje zadaniowo i oczekuje wytycznych, na tobie spoczywa podejmowanie decyzji, ty jesteś osobą, która inicjuje większość procesów także tych technicznych. Jeśli dodatkowo masz doświadczenie z poprzednich projektów, które pozwalają Ci dyskutować ze specjalistą jak równy z równym, a nawet zwracać uwagę na rzeczy, z którym sam Dev się nie zetknął, zyskujesz w oczach ludzi.

Autorytet pomaga Ci w pracy, powoduje, że łatwiej ci konsolidować zespół. Nie ma co ukrywać, sprawia też nieco satysfacji 😉

Podnosisz swoją wartość na rynku pracy

IT to bardzo dynamiczna branża. HR’owcy biją się o dobrych specjalistów, ale gdy dochodzi do rekrytacji, liczą się fakty, nagie liczby, skille. Jak pokazać, że jesteś lepszy od konkurencji? Dodatkowe umiejętności, kursy, certyfikaty w sposób oczywisty poprawiają twoją pozycję przetargową, im więcej umiesz tym więcej możesz sie cenić. Zwiększa się także twój “zasięg”, twój profil pasuje do większej liczby ofert, więć wzbudasz większe zaintersowanie rekruterów. Budujesz swoję historię zatrudnienia z takich niewielkich elementów jak znajomość nowej biblioteki JS.

Podsumowanie

Ile zatem tego Dev w PM’ie powinno być? Moim zdaniem, im więcej tym lepiej. Korzystaj z dostępnych źródeł, z doświadczenia swojego zespołu, z własnej inicjatywy i determinacji. Ale też nie przesadzaj w drugą stronę. Nie ma sensu ślęczeć nocami nad kodem, jeśli nie zamierzasz zostać Devem. Twoim głównym zajęciem jest nadal project managment. Musisz ważyć proporcje i zdobywać kompetancje przede wszystkim w swojej dziedzinie. Ale pamiętaj, że każda wiedza jest cenna, a w przypadku PM’a wiedza techniczna naprawdę pomaga w pracy.

Warto poczytać także:
https://tomassetti.me/the-5-things-a-developer-expects-from-a-project-manager-how-a-project-manager-can-help-developers-becoming-much-more-productive/