Podcast TechChatter odcinek 2

Kinga: Cześć, z tej strony Kinga.
Daria: I Daria.
Kinga: Nadajemy do was z Capgemini we Wrocławiu i opowiemy wam dzisiaj o Zero Waste. Trochę dziwny temat, jak na testowanie oprogramowania, ale, nie wiem, damy radę. Chcemy wam powiedzieć jak można zyskać więcej czasu na testowanie stosując zasady Zero Waste. Daria co ty na to?
Daria: No, super pomysł. Ogólnie ten Zero Waste teraz jest taki mega na topie, nie? I wszędzie się to wrzuca, także czemu nie w testowaniu…?
Kinga: Ja mam definicję. Czym jest Zero Waste? I możemy od tego zacząć, a potem sobie pogadamy dalej, jak to odnieść do testowania. Więc, filozofia Zero Waste zachęca ludzi do zmiany stylu życia produktów tak, aby nie pozostawiać żadnych zbędnych odpadów. Nic do wyrzucenia. No i tutaj w tym przypadku słowo produkt, no to może być wszystko. To może być przedmiot, który kupujesz, który wytwarzasz, albo którego używasz na co dzień. No i mam taką rozkminę, czy to w ogóle da się przenieść na testowanie? Ja myślę, że tak ale Cię tutaj trochę podprowadzam.
Daria: Znaczy wiesz co? Mnie się wydaje, że takie rzeczy da się robić, tym bardziej, że żyjemy w takich trochę czasach zwariowanych tak? Że troszkę zmieniamy swój tryb pracy. Na początku gdzieś tam był ten Waterfall, mnóstwo dokumentacji i spędzonego czasu na to. Teraz gdzieś tam przechodzimy w Agile i jesteśmy bardzo elastyczni, więc wydaję mi się, że ta elastyczność trochę się z tym łączy też, ponieważ tutaj możemy bardzo dużo rzeczy dostosowywać i próbować nowych. Nie? Wplatać. Także to też nie jest jakaś tam sztywna rama, z którą musimy pracować, tylko właśnie fajnie jest eksperymentować.
Kinga: No dobra, to może podeprzyjmy się taką znowu teorią Zero Waste. Zero Waste opiera się na 5 filarach, tak zwanych 5R oznaczających Refuse, Reduce, Reuse, Recycle i Rot. Czyli Odmawiaj, Redukuj, Re-używaj, Recycle czyli można tutaj mówić o takim recyklingu, które mamy na co dzień plastików, papierów, coś z tego możemy odnieść też do testów. No i Rots tutaj to jest takie kompostowanie, ale ja bym to odniosła to do archiwizacji różnych rzeczy. To może idźmy po kolei, jakieś fajne przykłady znajdziemy z naszego podwórka. Refuse czyli Odmawianie. Ja mam taką tutaj historię a propos menadżerów, czyli trochę z naszego podwórka, tego czym my się zajmujemy w testach. Czasami przychodzimy do ludzi prawda, z naprawdę głupimi pomysłami, albo nasi menedżerowie przychodzą do nas i proponują nam genialne rozwiązania. Jesteśmy pod koniec spreadu na przykład i zostało mnóstwo rzeczy, albo jesteśmy przed samym releasem, przed delivery i przychodzi menedżer i mówi „hmm jakby to przyśpieszyć, to może olejmy testy, w ogóle ich nie róbmy?”. Albo jeszcze takie fantastyczne pomysły jak dokładanie ludzi pod koniec projektu, no bo przecież robota pójdzie szybciej nie, 9 kobiet urodzi dziecko w miesiąc.
Daria: Czemu nie?
Kinga: Może jakieś takie historie z siebie.
Daria: Wiesz co, historie może się zaraz jakieś znajdą, natomiast ja bym tutaj dorzuciła, że ja naprawdę sobie bardzo cenię szczerość ludzi w tych momentach, nie? Że rzeczywiście, my jako jakieś menadżerki tak, sobie próbujemy gdzieś tam znaleźć, odnaleźć się w tym naszym świecie właśnie w deadline’ach i tak dalej, i czasami troszeczkę się zagalopowujemy, nie? I mamy takie pomysły, które wydają nam się „ o super, uratują nam życie”. Natomiast, mówiąc je głośno super jest usłyszeć od naszego zespołu, od jakiejś jednej osoby, albo konkretnej, albo dwóch, trzech, nie? Że coś w ogóle jest, pomysł z czapy, nie. I może jednak warto to przemyśleć i może troszkę inaczej, albo nie biegać z tymi pustymi taczkami, nie? Tak że tutaj, no wydaję mi się, że to jest naprawdę wartościowe mieć w zespole takie otwarte osoby, które gdzieś tam szczerze powiedzą, że „no to jest w ogóle bez sensu nie, nie róbmy tego w ten sposób”. Natomiast, jeżeli chodzi o sam taki przykład, to że nie testujemy całego [niezrozumiałe 00:04:18], to, to jest klasyk. To jest w ogóle, tak, standard. Dorzucanie ludzi na ostatnią chwilę, to samo, nie? Klasyczne. Natomiast wydaję mi się właśnie, że testerzy najczęściej obrywają przy tym wszystkim nie, że są te deadline-y, problemy w projekcie. To zawsze jakoś dziwnie się zdarzy, że spada na testy.
Kinga: No właśnie, a najgorzej, nie wiem, ja mam też takie poczucie, że testerzy mają bardzo duże poczucie odpowiedzialności. Przynajmniej w moim zespole tak to wygląda.
Daria: Tak.
Kinga: Że każdy chce dowieźć ten projekt jak najlepszej jakości i zależy na tym, żeby właśnie klient dostał coś dobrego. No jak jesteśmy pod koniec już, przy jakimś deadline, przy realise, no to jedziemy i nadgodziny, i weekendy, i wtedy wszystko, wszyscy postawione na ostrzu noża, nie?
Daria: No to prawda. To zawsze stawiamy się w takim, nie wiem, pod taką ścianą dosłownie, nie? I ciśnieniem po prostu, żeby to dowieźć. 
Kinga: Także apelujemy do wszystkich testerów, którzy nas słuchają, mówcie, że rzeczy nie mają sensu. Po prostu, odmawiajcie jakichś głupich pomysłów, czy to wychodzi od testów menedżera, czy to wychodzi od project menedżera, czy kogokolwiek kto właśnie wpada na jakieś genialne pomysły, zwłaszcza pod koniec sprintu lub delivery. Mówcie głośno, że coś nie ma sensu, bo to jest naprawdę cenne, żeby kogoś troszeczkę sprowadzić na ziemię.
Daria: To prawda, to jest naprawdę mega wartościowe.
Kinga: No dobra, idąc o krok dalej mamy Reduce, Redukowanie. To ja mam taką historię na początek a propos  redukowania spotkań. Mamy takie określenie u nas Time Wasting Meetings, czyli spotkania które mogłyby być mailem. I tego czasami w projektach jest za dużo. Ja byłam kiedyś w takim projekcie, w którym naprawdę spotkań było mnóstwo, a najgorsze było to, że one były tak poprzeplatane z niby pracą. Czyli pół godziny spotkania, pół godziny wolne, pół godziny spotkania, pół godziny wolne i wiadomo, że w takim dniu 8-godzinnym, a w przypadku developmentu 6-godzinnym, no to, no nic nie zrobisz. No nie masz szans. Z spotkania na spotkanie i te przerwy, no to co? Nie wiem, na kawę no nie odpalisz kompa, ani nie wiem, kodu nie otworzysz. No i wpadliśmy wtedy na taki pomysł, żeby robić sobie takie bloki spotkań. I przede wszystkim wywaliliśmy z grafiku te spotkania, w których nie wszyscy musieli uczestniczyć. No bo nie zawsze jest tak, że każdy musi chodzić na każde spotkanie, bo jesteśmy jedną wielką rodziną. No nie, w zasadzie rozmawiamy ze sobą na co dzień i możemy jakieś ważne informacje przekazać. A na przykład takie spotkania, które rzeczywiście były istotne z punktu widzenia całego zespołu, no to połączyliśmy sobie w takie bloki i mieliśmy na przykład blok-praca. On był wyłączony i nikt tam nie mógł wrzucać spotkań i to były, powiedzmy 4 godziny takiego czasu skupienia. No a później były blok spotkania i wtedy można było po kolei jechać nie wiem, planowanie, jakiś red row i tak dalej.
Daria: To jest fajny pomysł, to co tu mówisz o tym bloku, ponieważ no nie zmieniamy tego całego kontekstu cały czas. I ten czas pomiędzy spotkaniami, on po prostu jego nie ma, bo spotkania są cały czas i możemy to jakoś lepiej wykorzystać. Natomiast, ja mam jedną dobrą historię a propos spotkań i spotkaniozy ogólnie. Pamiętam w jednym z projektów mieliśmy tak wiele spotkań i tak dużo czasu marnowaliśmy na te spotkania, bo oczywiście one nie wnosiły nic do naszego życia, tak na co dzień, że o ironio, musiałam zrobić spotkanie na temat spotkań. Żeby jednak zredukować jakoś liczbę spotkań, albo żeby właśnie wybrać osoby, które powinny uczestniczyć w danym spotkaniu, bo one coś wniosą, albo wyniosą z tego spotkania, ale, to co mówisz właśnie, jeżeli chodzi o te bloki, to to jest super pomysł no i ja też jestem fanką po prostu wychodzenia ze spotkań. Jeżeli dołączysz się i czujesz, że w ogóle ten temat totalnie nie jest dla Ciebie, nic tam nie wniesiesz, ani nie, ani nie dotyczy Cię to w ogóle, to po prostu wyjdź z tego spotkania i rób swoje rzeczy. Bo naprawdę, ludzie zapraszają wszystkich dookoła, bo wydaje im się, że „super, im więcej ludzi, tym lepiej”, ale to troszeczkę czasami się jednak mija z celem.
Kinga: Ja miałam kiedyś fajnego menadżera, który miał świetną praktykę. Umawiał sobie na przykład 3 równorzędne spotkania, albo był zapraszany z racji ze stanowiska, które piastował w tej firmie. Był zapraszany na różne spotkania równolegle i koleś miał świetny patent. Przychodził na każde spotkanie i mówił „przepraszam, ale mam inne spotkanie” i de facto nie szedł na żadne, nie? I miał godzinę na obiad, albo godzinna przerwa na kawę.
Daria: Dobre.
Kinga: Także polecam.
Daria: Dobre, jak się ma taki no kalendarz wypchany po brzegi, to, to jest dobra opcja. Ja się już widzisz spotkałam z taką sytuacją, że właśnie dla osoby, która ma wypchany kalendarz i jest bardzo ciężko uchwytna, nie? Żeby cokolwiek zrobiła. To widziałam  jeszcze takie sytuację, że ludzie wrzucali w spotkania takie pół godzinne, godzinne i później się wydzwaniali na 5 minut i mówili „że słuchaj to tutaj masz slota tego półgodzinnego, to zrób mi to i to, nara”. To jest w ogóle hit, takie znajdowanie czasu na siłę dla tej drugiej osoby, nie? Żeby coś zrobiła, nie i takie wbijają tego slota, to jest coś pięknego.
Kinga: W sumie tak, no bo jak masz taką osobę, która jest trudno dostępna, bo nie wiem, angażuję się w jakieś inne rzeczy, masz architekta w projekcie i ciężko go wyciągnąć z pracy, to super. 20 minut gratis.
Daria: Tak. Znaczy, wiesz co? Nie wiem, czy ta osoba, która ma coś zrobić jest też szczęśliwa z tego tytułu.
Kinga: Niespodzianka. [śmiech]
Daria: Ale może czasami to pomóc.
Kinga: Fajne. A propos redukowania rzeczy to ja też mam taki pomysł dla projektów, żeby redukować jednak dokumentację. Czasami mam wrażenie, zwłaszcza w dużych firmach, korporacjach. Ta dokumentacja się po prostu przelewa, każdy musi produkować swoją i najlepiej od nowa. Także no dużo tego jest, wolałabym, żeby było mniej.
Daria: Tak. I dublowania pracy, to jest po prostu też nasze ulubione zajęcie. Mamy testy automatyczne i jest duży zespół, wielu testerów, którzy pracują w różnych zespołach. I okazuję się, że te testy automatyczne, które bardzo dużą część aplikacji pokrywają, są również testowane manualnie. Bóg jeden wie po co, znaczy ja rozumiem czasami są takie potrzebne momenty, nie? I sytuacje są też różne, ale skoro są pokryte automatami i my mamy zaufanie do tych automatów, no to po co robić dokładnie tą samą pracę ręcznie, nie? Więc tu jeszcze są tego typu  historie, którym warto też się przyjrzeć. Czy my po prostu nie dodajemy sobie sensu tej pracy, nie? Na co dzień.
Kinga: No dobre, dobre, ale to już. Myślę, że to fajnie już przeszliśmy do następnego punktu tej reużywalności, no bo redukowanie to jedno, a druga rzecz, utrzymywanie testów. Ja miałam niedawno historię w projekcie taką, że mieliśmy testów, dalej mamy bardzo dużo, naprawdę tam jest ponad 1600 manualnych testów, no jakby fizycznie niemożliwe. Utrzymaj 1600 testów, nie? Jakieś scenariusze gigantyczne i okazało się, że testerzy za każdym razem, kiedy przychodził,  update jakiegoś future’a, nawet nie nowy future, tylko jakiś dodatek, pisali po prostu nowy test od początku dla tego future’a. 
Daria: Doskonałe.
Kinga: No nie? I późnej patrzysz i 1600 testów, naprawdę. Nie mamy tyle funkcjonalności, nie i tak „dlaczego mamy tyle testów”? „No bo my piszemy zawsze wszystko od nowa”. „Ok, ale testy można update’ować” i to jest super na przykład w automatyzacji, że te testy, oczywiście to jest kosztowne, ale te testy są, utrzymywane są osoby, które cały czas zwracają uwagę na to, co w tych testach jest, czy one przechodzą, dlaczego nie przechodzą? Coś się zmienia, no to update’ują testy. No, a tutaj testerzy manualni jednak troszeczkę poszli w innym kierunku.
Daria: Tak, ale tutaj możemy trochę chyba zahaczyć też o komunikację, że ludzie po prostu bardzo często ze sobą nie rozmawiają najzwyczajniej w świecie, nie i to jest kolejny jakiś tam problem chyba aktualnie może tego, że pracujemy zdalnie. A może po prostu trochę się zamknęliśmy już i nie rozmawiamy ze sobą tak jak kiedyś. I po prostu nie mamy czasami tej świadomości, a nawet nie zapytamy. Nie? No bo po co i to takie sytuacje później się mogą właśnie niestety, ale pojawiać.
Kinga: Dużo rzeczy jest w ogóle takich, które można re-używać, bo ja mam takie poczucie, że ludzie zazwyczaj próbują wymyślić koło od nowa. Ja ma takie doświadczenie z deweloperami, że oni zawsze sobie wymyślają.
Daria: Tak.
Kinga: Bo on, on wie najlepiej, non zrobi to nareszcie porządnie.
Daria: Kto to napisał? [śmiech]
Kinga: O, albo to. A potem „o ja”, nie, „ja to napisałem”, także to jest fajnie, żeby jednak czerpać tę wiedzę od innych osób i też z doświadczenia innych osób, no bo między tymi projektami cały czas się przemieszczamy. Nie jest tak, że znaczy, oczywiście są osoby, które siedzą w projekcie 10 lat i tym samym są super ekspertami w domenie, ale zazwyczaj jednak częściej zmieniamy projekty. Tu widzieliśmy coś tam, tu można podpatrzeć jakiś Continuous Delivery w innym projekcie. Może w jaki sposób robione są testy automatyczne? I można tę wiedzę przenosić z jednego projektu do drugiego. A mam takie wrażenie, że czasami ludzie jednak wiedzą lepiej. Chcą wszystko zrobić od nowa, a najgorzej jak trafiają do projektu, który już funkcjonuje od iluś lat i niewiele da się tam zmienić. No to ten brak elastyczności jest strasznie mi przeszkadza.
Daria: To prawda. Ale to jest znowu trochę wracamy do tej elastyczności, usprawniania i tych wszystkich, jakiś różnych zmian nie, które teoretycznie w projektach się dzieją, no bo to jest żywy produkt i my też staramy się ulepszać i właśnie redukować, re-używać pewnych rzeczy tak, żeby zmniejszać sobie nakład pracy, nie?
Kinga: No dobra, to ja jeszcze a propos re-używalności. Mam taką myśl, że super jest jak ludzie dzielą się swoją wiedzą. Bo często jest tak, że mamy ekspertów w projekcie i oni są super, są bardzo techniczni, ale są strasznie zamknięci w tym co robią. I grzebią tam sobie coś w kodzie, czy robią infrastrukturę i w zasadzie mamy takie silosy wiedzy później. Mamy jedną osobę, która coś wie i jak tej osoby zabraknie, bo nie wiem, rozchoruje się, albo odejdzie na emeryturę, tak też się zdarza. Więc warto tą wiedzą się dzielić i w projekcie, i też poza projektem. Ja uwielbiam w Capie to, że mamy nasze Community i jest tyle osób, które mają fantastyczne doświadczenie i wiedzę, i przychodzą na spotkania i dzielą się swoimi, jakimiś doświadczeniami i z projektów, jakimiś swoimi unikalnymi umiejętnościami. Czy też warsztaty, które robimy dla ludzi. To jest rewelacja, że ludzie chcą szerzyć te wiedzę i dobre praktyki, no bo to też jest tak, że jak jesteś początkującym testerem i trafisz do projektu, w którym nie masz się od kogo uczyć. Ktoś daje Ci łódkę, wiosło i płyń, nie? No to nie bardzo wiesz co masz robić. A jak dołączysz to Community, poczytasz trochę, poszukasz jakiejś takiej wiedzy u innych osób, no to możesz mieć  pomysł jak zacząć, albo jak usprawnić pracę w swoim projekcie, żeby właśnie nie biegać z tymi pustymi taczkami, o których mówiłaś.
Daria: Tak, ale tutaj warto rozmawiać i, i pytać, szukać, dopytywać. Właśnie super jest mieć do kogo w ogóle pójść z danym problemem, pytaniem. To tak jak wspomniałaś, u nas są takie grupy, można sobie na forum bez problemu przegadać jakieś różne problemy, tylko po prostu trzeba z tym wyjść, a czasami po prostu my się zamykamy w tym naszym małym pokoiku i po prostu nie rozmawiamy z nikim, no bo, no bo po co? A tutaj naprawdę można czerpać wiedzą od wielu, wielu osób, które już przeszły podobne, podobne jakieś tam tematy, problemy, nie? Jeszcze chciałam nawiązać do tej Twojej dokumentacji z racji tego, że, że my teraz jesteśmy tacy super elastyczni i, i możemy wszystko robić w ogóle elastycznie, podchodzić do wszystkiego gdzieś tam. To właśnie zapominamy o takiej podstawie nie, czyli nawet takiej prostej dokumentacji i ona gdzieś tam jest, może kiedyś ją ktoś stworzył, albo w ogóle nikt jej nie stworzył, bo po co? Bo przecież jesteśmy w Agile’u. A może jednak czasami warto gdzieś tam wrzucić jakieś parę zdań i właśnie może się komuś to przyda w przyszłości. Jeżeli nie ma tam informacji, której szukamy, to po prostu napiszmy tam jakieś 2-3 zdania, o których się dowiedzieliśmy, bo było nam to potrzebne, to też nam pomoże gdzieś tam, w takim codziennym życiu i później będziemy mogli łatwiej tego re-użyć po prostu.
Kinga: No to prawda, taki recycling wiedzy czy nawet to kompostowanie, o którym mówiłam na początku, taka archiwizacja, no to jest mimo wszystko potrzebna. To piszemy, albo dla siebie w przyszłości, bo też są takie sytuacje, że później odpalasz kod, komentarze, a tam pusto, nie?
Daria. No, to prawda.
Kinga: „Co ja miałam na myśli”, nie jeszcze miesiąc temu, albo właśnie te sytuacje, kiedy ktoś odchodzi na emeryturę. To jest moje ulubione, bo okazuję się, że jest jakaś jedna osoba w projekcie, która gromadzi sobie przez lata całą wiedzę i jest tą jedną, jedyną osobą, która używa jakiegoś narzędzia i tylko ona tego narzędzia potrafi użyć. I nagle „o odchodzę na emeryturę za miesiąc”, nie? i mamy miesiąc czasu na tak zwany Knowledge Transfer i zostajesz po prostu z narzędziem, którego nie znasz. Z danymi, których nie rozumiesz i nigdzie to nie jest udokumentowane, bo wszystko było w głowie tej jednej osoby.
Daria: Tak, dokładnie i to jest sytuacja u mnie aktualnie w projekcie, jeden z analityków, co prawda nie odchodzi na emeryturę, ale zmienia projekt. I to jest taka osoba do której się idzie i mówi „słuchaj do zespołu idziesz, nie” do zespołu i pytasz „potrzebuję dowiedzieć się czegoś a propos tej danej działalności” i zespół mówi „ale my tego nie mamy”, analityk odpowiada, że „Ty nie wiesz, że my to mamy, ale my to mamy”. I tu się nagle okazuję, że znowu nie, że jest ta wiedza, tylko w jednej głowie i ona tam siedzi sobie. Nie ma skąd jej czerpać i teraz za miesiąc człowiek zniknie i co dalej?
Kinga: W jednym projekcie, w którym pracowałam mieliśmy też taki pomysł, żeby nagrywać rzeczy. I to jest super pomocne zwłaszcza jak pracujemy zdalnie, no bo i tak odpalamy kamerę, włączamy się na spotkanie i jest, można tę wiedzę sobie nagrać, można sobie z tego później skorzystać. I na przykład robiliśmy sesję demo w domyślę dla klienta, natomiast klient był w innej strefie czasowej i to było strasznie uciążliwe. No bo,  zespół Polski kończył swoją pracę powiedzmy, nie wiem, o godzinie 15 czy 16, a w stanach dopiero tak naprawdę zaczynali dzień o tej porze. I ten Polski zespół musiał siedzieć do późna, żeby demo pokazać, żeby ta sesja rzeczywiście  była na żywo, żeby ktoś dał ten feedback jak to poszło. No ale klient też się frustrował, no bo musieli wcześniej wstawać, żeby w ogóle jakoś zazębić 2 godziny, czy godzinę na te sesje. No i wymyśliliśmy taki sposób, żeby nagrywać wideo z sesji demo, wysłać to do klienta, klient w ciągu dnia sobie to oglądał, dawał jakieś komentarze, czy uwagi i potem można było w ten sposób pracować. Trochę zdalnie, trochę pokazują też siebie i swoją pracę, no bo nie tylko przez wysłanie aplikacji, czy jakiegoś future’a, z którego klient mógłby skorzystać, ale rzeczywiście, żeby pokazać też ludzi, którzy przy tym pracowali. Bo ja myślę, że na demo to też jest bardzo ważne, że pracowały nad tym konkretne osoby, one się też mogą pochwalić swoją pracą, wynikami swojej pracy  i to jest super. No ale w takich setupach międzystrefowych, w różnych strefach czasowych no to niestety bywa to uciążliwe.
Daria: Tak, takie nagrania są. Super, że o tym wspomniałaś, one są również mega przydatne podczas onboardingu. Jak onbordujemy osobę, to po prostu ilość wiedzy przekazywanej dla tej nowej osoby, to jest po prostu, no kosmos aż. Kurczę, nowy projekt, nowi ludzie, wszystko jest w ogóle do po ogarniania i ta wiedza czasami po prostu mega przytłacza, nie? I mając takie nagranie, no to też możemy sobie do tego wracać po prostu regularnie i gdzieś tam odsłuchiwać, i jakieś tam nowe rzeczy wyłapywać, po jakimś czasie. No i mało tego, jak kolejna osoba przychodzi, to znowu nie musimy spędzać tych dwóch godzin tłukąc o tym wszystkim, tylko po prostu podsyłamy takie nagranie i jest. To oczywiście też nie zastąpi takiego kontaktu z człowiekiem, nie? No bo czasami taka interakcja, odpowiadanie na pytanie jakieś tam bieżące, to też jest coś istotnego, no ale to jest taka podstawa do, do takiego przekazywania wiedzy po prostu, też może się przydać.
Kinga: U mnie w projekcie teraz testerki wymyśliły super patent właśnie na onboarding. Po części to o czym mówisz, ale zrobiły taką check listę z rzeczami, które w projekcie są potrzebne, taki starter pack dla człowieka, który do tego projektu wchodzi. Bo też mieliśmy dużo osób nowych, które dochodziły i za każdym razem pojawiały się te same pytania.
Daria: Tak.
Kinga: No i żeby też nie marnować w kółko czasu osób, które w projekcie są, no to właśnie powstała check lista z linkami, z odnośnikami, z jakimiś takimi fajnymi źródłami, z których można korzystać, żeby zostawić człowieka, który wchodzi do projektu, żeby na spokojnie mógł się wdrażać, a też niekoniecznie wywierał presję na inne osoby. Bo to też jest trudne, wchodzisz do projektu, jesteś nowa, nie chcesz co chwilę zawracać gitary wszystkim dookoła, a tutaj masz już spisane w jednym miejscu. Macie jakiś taki patent u siebie na to?
Daria: Mamy całą instrukcję jak w ogóle setupować środowiska, jak sobie poustawiać jakieś informacje takie podstawowe na temat użytkowników i ich ról, i jakichś uprawnień. Także takie rzeczy też są i to jest super właśnie, jeżeli masz tak spisane krok po kroku, nie? No, bo nie zgubisz się po pierwsze, nie? Widzisz co masz robisz i po 2-gie to o czym ty mówisz. My jeszcze wchodząc do projektu nie mamy takiej śmiałości, żeby kogoś non stop podpytywać, tylko gdzieś tam będziemy czekać, „może oni sami zapytają, albo na daily powiem” i to tak się trochę siedzi, i trochę się wdraża, ale troszkę się nie wie i tu wydaje mi się, że taka lista to jest naprawdę coś bardzo przydatnego.
Kinga: Myślę sobie, że tak gadamy o różnych aspektach naszego życia projektowego i mimo wszystko dość mocno mi się to zazębia z tym Zero Waste, bo mam wrażenie, że jednak dużo czasu marnujemy na czynności, które są niekoniecznie potrzebne. Albo których mogłoby być mniej, które nam zajmują bardzo dużo czasu, a moglibyśmy ten czas poświęcić na to, co tygryski lubią najbardziej, czyli na psucie rzeczy.
Daria: Tak, dokładnie.
Kinga: Zawsze jest miejsce na improvement, bo ja, jak obserwuję testerów w projektach, to często jest tak, że na początku jest bardzo duża energia i chęć uczenia się, zdobywania wiedzy. Trochę też takiego pokazania, że jestem coś wart, że, że mam fajną wiedzę, że mogę się tutaj przydać i mogę się z wami podzielić. A po 1-wszym etapie euforii już tak osiadamy, już ta energia trochę spada, a właśnie wtedy wydaje mi się, że to jest dobre miejsce, żeby robić takie improvementy, żeby coś  ulepszać, żeby zmieniać, żeby, nie wiem, zastanowić się co moglibyśmy na przykład zautomatyzować, albo co dodać do tych testów.
Daria: Tak i wchodząc w ogóle w projekt jako nowa osoba, ty masz jeszcze taki fresh look.
Kinga: Tak.
Daria: I to jest też super ważne nie? Żeby wyciągnąć od tej osoby, która wchodzi do tego projektu. Jakieś jej może pomysły, albo spostrzeżenia, nie? Które ona ma, bo może w innym projekcie, w którym ona była ta osoba, robili jakoś inaczej, lepiej, szybciej, sprawniej i może warto byłoby to przełożyć również na ten nasz projekt. Oczywiście, nie każdy lubi zmiany, nie? Bo po co, natomiast no wydaje mi się, że to jest naprawdę fajne, jeżeli ktoś nowy wchodzi i, i nagle zaczyna gdzieś tam nawet sam z siebie mówić, że „a my to w sumie robiliśmy trochę inaczej”, nie? I to warto może też pociągnąć trochę za język i może też się czegoś nauczyć od tej osoby przy okazji.
Kinga: Ale to też jest chyba kwestia otwartości i zespołu, i osób, które już w tym projekcie są.
Daria: Oj tak.
Kinga: Bo ja też tak czasami obserwuję, że osoby, które mają dobre pomysły, albo pomysły, które właśnie sprawiają, że ten czas w przeszłości można było zaoszczędzić, no to jest duży opór, albo duża niechęć. Bo zawsze tak robiliśmy, to już parę razy słyszałam takie zdanie „no, ale po co, przecież zawsze tak robiliśmy”. Super zawsze woziliśmy taczkę na kwadratach, po co nam kółko.
Daria: To prawda. Takie koniki z klapkami na oczach.
Kinga: No trochę tak. I to jest zarówno w testach, jak i w developmencie, nie? O to jest też fajne, jak testerzy mają dużo pomysłów, które mogą sprzedać deweloperom, bo mają trochę inne spojrzenie na to, co robimy i jak robimy. I często też mają takie ogólne całościowe spojrzenie na produkt, a deweloperzy jednak siedzą w jakimś swoim kawałku, nie zawsze wiedzą co się dzieje w innych częściach produktu. Zwłaszcza jeżeli ten projekt jest duży, a tester może tutaj pomóc w takim ulepszaniu pracy, albo trochę innym spojrzeniu na to, w jaki sposób pracujemy.
Daria: No to prawda. Mi tu przychodzi, troszkę w temacie, może troszkę poza już, ale przychodzi mi też taki pomysł właśnie na per testing nawet z takim deweloperem czasami nie, żeby usiąść zanim jeszcze coś wyjdzie na środowisko testowe, żeby usiąść lokalnie, gdzieś tam zerknąć we dwójkę co się zmieniło, tak? I właśnie wyłapać wcześniej te sytuacje i przytoczę tutaj po prostu mój przykład z życia, dosłownie. Jak dostałam raz od właśnie dewelopera PDF-a do przetestowania, to był jednostronicowy PDF z tabelką i  naprawdę on miał 30 błędów. 30 błędów zgłosiłam do jednej tabelki, nagłówka. No co może być w PDF-ie, nie? I po prostu ja chyba spędziłam więcej czasu na zgłaszaniu tych błędów, niż ten człowiek na implementacji tego, nie? To był hit i takie właśnie te testowania, takie w parze z deweloperem, no to tutaj też bardzo co by zaoszczędziło nam czasu, nie? Bo te rzeczy bym wytknęła po prostu szybciej.
Kinga: A propos parte testingu to jest fajne, że możemy uczyć się od dewelopera, no bo ja wiem, że ta seria zazwyczaj wychodzi z pozycji „stary i tak wiem lepiej”. Natomiast deweloperzy mają jednak dużo większe takie skile techniczne. Zazwyczaj nie obrażam testerów automatyzujących, nie obrażam testerów technicznych, ale zazwyczaj deweloperzy mają większą umiejętności, jeżeli chodzi o kodowanie. I ja sama korzystałam z właśnie kompetencji deweloperów, kiedy chciałam mieć jakieś rzeczy w projekcie zautomatyzowane, a sama nie automatyzowałam i siadaliśmy razem, ja pokazywałam co powinno być zautomatyzowane. Tak naprawdę taki scenariusz manualny do przetransformowania tego w kod czy w skrypt testowy. Bo tam akurat chodziło o skrypty i deweloper pisał skrypt i mieliśmy tak naprawdę sprawę testów załatwioną w godzinę, a ja bym to później musiała klikać. Nie wiadomo ile razy, żeby rzeczywiście ten scenariusz przejść, a w ten sposób wszyscy zaoszczędziliśmy czas. Nie? więc to jest też taki dobry pomysł na współpracy między testerami, między deweloperami i takie używanie tej naszej wiedzy po to, żeby w tym projekcie się po prostu pracowało lepiej, a nie okopywanie się w swoich nazwach ról, ja jestem deweloperem, ja jestem testerem, nie będę robić z tych rzeczy.
Daria: Tak, tak, ale to właśnie też, to też jest bardzo fajne, nie? Jeżeli te nasze rolę się tak trochę przenikają i razem właśnie próbujemy coś zrobić nie, tylko że deweloperzy dewelopują, testerzy testują. Tylko właśnie to gdzieś tam jest ta współpraca taka bardziej, nie wiem ścisła, nie? I możemy sobie coś porobić razem, żeby właśnie trochę zaoszczędzić tego czasu i, i móc zrobić jakieś inne ciekawe rzeczy.
Kinga: Ale to też chyba musi być tak, że zespół powinien być przynajmniej trochę zgrany.
Daria: Oj tak, no. No to tak.
Kinga: Że ten test menedżer czy project menadżer, czy ktokolwiek w tym zespole jest taką osobą zarządzającą. Musi jednak zadbać o to, żeby ten zespół w jakiś sposób ze sobą zintegrować, zwłaszcza jak pracujemy zdalnie. No bo, no nie ma siły, to samo się nie wydarzy. Jak spotykamy się nawet w kuchni na kawie, nie? Taka pierdoła i rozmawiamy zupełnie o czymś innym, rozmawiamy o dzieciach, o przedszkolu, o dojeżdżaniu do szkoły. Nie wiem, o remoncie we Wrocławiu, który trwa na drogach nieustannie i nie da się dojechać.
Daria: I czy tramwaje się wykoleiły dzisiaj czy nie? [śmiech]
Kinga: Czy dzisiaj się tramwaje wykoleiły i wiadomo, że tak. To w międzyczasie może wyniknąć jakaś sprawa już typowo projektowa, komuś się coś przypomni. Znajdzie się osoba w kuchni, która też miała podobny problem i od słowa do słowa. Znajdujemy rozwiązanie na palące problemy, których w sumie albo nie rozmawialiśmy wcześniej, albo okazywało się, że wszyscy wcześniej mają ten problem właśnie i nie powiedzieli, bo nie wiem. Bo wstydzili się, albo uważali, że to jest nieważne.
Daria: Tak, dokładnie i wiesz, i tu wracamy znowu do tych spotkań. Jeżeli tworzymy spotkanie, to załóżmy nie? Ono powinno mieć plan, agendę i cel. No i w tym momencie my poruszamy jakiś jeden dany temat i nie poruszamy jakiś tam ubocznych problemów, problemików. Natomiast właśnie w tej przysłowiowej kuchni, my możemy naprawdę wielu rzeczy się dowiedzieć tak przy okazji totalnie, nie? Albo właśnie komuś pomóc.
Kinga: No to prawda. Ale mój zespół też jest w biurze w większości i rzeczywiście te relację są inne, i jest szybsza praca. Nie no, nie ukrywajmy. Zanim do kogoś zadzwonisz, nie wiesz czy ta osoba jest, czy ona przypadkiem nie je śniadania, a najczęściej je.
Daria: Albo gotuje obiad, tak.
Kinga: Albo gotuje obiad. [śmiech] Zanim się zdzwonicie, poszerujecie ekran, klasyczne „ej słyszysz mnie, ej widzisz mój ekran”, to w ogóle powinno być w standardzie na Teamsach, nie? A na żywo to widzisz, że ta osoba akurat, nie wiem, robi jakieś zadanie, ale one nie jest super pilne i też nie biega w Bardziej na nie. A na żywo, no to widzisz, że ta osoba akurat nie wiem robi jakieś zadanie, ale ono nie jest super pilne i też nie biega w headless chicken mode tylko możesz tak stuknąć palcem i powiedzieć, „Hej, mogę ci zająć chwilę?” i to rzeczywiście wychodzi trochę szybciej. I tu znowu wracamy do, do tego niemarnowania czasu, no bo to nie jest marnowanie czyjegoś czas, jeżeli zadamy mu pytanie, jeżeli chcemy zdobyć jakąś wiedzę, albo coś jest nam potrzebne, no bo blokuje naszą pracę. No to mimo wszystko działamy dla takiego wspólnego dobra, dla dobra projektu, a nie, nie tylko we własnym imieniu, nie?
Daria: Tak, dokładnie. Dlatego te relację są naprawdę ważne. Jeżeli jest jakaś osoba, która źle się czuję w zespole, to najzwyczajniej w świecie no nie będzie dobrze pracowała tak? No bo to tak nie działa.
Kinga: W bardzo ciekawym kierunku poszłyśmy. Od niemarnowania czasu i odmawiania menadżerom do dobrych relacji w pracy, siedzenia w biurze. [śmiech]
Daria: No ale to tak jak wspomniałaś nie, to też jest te właśnie niemarnowanie czasu, no bo przy dobrych relacjach my pójdziemy do kogoś i po prostu zapytamy, a nie będziemy czekać, aż on zapyta czy nam coś trzeba.
Kinga: Czasami też nawet jak pytasz to, to jeżeli relacji między osobami nie ma, no to ktoś Ci nie powie, albo wstydzi zapytać, albo się boi, albo myśli, że to głupie pytanie. Ja też mam takie doświadczenia zwłaszcza z…
Daria: Nie ma głupich pytań, pamiętajmy.
Kinga: Właśnie.
Daria: Nie ma głupich pytań.
Kinga: Ludności, która nas słuchasz, nie ma głupich pytań, każde pytanie jest ważne. No dokładnie, no bo ja też nie wiem wielu rzeczy. Moja rola w projekcie jest inna, niż rola, nie wiem, project menedżera, niż rola, niee wiem, wielu rzeczy moja rola w projekcie jest inna niż rola business analityka. Mogę nie wiedzieć tak oczywiście ma do tego prawo.
Daria: Oczywiście, że tak, dlatego trzeba pytać i te pytania, naprawdę, one świadczą tylko o tym, że my jesteśmy zaangażowani i chcemy po prostu dobrze dla projektu. A nie, że nie wiemy, bo jesteśmy niedoświadczeni i nie ogarniamy po prostu.
Kinga: Każdy na początku nie ogarniał. Zostańmy z tą złotą myślą. [śmiech]
Daria: Tak.
Kinga: Dobra, fajna ta nasza rozmowa, podoba mi się, podobają mi się te Twoje pomysły na takie nawiązywanie relacji. No, bo rzeczywiście to jest ważne. Podobają też mi się Twoje pomysły na takie redukowanie rzeczy, które są zupełnie niepotrzebne w tych projektach, no albo potrzebne troszeczkę. Ale tak myślę sobie, że na przykład, jeżeli zredukujemy czas testów manualnych, tak jak w Twoim przypadku mówisz, że robiliście manualną regresję mając automatyczną regresję. Regresowaliście dokładnie to samo, super. No to ten czas można by poświęcić nie wiem, na napisanie skryptów do performansu, albo na jakieś takie niefunkcjonalne testowanie, nie? No bo to zazwyczaj czasu w projekcie nie ma, bo przecież to jest coś zupełnie innego, niż testowanie funkcjonalne. No, a rzeczywiście można by ten zaoszczędzony czas przeznaczyć na jakieś inne aktywności.
Daria: Tak to prawda. I wszyscy narzekamy, że biegamy z pustymi taczkami, nie. I po prostu mamy po dziurki w nosie zadań i jakiś tam różnych rzeczy do zrobienia, lista nam się nie kończy. Natomiast właśnie tak trochę zamknięte koło nam się tutaj tworzy. I zamiast usiąść i się zastanowić chwilę, co zrobić, żeby znaleźć ten czas i na przykład tutaj redukując właśnie w ogóle czas poświęcony na regresję z manualnej i powierzyć tylko automatom, nie? I mieć tą przestrzeń na jakieś nowe rzeczy, my cały czas jesteśmy właśnie w tym takim błędnym kole i sobie ciśniemy, nie? Tak warto naprawdę się czasami nie wiem, usiąść sobie na spokojnie, przemyśleć, zobaczyć co my możemy zrobić, żeby po prostu nam się żyło lepiej?
Kinga: I z tą myślą was zostawimy. Zawsze jest miejsce na improvement, reużywajcie swoich rozwiązań, pytajcie kolegów, nawiązujcie relacje. A jak będzie w biurze to możecie się z nami spotkać. [śmiech] 
Daria: Zapraszamy.
Kinga: Zapraszamy. Dziękujemy wam bardzo za wysłuchanie naszej rozmowy.
Daria: Dzięki i powodzenia w niemarnowaniu czasu.
Kinga: Do dalszej pracy i poszukiwania odpowiedzi na to, jak lepiej wykorzystywać czas w pracy i jak lepiej dogadywać się z ludźmi? Polecamy wam książkę Otoczeni przez idiotów. Jak dogadać się z tymi, których nie sposób zrozumieć.”, i tego samego autora „Mój szef jest idiotą”. To autorem jest tutaj Erikson Thomas. Książki są naprawdę otwierające głowę, pokazujące w jaki sposób myślą inni ludzie i to może bardzo pomóc w pracy, w dogadywaniu się, a tym samym w zyskiwaniu więcej czasu dla siebie, więcej czasu na relację, w swoich działaniach. 
KONIEC