"Co tak drogo?!" - to pytanie słyszała w swoim życiu (i to wielokrotnie) praktycznie każda osoba, która prowadzi firmę usługową, produkcyjną lub sklep. Nie da się ukryć, że o ile wszyscy zawsze podkreślają, że jakość jest najważniejsza, to cena zazwyczaj jest pewną barierą. Oczywiście, nie musi tak być - istnieją usługi, w których większość jest w stanie dopłacić do jakości lub zwyczajnie cena jest wystarczająco niska. Tym niemniej na pewno większość z nas musiała choćby raz tłumaczyć, dlaczego cena, za którą oferuje dany produkt lub działanie, jest ustawiona na tak wysokim pułapie.
Dzisiaj pokażemy sobie, z czego składa się cena za oprogramowanie lub usługę IT. Od razu zastrzegam, że nie będziemy wchodzili w szczegóły, a tym bardziej podawać konkretnych kwot, gdyż zależą one od stawek firmy (naszą możecie znaleźć pod tym linkiem), pracy do zrealizowania, a także typie wykonawcy. Zaznaczam też, że będziemy pisać o koszcie systemu informatycznego tworzonego na zlecenie - w przypadku produktów do kupienia "z półki" jest to zwykle kwestia strategii cenowej danej firmy i planów sprzedażowych związanych z oprogramowaniem. Dlatego wszystko, co przeczytacie poniżej, dotyczy wycen tworzonych indywidualnie na zamówienie.
Każdy, kto kiedykolwiek widział wycenę oprogramowania, wie, że zazwyczaj wynika z pracochłonności konkretnych zadań. Często jest to szacowana liczba godzin potrzebna do realizacji czegoś, czasem stosowane są punkty funkcjonalne lub inne jednostki, według, których łatwiej ustalać choćby rząd wielkości. Estymacje wynikają z burzy mózgów, metod typu Planning Poker, historii lub po prostu doświadczenia, że coś tyle czasu zwykle zajmuje. Nie jest też żadną tajemnicą, że bywają niedokładne - to w końcu oszacowania, które są bazą dla podejścia fixed price. Ale pytanie, czy faktycznie jest to tylko samo wprowadzenie zmiany do kodu? Czy wprowadzenie jakiegoś pola do formularza to nie jest tak naprawdę kwestia 30 minut, a ten zły software house liczy za to kilka godzin? Otóż, nie, słusznie tak liczy i to z kilku powodów.
Po pierwsze, zazwyczaj jako użytkownicy oceniamy dane funkcje pod kątem ich pojawienia się w interfejsie użytkownika. Mówiąc bardziej obrazowo, dla laików sam fakt, że może uzupełnić dane pole oznacza wykonanie zadania, jednak takie podejście jest dużą pomyłką. To troche tak, jakby wstawić do samochodu ładny fotel, ale go nie przytwierdzić do reszty. Za zmianami na frontendzie muszą podążyć zmiany w backendzie i obsługa tego pola w systemie. A to nie zawsze jest proste, szczególnie przy danych kluczowych dla działania systemu. Po drugie, czasem dodanie pola (nie mówiąc już o bardziej złożonych modyfikacjach) uruchamia efekt domina i wymaga przemyślenia innych części systemu. Po trzecie, w ten czas wliczona jest także weryfikacja, czyli przetestowanie tej zmiany. Uwierzcie mi - nie chcielibyście, aby programista dodał pole i uznał, że sprawa jest zakończona. Trzeba rozpisać, co ta zmiana ze sobą niesie, jakie są warunki wykonania zadania oraz je przetestować, łącznie ze skrajnymi przypadkami. Oczywiście, nie zawsze wszystko zostanie wykryte na etapie wewnętrznych testów, jednak bez tej fazy błędów byłoby znacznie więcej. Po czwarte, czasem liczy się moment wprowadzenia zmiany - łatwiej wprowadzić do jednego formularza trzy pola naraz niż każde z nich osobno, w tygodniowych odstępach.
Bardzo duże, wręcz ogromne znaczenie mają też wymagania pozafunkcjonalne, które mogą funkcję pozornie prostą wywindować do zadania wymagającego wiele godzin pracy. Inaczej kształtują się estymacje dla systemów kierowanych do małego grona osób, a inaczej dla oprogramowania, które musi obsłużyć miliony użytkowników i będzie działać na serwerach o określonym charakterze. Im większe bezpieczeństwo czy wymagania związane z interfejsem użytkownika, tym bardziej trzeba na to zwrócić uwagę przy liczeniu potrzebnych środków. Tak samo narzucenie określonych technologii (co wynika np. z wewnętrznego działu IT klienta, który potem przejmie rozwój aplikacji) może podnieść koszty ze względu na potrzebę zapoznania się z nowymi narzędziami przez dany software house. Wreszcie, znaczenie ma liczba komponentów - inaczej wycenia się oprogramowanie składające sie z samej aplikacji webowej, a inaczej takie, które zawierają również "mobilkę" czy interfejs desktopowy. Dając do wyceny tę sama aplikację jako webową i mobilną uzyskacie dwa różne oszacowania i to normalne. Wreszcie, wszelkie dodatkowe panele (np. administracyjny) również mogą wpłynąć na budżet potrzebny do stworzenia oprogramowania.
Jednak prace programistyczne, nawet włącznie z testowaniem, to nie jedyne, co trzeba uwzględnić. Niektóre obszary wymagają bowiem zaprojektowania nowych modułów i architektury pod nie. A to oznacza kolejną pracę, którą software house musi wykonać. Niekiedy zdarza się też, że jakaś funkcja wymaga zapoznania się z dostępnymi rozwiązaniami i wybór konkretnego - jest to tzw. research, który też ktoś musi zrobić. Kolejna kwestia to przygotowanie makiet oraz prototypów, nawet jeśli tylko do części zadań. Podeście "zaproponujcie coś, a potem się zmieni" jest fatalne i generuje frustrację oraz kolejne koszty, z którymi zarówno klient, jak i wykonawca nie mogą się pogodzić - stąd przy bardziej skomplikowanych lub kluczowych z punktu widzenia systemu ekranach należy wcześniej przygotować ich projekt.
Ale nie tylko praca techniczna musi być opłacona - to także praca osób kierujących projektem, osób przeprowadzających szkolenia, prezentacje dla klienta, a także analizujące nowe potrzeby. To również nie jest robione "z marszu" i wymaga przemyślenia oraz przygotowania choćby szczątkowej specyfikacji. Spotkania i konsultacje również wchodzą w zakres tego segmentu prac. Sporo osób zapomina również o tym, że oprogramowanie należy wdrożyć. A to oznacza czas spędzony na przygotowywaniu paczek z oprogramowaniem, opracowaniu procedury wdrożeniowej i "ostatniej linii" testów, które sprawdzają nie tylko same funkcje, ale także ich powiązania ze sobą.
Tak, jak pisałem - w zależności od projektu, kosztorys prac może mieć najróżniejsze pozycje zawarte w sobie. Zdarzają się choćby systemy, w których konieczne jest zakupienie odpowiedniej licencji na biblioteki czy oprogramowanie, a nawet sprzęt. Co więcej, istnieją projekty, w których potrzebny staje się dojazd do klienta w celu wykonania określonych prac na miejscu (choć, na szczęście, jest to duża rzadkość). Może być to też koszt wynajęcia odpowiedniego eksperta, konsultanta, który nie tylko będzie stanowił pomoc w zrozumieniu kontekstu biznesowego (szczególnie ważne przy systemach tworzonych przez dłuższy czas w specyficznej branży), ale też ograniczy występowania nieporozumień.
Natomiast klient musi też pamiętać o innych kosztach tworzenia oprogramowania, niebezpośrednio związanych z pracami technicznymi. Pamiętajmy o tym, że otwarte systemy wymagają regulaminów i przeprowadzenia różnych formalności, które stają się możliwe z udziałem prawników lub np. audytorów. W przypadku aplikacji wielojęzycznych konieczne okazuje się zapewnienie tłumaczeń, które będą mogły zostać wprowadzone do aplikacji. Wcześniej wspomniane zostały też makiety, które mogą wymagać konsultacji z grafikiem, np. pod kątem loga serwisu czy użytych kolorów. Wreszcie, większość systemów działa na serwerach i innej infrastrukturze, którą trzeba zakupić, skonfigurować oraz utrzymać. A żeby tego było mało, to w niektórych przypadkach należy zapewnić moderatorów i wsparcie klienta...
Z tego wszystkiego powinny płynąć dwa wnioski. Po pierwsze, zaimplementowanie czy dodanie nowej funkcji do systemu to nie jest tylko czas poświęcony na samo dodanie paru linijek kodu - to także cała "otoczka" wokół tego, weryfikacja, czasem projekt, przemyślenie sposobu działania itd. Z tego powodu już dawno przestało się oceniać programistów poprzez napisane linie kodu (choć bywa, że ten temat wraca). Po drugie, jeśli ktoś chce stworzyć oprogramowanie, musi liczyć się także z kosztami pozatechnicznymi i utrzymaniem systemu przez dłuższy czas. Stąd warto zaznajomić się z technikami, które umożliwiają większy zwrot z przeprowadzonej inwestycji w kod lub po prostu przemyśleć kwestię MVP.
Pozdrawiam i dziękuję - Jakub Rojek.