Nie trać czasu na call, rób lepsze opisy zadań
Często dostaje takie same pytanie od czytelników, którzy są Analitykami, Kierownikami Projektów , CEO/CTO i Liderami technicznymi.
JAK LEPIEJ OPISYWAĆ ZADANIA DLA PROGRAMISTÓW?
Tyle stanowisk i wspólny problem. Okazuje się, że współpracująć ściślej z programistami (prędzej czy później) zetkniesz się z problemem niedokładnie opisanych zadań.
Pewnie w swojej karierze miałeś okazję usłyszeć od programisty:
🤯 AAAAA, TO O TO CHODZIŁO
🤯 OK, TERAZ JUŻ ROZUMIEM
🤯 TO NIE MOGŁEŚ TAK TEGO OD RAZU OPISAĆ?
🤯 BYŁO WCZEŚNIEJ MÓWIĆ, TERAZ TRZEBA PRZEROBIĆ
Mógłbym tego wypisać nieskończenie wiele, ale chyba „czujesz klimat”.
Kiedyś myślałem, że to świadczy o podejściu roszczeniowym programistów. Jednak dziś wiem, że często mają racje, bo zadania często są opisywane przez biznes po prostu kiepsko.
Powodów jest kilka,
- często po prostu nie ma na to czasu bo mamy 60 innych zadań do zrobienia
- albo klient sam nie jest w stanie określić „JAK COŚ MA DZIAŁAĆ” więc staramy się „szyć”…
Anyway… skutek jest jeden – zadania są w kiepskiej jakości. Nie możemy więc oczekiwać poprawnego wykonania bez masy błędów znalezionych przez QA.
JAK OPISYWAĆ LEPIEJ?
Na początku wyjaśnię jedną rzecz – to czy opis zadania znajduje się w Jirze, Redmine, Trello czy pliku dokumentacja.docx nie zmienia postaci rzeczy.
Musisz zrozumieć, że każdy tekst, który opisuje jak ma być wykonany projekt można nazwać dokumentacją.
Bez znaczenia czy znajduje się w PDF, Word… czy opisie zadania.
Pewnie zauważasz, że wiele razy pisałeś dokumentację w formie zadań dla programistów.
Twoi programiści pokochają ❤️ Cię gdy w opisie zadań znajdą:
- (not) happy path – czyli sytuację, w której opisujesz CO MA SIĘ DZIAĆ, gdy coś się „wysypie”. W skrócie mówiąc… często opisujemy jedynie happy path w danym zadaniu. Zacznij również opisywać co ma się stać gdy dana rzecz nie zadziała / wysypie się.
- rysuj diagramy – obrazuj szerszy kontekst procesu w jakim znajduje się dane zadanie. Programista będzie miał odniesienie jak „spiąć to” z resztą projektu. Idealnie sprawdzają się do tego diagramy UML.
- projektuj makiety funkcjonalne – szczególnie przydatne w sytuacji gdy JEDEN WIDOK może mieć WIELE WARIANTÓW w zależności np. od roli użytkownika, który go przegląda, daty, „stanu” albo czegokolwiek innego. Tworzenie makiet idealnie rozwiązuje ten problem i ułatwia życie programistom.
Sam widzisz, że dokumentacja to nie tylko plik.docx, to również opis tworzonych przez Ciebie zadań dla programistów.
Robiąc to dobrze REALNIE WPŁYWASZ NA JAKOŚĆ IT w swojej firmie, PODNOSISZ SWOJE KWALIFIKACJE – więc warto 🙂
Dlatego tym bardziej chciałbym Cię zaprosić do kursu Dokumentacja.Pro, gdzie nauczę Cię tworzyć zrozumiałe dokumentacje IT (w tym opisy zadań) + wiele innych.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
