Jak zabić każdy projekt IT? Lista przebojów

Project Manager płakał, jak to pisał – postanowiliśmy zebrać najważniejsze grzechy, jakie pojawiają się w trakcie tworzenia oprogramowania. Lista
powstała na podstawie kilkudziesięciu “hitów”, które wyłoniliśmy my i nasi klienci, zarówno w projektach tworzonych w Develtio, jak i w innych firmach. W podsumowaniu pokazujemy pożądany rytm pracy, który nierzadko gubi się w natłoku powtarzających się (nie)taktów. A w projekcie – jak w muzyce – wszystko musi się zgadzać. Dzielimy się tym żartobliwym opracowaniem, bo wierzymy, że to ogromna wartość dla naszych klientów i wsparcie we wspólnym procesie projektowym, który nas czeka.

Nothing else matters, czyli…Czego nie ma w zakresie, tego nie ma w projekcie

Jeśli umawiamy się na konkretny zestaw funkcji, to pamiętajmy, że musza być one bardzo szczegółowo opisane w zakresie projektu. W projektach, które nie są realizowane w modelu Time and Material, zakres prac powinien być spisany i zaakceptowany przez obie strony.

Wich you were here, czyli…Spotkania to NIE strata czasu

Wiele osób uważa spotkania za stratę czasu. To duży błąd. Tylko źle zaplanowane spotkania to strata czasu. Natomiast rozmowy projektowe w IT to kluczowy element procesu, który musi być uwzględniony w harmonogramie. Wspólnie tworzymy dany produkt i musimy systematycznie konfrontować nasze przekonania i założenia. I jeszcze jedno – spotkanie bez spisanego memo się nie liczy.

Right here, right now, czyli…Dlaczego nie zrobimy tego na jutro

Na jutro możemy przygotować wycenę lub propozycję tego, JAK coś zrobić – natomiast nie jesteśmy w stanie wdrożyć żadnej istotnej zmiany w projekcie. Projekty są trochę jak puzzle – dorzucenie jednego elementu wpływa na całość obrazka który układamy.

Every breath you take, every change you make…Historia małej, wielkiej zmiany

Jeśli klient chce zmienić zakres prac, musi pamiętać, że wiąże się to ze zmianą harmonogramu i budżetu. My natomiast powinniśmy od razu zakomunikować aktualizacje i przesłać je do akceptacji. Często w wyniku jasnej i transparentnej komunikacji klient zastanawia się trzy razy, czy zmiana faktycznie jest potrzebna.

The Final Countdown, czyli…NIE odkładaj tego na piątek

Tak, niestety wziąć należy o tym pamiętać. Wiele firm i zespołów wprowadza zmiany na serwerze produkcyjnym lub robi istotne wdrożenia przed weekendem. Pamiętaj, aby rozmawiać z firmami które wybierasz, o tym, jak wygląda u nich proces wdrożeniowy – i wybierz mądrze.

The way you lie, czyli…Czy programista serio był na urlopie?

Często sponsorzy projektów słyszą, że dana rzecz przesunęła się w czasie bo programista był na urlopie. Zazwyczaj stoi za tym smutna prawda polegająca na overbookingu czasu programistów. Dobra nie jest z gumy.

I just call to cay…czyli Nazywajmy rzeczy po imieniu

W projektach IT nie ma rzeczy oczywistych – jeśli coś nie jest opisane i ustalone pomiędzy uczestnikami projektu, to znaczy, że w nim nie istnieje.

Tell me why, czyli…nie zakładajmy, że “rozumiemy się bez słów”

Czasami w projekcie wyłania się coś nieprzewidzialnego. Pojawia się wówczas pokusa, aby dodać daną zmianę czy feature bez etapu analizy, makietowania, czy projektowania graficznego. Nie pozwalajmy na to, aby “rozumieć się bez słów”, czy też bardziej dosadnie: “rozumieć się bez specyfikacji”.

Somewhere over the rainbow, czyli…Plan. ma być realny, nie idealny

Zaplanowanie harmonogramu projektu musi uwzględniać nie tylko zasoby firmy produkującej software, ale także możliwości klienta – w tym urlopy czy ścieżki akceptacji. Bądźmy realistami – bardzo często opóźnienia wynikają jedynie z nieuwzględnienia procesu akceptacji. Żyjemy w fajnym świecie, ale pamiętajmy, że nie jest on idealny.

Let’s talk about you and me, czyli…Rozmawiajmy o tym, co naprawdę ważne

Bywa tak, że klient ma nie tylko pomysł, ale również całą wizję na swój projekt i potrzebuje jedynie produkcji. To niestety może okazać się pułapką. Rozmawiajmy wtedy o realizacji pomysłu, zamiast o tym, jaki problem faktycznie mamy do rozwiązania.