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! 👍

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.