Chciałbym podzielić się z Wami pewnym podejściem, bardzo istotnym, gdy chcemy by nasz zespół można było określić jako “high performing”. I nie chodzi tu o konkretny proces czy framework. Raczej o zbiór zasad, nawyków i ustaleń stosowanych przez zespół, w celu strukturyzowania swojej pracy. Opiszę także kilka problemów związanych z wydajnością zespołu.
Niedawno zapytano mnie, co dokładnie mam na myśli, mówiąc o “high performing team’ie”. Dla mnie to zespół, który jest w stanie dostarczyć adekwatne oprogramowanie, do adekwatnego odbiorcy, we adekwatnym czasie. Przez „właściwe oprogramowanie” mam na myśli takie, którego złożoność i zgodność z wymaganiami/standardami UX odpowiada obecnemu etapowi życia produktu.
„Właściwy odbiorca” oznacza ciągłe dostarczanie systemu do użytkownika, co może pomóc nam zweryfikować pomysł na danym etapie. A dostarczenie we „właściwym czasie” to branie pod uwagę tego, w jaki sposób dowiezienie produktu w jego obecnej formie na teraz, może wpłynąć na biznes, w porównaniu z tym, jak zmieniłby się ten wpływ, gdybyśmy dostarczyli go później, jako „ulepszoną” wersję produktu.
Moje spostrzeżenia
Jedną z kluczowych rzeczy, których nauczyłem się w ciągu ostatnich lat, jest to, iż wiele zespołów programistycznych nie pasuje do tej definicji. W rzeczywistości, wszystkie zespoły w jakiś stopniu, nie są do końca efektywne. Z moich obserwacji wynika, iż istnieją pewne ‘nieefektywności’, wspólne dla wielu zespołów, które sprawiają, iż nie jest im łatwo stać się najlepszymi wersjami samych siebie.
Praca zarówno w software house, jak i jako freelancer, przynosi korzyści w postaci możliwości spotykania się i współpracy z wieloma różnymi zespołami oraz dostrzegania pewnych wspólnych wzorców. Uwielbiam to w mojej pracy i uważam, iż właśnie te spotkania zapewniają mi wiele możliwości rozwoju. Dowiedziałem się o sobie tego, iż rozwiązywanie tych ‘nieefektywności’ i pomaganie zespołom w osiąganiu wysokiej wydajności jest tym, co najbardziej napędza mnie w codziennej pracy i jest moim preferowanym sposobem wpływania na biznes.
Przedłużający się czas development’u
Może istnieć wiele czynników wpływających na długi czas development’u, ale tutaj chciałbym skupić się na dwóch z nich – małej szansy wykonania usługi (na poziomie logicznym lub UI/UX) oraz dostarczaniu usługi, która nie w pełni pasuje do wymagań stawianych przez biznes. Zaskakująco często ma to związek z podejściem zespołowym. Dlaczego? O ilu przypadkach zespołów działających w poniżej podany sposób słyszałeś? Przygotuj wymagania (biznes), stwórz UI i UX (product designer), stwórz kilka zadań (project manager), oszacuj, zacznij nad nimi pracować, wróć z feedback’iem mówiącym o małej szansie stworzenia tego systemu.
Stosowanie powyższych kroków dla tylko jednej dużej funkcji jest już kiepskim pomysłem, a widziałem zespoły pracujące w ten sposób nad całymi systemami. Gdy ktoś (właściciel danego biznesu, product designer) włożył dużo pracy w przygotowanie tych wymagań, a nie jest zbyt chętny do tego, by wykonać kroku wstecz i wprowadzić jakieś zmiany, to stawia to zespół w trudnym położeniu. Powoduje to sytuację, w której zespół musi wykonywać dodatkową pracę, której można było uniknąć, albo w ogóle nie jest w stanie dostarczyć rozwiązania.
W jaki sposób my, jako zespół programistów, możemy przyczynić się do skrócenia czasu development’u i odnieść sukces w dostarczaniu adekwatnej usługi we adekwatnym czasie?
- Angażuj się na wczesnym etapie – rozmawiaj z właścicielami biznesu i product designerami. Upewnij się, iż dostarczasz im odpowiednie informacje dotyczące wykonalności proponowanego przez nich rozwiązania i narzędzia pozwalające na oszczędzenie czasu, za każdym razem, gdy widzimy taką okazję. Być może nie musimy wdrażać niestandardowego systemu mailingowego, a inne rozwiązanie może okazać się tak samo skuteczne przy mniejszym nakładzie czasu i pieniędzy.
- Zrób demo naszej pracy, zaczynając od pierwszego tygodnia pracy, aby ‘stakeholderzy’ widzieli swoje pomysły wprowadzane w życie możliwie najszybciej i by mogli przekazać feedback na ich temat oraz nadać kierunek pracy, jeżeli jest to konieczne. Nie uzyskasz takiego efektu, jeżeli zdecydujesz się informować o postępach pracy w tylko niektórych zadaniach lub, co gorsza, w ogóle nie rozmawiasz ze ‘stakeholderami’ w trakcie development’u.
- Wydawaj wersje systemu, z aktualnym postępem prac, już od pierwszego tygodnia. Dzięki temu ‘stakeholderzy’ będą mogli nie tylko śledzić swoje pomysły opatrzone naszym komentarzem, ale także ich „dotknąć”. To w większym stopniu pomoże im zrozumieć to, co klient końcowy zobaczy i poczuje, korzystając z naszego produktu. Trudno jest zweryfikować, czy zaprojektowany przez nas UX jest „poprawny” oglądając filmik o danej aplikacji, zaprezentowany przez jakiegoś programistę.
Dostarczanie wartości użytkownikom w dużych porcjach
Bardzo często zdarza się, iż zespoły (a czasem całe firmy) za bardzo koncentrują się na tym, co wyobrażają sobie jako „ostateczną” wersję produktu lub funkcji i na jakimś sztucznym terminie ich dostarczenia. Czasami zdarza się to również na poziomie technicznym – na pewno nie raz słyszałeś „przepiszmy ten system od zera”. Może to mieć olbrzymie, negatywne konsekwencje dla całej firmy. Często decydujemy się na duże ryzyko w kontekście naszych pomysłów, zamiast weryfikować je tak szybko, jak to możliwe, co mogłoby pomóc nam określić kierunek pracy.
W najgorszym przypadku (tj. w startupach z krótkim runaway’em) może to być zabójcze dla biznesu, ponieważ zwykle nie będziemy mieli wystarczającej ilości pieniędzy, aby poradzić sobie ze zmianą na tak późnym etapie. Można by pomyśleć, iż nie ma to nic wspólnego z pojedynczym zespołem, ponieważ może to być decyzja „wyższego szczebla”, jednak zespół programistów może wspierać bardziej iteracyjne podejście w następujący sposób:
Upewnij się, iż wdrożenie i wypuszczenie produktu są dwoma oddzielnymi procesami, tak aby firma mogła łatwo podjąć decyzję odnośnie do tego, co w tej chwili wdrożyliśmy, nacisnąć jeden lub dwa przyciski i udostępnić funkcję użytkownikom.
Udostępnij możliwość sterowania tym, do jakiego podzbioru użytkowników trafia dana zmiana (być może taka decyzja nie jest tak “poważna”, jeżeli jest skierowana do 2% naszych użytkowników).
Korzystaj z narzędzi, które pozwalają wygodnie pracować nad funkcjami, które nie są udostępnianie, ale dziel się bieżącymi postępami pracy z użytkownikami, dzięki czemu dwa powyższe punkty są możliwe bez zmian w samym kodzie.
Udzielaj feedback’u na temat decyzji „produktowych” i sugeruj rozwiązania, które można zastosować, aby jak najszybciej zweryfikować naszą pracę z użytkownikami (może nie potrzebujemy możliwości logowania się za pośrednictwem serwisów społecznościowych od pierwszego dnia, biorąc pod uwagę, iż ich wdrożenie zajmie jeszcze dwa tygodnie?
Brak widocznych postępów w pracy poszczególnych członków zespołu
Ile razy natrafiłeś na programistę, który przez tydzień lub dwa nie dzieli się postępami w pracy z resztą zespołu? Albo słyszałeś: „Pracuję nad zadaniem X, nie napotkałem jeszcze żadnych problemów” czwarty dzień z rzędu podczas ‘daily’? A potem, piątego dnia, usłyszałeś od innego programisty: „Będę przeglądał kod z zadania X”, ponieważ ilość zmian wprowadzonych w ciągu tych 4 dni była niemożliwa do zweryfikowania? Innym przypadkiem, specyficznym dla platform frontendowych, byłoby „Skończyłem Y, ale nie można tego jeszcze przetestować ani wyświetlić – backend nie jest gotowy”. Albo „Skończyłem Z, ale nie można tego przetestować bez ukończenia Y”.
Zdarza się to bardzo często, ale akceptujemy to, rezygnując z możliwości przekazywania sobie nawzajem feedback’u na temat swojej codziennej pracy bądź blokując innych członków zespołu (np: zezwalanie QA na testowanie choćby bez ukończenia pracy backendu). Zastosowanie takiego podejścia może na dłuższą metę pozwolić zaoszczędzić dużo czasu i pieniędzy.
Jak my, jako zespół programistów, możemy być bardziej ‘agile’ w naszej codziennej pracy?
- Wprowadź wysoki poziom granularności do naszej pracy – nie bierz pod uwagę całej funkcji, która będzie końcowym rezultatem naszej pracy, ale raczej skup się na mniejszych fragmentach, które możemy dostarczać każdego dnia.
- Upewnij się, iż ten podział jest stosowany na poziomie całej „podfunkcjonalności” – zamiast dostarczać warstwę networkingową, warstwę interfejsu użytkownika i warstwę logiczną jako oddzielne fragmenty, dostarcz możliwość wprowadzenia danych uwierzytelniających, akceptację warunków korzystania z serwisu, ‘login happy path’ i ‘error handling’ – ponieważ każde z nich można uznać za funkcjonalny fragment większej całości.
- Zastosuj taki podział nie tylko na etapie tworzenia kodu odpowiedzialnego za obsługę tych funkcjonalności, ale także w procesie testowania (upewnij się, iż te mniejsze składowe pracy mogą być wdrażane i testowane przez testerów manualnych lub innych członków zespołu).
- I jeszcze raz – miej na podorędziu odpowiednie narzędzia i oprogramowanie, które umożliwiają pracę w taki sposób.
Keep it Agile
„Agile” jako termin był w ostatnich latach używany w EB i treściach marketingowych tak często, iż wychodzi nam już bokiem. jeżeli jednak spojrzysz na zasady z manifestu agile, zobaczysz takie zdania: „Dostarczaj działające oprogramowanie z dużą częstotliwością […]”, “Biznes i deweloperzy muszą współpracować codziennie, przez cały czas trwania projektu.”, „Działające oprogramowanie jest podstawową miarą postępu.” Mają one już ponad dwadzieścia lat, a mimo to są przez cały czas aktualne, a podejście, które przedstawiłem w tym artykule, ma na celu wprowadzenie tych idei w życie. Mocno wierzę, iż zastosowanie tego podejścia jest pierwszym, dużym krokiem w kierunku stania się zespołem o wysokiej wydajności.
Narzędzia i oprogramowanie
Wspomniałem o tym wcześniej, ale chciałbym to podkreślić jeszcze raz: musisz mieć skuteczne narzędzia i kod, które pozwolą ci pracować w ten sposób. W przeciwnym razie, mimo wprowadzenia w życie tych wszystkich „dobrych” praktyk, zastosowanie takiego podejścia w codziennej pracy nie będzie łatwe, przez co zespół będzie miał przez cały czas trudności z osiągnięciem wysokiej wydajności.
Jak więc zbudować wydajny zespół?
Zacznijmy od podejścia zespołu. Upewnij się, iż zawiera on niektóre z wyżej wymienionych kluczowych cech. Utrzymuj wysoki poziom współpracy z produktem – upewnij się, można mieć wgląd w postępy pracy zespołu. Upewnij się też, iż każdy programista w zespole pracuje w małych iteracjach, dzięki czemu feedback jest przekazywany wystarczająco często. Niech dostarczanie produktu użytkownikom będzie łatwe – oddziel od siebie procesy udostępniania i wdrażania, spraw by te decyzje były bezpieczne, umożliwiając przekierowanie ich do określonego odsetka bazy użytkowników.
Zdjęcie główne artykułu pochodzi z unsplash.com.
