Moja historia

Gdy pracowałam, jako Junior Account Executive, w jednej z uznanych agencji marketingowych, byłam odpowiedzialna za dostarczenie materiałów reklamowych w ramach kampanii wizerunkowej dla ważnego klienta.

To były początki mojej drogi zawodowej. Wtedy zrozumiałam, jak ważna jest komunikacja. Projekt można poprawić w mgnieniu oka, ale wydrukowane materiały to zrealizowany budżet i tego nie da się odkręcić bez dodatkowych kosztów. Panuje tu jedna prosta zasada – shit in, shit out. Z błędów bierze się korporacyjne polowanie na czarownice i szukanie winnego. Nic przyjemnego.

Chcesz tego uniknąć za wszelką cenę, więc robisz dużo wizualizacji. Jak wiesz od grafika, że będzie problem z tłem na bilbordzie, to powiększasz próbny wydruk tak, by ten problem unaocznić i przedyskutować. Prezentujesz. Modyfikujesz lub zatwierdzasz i dopiero drukujesz.  

To doświadczenie mnie ukształtowało. Pokazało mi, że jeden obraz jest wart więcej niż 1000 słów. Dlatego teraz chętnie przygotowuję wizualizacje, robię proste prezentacje, tylko po to, żeby pokazać przybliżony efekt, zanim do zadania usiądą deweloperzy. Robię to od lat – bo wiem, że to działa.

Jednak odkąd zaczęłam pracę, jako analityk systemowy miałam przeczucie, że mogę zrobić coś więcej również dla zespołu programistycznego. Zaczęłam szukać najlepszych praktyk, wskazówek i wiedzy na rynku. Wynikiem tych poszukiwań i wielu lat praktyki jest załączony poniżej szablon. Wypróbuj go u siebie i daj znać, jak wpłynął na pracę Twojego zespołu.  

Szablon

Podstawa historyjki

=====

Podsumowanie: [zmiana na interfejsie graficznym: tj. FE/zmiana systemowa, tj. BE] Tytuł

Kryteria akceptacji:

Pozytywny / negatywny scenariusz

Scenariusz 1: <nagłówek opisujący scenariusz>

Warunki brzegowe: Założenia spełnione przez użytkownika lub system, niezbędne do wykonania określonej akcji

Działanie: Akcja, która ma zostać wykonana przez użytkownika lub system.

Rezultat działania: Zamierzony, testowalny rezultat wykonanego działania

Opis:

Jako <użytkownik systemu/klient/system> chciałbym <zdefiniowanie potrzeby biznesowej>, żeby <co zyskam przez wdrożenie tej zmiany?>

===

INFORMACJE TECHNICZNE

Projekt: wizualizacja, mock-up, wzór graficzny potrzebnej zmiany.

API: zmiany potrzebne do wysłania pożądanych zmian na interfejs.

Baza danych: zmian na bazie, procedurach lub logice systemu potrzebne do wdrożenia zmiany.

Środowiska: <produkcyjne/ testowe / deweloperskie>

Kontekst: jakiej grupy klientów dotyczy zmiana/ jakiego komponentu w systemie dotyczy zmiana.

Role: jakie role w systemie są objęte opisaną zmianą/ jakie uprawnienia są potrzebne do wykonania określonej akcji przez użytkownika / klienta / inny system.

===

DODATKOWE INFORMACJE

Dokumentacja: jaka dokumentacja projektowa/techniczna powinna zostać zaktualizowana, żeby skutecznie powiadomić interesariuszy o zmianie.