Dostawcy

Wybór zleceniobiorcy przy pracach związanych z tworzeniem oprogramowania jest najważniejszym, najtrudniejszym, a jednocześnie jednym z pierwszych kroków w realizacji przedsięwzięcia internetowego. Warto zastosować się, lub chociażby przemyśleć samodzielnie, kilka istotnych kwestii związanych z tym kto będzie wykonywał (lub dostarczał) nam oprogramowanie, niezależnie od tego czy zdecydowaliśmy się na zatrudnienie własnego zespołu czy też na zlecenie realizacji na zewnątrz. Najprostszym i najczęstszym rozwiązaniem jakie preferowane jest na Polskim rynku to wybór indywidualnego programisty (freelancer). Bardzo często zdarza się że tak wybrani zleceniobiorcy nie mają żadnych referencji, żadnego doświadczenia w sektorze gospodarki w którym operuje zamawiający, lub wręcz bardzo często znikome doświadczenia w tworzeniu oprogramowania na zamówienie lub tworzeniu oprogramowania w ogóle. Zbyt często realizację projektu powierza się osobie, która reprezentuje pewien talent techniczny i dobre ceny. Nasza rada jest taka aby mniej skupiać się na oferowanych aspektach technicznych, a bardziej na zdobytych doświadczeniach w zakresie realizacji podobnych przedsięwzięć lub przedsięwzięć w ogóle. Wynika to z tego że wiedza techniczna jest pewnym dobrym powszechnym, często również zresztą bardzo ciężkim do zmierzenia. Umiejętność dostarczenia kompletnego rozwiązania z drugiej strony to zupełnie inny zestaw umiejętności, które z kolei łatwo ocenić po tym jak zostały zastosowane i wykorzystane, oraz na jakie wyniki przełożyły się w przypadku poprzednio realizowanych projektów.

Kolejnym istotny czynnikiem który powinien wpływać na wybór zleceniodawcy jest pewność że zamówione oprogramowanie powstaje przy użyciu odpowiedniej technologii i legalnego oprogramowania. Jest to o tyle istotne z punktu widzenia zleceniobiorcy że wytworzone oprogramowanie funkcjonować będzie w ramach działalności zamawiającego. Wszelkie ewentualne problemy dotyczące oprogramowania i legalności narzędzi które służyły do jego wytworzenia mają wpływ w efekcie na legalność oprogramowania funkcjonującego u zamawiającego, a w najlepszym razie mają wpływ na możliwość użytkowania takiego oprogramowania w przypadku gdyby narzędzia zleceniobiorcy okazały się nielegalne. Jakkolwiek ten warunek wydaje się mniej istotny w przypadku działalności w Polsce (przynajmniej historycznie rzecz biorąc), tak warto zastanowić się jak różne aspekty prawne będą wpływały na działalność firmy jeżeli ta osiągnie sukces. Może się bowiem okazać że pewne niewygodne i – szczerze zawstydzające – fakty związane z tym jak powstawał biznes w pierwszych latach działalności mogą nabrać większego znaczenia w momencie kiedy będzie generował on wielomilionowe zyski. Praktyka wielu sukcesów pokazuje, że może się bowiem okazać że wszystkie czynniki prawne (umowy z dostawcami, umowy z partnerami, umowy z producentami) zostaną dokładnie przestudiowane w poszukiwaniu dodatkowych możliwości zysku dla producentów lub dostawców których prawa mogłyby być naruszone nawet wiele lat wcześniej.

Jak wybrać dostawcę
oprogramowania na zamówienie?

Najważniejsze kryterium dobory wykonawcy oprogramowania na zamówienie to nie koszt i czas, ale ryzyko. Nie wybiera się najtańszego dostawcy, który dostarczy oprogramowanie w najkrótszym czasie. Wybrany dostawca powinien być tym, który zapewnia największe szanse na to że zamówione oprogramowanie naprawdę zostanie dostarczone. Jeżeli realizacja podsystemu, komponentu lub jakiejkolwiek innej części jest krytycznie ważna dla powodzenia projektu, to wybór powinien paść na najpewniejszego dostawcę, który oferuje rozwiązanie po najniższym koszcie, w najkrótszym czasie.

Niewiele firm inwestujących w oprogramowanie budowane pod specyficzne zamówienie docenia złożoność projektów informatycznych. Dziesięć lat temu wiedza na temat dobrych praktyk w zakresie realizacji projektów informatycznych praktycznie nie istniała w świadomości kadry zarządzającej typowej firmy średniej wielkości, o mniejszych firmach nawet nie wspominając. Niestety nawet dzisiaj spora część menedżerów wydaje się szczerze zaskoczona dowiadując się że statystycznie mniej niż połowa projektów informatycznych na rynku realizowana jest z powodzeniem, tzn. na czas i w określonym budżecie. Dlaczego świadomość tej zatrważającej statystyki jest istotna i jak zrobić aby nasz właśnie projekt znalazł się w tej “właściwej” połowie statystyki?

Powiedzmy sobie szczerze: nie jest tajemnicą w branży, że ogromna część projektów które nie powodzą się nigdy nie dociera do fazy wdrożenia w ogóle. Brak wiedzy na temat ryzyka związanego z realizacją projektów informatycznych wielokrotnie prowadzi kadrę zarządzającą do niewłaściwych wyborów w zakresie wykonawcy oprogramowania na zamówienie. Ponieważ zakłada się że realizacja projektu informatycznego zasadniczo nie odbiega w swojej specyfice od każdego innego zlecenia składanego przez firmę, zleceniodawcy kierują się głównie czynnikami ceny i czasu podczas wyboru firmy, która dostarczy zamówione oprogramowanie na konkretne zamówienie. Zakłada się że ryzyko związane z produkcją i wdrożeniem systemu informatycznego leży gdzieś w typowych przedziałach uśrednionego ryzyka, jakie wiąże się z innymi typowymi projektami inżynieryjnymi (budowa domu czy mostu) realizowanego przez daną firmę.

Zlecenia na realizację systemów informatycznych niosą ze sobą większe ryzyko niż typowe zlecenia dostawy maszyn lub usług konserwacji sprzętu. Przykładowo, zlecenie dostawy zwykłego materiału lub prostej usługi może być złożone najtańszemu i najszybszemu oferentowi, ponieważ ryzyko iż dostawca przeszacuje swoje zasoby magazynowe lub nakłady czasowe jest niska. Jeżeli nawet podwykonawca prostych usług przeszacuje swoje możliwości podczas zlecenia usługi, ewentualne zmiany w kosztorysie, niedociągnięcia lub braki materiałowe mogą zostać wykryte podczas pierwszych etapów dostawy lub podczas pierwszej fazy realizacji usługi. Ponieważ zwykle temat dostawy materiałów lub usług jest znany zarówno zleceniodawcy jak i zleceniobiorcy, ewentualne korekty w realizacji zlecenia mogą zostać szybko i właściwie ustalone przez obie strony.

Ponieważ ogromna większość dostawców na rynku usług tworzenia oprogramowania na zamówienie, zwłaszcza młodych firm informatycznych, ma tendencję do ogromnego niedoszacowywania nakładów związanych z realizacją projektów informatycznych, zlecenie dostawy systemu informatycznego niedoświadczonemu podwykonawcy niesie ze sobą ogromne ryzyko. Jeszcze większym zagrożeniem dla realizacji projektów jest nie tyle niedoszacowanie, co nieumiejętność specyfikowania wymagań po obu stronach: Zamawiającego i Wykonawcy. Co ciekawe dotyczy to zarówno projektów realizowanych przez “własnych” programistów, jak również tych zlecanych zewnętrznym. Osobiście zawsze sceptycznie podchodzę do diagnozowania problemów jako wynikających z niedoszacowania, a znacznie częściej potrafię znaleźć ewidentne luki w technicznych umiejętnościach przygotowywania specyfikacji. Już na samym początku, ocena kwalifikacji i możliwości technicznych podwykonawcy może być bardzo trudnym zadaniem dla kadry nie posiadającej technicznego zaplecza i wiedzy. Ocena postępu realizacji systemów informatycznych jest ogromnie skomplikowana we wczesnych fazach postępu projektu, bardzo często wręcz niemożliwa do wykonania ani przez zamawiającego, ani nawet przez zleceniobiorcę!

Ponieważ oprogramowanie komputerowe, z definicji, ma tak bardzo nienamacalną postać, postęp realiacji projektów informatycznych we wczesnych fazach bardzo oceniana jest niestety wyłącznie na podstawie raportów dostarczanych zamawiającemu przez samego dostawcę. Dostawcy oczywiście mają tendencję do zbyt optymistycznej oceny postępu realizacji powierzonego im projektu, co jest częścią problemu, przy czym znacznie większy problem zwykle tkwi w poczynianiu założeń po obu stronach. Zamawiający zakłada że dostawca rozumie jego model biznesowy oraz pewne wyobrażenia które przyjmowane są jako oczywiste. Z drugiej strony wykonawca zakłada pewne uproszczenia licząc na to że komplikacje są wyjątkiem, który odbiega od tego co zamawiający życzyłby sobie aby jego firma realizowała. Założenia poczynione zarówno z jednej, jak i z drugiej strony w najlepszym przypadku powodują ogromną frustrację po obu stronach, a w najgorszym mogą prowadzić do opóźnień w realizacji projektu, wynikających z tego konsekwencji, z zerwaniem kontraktu włącznie. Nadmiernie optymistyczne szacowanie postępów wiąże się najczęściej albo z niedoszacowania wymagań postawionych przed projektem, albo z powodu postanowień umowy, w której założono wypłacanie zleceniobiorcy wynagrodzenia etapowo, na podstawie modułów systemu przekazanych zleceniodawcy. Równie często z obu powodów jednocześnie.

Nienamacalność projektów, późno zmieniające się wymagania, braki doświadczenia – zarówno po stronie zleceniobiorcy jak i zleceniodawcy to zdecydowanie najczęstsze przyczyny niepowodzeń we wdrożeniach systemów informatycznych z jakimi spotkałem się w ciągu ostatniej dekady. Wszystkie powyższe powody sprowadzają się jednak do jednego źródła jakim jest niedoszacowanie ryzyka związanego z realizacją projektu informatycznego i związane zbyt pochopne wybory rozwiązań, wymagań, ale przede wszystkim podwykonawców, którzy częstokroć pomimo zdolności technicznych zawodzą w zakresie uświadamiania zleceniobiorcy w zakresie podejmowanych planów, kosztorysów, wyborów, założeń lub nawet całych metodologii.

W ciągu ostatnich lat prawie zawsze spotykałem się z typowym podejściem doboru wykonwców systemów na zamówienie na podstawie tradycyjnego materiałowo-nakładowego podejścia. Dotyczy to zarówno małych, średnich firm, jak również podmiotów sektora publicznego. Niejednokrotnie kryteriami przetargowymi była wyłącznie cena i czas realizacji projektu. Prawie nigdy szacowanie ryzyka niepowodzenia realizacji projektu przez danego podwykonawcę nie było w ogóle brane pod uwagę. W każdym przypadku przetarg w którym uczestniczyłem lub przetargowe podejście do wyboru zleceniodawcy kończyło się niepowodzeniem projektu w postaci najgorszego możliwego scenariusza.

Aby ustrzec się przed problemami wynikającymi zarówno ze złych założeń jak i niedoszacowania wymagań i złożoności, należałoby zastanowić się nad powierzeniem kwestii specyfikacji oprogramowania, jak również całego zarządzania projketem firmie zewnętrznej. Zarządzanie projektem przez zarząd zamawiającego niesie za sobą ryzyko braku umiejętności technicznych pozwalających na efektywne mierzenie postępu realizacji projektu. Zarządzanie projektem przez zarząd zleceniobiorcy powoduje równie duży nacisk na optymistyczne przyjmowanie rzeczywistości, jak również wiąże się często z brakiem znajomości natury biznesu czy też branży zamawiającego pozwalające na efektywną ocenę kompletności specyfikacji realizowanego rozwiązania. Powierzenie specyfikacji jak również zarządzania projektem firmie (lub osobie) niezwiązanej z żadną ze stron, a specjalizującej się w samej naturze zarządzania projektami informatycznymi pozwala na znacznie większy obiektywizm podczas realizacji projektu. Profesjonalne podmioty specjalizujące się w zarządzaniu projektami doceniają również z jednej strony techniczne aspekty przedsięwzięcia (wraz z ogólnymi ich komplikacjami), a z drugiej strony na biznesowe aspekty branży, dla której projekt jest realizowany (wraz z ogólnymi komplikacjami każdej branży). Co najważniejsze zarządzający projektem (analityk biznesowy) występujący jako podmiot trzeci jest niezależny od presji nadmiernego upraszczania wymagań, tj. przedstawiania projektu jako tańszy jeżeli kilka funkcji nie zostanie omówionych, jak również nadmiernego ich komplikowania-, tj. przedstawiania projektu jako listy życzeń a nie faktycznej listy wymagań celem osiągnięcia pozornie lepsze stosunku wartości do ceny.

Niezależni dostawcy oprogramowania
- Firmy świadczące usługi programistyczne lub konsultingowe to nie firmy ISV, aczkolwiek firmy ISV mogą również być firmami konsultingowymi.
- Value Added Resellers to nie firmy ISV, aczkolwiek firmy ISV mogą sprzedawać programy napisane przez kogoś innego jako część ich oferty.
- Firmy ISV muszą brać ryzyko kosztów produkcji oprogramowania licząc na to że w momencie kiedy będzie ono gotowe, ktoś będzie chciał kupić ich produkt.
- Jeżeli nie posiadasz żadnego gotowego oprogramowania, nie reprezentujesz branży ISV. Firmy branży ISV posiadają własne, niezależnie wytworzone oprogramowanie.