Dziś coś dla tych wszystkich, których czeka wdrożenie systemu IT, u siebie w zespole albo u siebie w firmie. Wiele osób jest przerażonych tym, że będą musieli wdrażać jakiś system, są też pełni nadziei, że dostawca powie im, czego można się spodziewać, co może się zadziać.
Opowiem o pułapkach, w które najczęściej wpada się w takich projektach. O tym dlaczego bardzo często kończy się to większymi problemami niż mogłoby się kończyć. I o tym jak połączyć dwa światy: ludzi, którzy nie mają do czynienia z IT i specjalistów od wdrażania systemu, tak aby całe przedsięwzięcie zakończyło się happy endem. Zapraszam do lektury.
Dzisiejszy wpis jest inspirowany moimi doświadczeniami z firmami z którymi pracowałem, które audytowałem pod kątem zarządzania projektami i którym pomagałem się przygotować do wdrożenia systemów IT. Okazało się, że pewne tematy, problemy są powtarzalne. Pracowałem w IT dosyć długo i przybliżę Wam jeden i drugi świat, tak, żebyście mogli się przygotować do tego typu operacji.
Specyfika branży
Był taki dowcip w Dilbercie dawno temu – przychodzi informatyk do użytkownika i prosi o podanie wymagań, czego użytkownik oczekuje od systemu. Użytkownik pyta, a co ten system potrafi zrobić. Odpowiedź informatyka – no wszystko. Na to użytkownik – to zróbcie tak, żeby podał Wam moje wymagania. Bardzo często z taką sytuacją mamy do czynienia, w której wszystko się rozbija o to w jaki sposób określić czego chcemy, czego potrzebujemy w projekcie. Clue sukcesu IT jest jasne określenie tego co jest potrzebne.
Konflikt na starcie
Jest kilka problemów. Pierwszy to kwestia konfliktu. Trzeba sobie zdawać sprawę, kto pracuje po stronie IT, jak dochodzi do procesu, w którym zaczynasz realizować projekt. Najpierw przychodzi sprzedawca, który mówi, że system wszystko zrobi. Potem dochodzi do podpisania umowy, sprzedawca znika, pojawia się inżynier, który nagle ma zrobić wszystko co sprzedawca naobiecywał i klienta, który jest mega nakręcony, że to dostanie. Tu się zaczyna zderzenie z rzeczywistością. Okazuje się, że inżynier ma inną perspektywę mówienia. Sprzedawca ma podejście, że wszystko jest możliwe, inżynier widzi całą masę skomplikowanych tematów i wiedzę, że nie wszystko jest możliwe. Pojawia się pierwszy zgrzyt.
Bardzo często nie do końca precyzyjnie jest też wpisane w umowę to co ma być dostarczone. To powoduje, że trzeba się dowiedzieć co trzeba zrobić, a kontrakt jest podpisany już na stałą cenę i więcej nie będzie. To powoduje, że stawiamy w konflikcie osoby, które mają dostarczać vs osoby, które mają dać wymagania czego oczekują od systemu. Są umieszczeni od razu w niekomfortowej sytuacji.
Mgła wojny
Kolejny problem to mgła wojny. Działasz w bitwie i nie wszystko jest dla Ciebie jasne, nie ma przejrzystych informacji, nie wiemy co, gdzie się dzieje. Tak samo jest w przypadku projektów technicznych, gdzie z drugiej strony partnerem jest osoba nietechniczna. Najczęściej działy biznesowe nie są guru technologii, bo to nie jest ich robota. Z drugiej strony deweloperzy i programiści to nie eksperci od każdego procesu biznesowego i dla nich tam jest mgła wojny. Trzeba te światy połączyć chociaż trochę, zrozumieć czego potrzebują deweloperzy, żeby być skuteczni i czego potrzebuje biznes. Dbajcie o to, żeby jedna i druga strona rozumiała.
Scope Creep
Pełzający zakres. Okazuje się, że w pewnym momencie po zaczęciu projektu i nagle chcielibyśmy jeszcze to i to i to. To jest wkurzające dla osób, które tworzą oprogramowanie, wskakują im nowe rzeczy. Osoba po stronie IT, która prowadzi projekt ma budżet, ma rozlokowane zasoby, a nagle zakres puchnie. To powoduje odpowiedź, że więcej nie możemy zrobić w tym budżecie. Po drugiej stronie pojawia się “ale jak to przecież sprzedawca mówił, że zrobicie wszystko, że wszystko jest możliwe.” Zaczyna się element z którego trudno wyjść.
Podsumowując na początku większość projektów jest obarczona konfliktem, który później się pojawia, bo mamy niedoprecyzowane tematy. Dodatkowo obie strony nie do końca się rozumieją i bardzo trudno z tego wyjść.
Czego warto pilnować?
Po pierwsze pytaj. Jak czegoś nie rozumiesz pytaj, warto, żeby pytania były z obu stron. Pytaj jak deweloperzy pracują, czego potrzebują, z drugiej strony spodziewaj się pytań jak działa proces, który ma być oprogramowany. Dużo winy leży po stronie firmy zamawiającej, bo nie do końca wie czego chce. Nie do końca wiemy jak działa nasz proces, nie wiemy jaki jest oficjalny, jak chcemy, żeby działał. Ludzie się boją i generują przypadki ‘na wszelki wypadek” zróbcie to i to, bo być może będzie to potrzebne. Jak wdrożymy bez tego, to może będziemy mieć później problem.
Jest sposób na przygotowanie swoich oczekiwań. To albo przypadki użycia albo historyjki – odcinek o tym tutaj . Najważniejsza rzecz – nie rozumiesz to pytaj. Mi zajęło trzy miesiące po tym jak zacząłem pracować z IT o co chodzi.
Po drugie ustalcie proces według którego będziecie pracować. Teraz modne jest, że jak firma przyjdzie do Ciebie i powie, że nie jest Agile, to słabo. Tak naprawdę większość tych sposobów wytwarzania nie ma nic wspólnego z Agile i jest jakąś hybrydą. Pytaj o proces i go zrozum. Zrozumcie jak działa firma z którą będziecie pracować, w jaki sposób zbiera wymagania, jak pracuje, to jest bardzo ważne.
Po trzecie ryzyko. Pod kątem zarządzania projektami IT ma to swoją specyfikę, ze względu na to jaki produkt powstaje. Jeżeli działasz w branży budowlanej i masz do zbudowania most to konstrukcja, którą widać. Tam też dużo rzeczy może się zadziać, ale dużo mniej elementów niż w IT. Jak zapomnisz przęseł to most nie będzie działał. W przypadku IT produkt wokół którego działamy jest inny, dlatego element zarządzania ryzykiem jest dosyć ważny.
Jakie to mogą być ryzyka?
Po kolei – błędy techniczne, pracujemy nad technologią. Warto rozróżnić błędy techniczne, które wynikają z tego, że coś jest nie tak w oprogramowaniu, od błędów popełnianych w samym oprogramowaniu przez informatyków. Jak ja prowadziłem takie projekty, to w momencie pokazywania demo dla klienta właśnie się wywracało. Złośliwość rzeczy martwych. Warto zidentyfikować, które z tych problemów były od nich niezależne, a które wygenerowały się przez złą jakość kodu. Ponieważ do końca nie odróżniasz skąd się to wzięło, to biedni deweloperzy są obarczani każdym błędem wynikających z ich winy oraz z winy firmy, która zamawia, na etapie tworzenia wymagań.
Inne problemy to problemy w komunikacji, opóźnienia po stronie firmy informatycznej, pominięcie istotnych elementów. Pominięcie istotnych elementów wynika z tego, że na początku projektu nie mamy do końca dobrze zdefiniowanego zakresu, tego co ma być wykonane. Czy pracujesz Agile czy nie nie daj się zwieść, że później sobie doprecyzujecie. Im szybciej wejdziemy w detale procesu, tym szybciej wybiją błędy, które będzie można rozpracować.
Słaba jakość kodu i tego co powstaje. Jesteśmy w konfliktowym otoczeniu, bardzo słabo rozumiemy procesy wytwarzania oprogramowania i procesy biznesowe. To powoduje, że dużo rzeczy deweloperzy, których goni czas muszą zgadywać. Na koniec okazuje się, że nie działa do końca jak powinno. Pomijam sytuację, w której kod jest napisany źle.
Zapraszam do zapoznania się z playlistą Agile . Zobacz o co chodzi, żeby zrozumieć w jaki sposób można pracować z IT. Jest spora szansa, że taki sposób pracy ktoś Ci zaproponuje. Dobrze, żebyś wiedział z czym to się je.
VIDEO