Wiele zespołów tworzących oprogramowanie ma trudności ze skutecznym włączeniem prac projektowych w swój proces Agile. Projektanci, którzy nie współpracują ściśle z resztą zespołu, zazwyczaj są źródłem dodatkowej pracy dla każdego (łącznie z nimi samymi) i mogą tworzyć szkodliwe bariery dla przepływu wiedzy wewnątrz zespołu produktowego.
W Atlassian współpracujemy ze sobą tak, aby w proces projektowania zaangażowany był cały zespół Agile. Dzięki temu, że wszyscy uczestniczą w procesie projektowania, możemy spojrzeć na problem z wielu różnych perspektyw i nie potrzebujemy dokumentacji, aby dzielić się pomysłami. W trakcie prezentacji omówimy, jak:
- zaangażować cały zespół w proces projektowania;
- zintegrować projektowanie z procesem Agile;
- uzyskać analizy dotyczące klientów, aby przyspieszyć etap testowania i ideacji.
Pytania i odpowiedzi
Poniższe pytania i odpowiedzi dotyczą różnych kwestii — od narzędzi projektowych wykorzystywanych przez Atlassian po sposób przetwarzania opinii klientów w firmie.
Pyt. 1: Czy projektant i programista to zawsze dwie różne osoby? Czy dobie HTML5 i nowoczesnych technik tworzenia interfejsów użytkownika projektanci są w stanie poradzić sobie bez podstawowych umiejętności kodowania?
Odp. 1: Granica między projektantem a programistą zaczyna się zacierać. Mamy w Atlassian projektantów, którzy zaczynali w zespołach inżynierskich, a także takich, którzy nie są w stanie napisać wiersza kodu. Mamy osoby o niezwykłych predyspozycjach wizualnych, architektów informacji oraz facyliatorów. Każda z tych osób ma inne zalety i ważne jest, aby je rozpoznać i wykorzystać w zespole.
Pyt. 2: Czy osoby spoza zespołu produktowego, na przykład marketingowcy, biorą udział w warsztatach dotyczących projektowania?
Odp. 2: Uczestnicy naszych warsztatów reprezentują różne dyscypliny, ale nie znaleźli się tutaj bez powodu. Zazwyczaj są to członkowie zespołów zarządzania projektami, inżynierskich i projektowych, jednak bywa również, że dołączamy osoby z działu wsparcia i marketingu, jeśli mogą wnieść spojrzenie na zagadnienie z innej perspektywy.
Warsztaty mogą trwać kilka dni i trudno jest zobowiązać się do udziału przez tak długi czas. Staram się udostępniać plan z wyprzedzeniem, aby uczestnicy wiedzieli, kiedy mogą wnieść coś od siebie, a kiedy wycofać się na kilka godzin. Powinna jednak istnieć stała grupa uczestnicząca przez cały czas.
Pyt. 3: Ja udało Ci się nakłonić ludzi do pracy nad szkicem, udziału w tworzeniu rysunków i zgłaszania pomysłów? Mam wrażenie, że product ownerzy i programiści niechętnie podejmują się taki zadań, czy to z bojaźni, czy z innych przyczyn.
Odp. 3: Ludzie wstydzą się podzielić swoimi pomysłami z grupą, a rysowanie na forum publicznym bywa jeszcze bardziej przytłaczające. Dlatego na tym etapie warsztatów lubię dzielić większą grupę na pary. To eliminuje presję związaną z pustą kartką, która zdaje się w Ciebie wpatrywać. Pozwala także ludziom wymieniać się pomysłami i zachować dynamikę działań.
Zauważyłem, że po udziale w jednej z takich sesji, wszyscy przestają odczuwać dyskomfort związany z procesem i uczestnictwo zaczyna sprawiać im przyjemność. W pokoju zawsze panuje szum, a ludzie toczą ze sobą ciekawe rozmowy.
Ważne, aby dać każdemu do zrozumienia, że nie interesują Cię arcydzieła. Chcesz po prostu uzyskać wizualizację ich pomysłu. Może to być szkic interfejsu, diagram czy zwykła lista punktowana — cokolwiek, co ułatwi uzyskanie wspólnego zrozumienia w całej grupie. Jeśli pomysł został zarejestrowany na papierze, możesz go zatrzymać w celach informacyjnych po zakończeniu warsztatów.
Pyt. 4: Jak dbasz o to, aby nowi członkowie zespołu projektowego byli na bieżąco?
Odp. 4: Mamy proces onboardingu, w którym uczestniczą wszyscy nowi członkowie zespołu projektowego. Rozpoczyna się od wprowadzenia w zagadnienie projektowania w Atlassian, w nasz proces oraz sposób współpracy z pozostałymi członkami zespołu produktowego. Przyglądamy się szczegółowo opracowanym zasadom projektowania i przedstawiamy przykłady ich zastosowania w praktyce. Prowadzone są zajęcia szkoleniowe, w trakcie których można dowiedzieć się więcej na temat naszych zasobów projektowych: wykorzystania person, wytycznych Atlassian dotyczących projektowania oraz porad strategicznych.
Na okres pierwszych kilku tygodni nowym projektantom przydzielamy również kolegę lub koleżankę. Taka osoba pokazuje im zależności i stopniowo przekazuje obowiązki.
Innym sposobem wdrażania nowego projektanta jest zaproszenie go do udziału w warsztatach w ciągu pierwszego tygodnia pracy. Są one dla takiej osoby doskonałą okazją do poznania zespołu produktowego i przekonania się w bezpośredni sposób, jak ze sobą współpracujemy. W ciągu pierwszych kilku miesięcy trzeba się wiele nauczyć, ale warsztaty to świetne miejsce do zagłębienia się w to środowisko i podejścia do problemu krok po kroku.
Pyt. 5: Jakie metody badań klientów uważasz za najbardziej przydatne? Badania terenowe, obserwację, testy użyteczności czy jeszcze coś innego?
Odp. 5: Myślę, że każdy rodzaj badań klienta jest przydatny, jednak na różnych etapach projektu stosuje się odmienne typy badań.
Przykładowo na początku projektu chcesz w pełni zrozumieć problem i kontekst, w którym pracują ludzie. W tym przypadku świetnie sprawdzają się wywiady kontekstowe — odwiedzasz zespół w miejscu pracy i rozmawiasz o jego procesie, wpływie problemu na ich pracę i rozwiązaniach, których potrzebują, aby zwiększyć skuteczność. Dobrze jest zobaczyć na własne oczy, jak próbują wykonywać zadania i jakie napotykają frustracje.
Gdy pomysł jest już nieco bardziej zaawansowany, świetnie sprawdzą się testy wśród użytkowników i wywiady z klientami. Obserwowanie ludzi realizujących przepływ z wykorzystaniem prostego prototypu lub po prostu rozmowa na temat proponowanego rozwiązania mogą być cennym źródłem informacji.
Z kolei testy A/B są świetnym sposobem oceny skuteczności rozwiązania.
Pyt. 6: Z jakich narzędzi korzystają projektanci Atlassian?
Odp. 6: Projektanci w Atlassian używają odpowiedniego narzędzia do danego zadania. Czasami jest to tradycyjny długopis i papier, a innym razem HTML i CSS.
Do tworzenia projektów o wysokim stopniu wierności większość zespołu używa programu Sketch, ale korzystamy również z pakietu Adobe. Wszystkie elementy interfejsu użytkownika z biblioteki wzorów Atlassian zostały utworzone jako obiekty wektorowe, więc złożenie podstawowego układu jest dość proste. Do prostego prototypowania używamy InVision lub Marvel. Do bardziej złożonych interakcji wykorzystujemy Framer Studio, Origami, Axure lub własny kod.
Zużywamy również całą masę karteczek samoprzylepnych i markerów do tablic. :)
Pyt. 7: Jakie przykładowe trudności napotykasz, pracując z wykorzystaniem ram postępowania Agile?
Odp. 7: Największym wyzwaniem jest poświęcenie dążenia do perfekcji na rzecz szybkiej, iteracyjnej pracy. Jako projektant zawsze chcesz tworzyć wysokiej jakości prace, ale musisz się pogodzić z dostarczaniem czegoś, co jest dobre tylko w 90%, a następnie poprawianiem tego.
Pyt. 8: Wspomniałeś kilka sposobów ograniczenia dokumentacji. W jakiej formie prowadzicie dokumentację? A może udało się ją całkiem wyeliminować?
Odp. 8: Do udostępniania prac w toku i gromadzenia opinii z szerszego grona zespołu wykorzystujemy Confluence. Typowa strona zawiera kontekst dotyczący problemu, który próbujemy rozwiązać, oraz korzyści, jakie oferuje proponowane rozwiązanie. Są zdjęcia szkiców, wstępne projekty o wysokim stopniu wierności lub łącza do prototypów osadzonych na stronie w celu zilustrowania rozwiązania. Ludzie dodają komentarze i pytania, a projektant publikuje zaktualizowane projekty w miarę postępu prac projektowych. Nie jest to tak naprawdę „prowadzenie dokumentacji” — to raczej ewoluująca strona, na której gromadzi się zasoby projektowe oraz opinie.
Pyt. 9: Jakie jest Twoje podejście do projektowania rozproszonego, gdy członkowie zespołu pracują z różnych miejsc?
Odp. 9: Atlassian jest firmą globalną, więc z zespołami rozproszonymi mamy do czynienia codziennie. W Jira mamy zespoły pracujące z Sydney, Gdańska i Sajgonu, dlatego zawsze staramy się zapewnić kanały kontaktu. Technologia jest tutaj niezwykle pomocna — korzystamy z Hipchat do prowadzenia wideorozmów i wymiany wiadomości, w Confluence zamieszczamy, udostępniamy i komentujemy pracę, a Jira służy do porządkowania całej pracy. Nie jest to jednak rozwiązanie idealne i nic nie jest w stanie zastąpić bezpośredniej rozmowy. W miarę możliwości staramy się, aby kluczowymi częściami projektu zajmowały się osoby pracujące w tym samym pomieszczeniu. W przeciwnym razie dobrze sprawdza się bardzo częsta komunikacja z członkami zespołu zdalnego i dokładanie wszelkich starań, aby byli na bieżąco.
Pyt. 10: W jaki sposób kontrolujecie i odfiltrowujecie „szumy”, które udają „opinie klientów”?
Odp. 10: Otrzymujemy od klientów wiele opinii, co bardzo nas cieszy. Mamy narzędzie do zbierania opinii, które gromadzi komentarze użytkowników i zapisuje je jako zgłoszenia w projekcie Jira. Pierwszą część dnia spędzam na czytaniu najnowszych zgłoszeń przy kawie. Podczas przeglądania komentarzy odnotowuję wszelkie wspólne motywy lub wzorce, które się pojawiają, i dodaję etykiety, aby je pogrupować. Mogę przefiltrować wszystkie opinie za pomocą tych etykiet, aby dowiedzieć się, ile osób zgłosiło podobny problem. Następnie po ustaleniu konkretnego wzorca, mogę skierować dany problem do zespołu produktowego z uwzględnieniem szczególnych przypadków użycia, którymi możemy się zająć.
