Big Picture - aplikacja do zarządzania projektami
Big Picture to aplikacja webowa o wysokim poziomie skomplikowania. Powstała w 2015r jako wtyczka w odpowiedzi na potrzeby użytkowników Jiry, głównie managerów, którym brakowało kompleksowego spojrzenia na dane jako dosłowne ‘big picture’ projektu – spojrzenia z góry. Zawiera 8 modułów, które przedstawiają te same dane kładąc w każdym z nich nacisk na coś innego np. na zadania, zasoby, ryzyka itp. Aplikacja jest przeznaczona dla managerów wyższego stopnia i służy do zarządzania projektem, produtem, portfolio oraz skierowana jest to organizacji SAF’owych ze skalowanym Agile’m. Big Picutre wspiera zarządzanie projektami prowadzonymi w różnych metodykach: klasyczne zarządzanie projektami (waterfall), zwinne (agile) a także hybrydowe (połączenie obu).
Moja rola
W czasie mojej półtorarocznej pracy w Big Picture brałam udział w różnych projektach. Pracowałam nad wdrażaniem nowych feature’ów, naprawą błędów i ciągłym usprawnianiem tego co już działało. Byłam UX Designerem jednocześnie w 3 zespołach developerskich. Nie sposób wymienić wszystkie elementy mojej pracy, bo nie zachowałam też większości rozwiązań, które wymyśliłam i które wdrożono. Zdradzę Wam, że Big Picture to tak zaawansowana i trudna jednocześnie aplikacja, że każdy nowy pracownik dopiero po około pół roku nabierał jako tako pewności że poznał już ją całą. Wdrożono szereg szkoleń dla nowych osób, ale na początku każdy nowy musiał radzić sobie sam, w tym ja 😉 Poniżej zbiór modułów i inicjatyw w których brałam udział. Było ich w rezeczywistości o wiele więcej, ale przedstawiam te, do których pobrałam z figmy mockupy przed odejściem do nowej firmy.
MODUŁ GANTT
Najważniejszy moduł w całej aplikacji i z zespołem developerskim, który go rozwijał pracowałam najdłużej. Gantt’a otrzymuje każdy klient, bez względu na to, którą wersję subskrypcyjną wykupi. Jest to moduł na którym zadania przedstawione są na osi czasu. Można zobaczyć ‘big picture’ swoich projektów patrząc na zadania, zależności, osoby przypisane do zadań oraz ważne dla projektu ‘milestones’ czyli kamienie milowe. Tych elementów jest oczywiście więcej.
Nad jakimi funkcjonalnościami pracowałam w module Gantt?
1. Ustawienia default'owe w module
Celem było określenie, które elementy w module powinny zostać za usera włączone na start, gdy zaczyna on dopiero pracę z tym produktem. Wiadomo, można użytkownikowi na start włączyć wszystko, ale jednocześnie też go przestraszyć i nieco spłoszyć. Tego nie chcieliśmy. Aplikacja może i wygląda niewinnie, ale posiada szereg funkcjonalności trudnych do opanowania nawet w późniejszym etapie pracy, a co dopiero na samym początku.
Swoje przemyślenia co do ustawień miał Product Owner, ja miałam swoje i w dużej mierze się one pokrywały. Mając ten luksus, że mieliśmy w firmie dział badań, poprosiliśmy o przeanalizowanie nagrań z hot jar u klientów. Oczywiście, nie mogliśmy bazować wyłącznie na nich, bo były to nagrania pochodzące z codziennej pracy wieloletnich użytkowników, którzy znając potencjał aplikacji mogli mieć włączone te bardziej złożone funkcjonalności
Raport z podsumowania 150 nagrań z Hot Jar:
Rozwiązanie
1. Wyłączyliśmy pokazywanie “Period warnings” – były to ostrzeżenia w możliwych konfliktach między zadaniami/zespołami o dość dużym poziomie zaawansowania. Na tym etapie nie były one konieczne.
2. Wyłączyliśmy pokazywanie ‘zasobów’ czyli osób przypisanych do konkretnych zadań u dołu ekranu. Ta funkcjonalność wprowadza dodatkowy ‘zamęt’ i służy głównie do ‘podglądania’, danych. 84% userów na nagraniach hot jar miała je także wyłączone. Kolejny argument, który za tym stał to zmniejszający się drastycznie view port. Podjęliśmy też decyzję o rodzaju zmianie agreagacji danych, jeśli już ten element zostanie uruchomiony i zmieniliśmy ją z dziennej na tygodniową, aby mieć jeszcze lepsze spojrzenie ‘big picture’ na dane. Potwierdziły to też nagrania z hot jar.
3. Wyłączyliśmy w prawej części ekranu pokazywanie linii wertykalnych, zostawiliśmy tylko horyzontalne (czystszy widok)
4. Nie sposób tu pokazać wszystkiego, jednak część ustawień utrzymaliśmy.
2. Inline editing - umożliwienie edytowania danych
Na czym polegało to zadanie?
To był złożony projekt i ku mojemu zaskoczeniu wydarzył się dopiero 6 lat po powstaniu aplikacji. Polegał on na tym, aby danych nie trzeba było edytować w Jirze, tylko w Big Picture i aby te dane aktualizowały się automatycznie w obu platformach. Jest aż 29 atrybutów zadania i każdy miał się dać teraz edytować inline’owo. Przykłady takich atrybutów to: osoba przypisana do zadania, data startu, data zakończenia, priorytetowość, estymacja. Nasz zespół deweloperski co sprint zajmował się innym atrybutem, więc nie będę się tu nad każdym rozpisywać.
Dlaczego to było tak złożone zadanie?
Bo obejmował tak naprawdę całą aplikację i wszystkie moduły. Mój zespół developerski przypisany był do jednego modułu (wspomnianego Gantt’a) ale dane pojawiały się na każdym module i chodziło o to aby te dane dało się edytować. Sposób prezentacji danych różnił się znacząco między modułami. Na Gantt zadania (taski) graficznie były w formie wąskich prostokątów umieszczonych na osi czasu. Na innych modułach to samo zadanie jest już tzw. karteczką (pokażę to poniżej). Dlatego ten projekt wymagał współpracy z innymi designerami przypisanymi do ich modułów, informując jakie zmiany zajdą. Zależało nam też na wspólnym spojrzeniu i akceptacji naszych działań, co z resztą się udało.
Rozwiązanie na module Gantt:
Na poniższym nagraniu widać jak wygląda taka inline’owa edycja. Nie wprowadziłam “ołóweczka” sugerującego edytowalność bo nie chciałam wprowadzać dodatkowego elementu graficznego na interfejsie, który i tak jest już wypełniony danymi, ikonami. Samo pojawianie się białego tła po najechaniu na dane miało już sugerować userowi, że z tymi danymi coś może zrobić. Od tego był już tylko krok od dwukliku i odkrycia tej funkcji. Oczywiście zawsze informowaliśmy userów o pojawieniu się nowych funkcjonalności, ale znamy życie i wiemy że kończy się to najczęsciej pomijaniem ->’skip-skip-skip’.
nagranie edytowania danych na module Gantt:
Edytowanie daty w module Board:
3. Uspójnienie komunikatów w aplikacji
Odkryłam, że w aplikacji występują niespójne komunikaty informujące o błędzie. Chodziło dokładnie o komunikat
Tak to wyglądało w kilku miejscach aplikacji:
Wprowadziliśmy jeden uspójniony komunikat:
4. Uciekający panel
Poniżej wyjaśnienie problemu:
Jakie rozwiązanie zastosowałam?
Uznałam, że user nie może ‘gonić’ za przyciskiem, który znika mu spod myszki. Wprowadziliśmy rozwiązanie polegające na tym, że jeśli użytkownik hoverował panel (stał na nim myszką) to dopóki z niego nie zjechał, to panel utrzymywał tę samą
A tak działa przesuwanie zadań po zmianie:
MODUŁ BOARD
Board to moduł przeznaczony dla zespołów pracujących w Agile. Tutaj zadania przeciąga się z prawej strony (backlog) do lewej na tzw. skeleton i umieszcza w konkretnej iteracji i przypisuje konkretnemu zespołowi. Zadania graficznie przedstawione są jako ‘karteczki’ oraz jako ‘linijki danych’.
Nad jakimi funkcjonalnościami pracowałam w module Board?
1. Usprawnianie przeciągania zadań z backlogu
Wcześniej gdy użytkownik ‘łapał’ zadanie w prawej części ekranu i chciał przerzucić je do lewej, to nie wiedział dokładnie gdzie to zadanie upuści, bo nie wyrysowywały się zony z przerywanym obramowaniem, więc dorobiliśmy to, aby user na był pewien na 100% gdzie upuszcza task.
2. Ryzyka multiplatformowe
Mój product owner w tym czasie odpowiadał jeszcze za elementy konfiguracyjne całej aplikacji Big Picture i tym samym ja też za ten element systemu odpowiadałam. Należało zaprojektować narzędzie, dzięki któremu przy korzystaniu z kilku źródeł danych (kilku Jir) będzie można ustalić części wspólne na modułu “Ryzyk”. Jira jak wiemy jest bardzo elastyczna i pozwala na dużą dowolność. Można w niej określić gradację ryzyk od najmniejszego do największego. Podczas agregacji danych przy korzystaniu z kilku Jir może się okazać, że te stopnie gradacji różnią się od siebie bo są inaczej skonfigurowane.
przed zmianą:
użyj strzałek <- -> alby zobaczyć rozwiązanie:
UFO - USER FRIENDLY OPERATIONS
Spis treści
To duży projekt, który obejmował całą aplikację, czyli wszystkie moduły. Celem było zapewnienie użytkownikowi możliwości filtrowania i sortowania danych. Wyzwaniem było to, że dane graficznie przedstawione były w różnych sposób na modułach. Raz dane były tabelą, innym razem zadania ułożone były na prostokątnych karteczkach umieszczonych na macierzy. Ważne było, żeby user nie musiał ‘uczyć się’ na każdym module od nowa jak te czynności wykonać, tylko żeby z łatwością je rozpoznawał i stosował.
tu przykład danych w tabeli:
a tu przykład tych samych danych na macierzy:
1. Filtrowanie proste
Przez atrybuty proste rozumiemy tutaj filtrowanie po danych, które nie mają drugiego, głębszego poziomu filtrowania. Jak wiemy zadanie (task w Jirze) ma w sobie zapisane różne dane np.: data startu, data zakończenia, kto je wykonuje, priorytet, story points itp.
1.1. Wprowdziłam nowy przycisk na każdym module, który wywoływał panel do filtrowania:
Jak to działa?
...to teraz zobaczmy, jak poradziłam sobie z filtrowaniem dwu-poziomowym
2. Filtrowanie złożone
Filtrowanie złożone polegało w tym projekcie na zapewnieniu użytkownikowi filtrowania na dwóch poziomach danych. Głównie skupiliśmy się tu na atrybucie ‘status’. Wiemy, że Big Picture bazuje na danych z Jiry. Elastyczność Jiry polega na tym, że w ramach 3 głównych statusów zadań (to do, in progress, done) każdy może stworzyć własne sub-statusy w ramach tych trzech głównych. Poniżej przykład takich statusów:
