UX: Dokumentowanie wymagań

0:00Okej. Teraz przejdziemy do kwestii porządkowania informacji. Bo nazbieraliśmy

0:04bardzo dużo informacji, rozmawialiśmy z naszymi klientami, rozmawialiśmy

0:09z pracownikami klienta, być może prowadziliśmy również w międzyczasie badania. Były

0:13warsztaty, były spotkania. Zapadały pewne decyzje. Wymyślaliśmy

0:18funkcje, nadawaliśmy im priorytety, potem przekształcaliśmy

0:22to wszystko w storyjki użytkownika, mapowaliśmy to wszystko. Więc tych informacji

0:26potrafi się ubierać bardzo, bardzo dużo. No i teraz pytanie w jaki sposób to

0:30zbierać i porządkować, żeby faktycznie mieć

0:35z tego jakiś sensowny pożytek? No bo co z tego, że zbierzemy masę informacji, jak

0:39w żaden sposób tych informacji nie wykorzystamy w późniejszej pracy i

0:43w żaden sposób jej nie przetworzymy? No i teraz tak: nie musimy tworzyć jakiejś superprofesjonalnej

0:48dokumentacji na miarę wielkiej korporacji. Chodzi tylko o to, żeby

0:52uporządkować te informacje w taki sposób, że w momencie, kiedy będziemy musieli

0:57się odnieść do jakiegoś materiału, to go bez problemu znajdziemy. Takim popularnym

1:02przykładem kiedy będziemy wracać do materiałów

1:06ze spotkań i warsztatów jest na przykład argumentowanie decyzji projektowych. Jeżeli

1:10wybraliście jakiś sposób w projekcie na rozwiązanie

1:15interfejsowe albo jakiś proces i pada pytanie od

1:19osób, które na przykład nie brały udziału w warsztatach czy badaniach: dlaczego została podjęta

1:23taka decyzja? To my możemy wrócić do tych materiałów, pokazać w jaki sposób pracowaliśmy

1:28nad nimi, skąd to się wszystko wzięło, skąd się wzięły te pomysły i w

1:32wyniku czego, dlaczego zapadły takie decyzje projektowe. Może zdarzyć się również,

1:36że w zespole, zarówno naszym, jak i tym klienta, wymieni

1:40się nagle bardzo dużo osób. Takie sytuacje się zdarzają. I nagle

1:44nowe osoby pojawiają się w projekcie. I my musimy razem

1:48z klientem w jakiś szybki sposób wprowadzić nowe

1:53osoby w to, co zostało w tej chwili wypracowane, co do

1:57tej pory zostało wymyślone, dlaczego

2:01to zostało w ten sposób wymyślone, dlaczego są takie, a nie inne priorytety czy takie,

2:05a nie inne procesy. I jeżeli będziemy mieć taką dokumentację,

2:09która będzie zebrana w jednym miejscu, będziemy mieć to wszystko uporządkowane, to możemy

2:13po prostu wrzucić takie nowe osoby do tej dokumentacji. Te osoby mogą

2:18sobie to przejrzeć, mogą sobie to przeczytać i bez problemu odnajdą

2:22się w tym projekcie. Niż w takiej sytuacji, gdy będziemy

2:26mieć wszystko w różnych mailach, gdzie będziemy mieć porozrzucane w różnych

2:30produktach, w różnych narzędziach i po prostu ciężko się będzie

2:34w tym wszystkim połapać. Więc porządkujemy informacje dla siebie, dla

2:39klienta i dla przyszłych pracowników, którzy będą zaangażowani

2:43w rozwój tego projektu. To, o czym trzeba pamiętać, to fakt, że nie

2:48ma powszechnego najlepszego

2:52sposobu na dokumentowanie wymagań czy tworzenie

2:57takiej specyfikacji projektowej, bo to będzie zależne

3:01w dużej mierze od wielkości projektu. W przypadku małych projektów

3:05będziemy mieć brief, będziemy mieć wyniki jakichś rozmów w postaci

3:10meeting notes, notatek po spotkaniach. I to tyle tak naprawdę. Ale

3:14w przypadku dużych projektów tych spotkań będzie dużo, tych decyzji podjętych będzie dużo

3:19więcej i tych materiałów po prostu będzie zebranych

3:23ogrom. I wtedy trzeba będzie dostosować jakiś system zapisu,

3:27żeby się w tym wszystkim po prostu odnaleźć. Bo bardzo łatwo się pogubić, jeżeli

3:31mamy tych dokumentów dużo. Bardzo łatwo się pogubić, kiedy mamy kilka spotkań, kilka

3:35warsztatów. Możemy nie pamiętać, co kiedy zostały podjęte, jaka

3:40decyzja kiedy została podjęta, jakie były priorytety, jak te priorytety

3:44się zmieniały. No więc tak naprawdę musimy dopasować sposób dokumentacji,

3:48porządkowania tych informacji do tego, w jaki sposób my pracujemy z klientem, do

3:53czasu jaki na to mamy. Bo możemy po prostu nie mieć na to czasu, możemy mieć

3:57tak upchnięty harmonogram działań, że tak naprawdę będziemy

4:01bardzo dynamicznie pracować, nie będziemy zastanawiać się specjalnie

4:05nad tym, jaką formę mają te notatki. Czy one są ładne, czy brzydkie, czy znajdują

4:09się tu, czy tam. Po prostu będziemy je gromadzić w jednym miejscu. A czasami

4:14będziemy mieć wydzielony czas na to, żeby tworzyć raporty, tworzyć

4:18analizy, wnioski i rekomendacje. Więc to w dużej

4:22mierze będzie zależało od projektu. Czasami oczywiście są osoby, które są

4:26odpowiedzialne za tworzenie takiej dokumentacji. Będziemy mieli na myśli analityków

4:30biznesowych. Analityków biznesowych często po stronie klienta, którzy tworzą już

4:34dokumentację techniczną, tworzą dokumentację biznesową i będą

4:38tym samym tworzyć dokumentację naszego projektu, będą dodawać architekturę

4:43informacji do tych swoich dokumentów, jakieś prototypy, screeny,

4:47które dostają od projektantów. Więc bardzo możliwe, że będzie również osoba,

4:51która będzie po prostu odpowiedzialna za dokumentowanie takich informacji. Najczęściej

4:56jednak w tych mniejszych projektach mamy jeden dokument czy jeden folder,

5:00w którym mamy zebrane notatki, mamy listę wymagań. To

5:04może być lista funkcji z podziałem na obszary, z pewnymi

5:08priorytetami. To może być już jakaś forma harmonogramu projektu. Więc

5:13takie najprostsze dokumenty również się sprawdzą

5:17w tych małych projektach i naprawdę czasami nie potrzebujemy kombinować, nie

5:21potrzebujemy wymyślać nie wiadomo czego, jak sprawdzi

5:25się w naszym tym konkretnym przypadku na przykład jeden dokument tekstowy, który

5:30będzie dostępny gdzieś online. To, o czym powinniśmy pamiętać, wybierając narzędzia,

5:34z którymi będziemy pracować, to to, żeby mieć możliwość łatwego śledzenia

5:38zmian. Bo będą się pojawiać zmiany. Żeby wiedzieć, co kiedy zostało

5:43zmienione. Na przykład zmieniły się priorytety. Dlaczego, i w którym momencie? Powinien

5:47być dostępny. Najlepiej, żeby był dostępny online, bo różne osoby z projektu

5:52mogą mieć do tego dostęp, więc fajnie by było, jeżeli

5:56jest taka możliwość, żeby to udostępnić gdzieś w

6:01sieci. No i fajnie jeżeli jest możliwość komentowania poszczególnych

6:05elementów czy chociażby całego dokumentu, żeby było to pole do dyskusji,

6:09było pole do rozmowy i ewentualnie uzupełniania pewnych informacji, których

6:14na początku nie zdobyliśmy, ale gdzieś w międzyczasie zaczęły się pojawiać, więc można

6:18od razu dodać je do zbioru takich wymagań. To, co

6:22jest najważniejsze, to fakt, żeby uświadomić klienta, że to jest ważne dla nas,

6:27że to nie jest tylko narzędzie, które pozwoli klientowi uporządkować

6:31sobie te wszystkie informacje, którymi się wymieniamy, ale

6:35że to jest po prostu coś, co będzie bazą do tworzenia struktury

6:40treści, architektury informacji, prototypów i ostatecznie, gotowego

6:44projektu. Więc warto zachęcać klientów do tego,

6:48żeby współtworzyć taką dokumentację, ale nie tworzyć

6:53jej za wszelką cenę. Bo ostatecznie te wszystkie rzeczy, o których tutaj

6:57mówimy, to są tylko narzędzia, które mają pomóc w naszej pracy. Więc nie fiksujmy

7:02się na to, żeby robić idealne dokumentacje. Raczej upewnijmy

7:06się, że w momencie kiedy już mamy jakieś efekty naszej pracy, coś co

7:11może być dokumentem, co może być fragmentem dokumentacji, w jakiś sposób skatalogować,

7:16uporządkować i przechowywać w jakimś dostępnym miejscu, że w razie

7:20co, kiedy trzeba będzie do tego wrócić, to będziemy mieć taką możliwość.