Problemy w projektach IT

Na temat zarządzania projektami IT powstała w zasadzie nieskończona ilość stron, książek, programów, filmów. Terminy takie jak: Scrum, Agile, Kanban są szeroko opisywane, wyjaśnianie i analizowane. Znacznie trudniej znaleźć można artykuły traktujące realne problemy, wykraczające poza idealny świat opracowań książkowych.

Ten wpis powstał z chęci podzielenia się latami doświadczeń w zarządzaniu projektami IT. Określone zostały najważniejsze problemy związane z produkcją oprogramowania.

Określenie „gotowe”

Najczęstszym problemem jest nadużywanie terminu „gotowe” i jego synonimów takich jak zrobione, done. Zdecydowana większość osób zaangażowanych niewłaściwie i zbyt pochopnie używa określenia „gotowe”. Wbrew pozorom zdefiniowanie, czy projekt, lub jego część są gotowe jest dość trudne. Można użyć porównania z gotowaniem obiadu, gdzie trzeba zrobić zakupy, ugotować obiad, pozmywać i posprzątać po obiedzie. Jak powszechnie wiadomo, dla niektórych obiad, to tylko zrobienie zakupów, dla niektórych to zrobienie zakupów i konsumpcja posiłku, a dla niektórych obiad jest skończony jak jest po nim pozmywane i posprzątane. Ta analogia, pomimo swojej prostoty, jest skalowalna na projekty IT. Dlatego poniżej zaprezentowane są popularne przypadki, w których nie można mówić, że coś jest „gotowe”. Dodatkowo każdy przypadek oferuje jeden output – wyjście projektowe w procesie produkcji oprogramowania, które identyfikuje, że task nie jest „gotowy”. Takich output-ów może być wiele, ale dla uproszczenia opisu zaprezentowany jest ten najważniejszy. Nie oznacza również, że realizacja output-u ustawia status zadania na „gotowe”.

Przykłady poniżej:

Programista napisał kod, który działa i spełnia wymagania funkcjonalne – Wcale nie oznacza, to że zadanie jest „gotowe”. Musi zostać przetestowane przez inną osobę z teamu, najlepiej testera.
Programista uwzględnił poprawki testera – Dalej task nie jest „gotowy”, tester powinien wykonać sprawdzenie ponownie
Testy nie wykrywają żadnych błędów – To zazwyczaj doskonała wiadomość. W zależności od „miejsca”, w którym test został wykonany, kod może wejść na produkcje, lub zostać przekazany do testów klientowi. W tym przypadku termin „gotowe” jest najczęściej nadużywany. Task lub sprint muszą być odebrane przez klienta i potwierdzone protokołem odbioru, lub pisemnym potwierdzeniem, że wszystko jest OK.
Kod jest napisany, testy przeszły pomyślnie, klient na sprint review, lub w trakcie rozmowy potwierdza wykonanie zadania – Tutaj można stwierdzić, że słowo mówione równe jest w teorii pisanemu. Niestety w życiu pojawiają się sytuacje nieoczekiwane i PM powinien mieć zawsze zatwierdzenie zadania na piśmie, lub w formie elektronicznej.

Uzyskanie statusu „gotowe” umożliwia zablokowanie wykonanego zadań. Oczywiście, jeżeli istnieje wyraźna potrzeba można wrócić do zadania, ale już w czasie dodatkowym. Potwierdzenie przez klienta wykonania zadania i ustawienia jego statusu na „gotowe” jest jednym z kluczowych aspektów prowadzenia projektu. Bardzo ważne, aby poszczególne sprinty w dużym projekcie uzyskiwały status „gotowe”, tak szybko jak to możliwe. Definicja „done” wydaje się być prosta. Jest to etap, w którym możemy klientowi wystawić fakturę i nie wracać już do tego zadania w tym projekcie.

Małe, duże problemy

Częstym problemem opóźniającym realizację projektów IT są uciążliwe drobiazgi wynikające ze złej komunikacji wewnątrzprojektowej.

Komunikacja z klientem to kluczowa rzecz i powinna być prowadzona przez osobę posiadającą łatwość nawiązywania kontaktów.

Bardzo ważne jest poszanowanie każdej ze stron w projekcie i w momencie pojawienia się problemów nie obwinianie nikogo, tylko poszukiwanie rozwiązania. Komunikacja z klientem powinna być prowadzona jasnymi i przejrzystymi komunikatami i klarownymi opisami zagadnień, co nie jest łatwe dla osób technologicznych. Bardzo ważnym elementem realizacji projektu jest wywiązywanie się klienta z zadań.

Nie ma szans na terminowe wykonanie, jeżeli klient sprawnie nie odpowiada na pytania i nie współpracuje. Jest on częścią projektu i musi zdawać sobie z tego sprawę. W wielu przypadkach trudno jest wyegzekwować wywiązywanie się z obowiązków jakie spoczywają na kliencie, ale nawet najlepszy zespół nie skończy należycie i na czas projektu bez obustronnej współpracy.

Ostatnim aspektem, z którym wiążą się opóźnienia projektowe jest całkowity brak zarządzania projektem przez osobę kompetentną w tym zakresie. Skutkuje to ignorancją dziennych spotkań co prowadzi do sytuacji, w której deweloper zaczyna pracować nad „swoją” wersją projektu. Brak wyznaczonych zadań wpisanych w ramy czasowe powoduje, że programiści przeskakują pomiędzy zadaniami. Wtedy na pytanie klienta, co w rzeczywistości zostało wykonane najczęstszą odpowiedzią są stwierdzenia w tylu „w zasadzie gotowe”, lub „prawie gotowe” – czyli krótko mówiąc nie gotowe.

 

Ignorowanie regularnych spotkań z klientem spowoduje, że wizja projektu prawie zawsze będzie rozbieżna pomiędzy stronami. Trzeba pamiętać, że wielu właścicieli firm IT popełniło błąd niezatrudnienia doświadczonego menadżera projektów. PM nie tworzy kodu i nie daje namacalnego wkładu w rozwój oprogramowania, ale jego brak w przeważającej większości przypadków powoduje zwiększeniem kosztów wykonania projektu i naraża na szwank reputację firmy. Stąd bardziej opłaca się zainwestować w dobrego PM niż podjąć ryzyko wykonania projektu IT bez niego

Comments are closed.