Agile by Example Light 2019
Agile by Example Light 2019

Relacja z Agile By Example Light 2019 cz.2

Wartościowe spotkania i konferencje mają to do siebie, że ich treści są ponadczasowe. Tak było również z ABE Light 2019, które odbyło się wiosną tego roku. Dlatego z (umiarkowanie) czystym sumieniem, dzielę się z Wami najciekawszymi elementami z wystąpienia Agnieszki Balcer-Thinlay o tym, jak odfiltrowywać nietrafione pomysły na rozwój produktu, bazując na testach z użytkownikami i danych. Tym z Was, którzy nie czytali pierwszej części relacji z konferencji, a w niej podsumowania prelekcji gościa głównego – Jurgena de Smet oraz prowadzonych przez niego warsztatów, polecam nadrobienie zaległości. 

Agnieszka Balcer-Thinlay – Odfiltrowywanie złych pomysłów: jak decydujemy w Codility, czego nie robić (Filtering out bad ideas: how we decide what not to do @Codility



Agnieszka Balcer-Thinlay jest badaczem (ang. researcher) w Codility – firmie, która oferuje testy ułatwiające firmom ocenę kompetencji programistów ubiegających się u nich o pracę. Na profilu Agnieszki na LinkedInie przeczytacie, że jednym z głównych obszarów jej działania jest wprowadzanie do organizacji procesu podejmowania decyzji na bazie danych (ang. Introducing data driven decision making process to the organisation). Prelegentka podzieliła się z nami dwoma przykładami, w których Codility nie zdecydowało się na wprowadzenie do swojego produktu na pozór atrakcyjnych zmian: jeden dotyczył doświadczenia kandydata, drugi oczekiwań klientów. Jak się pewnie domyślacie, obie decyzje zostały podjęte na bazie danych właśnie. 

Pierwsza zmiana to umożliwienie kandydatom eksportowania rozwiązywanych zadań na środowisko programistyczne, z którego korzystają na co dzień (tzw. IDE – ang. an integrated development environment). Propozycja brzmi sensownie. Dlaczego by nie uprzyjemnić pierwszego etapu procesu rekrutacji, dając kandydatom możliwość rozwiązywania testów w znajomym widoku i z wykorzystaniem znanych opcji? Ponieważ wprowadzenie zmiany na produkcję, byłoby dla firmy kosztowne i czasochłonne, przygotowano mockupy proponowanych rozwiązań i zorganizowano panel ekspercki z udziałem małej grupy użytkowników, aby je z nimi przetestować. Szybko okazało się jednak, że rozwiązywanie testów w widoku Codility było dla nich bardziej intuicyjne i mniej czasochłonne, niż korzystanie z rozwiązania, wymagającego eksportowania zadań na IDE. Przy okazji odkryto natomiast, że brakująca funkcja, na którą warto poświęcić czas i pieniądze to autouzupełnianie, na co nikt wcześniej nie wpadł. 

Korzyści dla firmy to oszczędzenie trzech miesięcy pracy programistów i możliwość przekazania im innego zadania, z większym potencjałem.

 

Druga zmiana to wprowadzenie do testów limitu czasu na rozwiązanie poszczególnych zadań. Zabiegali o nią jedni z większych klientów, czyli firm rekrutujących, budziła natomiast wątpliwości programistów z Codility, którzy mieli wprowadzić opcję do produktu. Z perspektywy tych ostatnich taka zmiana znacznie zmniejszyłaby kandydatom komfort pracy. Słysząc ten dwógłos, Agnieszka zaproponowała, aby przeanalizować dane z ostatniego roku i sprawdzić, jak wprowadzenie oczekiwanego przez klientów limitu, wpłynęłoby na wyniki testów. W tym przypadku wnioski również były zaskakujące dla Codility. Zmiana wpłynęłaby negatywnie na wyniki 34% kandydatów, którzy przekroczyliby czas wykonania minimum jednego zadania, a w tym aż 25% kandydatów, wyniki których były świetne, bo otrzymali 90% i więcej punktów. W efekcie Product Manager podjął decyzję o nie wprowadzaniu zmiany i wyjaśnił tę decyzję klientom, popierając ją danymi. Według Agnieszki, dzięki temu firma oszczędziła czas i pieniądze, a programiści zyskali poczucie realnego wpływu na produkt, który współtworzą. Decyzja miała też pozytywny wpływ na relacje z klientami oraz ich zaufanie do firmy, wzmacniając jej wizerunek jako eksperta w dziedzinie.

Motyw zdobywania górskich szczytów, które widzicie na slajdach, nie jest przypadkowy. Na wstępie swojej prezentacji Agnieszka powołała się na cytat amerykańskiego himalaisty Eda Viestursa, zdobywcy Korony Himalajów, który wszedł na wszystkie ośmiotysięczniki bez użycia butli z tlenem: “Słuchaj gór”. W przypadku przytoczonych przez nią przykładów było to “wsłuchanie się” w doświadczenie użytkownika – w pierwszym przykładzie dosłowne, w drugim za sprawą analizy już dostępnych danych. 

Trzy warte uwagi przesłania, którymi podsumowała swoje wystąpienie to: 

Trzy warte uwagi przesłania, którymi prelegentka podsumowała swoje wystąpienie to: 

1. Nie obawiaj się odmawiać swoim klientom, jeśli masz ku temu dobre powody (ang. Don’t be afraid to refuse your customers when you have good reasons for it)

2. Kiedy robisz badania, nie obawiaj się małych prób – czasem wszystko, czego potrzebujesz, to inna perspektywa (ang. When you do research, don’t be afraid of small samples – sometimes all you need is a different perspective)

3. Kluczowa rola badacza polega na obalaniu fałszywych hipotez (i tylko jeśli to nie jest możliwie – na mówieniu, jak robić rzeczy) (ang. Main role of research is to refute the hypothesis (and only if not possible – tell you how to do things).

Prezentacja na tyle mnie zaciekawiła, że postanowiłam ją dla Was szczegółowo streścić. Jednocześnie podczas pisania tego materiału, pojawiły mi się pytania i wątpliwości typu: Jaki wpływ na wyniki pierwszego testu miałoby zwiększenie ilości paneli eksperckich do trzech lub czterech? Na jakiej podstawie uznano, że ten jeden jest wystarczający? W jaki sposób zostali wybrani do niego zaproszeni programiści i jaki to mogło mieć wpływ na wyniki? Skoro programiści z drugiego przykładu nie wiedzieli o limicie czasu, nie zwracali uwagi na to, jak długo wykonują zadanie. Być może gdyby musieli wykonać zadanie w określonym czasie, zrobiliby to poprawnie, a zatem zrobienie testu typu A/B dla opcji limitu, czyli wprowadzenie rozwiązania na produkcję dla wybranej grupy kandydatów, dałoby inne wyniki? Mogłabym mnożyć tego typu pytania, podsumuję je natomiast dwoma refleksjami:

1. W przypadku przygotowywania prezentacji dotyczących badań, warto dodać metakomentarz dotyczący przyjętych założeń, hipotez, teorii statystycznych po to, aby przy okazji edukować słuchaczy,

2. Można próbować opomiarować i śledzić niemal wszystkie opcje w produkcie i zarazem nie potrafić podjąć na ich bazie żadnej konstruktywnej decyzji poza taką, że “potrzebujemy więcej analiz i danych”. Dlatego bardzo doceniam omówione przez Agnieszkę Balcer-Thinlay: zadbanie o feedback od użytkowników i klientów, eksperymentowanie z rozwiązaniami, wsłuchanie się w głos zespołu odpowiedzialnego za produkt, decyzyjność i dynamikę działań. Wszystkie te elementy uważam za kluczowe w zwinnym podejściu, o czym napisałam szerszej w dedykowanym materiale o agile.

Nagranie z wystąpieniem Agnieszki jest dostępne na You Tube (21 min): https://www.youtube.com/watch?v=qZtc5kbsagY 

Jeśli zainteresował Was ten materiał, polecam Wam również moje wcześniejsze artykuły dotyczące tego, jak sprawdzać czy nasz pomysł na nowy produkt lub opcję jest faktycznie dobry i w jaki sposób najszybciej i najtaniej wykryć ewentualne błędne założenia:

Dwa inne wystąpienia z konferencji ABE Light również znajdziecie na You Tube:

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x