Jak zlecić i przeprowadzić projekt IT?

• 1. Wstęp
• 2. Do kogo skierowany jest ten artykuł?
• 3. Przygotowanie do projektu
• 3.1. Wybór osoby odbierającej oprogramowanie
• 3.2. Przeprowadzenie audytu oraz wywiadów
• 3.3. Opracowanie specyfikacji
• 4. Wybór Wykonawcy
• 4.1. Zebranie ofert
• 4.2. Negocjacje
• 5. Podpisanie umowy z Wykonawcą
• 6. Realizacja
• 6.1. Największe ryzyka dla Zamawiającego
• 6.2. Największe ryzyka dla Wykonawcy
• 7. Monitorowanie realizacji
• 8. Odbiór etapów
• 9. Odbiór końcowy
• 10. Podsumowanie

1. Wstęp

Artykuł opisuje moje doświadczania w zakresie zlecania i przeprowadzania projektów IT. Kieruję go głównie do Zlecających jak i Wykonawców.

W treści koncentruje się głównie na projektach, w których występuje wycena obejmująca pełen zakres prac Wykonawcy (tzw. model fixed price). W tym wpisie pomijam temat projektów przetargowych. Projekty przetargowe opiszę przy okazji kolejnych wpisów.

Zachęcam Cię do podania swojego adresu e-mail. Dzięki temu otrzymasz wiadomość kiedy pojawi się nowy wpis na blogu.

W modelu rozliczeniowym time & material (T&M) główny ciężar kładzie się na pomiar efektywności wynajmowanego zespołu. Ten typ współpracy również opiszę w kolejnych wpisach.

Podczas mojej pracy często spotykam się z sytuacją, kiedy projekt IT jest już na zaawansowanym etapie realizacji. Klienci prowadzący projekt posiadają problemy odnoszące się do faz przygotowania, monitorowania i odbioru projektu IT. Napisałem ten artykuł jako poradnik dla klientów zlecających oprogramowanie i wykonawców, ponieważ wielu problemów można uniknąć na wczesnym etapie projektu.

2. Do kogo skierowany jest ten artykuł?

• Zamawiających – Jeśli zastanawiasz się lub jesteś w trakcie projektu IT w swojej firmie to ten artykuł pozwoli Ci na sprawne przeprowadzenie tego procesu.
• Wykonawców – Jeśli tworzysz lub wdrażasz oprogramowanie możesz poznać inne doświadczenia w tej dziedzinie.

3. Przygotowanie do projektu

Projekt IT powinniśmy rozpocząć od przygotowania. Każdy projekt jest inny i tym samym każde przygotowanie powinno być dopasowane do specyfiki danego projektu.

Bardzo częstym błędem jaki jest popełniamy w projektach to „zbyt zwinne” podejście do jego realizacji, które powoduje, że od samego początku wizja projektu nie jest klarowna.

Poniżej prezentuje Ci klika punktów, które są podobne dla wielu projektów IT na etapie planowania.

3.1. Wybór osoby odbierającej oprogramowanie

Jeśli nie posiadasz wiedzy na temat wytwarzania oprogramowania, odbioru lub monitorowania projektem IT bardzo dobrym rozwiązaniem jest podjęcie współpracy z osobą zewnętrzną, która posiada taką wiedzę. Taką osobą jest doświadczony Analityk lub Product Owner.

Niezależenie od stanowiska i doświadczenia osoby zewnętrznej w dalszej części nazwijmy ją Analitykiem.

Pamiętaj, że bardzo zgubne na tym etapie jest przekonanie, że Ty lub ktoś z organizacji będzie w stanie taki projekt przeprowadzić i odebrać. Spotykałem się z wieloma sytuacjami, kiedy projekt był monitorowany i odbierany przez pracowników Zamawiającego i najzwyczajniej w świecie brakowało osoby, która po stronie Zamawiającego posiada wiedzę na temat procesu budowy oprogramowania.

Moim zdaniem najlepszą analogią jaką powinniśmy zastosować podczas realizacji projektu IT jest typowy projekt budowlany. W projekcie budowlanym bardzo często decydujemy się na inżyniera kontraktu / rezydenta budowy, który monitoruje cały projekt. Im projekt jest bardziej skomplikowany tym udział takiej osoby jest tym bardziej potrzebny. Podobnie powinniśmy postępować w przypadku projektu IT.

Dlaczego Zamawiający nie decydują się na analityka, który planuje i odbiera rezultaty projektu IT?

1. Chcą obniżyć koszty realizacji projektu. Analityk zatrudniany na początkowym etapie projektu może zwiększyć koszt etapu planowania, jednak doświadczenie pokazuje, że w dłuższej perspektywie praca takiej osoby oszczędza koszty na dalszych etapach.
2. Uznają, że wewnętrzna osoba poradzi sobie z monitorowaniem i odbiorem. Osoba z wewnątrz prawdopodobnie zna lepiej problem jaki jest do rozwiązania za pomocą oprogramowania, jednak zdecydowanie gorzej poradzi sobie w komunikacji z zespołem wykonawczym. Doświadczony analityk może zupełnie inaczej spojrzeć na problem i możne zaproponować różne drogi rozwiązania.
3. Osoba w wewnątrz jest godna zaufania. Jest to ważny argument. W mojej ocenie nie musimy w pełni rezygnować z naszej osoby wewnętrznej podczas realizacji projektu. Najlepszym rozwiązaniem jest zaangażowanie dwóch osób. Osoba wewnętrzna może być ekspertem odpowiedzialnym głównie za sferę biznesową a analityk za analizę, dokumentację i komunikację w projekcie IT.

Dlaczego warto wybrać analityka do zarządzania projektem IT?

1. Wiedza i doświadczenie. Analityk powinien posiadać doświadczenie zebrane podczas uczestnictwa w różnych projektach IT. Takie doświadczenie przekłada się na możliwość uniknięcia szeregu problemów jakie mogą wystąpić w trakcie realizacji twojego projektu.
2. Komunikacja. Analityk potrafi skutecznie komunikować się z programistami. Opracowana dokumentacja oprogramowania będzie bardziej szczegółowa i zrozumiała dla programistów.
3. Odmienne interesy względem Wykonawcy. Analityk zatrudniony przez Zamawiającego posiada odmienne interesy od Wykonawcy. Jego głównym zadaniem jest obrona interesów Zamawiającego. Jeśli w projekcie IT analityk będzie zatrudniony ze strony Wykonawcy istnieje ryzyko, że będzie on w głównej mierze chronił interesy Wykonawcy.

3.2. Przeprowadzenie audytu oraz wywiadów

Podstawowym etapem, od którego powinniśmy rozpocząć pracę na projektem IT to przeprowadzenie wywiadów z użytkownikami końcowymi oprogramowania. Możemy to zrobić z pomocą analityka lub we własnym zakresie. Musimy jednak przeprowadzić ten krok.

Bardzo łatwo dojść  do wniosku, że na tym etapie posiada się już wiedzę, która jest konieczna do przeprowadzenia projektu (przecież jesteśmy ekspertami w tej dziedzinie), jednak byłem świadkiem wielu projektów, w których dopiero na dalszych fazach okazywało się, że procesy przebiegają zupełnie inaczej lub też w wizji projektu brakowało istotnych elementów.

Istotne na samym początku jest nakreślenie gdzie aktualnie się znajdujesz poprzez określenie kluczowych punktów, ustalenie wskaźników początkowych i docelowych. Można to zrobić bardzo szybko za pomocą poniższego przykładu.

Taka forma pozwala na ułożenie priorytetów projektu. Opracowana w dalszym kroku specyfikacja powinna odnosić się do ustalonych punktów.

3.3. Opracowanie specyfikacji

Na podstawie przeprowadzonych wywiadów z pracownikami należy opracować specyfikację wymagań, która w minimalnym zakresie powinna zawierać opis wymagań, procesy biznesowe oraz widoki oprogramowania.

Opracowana specyfikacja może zostać rozbudowana m.in. o diagramy UML. Poniżej prezentuję podstawowe punkty specyfikacji:

1. Opis ogólny. Wizja produktu, charakterystyka użytkowników, środowisko operacyjne, ograniczenia projektu, założenia i zależności.
2. Opis wymagań. Wymagania funkcjonalne.
3. Wymagania dotyczące danych. Logiczny model danych, słownik danych, raporty, integralność danych, przechowywanie i usuwanie danych.
4. Atrybuty jakościowe. Użyteczność, wydajność, bezpieczeństwo, zagrożenia.
5. Pozostałe wymagania.
6. Procesy biznesowe. Diagramy i opisy procesów biznesowych.
7. Widoki. Jak mówi stare powiedzenie „Jeden obraz jest wart więcej niż tysiąc słów”. Prezentacja widoków w formie UX pozwala programistom i osobom, które uczestniczą w projekcie w lepszy sposób wyobrazić sobie docelowe oprogramowanie.

4. Wybór Wykonawcy

Faza wyboru Wykonawcy składa się z następujących kroków:

4.1. Zebranie ofert

Na podstawie wysłanego zapytania wraz ze specyfikacją, Wykonawcy powinni udzielić odpowiedzi (z nastawieniem na powinni 🙂 ). Warto po wysłaniu zapytania upewnić się telefonicznie, że wiadomość dotarła i że oczekujemy odpowiedzi. Dzięki temu nasza oferta zostanie poważnie odebrana.

Zebrane wyceny mogą być bardzo różne. Główne powody różnic w wycenach to:

1. Poziom specjalistów oraz ich doświadczenie. Wśród Wykonawców poziom ich specjalistów może być bardzo różnorodny. Rozwiązaniem w takiej sytuacji jest poproszenie Wykonawcy o informację na temat kosztów zespołu i przesłanie tzw. blindów członków zespołu (CV członków zespołu bez danych osobowych).
2. Politykę danego Wykonawcy. Wykonawcy posiadają różną politykę cenową i koszty prowadzenia działalności. Koszty danego Wykonawcy są uzależnione od jego struktury organizacyjnej. Rozwiązaniem jest poproszenie Wykonawcy o podanie cen częściowych wraz z kosztami stałymi. Nie zawsze taka prośba będzie skuteczna, jednak warto spróbować.
3. Poziom ryzyka jaki musi ponieść Wykonawca. Mało doświadczony Wykonawca może nie zdawać sobie sprawy z ryzyka jakie nakłada na niego realizowany projekt, dlatego cena może być mniejsza. Rozwiązaniem dla takiej sytuacji jest zadanie pytania do Wykonawcy, jaki procent ceny jest przeznaczony na ryzyko związane z projektem. Wiadome jest to, że doświadczeni Wykonawcy je liczą.
4. Rozpoznawalność Wykonawcy. Większa rozpoznawalność Wykonawcy może również wpłynąć na wycenę. Jest to spowodowane głównie poziomem jego doświadczenia jak i również liczbą zapytań i projektów prowadzonych przez Wykonawcę.

Podczas procesu oceny Wykonawcy najważniejsze jest zadanie sobie kilku podstawowych pytań:

1. Czy Wykonawca realizował podobny projekt? Brak doświadczenia Wykonawcy realizującego Twój projekt powoduje wydłużenie prac i ryzyko pojawienia się częstszych błędów. Korzystnym jest wybór Wykonawcy, który już wcześniej realizował podobny projekt i tym samym zetknął się już z podobnymi problemami.
2. Czy Wykonawca pracował w takiej metodyce? Chodzi o metodykę prowadzenia projektu (np. scrum, kanban, kaskada). Wykonawca, który pracował w metodykach zwinnych może nie posiadać dobrych praktyk do pracy w modelu kaskadowym i na odwrót.
3. Czy Wykonawca posiada doświadczenie? Niezależnie od metodyki mało doświadczeni Wykonawcy mogą również nie posiadać kompetencji w skutecznym egzekwowaniu wiedzy jaką powinni otrzymywać od Zamawiającego. Jest to problem zarówno dla Wykonawcy jak i również Zamawiającego.
4. Czy Wykonawca realizował projekt o podobnej skali? Wykonawcy, który dotychczas realizowali małe projekty IT mogą nie poradzić sobie z większymi realizacjami, które trzeba dokładniej zaplanować w pierwszych fazach i przewidzieć istotne ryzyka.

4.2. Negocjacje

Cenowa wygrana w negocjacjach nie zawsze oznacza ostatecznej wygranej jakim jest rezultat projektu. Jeśli wynegocjujesz zbyt niską cenę za realizację może pojawić się ryzyko, że Wykonawca będzie chciał obniżyć koszty realizacji, tak aby zarobić na projekcie. Nie jest to najlepsza droga.

Lepszym rozwiązaniem dla Zamawiającego jest negocjacja o zakresie gwarancji, transparentności realizacji oraz prawach autorskich.

5. Podpisanie umowy z Wykonawcą

Częścią etapu negocjacji jest również podpisanie samej umowy z Wykonawcą. Istotne jest to, aby umowa składała się podstawowych punktów takich jak:

1. Przedmiot umowy wraz ze specyfikacją. Załączniki do umowy powinny zawierać specyfikację oprogramowania obejmującą opis wymagań, procesy i widoki.
2. Prawa autorskie. Zapisy o przekazaniu praw autorskich do oprogramowania wraz z podanymi polami eksploatacji.
3. Harmonogram zawierający terminy realizacji poszczególnych etapów i ich odbiory.
4. Wynagrodzenie. Może być całościowe lub częściowe. Warto podzielić projekt na etapy i wynagrodzenie za projekt również rozliczać etapowo.
5. Kary umowne. Kary umowne powinny być powiązane z terminami ustalonymi w harmonogramie.
6. Komunikacja. Formę komunikacji opisującą proces odbioru, poprawy ewentualnych błędów.
7. SLA (service level agreement). Jest to część umowy prezentująca poziom świadczenia usług najczęściej na etapie utrzymania. W tej części powinny zostać określone m.in. poziom incydentów oraz szybkość reakcji w sytuacji zaistnienia określonego incydentu.
8. Warunki gwarancji
9. Zapisy odnośnie RODO.

Umowa powinna zabezpieczać nasze interesy, jednak powinniśmy pamiętać o równości stron. Pamięć o tej zasadzie powoduje, że negocjacje odnośnie umowy przebiegają zdecydowanie szybciej.

6. Realizacja

Po podpisaniu umowy można rozpocząć realizację projektu IT. Poniżej prezentuje największe ryzyka jakie mogą wystąpić w trakcie realizacji.

6.1. Największe ryzyka dla Zamawiającego

1. Zamawiający twierdzi, że dane zadanie wykracza poza uzgodnienia. Z własnego doświadczania muszę napisać, że jest to jeden z najczęstszych ryzyk, jakie pojawiają się podczas realizacji projektu IT. Zabezpieczeniem takiej sytuacji jest dobra dokumentacja.
2. Brak wyników dostarczanych przez Wykonawcę. Wykonawca pracuje nad zleceniem, jednak nie dostarcza wyników, jakie są oczekiwane. Mogą to być przejściowe problemy Wykonawcy lub objaw większych problemów z realizacją. Rozwiązaniem dla tego problemu jest ciągły monitoring zarówno od strony rezultatów jak i również od strony kodu. Warto od samego początku omawiać takie sytuacje i negocjować warunki realizacji. Umowa i jej zmiany powinny w możliwie dużym stopniu oddawać rzeczywistość.
3. Relacje i prowadzenie projektu niepozwalające na jego konsekwentne rozliczenie. Problemy w zakresie realizacji projektu pojawiają się zarówno po stronie Wykonawcy jak i również po stronie Zamawiającego. W przypadku przekroczenia terminów Wykonawca może powiedzieć, że nie otrzymał wszystkich potrzebnych informacji od Zamawiającego i spowodowało to przesunięcie. W projekcie bardzo ważne są relacje, jednak równie ważna jest klarowna komunikacja, która pozwala uniknąć wielu nieporozumień.
4. Elementy, które zostały odebrane ulegają uszkodzeniu. Zamawiający odbiera poszczególne elementy oprogramowania, które działają poprawnie. Wykonawca podczas dalszych prac powoduje uszkodzenie tych elementów. Rozwiązaniem w takiej sytuacji jest zaprezentowanie błędów dla Wykonawcy i ustalenie terminu zakończenia ich poprawy. Przekroczenie terminów będzie wiązało się z karami umownymi dla Wykonawcy.
5. Wadliwe działanie oprogramowania. Prace nad oprogramowaniem zostały ukończone, jednak nadal występują błędy w działaniu. Taki przypadek wyraźnie pokazuje, że problemy w projekcie występowały już na wcześniejszym etapie gdzie zabrakło odpowiedniego monitorowania. Rozwiązaniem w takiej sytuacji jest: przeprowadzenie audytu i wykazanie błędów, oczekiwanie na poprawę błędów lub wybór nowego Wykonawcy.
6. Przerwanie prac. Taka sytuacja również może pojawić się podczas realizacji projektu IT. Rozwiązaniem okazuje się zabezpieczenie repozytorium kodu oraz monitorowanie prac nad kodem oprogramowania. Jeśli projekt był monitorowany i zabezpieczony to pracę nad nim można kontynuować wybierając innego Wykonawcę.

6.2. Największe ryzyka dla Wykonawcy

1. Brak zaangażowania ze strony Zamawiającego. Jest to częsty problem po stronie Wykonawcy. Z uwagi na to ryzyko Wykonawcy bardzo często decydują się na model rozliczania za czas i materiały, czyli T&M (time & material). Rozwiązaniem tego problemu jest formalizowanie komunikacji z Zamawiającym, czyli opracowywanie podsumowań i przekazywanie ich możliwie jak najwyżej w hierarchii. Podsumowania można eskalować stopniowo. Jeśli osoby ze strony Zamawiającego nie reagują można przesyłać je poziom wyżej.
2. Brak szczegółowej specyfikacji. Spotkałem się z projektami, w których specyfikacja rozbudowanego oprogramowania była opracowana na dwóch stronach A4. Trzeba sobie jasno powiedzieć, że nie jest to specyfikacja lecz raczej wizja oprogramowania jakie ma zostać stworzone. Zdesperowani Wykonawcy, którzy nie chcą urazić Zamawiającego mogą decydować się na tego typu realizację, wyceniając jej pracę. Ponieważ interpretacja zapisów takiej wizji jest bardzo szeroka w trakcie realizacji najczęściej pojawia się wiele nieoczekiwanych elementów oprogramowania.
3. Koncentracja Zamawiającego na szczegółach. Jest to problem jaki pojawia się podczas odbiorów wykonanej pracy. Zamawiający podczas takich prezentacji bardzo skupia się na szczegółach a nie na głównych procesach biznesowych. Rozwiązaniem tego problemu jest odpowiednie poprowadzenie rozmów i podsumowań z Wykonawcą tak, aby skoncentrować się na głównych problemach.
4. Nadmiarowe wymagania. Podczas odbiorów oprogramowania ze strony Wykonawcy mogą pojawić się potrzeby, które mieszą się zapisie specyfikacji jednak są nadmiarowe, czyli bardzo mało stosowane przez użytkowników. Rozwiązaniem w takiej sytuacji jest zanotowanie takich wymagań i dołączenie do listy. Jeśli nie są to pilne wymagania wg priorytetu zostaną umieszczone na dole listy. W miarę postępu prac oraz odbiorów może okazać się, że Zamawiający nie będzie już miał potrzeby wprowadzania danej funkcjonalności.

7. Monitorowanie realizacji

Niezależnie od metodologii prowadzenia projektu pracę należy okresowo monitorować. Dobrym rozwiązaniem jest przyjęcie dwutygodniowego lub miesięcznego okresu, w którym wykonujemy podsumowanie.

Z mojego doświadczenia wynika, że bardzo istotne jest to, aby podsumowanie odnośnie realizacji projektu dotarło do kadry zarządzającej. Jest to w interesie Project Managera jak i również samego projektu. W przypadku problemów z wyższego poziomu można zastosować skuteczniejsze środki naprawcze dla projektu. Dobrym rozwiązaniem jest również przekazanie takiego podsumowania do Wykonawcy.

Elementy jakie powinny być monitorowane:

1. Harmonogram i zrealizowane procesy biznesowe. Istotne jest to, jakie cele biznesowe zostały zrealizowane przez Wykonawcę. Dobrym rozwiązaniem jest monitoring już zrealizowanych procesów biznesowych lub przypadków użycia, które zostały przedstawione w specyfikacji.
2. Realizacja zadań. Bardzo dobrym podejściem podczas realizacji jest udostępnienie systemu zadań dla Zamawiającego tak, aby na bieżąco mógł śledzić postęp prac nad oprogramowaniem. Ważne, aby nie był to system powiadamiania o zmianach „wystawiony specjalnie dla klienta” a rzeczywisty system, na którym bazują programiści. Prawidłowym podejściem jest powiązanie zadań z repozytorium kodu tak, aby zmiany w obszarze zadań były powiązane ze zmianami w kodzie. Przykładowym systemem jaki daje takie możliwości jest JIRA wraz z Bitbucket.
3. Repozytorium kodu. W tym punkcie zastosuję podobne porównanie jak wcześniej, czyli do prac budowlanych. Podobnie jak wyniki na placu budowy, tak samo w przypadku repozytorium kodu można oceniać pracę Wykonawcy. W mojej ocenie doświadczona osoba po stronie zamawiającego powinna co określony przedział czasu przeglądać repozytorium i informować Zamawiającego o jego stanie.
   
   Bardzo często spotykam się z sytuacją, że Zamawiający interesuje się tylko finalnym wynikiem nie mając wglądu w repozytorium kodu. Zamawiający opiera się głównie na zaufaniu do Wykonawcy. Uważam, że taką sytuację można porównać do budowy, w której nie interesuje nas jak została wykonana konstrukcja.

Trzeba pamiętać o tym, że Wykonawca, który rzetelnie wykonuje swoją pracę nie obawia się transparentności w zakresie monitorowania realizacji projektu.

8. Odbiór etapów

Odbiory częściowe są istotnym elementem projektu. Podczas odbiorów częściowych powinniśmy wykonać podsumowanie wraz z Wykonawcą i wyciągnąć wnioski, które usprawnią projekt w dalszych etapach.

Podczas odbiorów częściowych warto przeprowadzić:

1. Szczegółowy test oddanych modułów oprogramowania. Zamawiający powinien znaleźć czas, aby przeprowadzić szczegółowe testy działania modułów jakie są odbierane. Na etapie odbioru częściowego nie powinno być sytuacji, że moduł, który jest przedmiotem odbioru nie działa.
2. Podsumowanie pod względem realizacji specyfikacji. Dobrym rozwiązaniem jest stworzenie zestawienia, które zawiera kolumny:
   | Opis ze specyfikacji | Ocena realizacji |

9. Odbiór końcowy

Z mojego doświadczanie wynika, że najbardziej tego etapu obawia się Zamawiający, ponieważ nie jest on pewien, czy oprogramowanie spełnia jego oczekiwania.

W przypadku występowania błędów w oprogramowaniu podczas odbioru końcowego można zastosować następujące warianty:

1. Przełożyć odbiór oprogramowania na kolejny termin, w którym zostaną poprawione wykazane błędy przez Zamawiającego.
2. Podpisać z Wykonawcą aneks do umowy, który będzie zawierał opisane błędy wraz z terminem ich poprawy.
3. Określić błędy w protokole odbioru i ustalić ich poprawę w ramach świadczonej gwarancji. Istotne jest określenie czasu w jakim błędy zostaną poprawione.

10. Podsumowanie

Podczas planowania, zlecania, monitorowania i odbioru projektu IT można uniknąć szeregu problemów. Ogólna zasada w prowadzeniu projektów jest taka, że im wcześniej zareagujesz tym koszty danego problemu będą mniejsze.

W tym wpisie chciałem przestawić Ci cały proces począwszy od planowania i skończywszy na odbiorze. Temat jest szeroki i odnośnie każdego z punktów można by napisać osobny wpis. W kolejnych wpisach będę dokładniej opisywał poszczególne punkty jak i również inne modele prowadzenia projektu IT.

Zachęcam Cię do skomentowania oraz podania swojego adresu e-mail.