10 najczęściej popełnianych błędów w projektach IT

Projekty IT są jednymi z najtrudniejszych do prowadzenia, ze względu na ich specjalistyczną specyfikę oraz specyficzny profil osób pracujących nad realnym wdrożeniem systemu lub oprogramowania.

Błędy w zarządzaniu projektami IT nie polegają najczęściej na technikaliach lub na zastosowaniu nieodpowiedniej technologii - polegają głównie na dopasowaniu do kwestii biznesowych i to właśnie na tym skupimy się w tym materiale.

1. Brak podłoża biznesowego - inwestowanie w development przed weryfikacją biznesową

Najczęstszym błędem jest brak podłoża biznesowego w danym projekcie technologicznym - czyli budowanie software’u, który nie jest potrzebny biznesowo i nie ma uzasadnienia biznesowego lub finansowego - w skrócie nie generuje pieniędzy dla firmy.

Wprawdzie moda na “budowanie kolejnego Facebooka” już minęła, to wciąż nie brakuje projektów bez jasnego planu i celu generowania przychodów i biznesu.

Mało tego, nawet duże firmy, wdrażając złożoną technologię, nie zaczynają od ustalenia KPI i celów finansowych wdrożenia danej technologii, lecz od wizji lub pozornej konieczności alokowania budżetu na daną technologię.

2. Overdevelopment i komplikowanie, czyli development zbyt dużej ilości funkcjonalności

Wrogiem sukcesu technologii jest zbyt szeroka wizja. Najlepsze programy to takie, które rozwiązują wąski i specyficzny problem. Bardzo często zdarza się, że w ferworze wizji i chęci rozwoju, dokłada się do oprogramowania masę niepotrzebnych ficzerów, które jedynie utrudniają użytkowanie oprogramowania.

Może to decydować o braku adaptacji projektu, a w skrajnym przypadku jego upadku.

Budując software, należy pamiętać o tym aby skupić się na kluczowych funkcjonalnościach - tych których rzeczywiście potrzebują użytkownicy i które decydują o tzw. “monetyzacji” projektu.

3. Brak weryfikacji wypuszczanych funkcjonalności na użytkownikach

Budując projekt technologiczny najtrudniejszą barierą psychologiczną jest uciekanie od tzw. “Zderzenia z rzeczywistością”, czyli weryfikacji założeń i funkcjonalności na rzeczywistych użytkownikach systemu.

Bardzo często, gdy następuje moment wypuszczenia produktu do testowania przez użytkowników, podejmuje się decyzję o odwlekaniu tego momentu i o dalszym developmencie rozwiązania bez jego wcześniejszej weryfikacji.

Na koniec dnia, w szczególności w projektach B2C, to użytkownicy systemu decydują o jego przydatności i walidacji i bez testowania funkcjonalności na prawdziwych użytkownikach, nie jest możliwy jej dalszy rozwój.

4. Omijanie procesu MVP, czyli Minimum Viable Product

Wiele projektów, w szczególności tych wysokobudżetowych i projektów B2B, często ignoruje potrzebę planowania produktu zgodnie z zasadami MVP - przecież jeśli projekt został już zabudżetowany, to jego adaptacja i przydatność jest potwierdzona.

Nic bardziej mylnego, bo nie tylko o walidację tutaj chodzi. Chodzi również o Project Management i efektywne wykorzystywanie zasobów.

Omijając proces MVP, narażasz się na niepotrzebne koszta i nieefektywne inwestowanie w zasoby, a skupiając się na dowiezieniu minimalnej wersji swojego produktu, zapewniasz, że dalszy rozwój skupi się na kluczowych dla projektu funkcjonalnościach.

5. Wyeliminowanie procesu testowania

W projektach o niskim budżecie często pomija się proces testowania oprogramowania, czy to w modelu manualnym, czy automatycznym.

Testowanie jednak to nie tylko standard, ale też oszczędność. Omijając ten proces, choćby w uproszczonej formie manualnej narażamy projekt na “odwracanie” deploymentów, które w developmencie technologicznym są bardzo kosztowne.

Testowanie wbrew pozorom nie musi również być bardzo kosztowne - można je zorganizować w modelu “budżetowym, efektywnie budując środowisko staging + production i nie angażując w proces testowania dużej ilości osób.

6. Przeciąganie sprintów i wydań w nieskończoność

Będąc niedoświadczonym liderem prowadzącym projekty, łatwo dać się zwieść iluzji o niekończących się pracach, testach i poprawkach. To bardzo często argumenty osób technicznych za którymi kryje się chęć przedłużania sprintów i deploymentów.

W praktyce jednak, warto dążyć do balansowania długości sprintów (ani za krótkie ani za długie nie będą w żadnym przypadku dobre), pamiętać o ograniczaniu niekończącego się dopieszczania developmentu, a poprawki przerzucać na przykład do kolejnych sprintów i wydań.

W ten sposób zapewniamy produktowi postęp i rozwój, jednocześnie pamiętając o jego późniejszym ulepszaniu i poprawkach.

7. Brak budżetowania finansowego projektu

Wiele projektów, nawet jeśli ma swoje budżety technologiczne, są one najczęściej niedoszacowane. Budowa technologii kosztuje duże pieniądze - a rozwiązania budżetowe rzadko znajdują swoje odzwierciedlenie w praktyce.

Projekty zawsze kosztują więcej niż pierwotnie się zakłada, a budżetując projekty bardzo często nie bierze się pod uwagę kosztów organizacyjnych takich jak HR, urlopy albo support proprojektowy - mimo, że to często największa część ponoszonych kosztów.

W praktyce, jedynie Ci którzy mają największe doświadczenie potrafią realnie budżetować projekty i przewidywać ich rzeczywiste koszta - jest to wiedza niedostępna dla osoby początkującej.

8.  Skalowanie niedziałających systemów i procesów

Budując projekty technologicze łatwo ulec  tzw. Iluzji ego i chęci jak najszybszego rozwoju, w szczególności widząc pierwszą sprzedaż i odnosząc pierwsze sukcesy.

W praktyce jednak nie wolno zbyt szybko skalować i inwestować w rozwój. Należy robić to jedynie gdy jesteśmy pewni co do funkcjonowania modelu biznesowego.

“Automation applied to inefficient operation will only amplify inefficiency”. Bill Gates

W ten sposób jesteśmy pewni, że automatyzujemy i skalujemy procesy, które rzeczywiście działają i przynoszą nam zyski.

9. Nieefektywne zarządzanie zasobami ludzkimi, np. przeładowanie obowiązków 1 osoby

Osoby z mniejszym doświadczeniem często niedoszacowują ilości czasu potrzebnego do developmentu danego produktu lub rozwiązania.

W ten sposób łatwo jest przeładować obowiązkami jedną osobę zakładając, że taka osoba zajmie się zarówno front-endem, back-endem oraz, że będzie posiadała odpowiednie umiejętności miękkie i biznesowe.

W praktyce to nierealne, takie osoby nie istnieją, a oczekiwania bardzo często rozmijają się w tym obszarze z rzeczywistością.

10. Brak rozróżnienia pomiędzy produktem B2B & B2C

Produkty B2B i B2C to całkowicie oddzielne segmenty produktów i mają zupełnie inny cel/przeznaczenie.

W praktyce development tych rozwiązań wygląda zupełnie inaczej - produkty B2C charakteryzują się focusem na UI i user experience, podczas gdy produkty B2B charakteryzują się skupieniem na obecnych (często niepłacących) użytkownikach.

Warto wiedzieć dla kogo rozwijany jest finalny produkt aby móc zaplanować jego odpowiedni i jakościowy development.

Te 10 punktów to jedynie wierzchołek góry lodowej i niewielka część błędów popełnianych przy projektach informatycznych. A jakie Wy błędy popełniliście przy swoich projektach? Podzielcie się z nami opinią w komentarzach.