Taski (bądź też tickety), to najczęstsze określenia na zadania, z jakimi możecie się zetknąć. Czym one tak naprawdę są? Dlaczego często się zdarza, że jest tak wiele nieporozumień, jeżeli chodzi o efekt końcowy?

Pisząc te słowa, przychodzą mi do głowy memy, obrazujące co klient chciał, jak to opisał, a co naprawdę potrzebował. Biorąc pod uwagę wszystkie te czynniki, możemy stworzyć prostą checklistę, pozwalającą nam stwierdzić, że zadanie zostało wykonane. Według mnie, składają się na nią, następujące kwestie:

• Zostało wykonane zgodnie z założeniami
  Jeżeli dostajemy zadanie, mówiące o tym, że mamy stworzyć przycisk, koloru niebieskiego, który będzie w kształcie prostokąta, o wymiarach 200px na 150px, to naszym zadaniem, jest dostarczenie takiego przycisku. Nie powinien on mieć innych wymiarów, niż w zadaniu, nie powinien mieć innego koloru, powinien zostać wykonany, zgodnie z tym, czego sobie życzył autor zadania. Wiele osób, szczególnie zaczynających swoją karierę, ma pokusę do ulepszania rzeczy, robienia ich niezgodnie z otrzymanym poleceniem. Jeżeli uważacie, że coś jest nie tak, lepiej dopytać się i upewnić, że tak właśnie miało być. Czasami pojawiają się w zadaniach błędy, rzeczą ludzką jest się mylić, ale pamiętajcie: nikt na Was nigdy nie powie złego słowa, jeżeli wykonacie zadanie, zgodnie z założeniami. Przycisk ma być koloru niebieskiego, to oznacza, że właśnie taki ma być.
• Zadanie zostało sprawdzone, przed oddaniem
  Najprostszym sposobem na weryfikację, jest przeczytanie sobie zadania, które mieliśmy do wykonania i szczegółowa analiza, czy to co stworzyliśmy / dostarczyliśmy, jest zgodne z treścią. Przydatna podczas tego tłumaczenia, może być „gumowa kaczuszka” (u programistów to sposób na szukanie błędów, polegający na opowiadaniu kaczuszce, bądź też innemu przedmiotowi, co się zrobiło, dzięki czemu, łatwiej jest odnaleźć błąd), której wyjaśnimy, tłumacząc linijka po linijce / kliknięcie po kliknięciu, co tak naprawdę stworzyliśmy.
• Zadanie jest gotowe, do umieszczenia na produkcji
  Przez produkcję, rozumiemy serwis, który jest dostępny dla użytkowników i przez nich widoczny. Deweloperzy mają często swoje wersje, na których mogą podejrzeć swoje zmiany. Najprościej można to przedstawić, na przykładzie bloga i posta. Tekst, który właśnie czytasz, wylądował na produkcji, czyli na stronie, na której właśnie się znajdujesz. Nim to się stało, był dostępny na „wersji deweloperskiej”, czyli miejscu, gdzie mogłem podglądać, wprowadzane zmiany i robić poprawki, a moja praca, nie była widoczna, przez osoby odwiedzających tego bloga. Kliknięcie przycisku opublikuj, jest umieszczeniem tego tekstu na produkcji. Zadanie jest skończone, jeżeli możesz odpowiedzieć sobie na pytanie: „Czy na pewno, sprawdziłem to co stworzyłem i jestem pewny, że w każdym momencie, może to zostać umieszczone na produkcji?”. Często się zdarza, że zapominamy o jakiś kwestiach, których moglibyśmy uniknąć, poświęcając 5 minut na upewnienie się, że zadanie jest faktycznie skończone.
• Wykonałem, to co do mnie należało
  Skończyłem zadanie, ale czy zostało wykonane zgodnie z obowiązującym procesem? Czy poinformowałem odpowiednie osoby o zakończeniu? Odpisałem klientowi na maila? Sprawdziłem, czy na pewno działa? Czy z czystym sumieniem, mogę powiedzieć, że jest zakończone i osoba sprawdzająca, mi to potwierdzi? Jest gotowe do przerzucenia na produkcję? Wykonałem je, zgodnie z założeniami? Jeżeli na którekolwiek pytanie, odpowiedziałeś sobie nie, oznacza że powinieneś wrócić do zadania.

Istnieje takie pojęcie, jak Definition of Done (DoD) – co musi zostać wykonane / dostarczone, żeby uznać, że praca została skończona. Najczęściej to pojęcie, używane jest w Scrumie, czyli metodyce pracy zwinnej, polegającej na dostarczeniu jakiegoś produktu, w określonym czasie. Skuteczne opisanie, co składa się na DoD, pozwala na wydanie produktu klientowi i pewność, że wszystko zostało wykonane, zgodnie z założeniami, nie ma ukrytych wad i przede wszystkim działa.

Polecam, żeby każdy tworzył własne standardy DoD, w zależności, z czego składa się Wasza praca. W przypadku programisty, może to być następujaca lista:

• czy wykonałem zadanie, zgodnie z założeniami?
• czy kod, został napisany zgodnie z dobrą praktyką programistyczną?
• czy przetestowałem działanie?
• czy może to mieć jakiś wpływ, na działanie systemu?
• czy sprawdziłem kod, przed oddaniem?
• czy faktycznie zadanie zostało skończone i jest gotowe do wrzucenia na produkcję?
• czy opisałem, ścieżki testowania i umieściłem wszystkie potrzebne informacje, do prawidłowego działania?
• czy jest coś, co trzeba wykonać, po wgraniu na produkcję?
• czy wprowadziłem wszystkie poprawki, jeżeli takie zostały mi zgłoszone?
• czy jest coś, o czym nie pomyślałem?

Będąc dokładnym, w tym co robimy, nie tylko budujemy własną pewność siebie, ale również sprawiamy, że nasi współpracownicy mogą nam ufać i stajemy się odpowiedzialną osobą, której można powierzać coraz trudniejsze zadania.

Niezależnie co robimy w życiu, warto się czymś wyróżniać. Według mnie, nie ma lepszej rzeczy do wyróżniania, niż jakość, którą dostarczamy własną pracą. Życzę Tobie, drogi czytelniku, żebyś również się wyróżniał – jakością, którą dostarczasz.