Lepsza współpraca dzięki zaangażowaniu projektantów w proces przeglądu kodu
Opublikowany: 2022-03-10Płynna współpraca między programistami a projektantami to coś, do czego wszyscy aspirują, ale jest to bardzo trudne. Ale przy dzisiejszej zaawansowanej sieci trudno – jeśli nie niemożliwe – zbudować naprawdę świetny produkt bez współpracy między dyscyplinami. Ze względu na szereg technologii wymaganych do zbudowania produktu, produkt może odnieść prawdziwy sukces tylko wtedy, gdy wszystkie dyscypliny — programiści i projektanci, twórcy treści i stratedzy ds. doświadczeń użytkownika — są głęboko zaangażowane od wczesnych etapów projektu. Kiedy tak się dzieje, wszystkie końce tego, co jest potrzebne do zbudowania produktu, naturalnie łączą się w jednolitą całość, a tym samym wspaniały produkt.
Z tego powodu nikt już tak naprawdę nie promuje procesów kaskadowych. Niemniej jednak zaangażowanie innych osób na wczesnym etapie, zwłaszcza osób z innych dyscyplin, może być przerażające. W najgorszym przypadku prowadzi to do „projektowania przez komisję”.
Co więcej, zarówno projektanci, jak i stratedzy treści często mają doświadczenie w dziedzinach, w których jedyny twórczy geniusz jest wciąż ideałem. Jeśli ktoś inny udowodni twoją pracę, może być zagrożeniem dla twojej kreatywności.
Jak więc wcześnie zaangażować ludzi, aby uniknąć wodospadu, ale jednocześnie upewnić się, że nie przygotowujesz się do projektu przez komisję? Znalazłem swoją odpowiedź, gdy dowiedziałem się o przeglądach kodu.
Aha! Za chwilę
W lipcu 2017 założyłem Confrere wraz z dwoma programistami i szybko zatrudniliśmy naszego pierwszego inżyniera (sam nie jestem programistą, jestem bardziej UX lub projektantem treści). Nasza współpraca przebiegała zaskakująco gładko, do tego stopnia, że podczas naszych retrospektyw motywem przewodnim było to, że wszyscy czuliśmy, że „robimy to dobrze”.
Usiadłem z moimi kolegami, aby spróbować określić, co dokładnie „robiliśmy dobrze”, abyśmy mogli zachować to uczucie, nawet gdy nasza firma rosła, a nasz zespół się powiększał. Doszliśmy do wniosku, że wszyscy doceniamy to, że cały zespół był zaangażowany od samego początku i że w naszych wzajemnych opiniach byliśmy szczerzy i jasno. Nasz CTO Dag-Inge dodał: „To działa, ponieważ robimy to jako rówieśnicy. Nie jesteś krytykowany i po prostu dostajesz listę błędów”.
Słowo „rówieśnik” dało mi chwilę aha. Zdałem sobie sprawę, że ci z nas, którzy pracują w zakresie UX, projektowania i treści, mogą się wiele nauczyć od programistów, jeśli chodzi o współpracę.
Recenzja w formie recenzji kodu jest niezbędna do tego, jak powstaje oprogramowanie. Dla mnie przeglądy kodu stanowią inspirację do usprawnienia współpracy w naszych własnych dziedzinach, ale także stanowią model współpracy między różnymi dziedzinami i dyscyplinami.
Jeśli znasz już przeglądy kodu, możesz pominąć następną sekcję.
Co to jest przegląd kodu?
Przegląd kodu można przeprowadzić na różne sposoby. Obecnie najbardziej typową formą przeglądu kodu są tzw. pull requesty (przy użyciu technologii zwanej git). Jak pokazano poniżej, żądania ściągnięcia informują inne osoby w zespole, że deweloper ukończył kod, który chce połączyć z główną bazą kodu. Pozwala także zespołowi na przeglądanie kodu: przekazują opinię na temat kodu, zanim zostanie on scalony, na wypadek gdyby wymagał poprawy.
Pull requesty mają jasno określone role: jest autor i recenzent (recenzenci).
Jako przykład, powiedzmy, że nasz starszy inżynier Ingvild dokonał zmiany w procesie rejestracji Konfratra. Zanim zostanie on włączony do głównej bazy kodu i wysłany, ona (autor) tworzy pull request, aby poprosić o recenzję naszego CTO Dag-Inge (recenzenta). Nie będzie dokonywał żadnych zmian w jej kodzie, tylko doda swoje komentarze.
To od Ingvild zależy, jak będzie postępować w związku z opiniami, które otrzymała w recenzji. Zaktualizuje swoje żądanie ściągnięcia o zmiany, które uzna za stosowne.
Gdy recenzenci zatwierdzą żądanie ściągnięcia, Ingvild może następnie scalić swoje zmiany z główną bazą kodu.
Po co zawracać sobie głowę przeglądem kodu?
Jeśli nigdy nie robiłeś przeglądu kodu, powyższy proces może wydawać się biurokratyczny. Jeśli masz wątpliwości, oto mnóstwo wpisów na blogu i badań naukowych na temat zalet recenzji kodu.
Przeglądy kodu nadają całej firmie ton, że wszystko, co robimy, powinno być otwarte na weryfikację ze strony innych i że taka analiza powinna być mile widzianą częścią przepływu pracy, a nie być postrzegana jako zagrożenie.
— Bruce Johnson, współzałożyciel Full Story
Przegląd kodu zmniejsza ryzyko. Posiadanie kogoś, kto sprawdzi twoją pracę, a także świadomość , że ktoś sprawdzi twoją pracę, pomaga wyeliminować błędy i podnosi jakość. Ponadto zapewnia spójność i pomaga każdemu członkowi zespołu zapoznać się z większą ilością kodu.
Poprawnie wykonany przegląd kodu buduje również kulturę współpracy i otwartości. Próba zrozumienia i krytyki pracy innych osób to doskonały sposób na naukę, podobnie jak uzyskanie szczerych informacji zwrotnych na temat swojej pracy.
Zawsze, gdy co najmniej dwie osoby przeglądają kod, ograniczają również pomysły na „mój” kod i „twój” kod. To nasz kod.
Biorąc pod uwagę te zalety, recenzja nie powinna dotyczyć tylko kodu.
Zasady przeglądu dla wszystkich dyscyplin, nie tylko kodu
W przypadku recenzji zawsze jest jeden autor i jeden lub więcej recenzentów. Oznacza to, że możesz zaangażować ludzi na wczesnym etapie bez wchodzenia w projektowanie przez komisję.
Najpierw muszę wspomnieć o dwóch ważnych czynnikach, które wpłyną na zdolność twojego zespołu do robienia korzystnych recenzji. Niekoniecznie musisz je opanować, ale jako minimum powinieneś dążyć do:
- Ty i Twoi koledzy szanujecie siebie nawzajem i swoje dyscypliny.
- Jesteś wystarczająco pewny siebie we własnej roli, tak że czujesz, że możesz zarówno dawać, jak i otrzymywać krytykę (jest to również związane z bezpieczeństwem psychologicznym zespołu).
Nawet jeśli nie recenzujemy kodu, można się wiele nauczyć z istniejących najlepszych praktyk dotyczących recenzji kodu.
W naszym zespole staramy się przestrzegać następujących zasad podczas dokonywania recenzji:
- Krytykuj dzieło, nie autora.
- Bądź krytyczny, ale bądź uprzejmy i ciekawy.
- Rozróżnij a) sugestie b) wymagania, c) punkty, które wymagają omówienia lub wyjaśnienia.
- Przenieś dyskusje z tekstu na twarzą w twarz. (Liczba filmów)
- Nie zapomnij pochwalić dobrych części! Co jest mądre, kreatywne, solidne, oryginalne, zabawne, ładne i tak dalej?
Zasady te nie zostały właściwie spisane, dopóki nie omówiliśmy, dlaczego nasza współpraca układa się tak dobrze. Wszyscy czuliśmy, że wolno nam i oczekuje się od nas zadawania pytań i sugerowania ulepszeń, i że naszą motywacją zawsze było wspólne zbudowanie czegoś wspaniałego, a nie krytykowanie innej osoby.
Ponieważ jasno określaliśmy, jakiego rodzaju opinie przekazujemy, a także pamiętaliśmy, aby chwalić się nawzajem za dobrą pracę, robienie recenzji było raczej pozytywną siłą niż demotywacją.
Przykład
Aby pokazać, w jaki sposób nasz zespół korzysta z recenzji w różnych dyscyplinach i podczas całego procesu, przyjrzyjmy się, jak różni członkowie naszego zespołu przełączali się między rolami autora i recenzenta, gdy tworzyliśmy nasz proces rejestracji.
Krok 1: Zbieranie wymagań
Autor: Ida (UX)
Recenzenci: Svein (strategia), Dag-Inge (inżynieria), Ingvild (inżynieria).
Sesje na tablicy mogą być wyczerpujące, jeśli nie ma dla nich struktury. Aby zachować produktywność i kreatywność, używamy struktury autor/recenzent, nawet w przypadku czegoś tak pozornie podstawowego, jak burza mózgów na tablicy. W tym przypadku, w którym wymyślaliśmy wymagania dotyczące procesu rejestracji, ja zostałem autorem, a reszta zespołu przekazała swoje uwagi i występowała jako recenzenci. Ponieważ wiedzieli również, że będą mogli przejrzeć to, co wymyśliłem w kroku 2 (dużo więcej możliwości korekt, sugestii i ulepszeń), pracowaliśmy szybko i byliśmy w stanie uzgodnić wymagania w czasie krótszym niż 2 godziny.
Krok 2: Makieta z mikrokopią
Autor: Ida (UX)
Recenzenci: Ingvild (inżynieria), Eivind (projekt), Svein (strategia).
Jako autor stworzyłem makieta procesu rejestracji za pomocą mikrokopii. Czy proces rejestracji miał sens, zarówno z perspektywy użytkownika, jak i inżynierów? I jak możemy poprawić przepływ z perspektywy designu i frontendu? Na tym etapie niezbędna była praca w formacie, w którym wszystkie branże mogą łatwo przekazywać informacje zwrotne (zdecydowaliśmy się na Dokumenty Google, ale można było to również zrobić za pomocą narzędzia takiego jak InvisionApp).
Krok 3: Implementacja procesu rejestracji
Autor: Ingvild (inżynieria)
Recenzent: Ida (UX) i Dag-Inge (inżynieria).
Uzgodniliśmy przepływ, pola wejściowe i mikrokopię, więc wdrożenie tego należało do Ingvilda. Dzięki Surge możemy automatycznie tworzyć podglądowe adresy URL zmian, aby osoby, które nie potrafią odczytać kodu, również na tym etapie mogły wyrazić opinię.
Krok 4: Testowanie użytkownika
Autor: Ida (UX)
Recenzent: Użytkownicy.
Tak, uważamy, że testowanie przez użytkowników jest formą recenzji. Przeprowadziliśmy nasz nowo utworzony proces rejestracji twarzą w twarz z rzeczywistymi użytkownikami. Ten krok dał nam mnóstwo wglądu, w wyniku czego nastąpiły najbardziej znaczące zmiany w procesie rejestracji.
Krok 5: Projekt
Autor: Eivind (projekt)
Recenzenci: Ingvild (inżynieria) i Ida (UX).
Kiedy projekt pojawia się nagle w kroku 5, może wyglądać jak proces kaskadowy. Jednak nasz projektant Eivind był już zaangażowany jako recenzent od kroku 2. Przekazał wiele przydatnych opinii na tym etapie, a także był w stanie zacząć myśleć o tym, jak możemy ulepszyć projekt przepływu rejestracji poza istniejące moduły w naszym systemie projektowania. Na tym etapie Eivind może również pomóc w rozwiązaniu niektórych problemów, które zidentyfikowaliśmy podczas testów użytkowników.
Krok 6: Wdrożenie
Autor: Ingvild (inżynieria)
Recenzent: Eivind (projekt), Ida (UX) i Dag-Inge (inżynieria).
A potem wracamy do wdrażania.
Dlaczego recenzja działa
Podsumowując, zawsze jest tylko jeden autor, dzięki czemu unika się projektowania przez komisję. Angażując szereg dyscyplin jako recenzentów na wczesnym etapie, unikamy procesu kaskadowego.
Ludzie mogą wcześnie zgłaszać swoje obawy, a także zacząć myśleć o tym, jak mogą wnieść swój wkład później. Jasno określone role utrzymują proces na torze.
Regularne przeglądy instruktażowe
Czerpiąc inspirację z przewodników po kodzie, wykonujemy również regularne przeglądy przewodników z różnymi foci, kierując się następującymi zasadami:
- Opis przejścia jest wykonywany wspólnie.
- Jedna osoba jest odpowiedzialna za przegląd i dokumentację.
- Chodzi o to, aby identyfikować problemy , a niekoniecznie je rozwiązywać.
- Wybierz format , który daje jak najwięcej kontekstu, aby łatwo było później działać na podstawie wyników (np. InvisionApp w przypadku recenzji wizualnych, Dokumenty Google w przypadku tekstu itd.).
Przeprowadziliśmy przegląd instruktaży dla takich rzeczy, jak audyty ułatwień dostępu, przeglądanie żądań funkcji, audytowanie implementacji projektu i przeprowadzanie heurystycznych ocen użyteczności.
Kiedy przeprowadzamy nasze kwartalne przeglądy ułatwień dostępu, nasz konsultant ds. ułatwień dostępu Joakim najpierw przegląda interfejs i dokumenty oraz ustala priorytety problemów znalezionych w udostępnionym Arkuszu Google. Joakim następnie prowadzi nas przez najważniejsze problemy, które zidentyfikował.
Spotkanie twarzą w twarz (lub przynajmniej na wideo), aby omówić problemy, pomaga stworzyć środowisko do nauki, a nie poczucie bycia nadzorowanym lub mikrozarządzanym.
Jeśli zauważysz, że zawsze jesteś związany z czymś, co ma zostać wydane, lub naprawiasz to, co znajduje się na górze Twojej skrzynki odbiorczej, recenzje mogą pomóc temu zaradzić. Jeśli przeznaczysz regularne pół dnia na przeglądanie już wykonanej pracy, możesz zidentyfikować problemy, zanim staną się pilne. Może również pomóc w ponownym skupieniu się i upewnieniu się, że priorytety są zgodne z zasadami. Być może Twój zespół nie powinien zaczynać tworzenia nowej funkcji, zanim nie będziesz mieć pewności, że istniejące funkcje spełniają Twoje standardy.
Testowanie użytkownika to forma przeglądu
Ważną motywacją do przeglądów kodu jest zmniejszenie ryzyka. Robiąc to za każdym razem, gdy wprowadzasz zmianę lub dodajesz coś nowego do swojego produktu, a nie tylko wtedy, gdy podejrzewasz, że coś nie jest zgodne z normami, zmniejszasz szansę na wysłanie błędów lub słabych funkcji. Uważam, że powinniśmy spojrzeć na testy użytkowników z tej samej perspektywy.
Widzisz, jeśli chcesz zmniejszyć ryzyko wysyłki z poważnymi problemami z użytecznością, testowanie użytkowników musi być częścią twojego procesu. Samo sprawdzenie interfejsu przez projektantów UX nie wystarczy. Kilka badań wykazało, że nawet eksperci ds. użyteczności nie potrafią zidentyfikować wszystkich rzeczywistych problemów z użytecznością. Średnio 1 na 3 problemy zidentyfikowane przez ekspertów to fałszywe alarmy — w praktyce nie były to problemy dla użytkowników. Ale co gorsza, 1 na 2 problemy, które faktycznie mieli użytkownicy, zostały przeoczone przez ekspertów.
Pomijanie testów użytkowników jest tak samo dużym ryzykiem jak pominięcie przeglądu kodu.
Czy przegląd oznacza śmierć kreatywności?
Osoby zajmujące się projektowaniem, doświadczeniem użytkownika i treściami często mają wykształcenie wykształcone w szkołach artystycznych lub może w literaturze, w której jedynym twórcą lub twórczym geniuszem artystycznym jest okrzyknięty ideałem. Jeśli cofniesz się do historii, tak samo było w przypadku programistów. Z biegiem czasu zmieniło się to z konieczności, ponieważ tworzenie stron internetowych stało się bardziej złożone.
Jeśli przylgniesz do idei kreatywności pochodzącej gdzieś z głębi ciebie, idea powtórki może wydawać się groźna lub przerażająca. Ktoś wtrąca się w twoją niedokończoną pracę? Auć. Ale jeśli myślisz o kreatywności jako o czymś, co może wypływać z wielu źródeł, w tym dialogu, współpracy lub jakiejkolwiek formy inspiracji (z zewnątrz lub z twojego wnętrza), wtedy recenzja jest tylko atutem i szansą.
Dopóki tworzymy coś dla sieci, nie ma mowy o współpracy z innymi ludźmi, czy to w naszej własnej dziedzinie, czy innych. A dobry pomysł przetrwa recenzję.
Stwórzmy razem coś wspaniałego.