Menu
Blog • projekty it
Skąd się bierze cena usługi IT? Poradnik dla kupującego.
Rozważasz zakup usługi IT, weźmy na przykład stworzenie oprogramowania dla Twojej firmy. Jednym z ważnych elementów, które bierzesz pod uwagę jest cena. Spisujesz wymagania. Kontaktujesz się z kilkoma wykonawcami i prosisz o oferty.
Jeżeli zamieściłeś ogłoszenie na jednym z portali z ofertami, całkiem możliwe, że dostałeś sporo odpowiedzi. Część wykonawców zadaje kilka pytań i wysyła wycenę. Okazuje się, że rozstrzał cen jest ogromny, możliwe, że ceny różnią się od siebie nawet o całe rzędy wielkości.
Dlaczego wyceny tak bardzo różnią się od siebie?
Typowych przyczyn jest kilka. Najczęstszą i mającą największy wpływ na różnice jest nieprecyzyjne określenie zakresu projektu.
Zakres projektu
Dlaczego dokładne określenie zakresu projektu jest tak ważne? Zacznijmy od tego, że z definicji jedną z cech projektu jest jego unikalność. Jeżeli chcesz stworzyć oprogramowanie, to znaczy, że nie znalazłeś na rynku rozwiązania, które spełnia Twoje wymagania.
Jeżeli oczekujesz, że ktoś zrobi dla Ciebie coś całkiem nowego, to powinno to być dokładnie opisane, aby uniknąć nieporozumień. Nie warto zakładać, że coś jest oczywiste i zostawiać pola do domysłów. Niestety często przygotowanie dokładnej specyfikacji jest pracą żmudną, ale prędzej, czy później i tak będzie trzeba ją wykonać.
Co, jeśli określisz projekt zbyt ogólnie? Wtedy właśnie rozstrzał cen jest tak duży, ponieważ jeden wykonawca może założyć plan minimum a inny zaproponować rozwiązania dopracowane i wygodne dla użytkowników.
Porównanie ofert
Upewnij się, że porównujesz oferty na ten sam zakres projektu. Jeśli nie przyjmiesz jakiejś metodyki porównania ofert, zakładając, że przecież przesłałeś wytyczne i obaj przykładowi wykonawcy wycenili to samo, może się okazać, że ten, który chciał zaproponować lepsze rozwiązanie – przegra ceną. Być może mógłby zaproponować korzystniejsze warunki niż konkurent, ale nie miał szansy, bo już został odrzucony. Rzadko się zdarza, że przy nieprecyzyjnie określonej specyfikacji rozwiązania, wielu wykonawców wyobraża sobie realizację projektu w taki sam sposób. W praktyce podejścia różnią się znacząco, co przekłada się na wynik, czyli Twój system, aplikację czy rozwiązanie IT.
Jak dokładnie określić projekt?
Jak dokładnie warto określić zakres projektu? Podam kilka przykładów dobrych praktyk.
- Zrób dokładną listę lub tabelę opisującą poszczególne funkcje.
- Nie zakładaj, że coś jest oczywiste. Np. logowanie użytkowników lub mechanizm odzyskiwania hasła może być dla Ciebie oczywisty, ale są systemy, które takich mechanizmów nie muszą posiadać.
- Przyjmij, że jeżeli coś nie jest zapisane to nie zostanie zrealizowane.
- Hasło „chcę tak samo, jak…” nie jest dobrą taktyką.
- Porównuj oferty na ten sam zakres pracy. Przydatnym narzędziem może być tabela zawierająca następujące kolumny: element programu, liczba godzin, stawka godzinowa, łączny koszt. Niech wykonawcy wypełnią Twoją tabelkę, wtedy porównanie będzie łatwiejsze. Jeśli jakiś element programu generuje duże różnice w wycenach, dopytaj skąd się to bierze.
- Nie odrzucaj najdroższej oferty, dopóki nie upewnisz się, że rozumiesz, z czego wynika wysoka cena. Będzie to świetne źródło informacji.
- Przydatnym narzędziem są scenariusze użycia, czyli tzw. user stories. Technika ta polega na opisaniu krok po kroku co w danym scenariuszu użycia będzie się działo zarówno od strony użytkownika, jak i od strony logiki programu.
- Jeśli wykonawca zadaje pytania – cierpliwie na nie odpowiadaj, to dobry znak. Nie przyspieszaj tego procesu. Cierpliwość na tym etapie się opłaci.
- Czy projekt graficzny (UI) bądź interfejsu (UX) jest konieczny do wyceny? Nie, ale bardzo pomaga, chociażby wymuszając na Tobie zastanowienie się nad niektórymi funkcjonalnościami. Widząc ekrany aplikacji naturalnie lepiej przewidujemy możliwe funkcjonalności czy usprawnienia.
- Zobacz jak pracuje się z wykonawcą na etapie wyceny. Czy jest zaangażowany w proces? Czy zadaje pytania? Czy pomaga Ci zrozumieć istotę projektu? Jaki jest z nim kontakt? Jeśli wszystko na tym etapie przebiega pozytywnie, to jest spora szansa, że współpraca się ułoży.
Analiza przedwdrożeniowa
Doświadczony wykonawca zazwyczaj przejmie inicjatywę w sytuacji, gdy określony przez Ciebie zakres projektu jest niewystarczający. Zada odpowiednie pytania. Poprowadzi Cię przez proces określania specyfikacji programu, jeśli mu na to pozwolisz. Pamiętaj jednak, że jest to praca do wykonania zajmująca często wiele godzin. Nie każdy będzie chciał ją wykonać za darmo. Najczęściej do pewnego stopnia wykonawcy godzą się pomóc doprecyzować projekt w ramach procesu zakupowego klienta, ale jeśli wymagany jest głębszy research, zbadanie niektórych technologii czy przetestowanie pewnych rozwiązań, mogą zaproponować płatne przygotowanie analizy lub dokumentacji przedwdrożeniowej.
Jeśli wykonawca czegoś nie wie i chce sprawdzić, to raczej dobra oznaka. Pamiętaj, że Twój projekt jest unikalny. Specjaliści nie mają i nie muszą mieć wszystkich rozwiązań w głowie. Często obierany jest jakiś kierunek rozwiązania danego problemu, ale wymagane jest sprawdzenie wielu szczegółów. Fakt, że wykonawca chce sprawdzić niepewne ścieżki oznacza jego zaangażowanie i chęć wyeliminowania niespodzianek w przyszłości.
Co może pójść nie tak?
Co może tutaj pójść nie tak? Albo profesjonalista zawyży stawki, akceptując tym samym wysoki stopień niepewności, ale jednocześnie zabezpieczy się przed stratą i zapewni sobie zysk, albo osoba mniej doświadczona niedoszacuje projektu.
Rozważmy drugi wariant. Co stanie w przypadku, gdy klient dostanie korzystną cenę, za którą nie da się dowieźć wymaganego rozwiązania? Czy wygrywa? Co się stanie, gdy wykonawcy zacznie kończyć się budżet, zorientuje się, że nie zarobi na projekcie albo, co gorsza będzie musiał dołożyć? Najczęściej ucierpi jakość, zacznie się realizacja funkcjonalności najprościej jak się da, pojawi się nerwowość i napięcia. Mogą nawet pojawić się renegocjacje wynagrodzenia. Żadne z tych zjawisk nie jest korzystne dla żadnego uczestnika projektu.
Konkluzja jest jedna, należy dokładnie określić zakres projektu, upewnić się, że cena jest adekwatna, a niekoniecznie najniższa. To jest w najlepszym interesie klienta.
Sposób realizacji
Kolejnym czynnikiem jest metodyka realizacji projektu. Podam dwa skrajne przykłady.
Może zjawić się wykonawca, który zechce zrealizować projekt po najmniejszej linii oporu, byle działał. Może to powodować szereg poważnych problemów w bliższej lub dalszej przyszłości. Czy klient zauważy w wycenie różnicę? Najczęściej nie, ponieważ mówimy tutaj o czynnikach technicznych.
Drugi wykonawca może założyć realizację przy użyciu najlepszych praktyk, co wpłynie na cenę, często znacząco. W określonych sytuacjach na niektórych elementach projektu jednak nie opłaca się oszczędzać.
Przykładowe, nieoczywiste dla klienta elementy dobrych praktyk:
- testy automatyczne,
- konteneryzacja,
- projektowanie interfejsów UI/UX,
- tworzenie dokumentacji projektowej,
- dobór architektury serwerowej,
- i wiele innych.
Dla niektórych wykonawców część z powyższych elementów będzie oczywistością, ale są tacy, którzy chcąc dać lepszą ofertę celowo rezygnują z zachowania standardów i dobrych praktyk realizacji projektów IT. Jest to zachowanie nieetyczne, ale występuje.
Czy wszystkie najlepsze praktyki muszą być wdrożone w każdym projekcie? Oczywiście, że nie, należy zachować rozsądek i dobrać narzędzia adekwatnie do potrzeb projektu.
Firma czy freelancer?
Ważnym czynnikiem wpływającym na cenę jest fakt, czy projekt będzie realizowała firma, czy freelancer. Praca z freelancerem jest tańsza, ale czy jest to lepsze rozwiązanie? Dokonując tego wyboru warto mieć świadomość kilku kwestii.
Po pierwsze, projekt IT realizują nie tylko programiści. Istnieje wiele innych ról niezbędnych przy realizacji. Może się wydawać, że programista, to programista, potrafi wszystko, ale podział na specjalizacje jest ogromny. Przykładowe role oprócz samego zespołu programistów:
- kierownik projektu – osoba, która koordynuje wszystkie prace, planuje, rozdziela zadania, podejmuje decyzje, pilnuje terminów, budżetu itd.,
- analityk biznesowy – osoba, która rozumie oba światy – świat biznesu oraz IT, pomaga modelować rozwiązania,
- projektant UI / UX – projektuje interfejsy pod względem użyteczności, wygody i efektywności używania, jak również wizualnie (często są to dwie różne osoby),
- DevOps – osoba odpowiedzialna za infrastrukturę serwerową, programiści najczęściej nie mają tej kompetencji i wymagają gotowej infrastruktury,
- tester – jak sama nazwa wskazuje osoba testująca rozwiązania, ma znacznie ważniejszą rolę, niż by to się mogło wydawać, dokładne testy zajmują dużo czasu, ale są konieczne.
Czy jesteś gotów przejąć te kompetencje w projekcie? Czy potrafisz zrealizować te funkcje prawidłowo? Bo jeśli nie, to projekt ma małe szanse na powodzenie.
Jeżeli więc zakładasz, że zlecisz projekt freelancerowi i będziesz mógł oczekiwać efektów, to najczęściej nie zadziała.
Wybór freelancera sprawdza się w przypadku realizacji pojedynczych, dobrze zdefiniowanych prac albo do dołączenia do zarządzanych już projektów. Do realizacji większych projektów samodzielnie najczęściej nie są dobrym wyborem.
Zespół realizujący projekt
Doświadczenie zespołu i stawki członków zespołu są bardzo różne. Da się zatrudnić studentów albo specjalistów o niskich kompetencjach i doświadczeniu, ale co z tego wyjdzie? W IT krąży taki żart: „każdy projekt da się ukończyć skończoną liczbą studentów”. Jeżeli osoba reprezentująca firmę ma wysokie umiejętności sprzedażowe, możliwe, że przekona Cię do współpracy. Upewnij się jednak kto będzie realizował projekt.
Odpowiedzialność we współpracy specjalisty z klientem
Skąd się bierze cena usługi IT? Poradnik dla kupującego.
Poprzedni
Następny