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.
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:
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.
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
