Poradnik Inwestora: Dobre praktyki w wycenie systemów IT – rozmowa z ekspertem

Koszt zakupu systemu informatycznego jest wypadkową wielu kluczowych czynników, składających się na proces wytwórczy i akceptacyjny. W dużej mierze jest on zależny od złożoności obszarów, które system obejmuje, a także funkcjonalności, które mają być zrealizowane. Jak sprawić, żeby wycena przebiegła w możliwie bliski ideału sposób? Jak uniknąć kosztownych błędów, jak się przygotować i zabezpieczyć? O meandrach wycen zaawansowanych systemów IT, rozmawiamy z ekspertem w tej dziedzinie - z dr. inż. Mirosławem Ochodkiem z Politechniki Poznańskiej.

Marek Kozłowicz: W dzisiejszych czasach, w znakomitej większości projektów wytwarzania oprogramowania na zamówienie, stosuje się techniki zwinne, polegające na stopniowym dostarczaniu klientowi coraz bardziej rozbudowanych wersji działającego systemu. Jak do wyceny zamawianego oprogramowania powinien przygotować się inwestor? Od czego zacząć?

Mirosław Ochodek: Myślę, że sam fakt oparcia procesu wytwarzania oprogramowania o zwinne metodyki nie determinuje jednoznacznie ani nie ogranicza sposobu wyceny. W pewnych sytuacjach możemy chcieć zastosować tradycyjne podejścia do wyceny, jak np. poprzez określenie „stałej ceny” (ang. fixed price), natomiast mocno iteracyjny i odkrywczy charakter tych metodyk może otworzyć nam nowe możliwości w zakresie organizacji współpracy i rozliczania prac programistycznych pomiędzy zamawiającym a wykonawcą. Dlatego, jako inwestor przygotowujący się do wyboru modelu finansowania i wyceny, w pierwszej kolejności spróbowałbym odpowiedzieć sobie na trzy pytania: Jak dużo wiem o produkcie? Jak duży jest produkt? Jak duże zaufanie mam do potencjalnego wykonawcy?

Dla przykładu, jeśli tworzony produkt byłby na tyle niewielki, że potrafiłbym dokładnie określić dla niego wymagania i mógłbym przyjąć, że będą one w miarę stabilne, a dodatkowo nie współpracowałbym wcześniej z wykonawcą, to prawdopodobnie pozostałbym przy modelu „stałej ceny”. W takim przypadku wykonawca wyceniłby całość prac programistycznych w oparciu o przedstawione wymagania. Dałoby mi to pewną gwarancję ceny i ograniczyło ryzyko. Niestety jeśli znacząco zmieniłbym zakres wymagań w trakcie prac, to prawdopodobnie musiałbym zapłacić dodatkowo za każdą znaczącą zmianę. Idąc w kierunku drugiego ekstremum, czyli sytuacji, kiedy o produkcie wiedziałbym bardzo niewiele (np. miałbym tylko jego wizję), dodatkowo spodziewałbym się, że będę produkt rozwijał w długim horyzoncie czasowym, to lepszym rozwiązaniem byłaby wycena w pierwszej kolejności w trybie „stałej ceny” minimalnego produktu gotowego do wprowadzenia na rynek (ang. Minimum Viable Produkt - MVP) i wraz ze wzrostem zaufania do wykonawcy próbowałbym przejść na model wyceny za wykonaną pracę (ang. time and materials).

MK: Jaki jest zakres szczegółowości kluczowych wymagań, które powinny być określone już na początku projektu?

MO: W tym miejscu warto wspomnieć o tzw. stożku niepewności, który mówi o tym, że dokładność oszacowania kosztów wytworzenia oprogramowania w ogromniej mierze zależy od zakresu naszej wiedzy na temat tworzonego produktu. Musimy liczyć się z tym, że wykonawca wyceniając prace programistyczne, będzie musiał uwzględnić takie ryzyko w swojej wycenie.

Dlatego w ramach dostępnych środków starałbym się jak najbardziej zredukować niepewność i już na bardzo wczesnym etapie określiłbym wizję produktu i kluczowe wymagania biznesowe. Jeśli chodzi o szczegółowość wymagań, to w przypadku modelu „stałej ceny” bardziej istotne byłoby dobre określenie zakresu (identyfikacja wymagań) niż szczegółowe wyspecyfikowanie kilku wybranych wymagań. W przypadku podejścia iteracyjnego do wyceny mniejszych fragmentów systemu dużo bardziej przydatne byłoby dokładne wyspecyfikowanie tych wymagań, które miałyby zostać zaimplementowane w kolejnej iteracji. Na tym etapie warto także zastanowić się nad ograniczeniami i wymaganiami jakościowymi (pozafunkcjonalnymi), np. dotyczącymi wydajności, bezpieczeństwa, dostępności. Wymagania tego typu często nie zyskują odpowiedniej atencji, a mogą mieć bardzo istotny wpływ na architekturę systemu informatycznego, a co za tym idzie – na koszt jego wytworzenia.

MK: Które koszty powinny być uwzględnione po stronie zamawiającego, a które po stronie dostawcy oprogramowania? Na co zwrócić szczególną uwagę, żeby uniknąć późniejszych rozczarowań?

MO: Myślę, że mimo wszystko zależy to od charakteru projektu. Natomiast będąc inwestorem, na pewno warto pamiętać o tym, że produkt informatyczny jest tylko narzędziem do wprowadzenia zmiany. Dlatego musimy wziąć pod uwagę także koszty jego wdrożenia i utrzymania po stronie organizacji zamawiającego (np. koszt przedłużenia licencji, wprowadzenia niezbędnych zmian, hostingu, jeśli istnieje taka potrzeba, zakupu sprzętu czy koszty zmian organizacyjnych). Dodatkowo, jak już wspomniałem, musimy mieć świadomość, że wprowadzanie zmian w oprogramowaniu kosztuje i choć jest pewnie łatwiejsze niż w przypadku wielu fizycznych produktów, radykalne zmiany, często konieczne, mogą być bardzo kosztowne i trzeba się z tym liczyć.

MK: Jaką pulę narzędzi służących wycenie projektów IT stosuje się w dzisiejszych realiach? Które z nich sprawdzają się najlepiej i dlaczego?

MO: Istnieje bardzo dużo metod szacowania pracochłonności i kosztów wytworzenia oprogramowania. Wbrew pozorom nie lekceważyłbym podejść czysto eksperckich. Natomiast ich niewątpliwą wadą w kontekście formalnej wyceny produktów informatycznych jest potencjalny subiektywizm eksperta (najczęściej będzie nim wykonawca). W związku z tym dla zwiększenia obiektywizmu wyceny często decydujemy się na użycie metod ustandaryzowanych. Popularnym podejściem tego typu jest oparcie wyceny o pomiar rozmiaru oprogramowania, np. za pomocą metody Punkty Funkcyjne czy COSMIC (metody te są standaryzowane przez ISO/IEC). Następnie korzystając z dostępnych danych przemysłowych (np. z bazy ISBSG), możemy oszacować, ile roboczogodzin potrzeba na wytworzenie oprogramowania określonego rozmiaru. Stosując to podejście, mamy także możliwość sprawdzenia, na ile konkurencyjna jest przedstawiona wycena (ang. benchmarking) – na przykład poprzez sprawdzenie, czy odbiega ona znacząco od średniej wyceny w oparciu o dane historyczne z podobnych projektów.

MK: Do pisania aplikacji wykorzystuje się różne języki programowania. Czy wybór określonego języka może mieć wpływ na koszty, a tym samym na wycenę?

MO: Tak, prowadzone badania wskazują, że istnieje zależność pomiędzy pracochłonnością wytworzenia aplikacji a wyborem języka programowania. Natomiast warto zastanowić się, jakie są przesłanki do użycia konkretnego języka programowania. Na przykład produktywność zespołów wygląda mniej korzystnie dla tzw. języków niskopoziomowych, ale z drugiej strony takie języki programowania dają zdecydowanie większą kontrolę nad wykonaniem programu, co może być bardzo istotne w przypadku tworzenia systemów wbudowanych czy aplikacji, dla których kluczowa jest wydajność. Dlatego język programowania, czy też inne decyzje projektowe, powinny być dostosowane do rozwiązywanego problemu i dobrze jest w tej kwestii zaufać wykonawcy, ew. skonsultować wybór z niezależnymi ekspertami.

MK: Jakie błędy popełniane są najczęściej podczas wyceny? Które z nich są domeną inwestora, a które dostawcy oprogramowania? Co jest ich przyczyną?

MO: Niestety, nie mam wiedzy co do częstotliwości popełniania konkretnych błędów. Natomiast od strony zamawiającego błędy, które możemy popełnić, to przede wszystkim niewłaściwy wybór modelu finansowania projektu oraz przyjęcie często bardzo błędnego założenia, że znamy wszystkie wymagania dla produktu przed przystąpieniem do prac rozwojowych i nie ulegną one zmianie. Myślę, że od strony wykonawcy ryzyko wiążę się przede wszystkim z koniecznością balansowania pomiędzy bezpieczeństwem finansowym projektu a konkurencyjnością na rynku. Chociaż nawet po stronie wykonawcy potencjalnym błędem może być założenie, że produkt informatyczny to tylko oprogramowanie, a często tak nie jest i wraz z oprogramowaniem musimy dostarczyć specjalistyczną dokumentację albo wytworzyć inne produkty niezbędne do funkcjonowania systemu.

MK: Czy istnieje recepta gwarantująca doskonałe przeprowadzenie wyceny systemu informatycznego, gwarantujące zabezpieczenie interesów zarówno inwestora, jak i dostawcy?

MO: Zaryzykowałbym stwierdzenie, że nie istnieje taka jedna metoda czy model finansowania, który sprawdziłby się w każdym rodzaju przedsięwzięcia. Warto wspomnieć, że prace nad metodami szacowania kosztów trwają nieustannie właściwie od samego początku komercjalizacji wytwarzania oprogramowania. Podejście do wyceny należy dobrać, analizując kontekst przedsięwzięcia, jego powtarzalność oraz dostępność danych historycznych.

 

Rozmawiał  Marek Kozłowicz, redaktor prowadzący „Industrial Monitor”.

 

DR INŻ. MIROSŁAW OCHODEK

INSTYTUT INFORMATYKI POLITECHNIKI POZNAŃSKIEJ

 

Dr inż. Mirosław Ochodek jest pracownikiem Instytutu Informatyki Politechniki Poznańskiej. Od ponad dekady prowadzi badania w zakresie wyceny projektów informatycznych, wspierając firmy informatyczne i instytucje publiczne, prowadząc szkolenia specjalistyczne, przygotowując ekspertyzy oraz wyceny. Jest certyfikowanym ekspertem w zakresie metod IFPUG Function Point Analysis oraz COSMIC.

Oferta: automatyka magazynowa, case study, centrum logistyczne, dystrybucja, logistyka, magazyn, magazynier, operator logistyczny, palety, regały, studia przypadków, system wms, wózek widłowy, wózki widłowe

Background Image

Header Color

:

Content Color

:

Strona korzysta z plików cookies w celu realizacji usług zgodnie z Polityką prywatności. Możesz określić warunki przechowywania lub dostępu do cookie w Twojej przeglądarce lub w konfiguracji usługi. Polityka prywatności.