pracaanalityka

Dlaczego projekty IT się nie udają? – przemyślenia

dlaczego projekty IT się nie udają
Posted by admin

Dlaczego projekty IT się nie udają? To pytanie zadawał sobie chyba każdy osobnik pracujący przy projektach IT. I jak to często bywa tysiące ludzi – tysiące opinii. Tak jak każdy ma różne założenia przy postrzeganiu zasadności wykonywania jakiegokolwiek zadania.

Patrząc na to jakie myślenie mają ludzie o projektach widzę kilka powodów w przekonaniu że większość projektów się nie udaje. Moim zdaniem cały problem związany z projektami w IT nie polega na tym że są one źle realizowane. Polega to na tym że źle o samych projektach myślimy.

dlaczego projekty IT się nie udają

Porównania. Wszędzie porównania

Pierwsza myśl jaka mi przychodzi do głowy to myślenie o developmencie w taki sam sposób jak o budowaniu domu czy innym tego typu zajęciu gdzie można dość dokładnie opisać co jest do zrobienia. No niestety. Programowanie to nie jest układanie pustaków jeden na drugim. Nikt nie jest w stanie policzyć ile dokładnie zajmie wykonanie danej pracy. Ponieważ nikt nie wie ile dokładnie jest pracy w danym zagadnieniu. W przypadku budowy jest to prostsze ponieważ jesteś w stanie z dużym prawdopodobieństwem policzyć ile dana czynność ci zajmie.

To jest pierwszy grzech myślenia o projekcie IT. Że jest to projekt taki jak każdy inny, jak budowa domu, drogi, stadionu itd. A tutaj mamy kilka czynników które projekt rozwoju oprogramowania wyróżniają:

  • Programowanie jest złożone
  • Programowanie jest abstrakcyjne
  • Technologie zmieniają się szybko w porównaniu z innymi dziedzinami
  • W programowaniu programista często robi dużo researchu zanim zacznie pisać kod
  • Programowanie to taka szeroka dziedzina że ciężko o wymienność ludzi
  • Wymagania biznesowe ciągle się zmieniają
  • Wymagania biznesowe mogą być niekompletne
  • Programowanie za każdym razem jest inne w przeciwieństwie do układania cegieł

A to wszystko prowadzi do jeszcze większych.

Dlaczego projekty IT się nie udają? – Złe założenia przy odpowiedzi

Pierwsze złe założenia to zakres.

  • Zakres nie jest mierzalny w roboczogodzinach tylko w funkcjonalnościach
  • Zakresu nie ustalimy w 100% na początku projektu
  • Nie zawsze da się wszystko idealnie wyestymować
  • Nie zawsze da się alokować jednego specjalistę do danego obszaru i on tam sobie sam poradzi.

Zawsze się pytamy(sami siebie lub kolegów) czy zakres jest w 100% zdefiniowany? A co jeśli zakresu nie da się zdefiniować? Przecież nie ma czegoś takiego jak niezamienialne wymaganie. Jak mamy zapewnić formalną akceptację zakresu który nie jest jasno zdefiniowany? To z definicji prowadzi do porażki projektu.

W trakcie trwania projektu po wyestymowaniu może się trafić że chcemy zamienić jedno wymaganie drugim. Niby ok przecież zakres się nie zmienia, wycena podobna. Niestety. To nie jest tak że jak tu nie położymy 10 pustaków to w drugim miejscu jesteśmy w stanie położyć taką samą liczbę pustaków. Dlaczego? Dlatego że:

  • inne miejsce aplikacji może być w innej technologii
  • to miejsce aplikacji może być źle napisane i wymaga refactoringu
  • inne miejsce aplikacji może być napisane przez kogoś innego(kto już np. nie pracuje w organizacji) i programista musi się wgryźć.

Drugie założenie to podejście do programistów

  • To że jeden programista wykona zadanie z 3 dni nie oznacza że drugi wykona to samo zadanie w tym samym czasie. Jak wymieniasz programistę(bo np. jeden odszedł z pracy) to wdrożenie drugiego może być bardzo czasochłonne. Programista nie jest równy innemu programiście.
  • Fakt że zwiększysz ilość programistów w zespole nie sprawi że od razu zwiększycie ilość wyprodukowanych funkcjonalności w danej jednostce czasu. Ci co byli wcześniej w zespole będą wdrażać tych nowych i koniec końców wykonacie mniej pracy.
  • Rzucanie pojedynczego programisty do kolejnych zagadnień bez utraty jakości nie jest możliwe.

Złe postrzeganie

Te wszystkie założenia prowadzą do tego że projekt developmenu aplikacji uznaje się za nieudany. Nieudany bo niewdrożony w terminie. Porównując projekt IT do zwykłego projektu który nie ma takich złożoności jak development jest z góry skazany na porażkę. Składanie z góry ustalonych elementów trwa X czasu. Jak dołożysz nowy zespół który ma jasno wyjaśnione co robić to złożenie zajmie Y czasu. To wszystko jest mierzalne i łatwe w estymacji.

Nie da się podejść do projektów w taki sposób. Dlatego:

  • Proszenie o termin jest kiepskim rozwiązaniem
  • Nie dziw się że wyceny software house są wystrzelone w kosmos
  • Zastanów się zanim będziesz w szoku gdy proste funkcjonalności są wyceniane na miliony monet
  • Nie bądź w szoku jak aplikacje są pokomplikowane do takiego stopnia że jest problem z utrzymaniem(a jak mają nie być skoro wszyscy piszą kod aby szybciej aby szybciej bo goni termin)

Na początku development jest prosty łatwy i przyjemny. Potem robią się schody i podejście w stylu na kiedy to będzie staje się niezbyt fajne.

Dlaczego projekty IT się nie udają?

Dlaczego projekty IT się nie udają? Udają się. Tylko nie jest w terminie. A dlaczego nie jest w terminie? Dlatego że chcesz porównać gruszkę z jabłkiem. Nieważne jak bardzo będziesz się starał to gruszka nie urośnie na jabłoni. Na szczęście coraz więcej organizacji zaczyna to rozumieć.

Dobra, ale projekt IT może też się nie udać. I nie udaje się w momencie gdy po wdrożeniu aplikacja jest nieprzydatna lub jest niewykorzystywana. I to jest prawdziwa porażka projektu.

A dlaczego takie projekty się nie udają? Dlatego że jest kiepska(lub brak) wykonanej analizy (a dokładnie to każdego kroku z tego wpisu). Nie mamy zdefiniowanych celów, nie mamy zdefiniowanych czynników podstawowych z modelu Kano, nie mamy not happy path. Pomijamy jakikolwiek krok w wymaganiach.

Jeśli miałbym zauważyć największy grzech główny w organizacjach to uważam że najczęściej pomijamy krok piąty czyli „Umożliwienie aby rozwiązanie wdrożono na produkcję”. Słabe komunikowanie zmian. Niezachęcanie użytkowników i nieprzełamywanie oporu do zmian.

Jednak termin to rzecz święta

Wiem że po przeczytaniu tych wszystkich wypocin każdy pomyślał że nie da się robić zadań bez terminu realizacji. No i tu się zgodzę. Termin powinien istnieć. Tak samo jak wyceny. Powinny one istnieć w celach motywacyjnych. Nie w celach określania czy projekt się udał czy nie. Jeśli jesteś w stanie z aptekarską dokładnością wycenić zadanie w ciągu 2minut(albo szybciej bo niektórzy wymagają wyceny od razu) to proszę o kontakt bo chętnie poznam twoje sposoby.

Podsumowując

  • Postrzeganie sukcesu/porażki projektu w IT przez okulary projektów z innych branż zawsze będzie prowadzić do postrzegania tego że projekt jest porażką.
  • Sam termin w IT musi występować jednak nie można się na nim tak bardzo skupiać i nie warto rozdzierać szat jak coś nie wyjdzie.
  • Projekt IT jest porażką w momencie gdy wdrożony produkt nie daje wartości biznesowej.

SZKOLENIE "Czy zawód Analityk IT jest dla mnie?"

Zapisz się na listę mailową a prześlę za darmo szkolenie Czy zawód Analityk IT jest dla mnie? Co muszę umieć żeby być Analitykiem IT?