Analiza projektu IT - przeprowadzać czy nie przeprowadzać?! Oto jest pytanie!

Analiza projektu IT - przeprowadzać czy nie przeprowadzać?! Oto jest pytanie!

Etap analizy projektu IT, to często niedoceniana część wdrożenia produktu. Nadal spotykamy się z przeświadczeniem, że odpowiednie zaplanowanie prac programistycznych, nim te rozpoczną się na dobre, jest stratą czasu i pieniędzy. Nic bardziej mylnego. To właśnie dzięki solidnie przeprowadzonej analizie jesteśmy w stanie uchronić budżet, harmonogram i własne nerwy przed zszarganiem. Poszedłbym nawet w tym zdaniu o jeden krok dalej: nie przeprowadzenie analizy projektu IT jest porównywalne z odrąbaniem własnej nogi przez właścicieli produktu. Dlaczego?

Dokumentacja projektu, czyli w poszukiwaniu wspólnego mianownika

Kiedy wpadasz na pomysł realizacji czegoś w Internecie: od sklepu po aplikację webową/mobilną (a może coś ze świata rozszerzonej/wirtualnej rzeczywistości), to masz w głowie pewne wyobrażenie tego produktu. Kwintesencją przeprowadzenia analizy projektu IT jest przekucie ów “wyobrażenia” w coś, co będzie jednoznaczne zarówno dla Ciebie, jako właściciela produktu, a także firmy programistycznej (lub agencji interaktywnej). Finalnie, wszyscy biorący udział w procesie wytwarzania produktu, powinni bazować na wspólnym mianowniku, jakim jest dokumentacja projektu.

Dokumentacja pozwala “czarno na białym” określić kierunek, w którym produkt IT będzie zmierzać na etapie wdrożenia. Zazwyczaj składa się z dwóch kluczowych elementów:

  • historyjek użytkownika (user stories), które w “łopatologiczny” sposób omawiają wszystkie najważniejsze funkcje produktu. Historyjki pozwalają opisać mechanizmy rządzące aplikacją w taki sposób, że każdy (osoba nietechniczna, programista, designer) będzie rozumieć sposób ich działania w ten sam sposób;
  • makiety (mockupy), czyli szkice przedstawiające wygląd i sposób zachowania się poszczególnych ekranów produktu, jeszcze przed zaprogramowaniem ich. Są one doskonałym uzupełnieniem user stories, bo kiedy te pierwsze pozwalają zrozumieć proces, to mockupy są po to, żeby każdy mógł go sobie wyobrazić.

W branży IT nie ma czegoś takiego jak “rzeczy oczywiste”

Za spisaniem, możliwie szczegółowej i oddającej naturę projektu IT, dokumentacji stoi jedna, niepowtarzalna korzyść, zarówno dla właściciela produktu, jak i dla firmy realizującej projekt. Otóż, dokumentacja eliminuje rozbieżności w rozumieniu tego, co będzie przedmiotem prac i pozwala jednoznacznie określić, co tak naprawdę ma być robione. Skutkuje to tym, że gdy rozpoczyna się etap wdrożenia produktu w życie: projektowany jest finalny wygląd aplikacji, a następnie programowane są jej funkcje, wszyscy wiedzą co mają robić i jak mają robić.

Każdy, kto kiedykolwiek miał do czynienia z wdrożeniem czegokolwiek w Internecie wie, jak różnie myślą o tych samych kwestiach poszczególni uczestnicy projektu IT. Dotyczy to nawet prozaicznych kwestii, jak na przykład sposóbu logowania się do aplikacji (z jakichś przyczyn może to być jej kluczowy element), który można zrealizować zgodnie z pewnym wyobrażeniem. Gdy jestem właścicielem produktu i posiadam biznesową potrzebę, żeby ten mechanizm był zrealizowany w kluczowy dla mnie sposób, to etap analizy jest doskonałym momentem na to, żeby moje oczekiwanie wybrzmiało na głos i zostało przez zespół projektowy stosownie opisane, a potem wdrożone.

Jeśli w projekcie nie ma miejsca na analizę, to bardzo szybko zostaniemy zakładnikami założeń. Te szybko obnażą jedno, bardzo niebezpieczne zjawisko: wszyscy zaangażowani w proces wytwarzania produktu rozumieją jego poszczególne funkcjonalności trochę inaczej. A to może prowadzić do tego, że niektóre z nich trzeba będzie przepisywać na nowo, co w praktyce oznacza: stratę czasu, pieniędzy i zszargane nerwy.

I jeśli będziesz mieć nieprzyjemność doświadczenia powyższego zjawiska, szybko przekonasz się, że w IT nie ma rzeczy oczywistych. Dlatego w eEngine, realizując projekt, jedną z głównych zasad, które przyświecają naszej pracy jest ta, która mówi:

W branży IT, nie ma rzeczy oczywistych.

Etap analizy projektu IT ma za zadanie obnażyć te oczywiste oczywistości i sprowadzić je do wspólnego mianownika. Robimy to w trosce o dobro klienta, ale też własne, bo im więcej niepotwierdzonych założeń w naszej pracy, tym większe ryzyko rozminięcia się z potrzebą biznesową klienta. A tego chcemy uniknąć, bo…czas, pieniądze i nerwy.

Zaangażowanie zainteresowanych stron w proces analizy

W procesie analizy powinni uczestniczyć właściciele produktu. To bardzo ważne, żeby byli możliwie blisko pracy firmy programistycznej, oczywiście na ile to jest możliwe. Chodzi o to, żeby pomysłodawcy czuli, że mają wpływ na to, jak ich pomysł będzie opisany przez zespół projektowy.

Niekiedy niezbędne jest włączenie do prac innych podmiotów, np. prawnika lub zewnętrznej firmy konsultingowej. Dużo zależy od charakterystyki produktu, jaki chcemy finalnie stworzyć. Nie mniej, analiza nie może wyglądać tak, że firma ją przeprowadzającą zbierze możliwie dużo informacji i od początku do końca procesu, nie będzie weryfikować ich trafności z założeniami pomysłodawców.

Sprawdzanie założeń na etapie prototypowania

Pytania o oczywiste oczywistości i możliwie silne zaangażowanie właścicieli produktu w proces analizy ma pozwolić sprawdzać sensowność przyjętych założeń. Analiza to doskonały czas na to, żeby jeszcze “na papierze” przetestować kluczowe mechanizmy i potencjalnie zweryfikować ich logikę biznesową.

Nierzadko zdarza się na tym etapie, że coś, co świetnie brzmiało w naszych głowach, w praktyce może okazać się niefunkcjonalne lub nieprzyjazne dla użytkownika. Czasami wystarczy pewną kwestię omówić z firmą przeprowadzającą analizę, niekiedy istnieje potrzeba, żeby to rozpisać za pomocą historyjek użytkownika lub funkcjonalnych makiet. Niezależnie od sposobu, jest to droga o wiele tańsza i szybsza, niż sprawdzanie naszych pomysłów dopiero po wdrożeniu ich przez programistów.

Bycie asertywnym i dyplomatycznym w kontakcie z klientem jest bardzo ważne, bo nigdy nie jest łatwo powiedzieć właścicielowi produktu, że jego pomysł jest nie do zrealizowania lub do całkowitego przeprojektowania. Szczególnie, gdy ten jest święcie przekonany, co do swoich racji. Pamiętajmy, że po to właśnie jest analiza projektu IT i wszystko, co z nią związane.

Sprawdzanie założeń nie dotyczy tylko tego, co zaproponuje klient. Warto mieć też na uwadze pomysły i sugestie firmy, przygotowującej analizę. Tutaj apeluję do klientów, którzy zlecają tego typu prace do wykonania. Bo to na przestrzeni analizy przekonacie się, na ile potencjalny wykonawca czuje Wasz biznes, jak dobrze (lub źle) się rozumiecie i w którą stronę będzie zmierzał Wasz projekt. Po to macie być blisko procesu analizowania Waszego pomysłu i przekuwania “wyobrażeń” w dokumentację, żeby mieć pewność co do jednego: na ile firma, która mnie obsługuje, rozumie moje potrzeby i oczekiwania?

Jeżeli rozmijacie się już na etapie analizowania produktu, to jest bardziej niż prawdopodobne, że w trakcie wdrożenia nie będzie wcale lepiej. W sytuacji ciągłego niezrozumienia się z wykonawcą, warto jest pomyśleć o zakończeniu współpracy już na etapie analizy i poszukanie innej firmy, która weźmie się za wdrożenie produktu w życie. Możliwe, że będzie to zdecydowanie lepsze rozwiązanie, niż brnięcie we współpracę, która już na etapie koncepcyjnym pokazuje, że komunikujecie się na innych częstotliwościach.

Dokąd prowadzi nas analiza projektu?

Namacalnym efektem analizy będzie wypracowana dokumentacja projektu. Ta może powstawać na przestrzeni miesiąca, trzech, a w skrajnych przypadkach nawet jeszcze dłużej. Czas trwania tego etapu zależy od wielu czynników, m.in. od tego na ile skomplikowany i złożony jest pomysł, który musimy opisać lub od szybkości działania klienta czy firmy wykonującej analizę.

Niezależnie od czasu trwania analizy, jej finalnym efektem powinno być możliwie dookreślenie wymagań, oczekiwań i potrzeb klienta względem swojego przyszłego produktu. Ujmując to bardziej przyziemnie, przeprowadzenie tego etapu powinno pozwolić (dowolnej firmie IT), przeprowadzić etap wyceny produktu i określić (możliwie precyzyjnie) zakres prac, kosztorys i harmonogram wdrożenia.

Pomimo tego, że przygotowanie dokumentacji projektu bardzo pomaga określić jego czasochłonność oraz zakres, warto nadal mieć na uwadze jedno: minimalizujemy niepewności i niedomówienia. Nie pozbywamy się ich w 100%. Jest to niestety niemożliwe w branży IT. Szczególnie w sytuacji, w której właściciel produktu chce na etapie wdrożenia być równie blisko swego produktu, co w trakcie analizy. Jest to bardzo dobre podejście z jego strony, bo zaangażowany w proces klient sprawia, że zespół projektowy również mocniej związuje się z tym, co wytwarza.

Z drugiej strony, w trakcie wdrożenia będą pojawiać się nowe pomysły, które firma IT będzie uwzględniać w trakcie produkcji. To będzie skutkować zmianą założeń oraz modyfikacją niektórych pomysłów, które wypracowaliśmy na etapie analizy. Dlatego warto jest podejść do dokumentacji projektu, jak do szkieletu całości, na podstawie którego będziemy wytwarzać produkt. Nie mniej, rozpocząć prace nad swoim produktem bez analizy i wszystkich korzyści, jakie niesie ze sobą, jest dość karkołomnym działaniem. Szczególnie w sytuacji, w której mamy ograniczony czas i budżet.

180 sekund o etapie analizy

Jeśli nadal potrzebujesz argumentów, żeby się przekonać, co do przeprowadzenia etapu analizy w przypadku Twojego produktu IT, sprawdź jeden z naszych vlogów na ten temat:

Zapoznaj się też z wpisem Arka, który opisał proces powstawania dokumentacji projektu dla dość rozbudowanego systemu customer relationship management.

 

Mogą cię zainteresować
Napisz do nas Chcesz dowiedzieć się więcej na temat kosztów wdrożenia Twojego projektu? Odezwij się do nas.
W ciągu 48 h
skontaktujemy się z Tobą!
Więcej o nas
Chcesz dowiedzieć się o nas więcej?
Sprawdź jak pracujemy, poznaj naszą
wyjątkową kulturę pracy.
Skontaktuj się z nami
Więcej o nas
Chcesz dowiedzieć się o nas więcej?
Sprawdź jak pracujemy, poznaj naszą
wyjątkową kulturę pracy.
PL EN
Zapytaj o ofertę