Planując przygotowania do pracy przy dużym projekcie z branży IT należy poświęcić uwagę równie mocno szczegółom towarzyszącym biznesowemu ujęciu pomysłu, co elementom samej realizacji i późniejszego rozwoju produktu. Dzięki temu już na początku dowiesz się jakie potrzeby i oczekiwania ma Twój Klient względem swojego projektu. Uwaga, nawet wtedy, kiedy on sam jeszcze o nich nie wie. W takich sytuacji z pomocą przychodzi dokumentacja projektu.

Postaram się przybliżyć zbawienną wartość, jaką daje dokumentacja projektu. Z naszego doświadczenia wynika, że pozwala ona w trakcie prac programistycznych zaoszczędzić czasu, nerwów i pozbyć się licznych niedomówień czy braków w logice biznesowej. A to wszystko przekłada się na zamknięcie projektu w budżecie i wysokiej jakości.

MVP – od tego powinniście zacząć

Rozpoczynając prace przy projekcie musicie zacząć od sprawdzenia, na ile sam klient wie z czym do nas przychodzi. Jaki jest cel biznesowy, który chce osiągnąć? Jakie funkcjonalności są w nim najważniejsze i bez których produkt na pewno nie może się obejść, bo wtedy nie dostarczy odpowiedniej wartości użytkownikowi? Może okazać się, że klient dostrzega jedynie wierzchołek góry lodowej. Wtedy wkraczamy my.

Przeprowadzamy wywiad, rozpoznanie produktu jakim jest zainteresowany. Słowem, gromadzimy jak najwięcej informacji i dążymy do tego, żeby poznać perspektywę klienta. Dzięki temu, polegając na naszym know-how, będziemy mogli wskazać klientowi, które elementy są dla jego rozwiązania niezbędne, a które można odłożyć na kolejny etap rozwoju – już po wdrożeniu.

Tym samym, mając nakreślony zarys projektu jesteśmy w stanie określić jego MVP (ang. Minimum Viable Product). Jest to nic innego jak wykonanie najważniejszych założeń, które muszą zostać spełnione, aby produkt działał i mógł być przetestowany na grupie docelowej.

Wszystko co ponad MVP jest traktowane jako kolejny etap rozwoju. Ten będziemy realizować w kolejnych miesiącach po uruchomieniu produktu dla użytkowników. Dlaczego określenie MVP jest takie ważne, a także niezwykle pomocne? Przede wszystkim dzięki niemu oszczędzamy to co najbardziej kosztowne, czyli czas. Zarówno nasz, za który Klient musiałby nam zapłacić rzecz jasna, jak i prywatny samego Klienta. Za przykład MVP, aby przybliżyć samą jego ideę, może posłużyć przykład Dropboxa, gdzie autor tej skomplikowanej platformy z technicznego punktu widzenia, przygotował na początku nagranie wideo obrazujące ideę działania aplikacji, zamiast brnąć w kosztowny proces programistyczny. Dzięki temu zgromadził niezbędny feedback bardzo małym kosztem i wiedział, co ma poprawić lub też jak duże zainteresowanie wzbudza jego produkt.

Nasze ostatnie doświadczenie z realizacją dokumentacji projektu polegało właśnie na zebraniu najważniejszych funkcjonalności, które interesowały klienta i przekuciu ich w opisy opatrzone prototypowymi widokami aplikacji. Z tym podejściem związana jest jedna i bezkonkurencyjna korzyść dla samego klienta.

Wie on dokładnie jak jego produkt będzie się zachowywał w momentach zgodnych z opisanymi scenariuszami użycia. Dzięki temu zdobędzie wyobrażenie działającej aplikacji i może łatwiej określić, które funkcjonalności będą wprowadzone w pierwszej iteracji produktu, a które mogą poczekać. Osiągnie to, bo “zobaczy” jak będzie wyglądała aplikacja w momencie produkcji. Może bowiem dojść do sytuacji w której okaże się, że umiejscowienie niektórych przycisków, filtrów etc. będzie bardziej uzasadnione w innym miejscu niż na pierwotnym mockup’ ie. Wtedy właśnie dostrzeżemy nieocenioną korzyść prototypów, którą jest czas ich przygotowania i wprowadzania zmian. Proces jest zdecydowanie szybszy i nie wymaga tak dużych nakładów pracy.

Czym prototypować widoki aplikacji?

Obecnie na rynku jest masa narzędzi dostarczających możliwości prototypowania. Ciekawe zestawienie bardzo dużej ilości narzędzi możecie znaleźć tutaj. W Internecie oczywiście toczy się nierozwiązany i nieodłączny tego typu zjawiskom spór o to, które oprogramowanie jest lepsze. Ale co tak naprawdę znaczy “lepsze”? Ja wychodzę z założenia, że software jest tylko środkiem do celu. Narzędzie nie może warunkować umiejętności, czy jakości wykonania danego projektu. Projektant powinien przekazać jasno swój pomysł nawet jeśli pod ręką ma tylko kartkę papieru ;).

Wracając do omawianego przypadku, w naszej realizacji zdecydowałem się na użycie Adobe XD. Być może narażę się “środowisku” tym co teraz napiszę ale przy mniejszych realizacjach wystarczał sam Photoshop (tak w nim też się da). Niemniej, podczas bardziej złożonych projektów potrzebujemy czegoś więcej. Tym czymś były między innymi interaktywne makiety które prezentują sposób lub ideę działania danej funkcjonalności. Okazało się także, co było raczej do przewidzenia, że czas wytwarzania kolejnych ekranów znacznie się skraca.

Bardzo pomocnym odkryciem w programie były tak zwane assety. Są to predefiniowane elementy, takie jak guziki, etykiety, ikony lub cokolwiek innego co stworzysz i wiesz, że ponownie wykorzystasz w niezmienionej formie. Tworząc taki bank mamy pod ręką zbiór gotowych grafik do ponownego wykorzystania w obszarze samego programu. Bardzo pomocne. Oczywiście na tym się nie kończy.

Mamy do dyspozycji tworzenie zbioru kolorów oraz stylów typografii. Wspomniałem o interaktywnych makietach. Adobe postarało się dopracować tę funkcjonalność, przynajmniej w moim odczuciu, ale oczywiście można by zrobić parę rzeczy lepiej lub inaczej.

Kolejny ważnym mechanizmem programu była na pewno łatwość w docieraniu do elementów, którym chciałem nadać połączenie oraz możliwy wybór rodzaju przejścia i docelowego ekranu. To co bym dodał to informowanie użytkownika (projektanta) o braku połączenia któregoś ekranu jeśli został on przegapiony wraz ze wskazaniem który konkretnie. Dzięki temu przy rozległych makietach mielibyśmy pewność, że wszystko zostało połączone.

A samo dzielenie się interaktywną makietą w chmurze jest banalnie proste i ułatwiające życie, ponieważ każdą zmianę można zaktualizować pod tym samym linkiem. Odczuwalnym brakiem natomiast był brak możliwości aktualizacji wszystkich widoków o nowe elementy. Ci którzy są w temacie zrozumieją porównanie tego o czym piszę do strony wzorcowej w Adobe InDesign. Niestety, podczas pracy przy rozległym projekcie, może dochodzić do sytuacji, w której należy zaktualizować widoki już zaprojektowane o elementy wcześniej nieprzewidziane. Łatwo się domyślić, że praca wstecz może być frustrująca i zabierać czas. W takiej sytuacji warto przygotować finalny mockup, który ma być wzorcowym dla wszystkich interesariuszy.

Pracując w Adobe XD miałem jednak wrażenie, że program nadal wymaga dopracowania i dodania funkcjonalności ułatwiających życie projektanta jak i dostarczających więcej rozwiązań. Niemniej wdrożenie się w sam workflow pracy w programie było bezbolesne i płynne. Miało na to wpływ zapewne wieloletnie doświadczenie pracy z programami z pakietu Adobe. Wybór oprogramowania nie był więc przypadkowy, raczej intuicyjny i świadomy.

Chciałbym też zaznaczyć, że omawiany program nie jest lekarstwem na wszystko. Jeśli inne oprogramowanie dostarcza Ci więcej swobody i satysfakcji, śmiało, działaj w nim. Nikt nie powinien narzucać Ci sposobu Twojej pracy.

Dokumentacja projektowa i proces jej powstawania

Proces powstawania dokumentacji projektowej nie jest skomplikowany. Nie mniej wymaga on zaangażowania zespołu projektowego na każdym etapie jego trwania.

Zacznijmy od tego, że trzeba poznać potrzeby Klienta. Ten element zrealizowaliśmy poprzez przeprowadzenie warsztatów, na których to odpowiednio drążyliśmy kluczowe tematy, doprecyzowywaliśmy niezbędne dla nas i dla głównego zainteresowanego informacje. Czasami okazywało się podczas rozmów, że sam klient nie wiedział o funkcjonalnościach, które mogłyby mu się przydać w jego produkcie.

Jest to efekt poniekąd burzy mózgów i otwartej dyskusji pomiędzy firmą IT a biznesem. Klient mówił nam o swoich potrzebach a my słuchaliśmy, weryfikowaliśmy i dostarczaliśmy możliwie najlepszych rozwiązań i uzasadnień.

Ważnym punktem jest także poinformowanie klienta co tak właściwie dostanie w ramach tej dokumentacji. Warto zaznaczyć, jeśli na to się umawiamy (a warto to zrobić), że dokumentacja będzie zawierała prototypy ekranów aplikacji. Czyli nie gotowy design z rozwiązaniami projektowymi. Klient musi zrozumieć i mieć tego świadomość, że ten etap ma za zadanie wypracować spójną wizję aplikacji, a nie gotowy produkt.

Kolejnym istotnym elementem procesu jest praca już nasza wewnętrzna. Należy jasno rozdzielić prace i wybrać project managera, który będzie je koordynował. Dzięki temu całość obowiązków będzie rozsądnie rozdzielona i nie spadnie na jedną osobą – designera. Korzyści z takiego układu jest wiele. Można zacząć od tego, że praca projektanta podlega ciągłej weryfikacji, gdzie przy dużej objętości projektu łatwo o przeoczenie szczegółów. Komunikacja na linii project manager-designer musi być także objęta zaufaniem i możliwością swobodnej wypowiedzi, która będzie brana pod uwagę. Dlatego też wszelkie wątpliwości warto notować i odkładać na spotkania projektowe w których uczestniczą wszyscy członkowie zespołu odpowiedzialni za projekt.

Wszelkie wątpliwości, bo takie pojawiają się zawsze, należy od razu weryfikować i omawiać. Pozwoli to wyeliminować sytuacje, gdzie błędnie zrozumiana informacja zapędzi projekt na niewłaściwe tory. Dzięki wczesnej prewencji istnieć będzie szansa na to, że cały proces pójdzie względnie gładko. To znaczy, nie będzie trzeba wracać do teoretycznie zrealizowanych już zadań lub dokładać pracy, która tworzyłaby dwie wersje, ponieważ ktoś nie mógł się zdecydować na konkretne rozwiązanie.

Kolejną dobrą praktyką będzie konsekwencja realizacji zadań. Będąc już w tym procesie, dobrze byłoby nie przerzucać swojej uwagi na inne rzeczy. Zapobiega to nie dotrzymywaniu terminów których powinien pilnować project manager i także informować o postępach w pracy. Harmonogram którego możemy się trzymać w takim przypadku okazuje się zbawienny.

Jeśli projekt jest rozciągnięty w czasie i od klienta dzielą nas setki kilometrów, warto zadbać o ciągłą komunikację. Regularny kontakt telefoniczny lub via Skype jest w zupełności wystarczający. Otrzymujemy wtedy feedback do wykonywanych zadań, a także dopytujemy na bieżąco i rozwiewamy wątpliwości, jakie pojawiają się na horyzoncie. Klient wtedy dodatkowo czuje nasze zaangażowanie i wie, że nie próżnujemy.

W całym procesie, który przeprowadziliśmy najtrudniejsze było przebrnięcie przez, czasami, bardzo obszerne spisy funkcjonalności. Na szczęście, mieliśmy tą swobodę tworzenia i możliwość interwencji, że mogłem zgłosić taką uwagę która została uwzględniona. Każdy kolejny dokument był już rozbity na drobniejsze zadania, które znacznie wygodniej mi się realizowało. Tak jak wspomniałem wcześniej, odpowiednio wczesna interwencja i jasna komunikacja pozwoliły zaoszczędzić frustracji i prawdopodobnie wynikającej z niej jakości projektu.

Fragmenty dokumentacji

W naszym procesie dokumentowania projektu przed rozpoczęciem prac programistycznych zazwyczaj korzystamy z połączenia user stories oraz makiet funkcjonalnych. Poniżej znajdziecie fragmenty przygotowanej dokumentacji. Oczywiście całość została poddana anonimizacji.

Scenario #1 Podstawowy widok kalendarza: tydzień

Given Znajduję się na dowolnej stronie aplikacji
When Naciskam na przycisk “Kalendarz” w górnej belce menu lub w bocznym menu
Then Wyświetla się domyślny widok kalendarza w formie:

  • menu po lewej stronie:
    • aktywna poczekalnia / aktywne gabinety
    • aktywna recepcja
    • filtrowanie kalendarza
  • widok tygodniowy (domyślnie od poniedziałku do niedzieli – przy edycji godzin otwarcia kliniki, kalendarz automatycznie się do nich dostosowuje)
  • gdzie data pojedynczego dnia jest hiperłączem do danego dnia i przenosi do widoku pojedynczego dnia
  • oś czasu podzielona jest na 5 minutowe odcinki
  • przycisk zmiany widoku kalendarza (tydzień, dzień, miesiąc, rok, recepcja)
  • obłożenie pokoi w postaci wykresu gantta

And Aktualny dzień zaznaczony jest na kalendarzu innym kolorem tła
And Aktualna godzina jest zaznaczona na kalendarzu czerwoną poziomą linią
When Wchodzę na widok kalendarza
Then Na widoku kalendarza zaznaczone są filtry przy wszystkich użytkownikach
And Na kalendarzu widzę wizyty wszystkich użytkowników w klinice z wybranego zakresu
When Wchodzę na widok kalendarza jako użytkownik o uprawnieniach wykonawcy lub koordynatora
Then Na widoku kalendarza zaznaczony jest tylko filtr przy moim imieniu i nazwisku
And Na kalendarzu widzę tylko moje zadania z wybranego zakresu

Scenario #2 Zmiana widoku kalendarza: dzień

Given Znajduję się na widoku kalendarza w aplikacji
When Naciskam na przycisk zmiany widoku kalendarza, znajdujący się w prawym górnym rogu
And Wybieram widok “Dzień”
Then Wyświetla się kalendarz w formie:

  • menu po lewej stronie (bez zmian w stosunku do widoku podstawowego: tydzień)
  • widok pojedynczego dnia
  • oś czasu podzielona jest na 5 minutowe odcinki
  • przycisk zmiany widoku kalendarza (tydzień, dzień, miesiąc, rok, recepcja)
  • obłożenie pokoi w postaci wykresu gantta

And Aktualna godzina jest zaznaczona na kalendarzu czerwoną poziomą linią

Scenario #1 Personel – podgląd wszystkich pracowników

Given Znajduję się na dowolnym ekranie aplikacji
When Naciskam na dział “Ustawienia” znajdujący się w bocznym menu
And Naciskam na przycisk “Personel” na widoku ustawień
Then Przechodzę na widok wszystkich pracowników, który wyświetlany jest w formie listingu:

  • awatar
  • imię i nazwisko
  • rola
  • dane kontaktowe (numer telefonu, adres e-mail)
  • dodany (DD-MM-RRRR)
  • konto:
    • potwierdzone – użytkownik, który aktywował konto poprzez wejście na swoje konto w aplikacji
    • niepotwierdzone – użytkownik, który nie zalogował się do aplikacji
    • nieaktywne – użytkownik, który ma dezaktywowane konto przez administratora

And Listing pracowników domyślnie wyświetlany jest od najwcześniej dodanego pracownika, do najpóźniej dodanego pracownika
And Nad listingiem pracowników widzę przycisk: “Dodaj nowy personel”
And Pod listingiem widzę przycisk do zarządzania ilością wyświetlanych wyników (10, 20, 50, 100)
When Jeśli wyników jest więcej niż wybrany zakres
Then Pojawia się paginacja

Można zauważyć, że każda funkcjonalność została dokładnie opisana. Dzięki temu nie miałem wątpliwości jak zrealizować dany widok i jakie interakcje dodać, a sprawdzający makiety członkowie zespołu sprawnie weryfikowali poprawność wykonania.

Po co dokumentować projekt? Nie można od razu programować?

Opisany wyżej proces ma przede wszystkim na celu ustrzec nas i klienta przed nie dowiezieniem projektu na czas. Bez odpowiedniej analizy i przygotowania dokumentacji projektu narażamy się na niebezpieczeństwo niedomówień i pomyłek. To finalnie może doprowadzić do niedostarczenia produktu na czas, przekroczenia budżetu i podniesienia wszystkim zaangażowanym w proces poziomu stresu.

Bardzo ważne jest, żeby w trakcie realizacji całego zadania wykazać umiejętność okiełznania bardzo dużego i ważnego projektu, gdzie klient już na tak wczesnym etapie potrzebuje często pomocy w usystematyzowaniu pracy i wyklarowaniu wizji, co do poszczególnych elementów aplikacji.

Statystyka pokazuje z jaką skalą wyzwania musieliśmy się zmierzyć, a prowadzone przez nas praktyki udowadniają, że można sprawnie przebrnąć nawet przez tak duże zadanie. Tworzenie dokumentacji w gruncie rzeczy nie jest porywającym procesem ale na pewno bardzo potrzebnym. Nam jako wykonawcom, w późniejszej pracy i klientowi jako głównemu zainteresowanemu, który ma czarno na białym spisane założenia projektu.

W ten sposób robimy dobrą rzecz dla obu stron. Dobrze przygotowana dokumentacja pozwala sprawnie dotrzeć do interesujących daną osobę elementów oraz wyjaśnić istotę ich działania. W idealnej sytuacji, programista nie będzie musiał zwracać się do projektanta z trywialnym zestawem pytań, tylko odpowiedzi na nie znajdzie właśnie w przygotowanej dokumentacji projektu.

Inne artykuły tęgo autora

Ania
29 grudnia, 2020
Ania
16 grudnia, 2020
Ania
19 maja, 2020