Kiedy już firma zdecyduje, iż potrzebuje oprogramowania dedykowanego, czyli „szytego dla niej na miarę”, powinna odpowiednio przygotować się do realizacji takiego projektu. Kluczowe znaczenie ma zrozumienie specyfiki relacji pomiędzy klientem a dostawcą IT dla takiego projektu. Specyfika ta ujawnia się na wielu etapach, m.in. w kontekście wyboru dostawcy, który wytworzy oprogramowanie (obojętne czy będzie on pracownikiem, zespołem wewnętrznego działu IT, czy też zewnętrzną firmą), określenia warunków współpracy, sposobów współdziałania w realizacji projektu i uczciwego go rozliczenia. Przygotowując się do takich działań, warto przeanalizować wymienione poniżej aspekty.

 

Tworzenie oprogramowania to także sztuka

 

Tworzenie oprogramowania to bardziej sztuka niż inżynieria; powtarzalne są tu metody pracy, ale końcowe dzieło jest zawsze unikalne, a z racji, iż jego odbiorcy specyficzni, to dochodzi się do niego zawsze trochę inną drogą. W konsekwencji jest to proces o wiele bardziej kreatywny niż inżynieryjny. Podobny raczej do projektowania nowego modelu samochodu, niż do wytwarzania kolejnego egzemplarza auta na taśmie produkcyjnej. Często zdarza się tu potrzeba eksperymentowania, zmiany kierunku, a nawet wycofanie z niektórych decyzji. Stąd też, proces ten przypomina drogę przez labirynt, której nie da się zaplanować przed faktycznym wejściem do niego.

 

 

 

Najważniejszy jest cel biznesowy

 

Najczęściej spotykanym kryterium służącym do oceny powodzenia realizacji projektu jest terminowe realizowanie przyjętego harmonogramu w ramach założonego budżetu. Tymczasem należy jasno powiedzieć, że w projektach realizujących złożone rozwiązania technologiczne, na etapie wstępnego planowania, żadna ze stron nie wie, jak ostatecznie będzie wyglądać rozwiązanie końcowe. Jego złożoność jest zbyt duża, by zgłębić całość w szczegółach przed rozpoczęciem współpracy, a dodatkowo, w trakcie prac, sytuacja każdej firmy działającej w warunkach rynkowych, ulega dynamicznym przeobrażeniom. Stąd wiele firm praktykuje takie rozpoznawanie zakresu projektu, by pozwoliło na wstępne szacowanie poziomu jego kosztów, natomiast w czasie realizacji doszczegółowienie wymagań i na bieżąco uwzględnianie ich zmian. Dlatego prawdziwym kryterium sukcesu jest przede wszystkim  osiągnięcie założonego na początku projektu celu biznesowego. To powinno być priorytetem i aspektem, pod który układa się warunki współpracy stron w projekcie.

 

Korzyści biznesowe u zadowolonych użytkowników i docelowo finansowy zwrot z inwestycji w projekt informatyczny są ostatecznie ważniejsze niż realizacja początkowych założeń. Nie można dopuścić do sytuacji, gdy założenia przyjęte apriori ograniczają realizację dobrych pomysłów, pojawiających się na etapie realizacji projektu, po rozpoznaniu nowych zdarzeń czy informacji, a których nie uwzględnił początkowy budżet i harmonogram.

 

Elastyczność pozwala oszczędzać

 

Niestety z badań wynika, że nadal duża część planowanych początkowo przez klienta funkcjonalności, nigdy nie jest używana przez użytkowników końcowych. Stąd nie powiększanie, a obcinanie zakresu prac, do tych dających największą korzyść biznesową jest dobrą praktyką, zwiększającą efektywność wydawanych na system IT pieniędzy.

 

Dlatego więc, należy zbudować warunki współpracy tak, by zmiana zakresu, czasu, a nawet budżetu była naturalna, uczciwa dla obu stron i nie wymagała dużej formalizacji. Akceptacja dla zmiany jest podstawą wszystkich najbardziej popularnych dziś metod realizacji projektów informatycznych – tzw. metodyk zwinnych. Takiej formy współpracy klienci powinni oczekiwać dziś od profesjonalnych dostawców IT.

 

Projekt dedykowany mocno angażuje zlecającego

 

Z reguły, oprogramowanie dedykowane tworzy się, jako element bezpośrednio wspierający budowanie przewagi biznesowej firmy. Nie można więc mierzyć jego wartości wprost kosztami wytworzenia, a do samego procesu należy podejść bardzo poważnie, gdyż może on decydować o przyszłości przedsiębiorstwa. Nieudane wdrożenie kosztuje firmę nie tylko wydane pieniądze, ale przede wszystkim stracony czas, często liczony w miesiącach lub latach. Tego, coraz bardziej konkurencyjny rynek, może nie wybaczyć. Oznacza to, oczywiście, że ze szczególną starannością należy podejść do wyboru wykonawcy, ale także to, że po stronie zlecającego musi pojawić się realne zaangażowanie na każdym etapie projektu. Tworzenie oprogramowania dedykowanego jest pracą wspólną, nie jest tym typem zlecenia, które można oddać na wyłączną odpowiedzialność dostawcy.

 

Dostawca musi pytać, a klient musi odpowiadać

 

Nawet jeśli dostawca zna naszą organizację lub realizował podobne projekty, to cel biznesowy, specyfika działania naszej firmy, jej aktualna i docelowa sytuacja, muszą być wykonawcy ciągle komunikowane. Co istotne, nie oznacza to jedynie transferu wiedzy na etapie negocjowania początkowego zakresu projektu i ustalania warunków kontraktu. Oznacza to, że przedstawiciele naszej firmy będą na bieżąco angażowani w udostępnianie informacji dla dostawcy.  Należy to uwzględnić i zaplanować. Po to, by rezultat projektowanych prac mógł lepiej odpowiadać naszym szczegółowym potrzebom. 

 

Projektem zarządza klient i musi robić to często

 

Dziś standardem wynikającym z podejścia zwinnego jest możliwość oczekiwania od dostawcy transparentności postępów jego prac. Ma to szczególne znaczenie ze względu na dużo większą niż lata temu zmienność projektów IT. Najlepszym podejściem jest umówienie się z dostawcą na iteracyjną realizację projektu. Polega to prowadzeniu prac w np. 1 lub 2-tygodniowych cyklach. W trakcie poszczególnych iteracji (zamkniętych cyklów organizowania i wytwarzania) planuje się prace, realizuje i ocenia. To zapewnia firmie, jako sponsorowi projektu, regularną możliwość, by na końcu każdej takiej iteracji, zebrać ocenę zadowolenia interesariuszy systemu z wyprodukowanych dotychczas jego elementów. Ocena projektu, możliwość szybkiego implementowania jego efektów powstałych w ramach iteracji, pozwala elastycznie dostosować zakres w kolejnych iteracjach. Dodatkowo można wtedy ocenić efektywność dostawcy oraz ostatecznie wspólnie zdecydować o tym, jak ma przebiegać projekt, aby optymalizować jego efekty biznesowe. Nawet w skrajnym przypadku, gdy zostanie podjęta decyzja o zmianie dostawcy, przy takim podejściu, zleceniodawca ryzykuje, przede wszystkim, jedynie kosztem realizacji jednej kolejnej iteracji. Uwzględnić należy jednak, iż decyzja o ewentualnej zmianie dostawcy nie będzie mogła być realizowana bezboleśnie i bez dodatkowych kosztów. To także motywuje klienta do budowania partnerskiej relacji z dostawcą. Jest to jednak, przede wszystkim, motywujące dla dostawcy; musi on stale dostarczać wysoką jakość i realizować cel biznesowy klienta, tak by to z nim klient chciał realizować kolejne etapy prac.

 

Ciąg dalszy wskazówek w kolejnej części artykułu.

 

Marcin Kaczmarek

CEO Consileon Polska