najczęstsze błędy podczas układania tasków w projekcie IT – część 2

W poprzednim wpisie rozpocząłem serię artykułów pod tytułem „najczęstsze błędy podczas układania tasków w projekcie IT”. Aktualnie czytasz część drugą, zachęcam cię do przeczytania również części pierwszej ponieważ artykuły tworzą ciąg przyczynowo-skutkowy. Link do poprzedniej części znajdziesz tutaj.

5. brak odpowiedniej konwersji task <-> subtask

Ten punkt ma pośredni związek #1 – różne poziomy szczegółowości tasków. Mam tutaj na myśli złe rozłożenie zakresu w zadaniach – jedne mają go bardzo dużo i powinny być rozbite na subtaski, inne mają go zbyt mało i powinny być pogrupowane w większe zadania. Jeśli z jakiegoś powodu task musi mieć w sobie dużo zakresu projektu, rozbijmy go na subtaski. Można wtedy śledzić status wykonania tasku głównego, a poziom wykonania tasku za pomocą subtasków np. 3/8. Natomiast jeśli tego nie rozbijemy ciężej będzie nam określić, w którym momencie jesteśmy z naszym „gigantem”. Sytuacja jest analogiczna, gdy mamy potworzonych 40 tasków po 5m, więcej czasu zajmie nam przeciąganie ich na „done” niżeli wykonanie. Mikrotaski można zgrupować w jeden i stworzyć dobre AC, dzięki, któremu developer o niczym nie zapomni, a ominiemy zbędną „biurokrację”.

6. zadania nie rozbite na technologie

Dobrym przykładem dzisiejszego wpisu jest strona internetowa. WWW możemy podzielić na część wizualną (frontend) i część liczącą/myślącą (backend). Jeśli dobrze rozbijemy zadania (np. na widoki), może się zdarzyć, że task „strona logowania” zajmie dla osoby tworzącej widok 4h (ponieważ musi dopracować RWD), a dla osoby tworzącej logikę – 30m (bo nie ma tam nic skomplikowanego). Całość wykonania zadania wynosi więc 4.5h. Problem rodzi się w momencie, gdy dwaj różni developerzy (frontend i backend) logują czas w ten task. Jeśli się przedłuża to tracimy cenne minuty na dochodzenie, kto zalogował więcej niż deklarował. Czasami warto rozbić dodatkowo zadanie na technologię – jeśli są to różne fragmenty architektury, ale spójne logicznie np. logowanie – backend (30m), logowanie – frontend (4h). Rozbicie jest też dobrym pomysłem, jeśli jesteśmy pewni, że w jednej technologii rozłożymy zadania między dwie osoby np. #1 redefinicja struktury bazy danych i aktualizacja Entities, #2 logika biznesowa etc.

7. brak wydzielonego tasku „pomocniczego”

Ponownie przykład strony internetowej. Podczas rozbicia zadań na podstawie widoków, robimy: #1 widok kalendarza, #1 widok ogłoszeń. Te widoki mają wiele części wspólnych jak nagłówek/menu, right/left side, footer. Pytając developera, jak estymuje stronę z widokiem kalendarza, skupia się na wycenie kalendarza, a nie elementów wspólnych dla każdej strony. Później może nastąpić „rozjazd” czasowy, bo ktoś siada do zadania z widokiem kalendarza, a okazuje się, że nie ma przygotowanej „siatki dokumentu” z menu, stopką itp, z której mógłby korzystać – więc ją tworzy przedłużając task z kalendarzem. W takich przypadkach dobrze jest to przewidzieć i utworzyć zadanie pomocnicze typu „przygotowanie bazy html” lub „konwersja PSD <-> html”. Problem ten powstaje gdy zbyt mało czasu spędzamy na analizie zadań, nie wyobrażając sobie jak developer do nich podejdzie, jak będzie wykonywał je krok po kroku. W momencie głębszego zastanowienia nad zadaniem dochodzimy do wniosku, że o czymś zapomnieliśmy i musimy przebudować harmonogram.

8. brak ciągłości przyczynowo-skutkowej między taskami

O tym, czy ten problem występuje w Twoim rozłożeniu tasków dowiesz się podczas układania harmonogramu. Układając harmonogram musimy zacząć od początku 🙂 nie możemy realizować projektu od końca. Nie możemy zrealizować modułu płatności, nie mając funkcjonalności odpowiadającej za użytkowników (przy założeniu, że użytkownik ma za coś płacić). Nasze zadania powinny być rozbite w taki sposób, że układają się w ciąg przyczynowo-skutkowy, są ciągłe i następują po sobie (lub idą równolegle, jeśli jest możliwość). Dobrze ułożone zadania dają się ułożyć w „historię tworzenia projektu” czyli harmonogram. Musimy mieć to na względzie ponieważ znacznie ułatwia to m.in. testowanie produktu. Podejrzewam, że słyszałeś – „ten moduł jest skończony, można go testować. Nie działają tylko XYZ – bo musimy najpierw skończyć ABC”. Przyczyny mogą być dwie: 1) źle ułożony harmonogram, 2) źle rozbite taski. Tworzenie produktu powinno odbywać się tak, jak toczenie powiększającej się stopniowo kuli śniegu.

Teoria teorią, ale musimy sobie zdawać sprawę, że świat nie jest idealny i często uniknięcie wszystkich powyższych błędów jest niemożliwe. Często musimy iść na kompromis, wybierając niektóre cechy kosztem innych – co sprawdzi się w danym przypadku
najlepiej, zależy od konkretnego projektu. Prawie każdy harmonogram da się zrealizować – to jakiej jest jakości będzie przekładało się bezpośrednio na czas wykonania. Napisz w komentarzu top 5 błędów, które według Ciebie są najczęściej popełniane podczas układania project planu/układania tasków 🙂