26. Zadanie
• Zasady:
Podział na grupy
Anonimowość (grupa A, B, C etc.)
Czas: 10 min
• Treść:
a) przygotuj dokumentację opisującą funkcję wysyłania sms-a z telefonu
komórkowego
b) weź pod uwagę PODSTAWOWE informacje i opisz w kilku punktach jak
przebiega proces, co użytkownik musi zrobić żeby wysłać wiadomość,
model telefonu nie jest ważny, najważniejsze jest zaplanowanie i
uwzględnienie istotnych informacji
W drodze do pracy, pierwszego dnia, jako TW wyobrażałam sobie, że wjdę do biura, gdzie słychać nieustające stuki klawiatury, a stosy dokumentów rosną jak na drożdżach. Szybko jednak zauważyłam, że tylko kilku TW coś naprawdę pisze. Co w takim razie robi w tym czasie reszta?
Szpieguje! ;) Przeglada zmiany kodu, planningi, dema, kontaktuje się z PO, zdobywa wiedzę na temat produktu, jego rozwoju, jego możliwości i wpływu na istniejące części produktu.
Negocjuje. Kiedy TW już wie co się zmieniło i gdzie, potrzebuje szczegółów na ten temat. Żeby je zdobyć kontaktuje się z deweloperami, którzy często rozrzuceni są po całym świecie. Zdarza się, że developerzy są tak zajęci swoimi obowiązkami, że zapominają o TW. Wtedy trzeba o sobie przypomnieć. Trenujemy to tutaj: Traning dla TW
Tłumaczy. Tłumaczy informacje, które dostał od developera na język zrozumiały dla ludzi spoza firmy, dla ludzi, którzy niekoniecznie są ekspertami w danej dziedzinie, używa przy tym prostego języka, tak aby nie native speakerzy mogli bez problemu i używania słownika przy co drugim słowie zrozumieć zawarte informacje.
Rysuje. Tworzy grafiki, ilustracje, diagramy, screenshoty. To wszystko po to żeby pokazać użytkownikowi, że np. po kliknięciu przycisku edit, znalazł się na właściwej stronie, jaki będzie przebieg np. logowania. Wszystko wg zasady: 1 obrazek mówi więcej, niż 1000 słów.
Testuje. Robimy smoke-testy. Czyli zanim napiszemy intrukcje instalacji, czy procedurę przejścia przez zakup produktu, sami przechodzimy przez wszystkie kroki. Często dwa razy. Dlaczego? Żeby upewnić się, że wszystko działa, tak jak zostało to zapisane w naszej dokumentacji (i w projekcie), sprawdzamy, czy wszystkie kroki da się wykonać i jakie dodatkowe oprogramowanie jest potrzebne do uruchomienia commerce suita.
Piszemy! Stricte pisanie dokumentacji to jakieś 30% naszej pracy. Kiedy już dostaniemy tzw documentation input, kiedy dopytamy o szczegóły, projektujemy całą dokumentację, czyli jaki zestaw dokumentów będzie potrzebny dla nowej funkcjonalności, a następnie projektujemy poszczgólne dokumenty. Kto będzie ich odbiorcą. Piszemy mając na uwadze Style Guide, czyli reguły: jakiego języka używać, jak konstruować zdania, jak używać kropek, przecinków, jak formatować tabele, listy, itp. Itd..
pomoc dla aplikacji mobilnych, podreczniki uzytkownika, pomoc online, bazy wiedzy, informacje o wydaniu/wersji