Chcesz, żeby Twój projekt IT przeszedł do historii? Żeby wspominali go pracownicy, kontrahenci, a może nawet lokalna prasa? Świetnie! Mamy dla Ciebie instrukcję krok po kroku, jak położyć projekt IT w sposób spektakularny. Tak, żeby nie został po nim nawet kurz. A na koniec – żeby można było napisać piękne case study. Takie z morałem: „Nigdy nie róbcie tak jak oni!”.
Krok 1. Zignoruj analizę potrzeb. Szkoda czasu.
Najlepszy sposób, żeby zacząć źle, to zacząć szybko. Po co tracić czas na analizę? Po co sprawdzać, czy Twój pomysł faktycznie rozwiązuje problem klientów? W końcu skoro konkurencja ma aplikację, Ty też musisz mieć. W efekcie powstaje narzędzie, którego nikt nie potrzebuje, nikt nie chce i nie będzie używać. Wersja hard: stwórzcie aplikację, która ma 30 funkcji, z czego 25 z nich, nikomu się nigdy przyda.
Analiza potrzeb to nie kaprys zespołu projektowego, tylko fundament przedsięwzięcia. Badania rynku czy rozmowy z użytkownikami to etap, na którym oszczędza się pieniądze. Jeśli pominiesz ten etap dzisiaj, to i tak zapłacisz jutro.
Krok 2. Podpisz pierwszą lepszą umowę. W końcu to tylko formalność.
Drugi klasyk. Wybierasz software house, freelancera albo kuzyna programistę. Umawiacie się w stylu „jakoś to będzie” i tworzycie umowę całego projektu w 5 minut. Bez harmonogramu, bez warunków testów, bez jasnego opisu zakresu itp.. A potem? Potem zaczyna się standard w takich przypadkach:
– „Tego nie zrobimy, tego nie było w umowie.”
– „Za tę funkcję to już trzeba dopłacić.”
– „Oddamy, oddamy, ale poczekacie jeszcze za dwa-cztery miesiące.”
Dobra umowa to Twoja polisa ubezpieczeniowa. Powinna jasno określać zakres, terminy, odpowiedzialności i sposób rozwiązywania konfliktów. Jeśli masz umowę na jedną stronę A4 w złożonym i kosztownym projekcie, to gratulacje, właśnie sam podłożyłeś sobie minę.
Krok 3. Nie testuj. Przecież w Excelu działało.
Najpiękniejsze porażki IT biorą się z założenia, że na testy nie ma już czasu, nie ma nie pieniędzy i zrobi się to potem. Przecież programista uruchomił aplikację u siebie i działała. Po co robić więcej? Efekt – klient dostaje system, który wyświetla błędy przy pierwszym logowaniu. Użytkownicy zamykają kartę szybciej, niż otworzyli. A Ty? Tobie zostaje raport od twórców: „Projekt produkcji zakończony sukcesem, tylko użytkownicy się nie dostosowali”.
Testy to nie etap „jak starczy czasu i pieniędzy”. To obowiązkowy punkt każdego projektu. Najpierw testy jednostkowe, potem integracyjne, na końcu testy z użytkownikami. Tak, to kosztuje. Ale jeszcze więcej kosztuje produkt, z którego nikt nie korzysta.
Krok 4. Komunikacja? A po co, przecież każdy wie, co robi
Kolejna pułapka to brak rozmów w trakcie projektu. Biznes mówi jedno, IT rozumie drugie, a klient końcowy ma trzecie oczekiwania. W efekcie powstaje coś, co nie działa dla nikogo. Częsta sceny z projektów to „Myślałem, że to będzie wyglądać inaczej.” lub „Przecież mówiliśmy o tym miesiąc temu.” albo „Nie wiedziałem, że to jest ważne.”.
Regularne spotkania, raporty, aktualizacje to nie jest zbędna biurokracja. To tlen dla projektu. Komunikacja między biznesem, a IT musi być jasna, prosta i regularna. Lepiej spędzić godzinę na spotkaniu choćby na Teams, niż pół roku na ratowaniu błędów.
Krok 5. Policz koszty ogólnie, z tzw. grubego palca
„Zróbmy to tanio i dobrze. Nie wydawajmy więcej niż X zł” To jeden z najlepszych sposobów, by projekt IT nie miał szans. Źle policzone koszty oznaczają, że potem brakuje pieniędzy na wspomniane wcześniej testy, na dodatkowe funkcje, na późniejsze utrzymanie i support. W efekcie system działa przez krótki czas, a potem zaczyna się sypać, czyli generować błędy, na które nie ma w projekcie już funduszy.
Budżet w IT to nie tylko koszt zespołu programistów. To między innymi także liczne testy, kolejne wdrożenia, utrzymanie, szkolenie zespołu. Jeśli planujesz wydać np. 100 000 zł, to przygotuj lepiej 130 000 zł, bo nieprzewidziane koszty zawsze się pojawią. Jednak zanim podejmiesz decyzję ile tego zapasu mieć, to poświęć czas na szczegółowe prognozy.
Krok 6. Zrób szybki research rynku
Kolejny gwóźdź do trumny – brak badań. Nie sprawdzasz technologii, nie analizujesz konkurencji, nie pytasz ekspertów. Bierzesz pomysł z jakiejś dyskusji na LinkedIn. A potem okazuje się, że to rozwiązanie nie pasuje do Twojej branży, nie integruje się z innymi systemami i kosztuje dwa razy więcej niż planowałeś.
Research to może być etap, w którym decydujesz o losie projektu. Trzeba sprawdzić technologie, narzędzia, integracje, konkurencję. Jeśli zrobisz to rzetelnie, to unikniesz niespodzianek i będziesz miał dane, które pozwolą ci zdecydować czy to właściwy kierunek. Jeśli nie zrobisz tego sumiennie, to masz gotowe case study z porażki.
Instrukcja obsługi porażki projektu:
1. Koniecznie zacznij bez analizy potrzeb.
2. Podpisz umowę bez jej czytania. Inni też tak robią.
3. Zrezygnuj z testów, bo to głupota.
4. Nie rozmawiaj zbyt często z zespołem.
5. Policz koszty po łebkach.
6. Pomiń etap researchu, bo sam wiesz lepiej.
A teraz na serio czy naprawdę chcesz być takim case study dla innych?
Ironia ironią, ale fakty są twarde. Większość projektów IT kończy się opóźnieniem, przekroczeniem budżetu lub całkowitym fiaskiem. I nie ma w tym magii, zawsze chodzi o te same, powtarzalne błędy, czyli między innymi: brak analizy, brak komunikacji, brak testów, źle policzone koszty.
Nikt nie planuje położyć projektu, ale większość robi to nieświadomie. Wystarczy zlekceważyć analizę, podpisać złą umowę, oszczędzić na testach. Reszta wydarzy się sama.
