Skąd się biorą różnice w wycenie projektu?

Zlecając napisanie oprogramowania dla swojego biznesu, prawdopodobnie spotkałeś się ze zjawiskiem przygotowania różnych wycen poszczególnych firm wytwarzających oprogramowanie oraz tym, że mogą się one znacząco od siebie różnić. Podobnie, gdy jesteś właścicielem software house'u, często słyszysz od swoich potencjalnych klientów, że Twoja wycena jest znacznie wyższa od innych ofert przygotowanych przez inne firmy.

W tym artykule chciałbym przedstawić, dlaczego rozrzut cen wykonania usługi stworzenia aplikacji webowej lub mobilnej, jest tak szeroki oraz z jakimi zagrożeniami wiąże się wybranie nieoptymalnej oferty, która jest atrakcyjna wyłącznie dlatego, że jest znacznie tańsza od pozostałych.

Rozrzut cen wykonania aplikacji jest bardzo duży, a przyczyną jest kilka ważnych czynników, które dotyczą realizacji każdego projektu IT. Jeśli nie masz bardzo dokładnie sprecyzowanych wymagań i zakresu prac (specyfikacja funkcjonalna i techniczna), każdy wykonawca może przyjąć inne założenia odnośnie do szczegółów i co za tym idzie, estymować inny zakres prac. Niewielki projekt może zostać napisany zarówno przez studenta, mały zespół, jak i większą firmę. Jeśli chodzi o większe projekty, w grę wchodzą już co najmniej małe firmy, ponieważ żadna pojedyncza osoba, jak i niewielki zespół nie będzie w stanie zrealizować takiego projektu (a decydując się na ten krok, skończy się to dostarczeniem oprogramowania bardzo słabej jakości). W znakomitej większości przypadków mniejsza firma zawsze zaoferuje niższą cenę wykonania niż firma większa. Nie wynika to jednak z faktu, że większa firma ma większą marżę i chce więcej zarobić. Wręcz przeciwnie, stawki zazwyczaj są bardzo podobne do siebie. Większa firma, z uwagi na znacznie większe koszty utrzymania i większy zespół, w praktyce marżę na projekcie ma niższą. Z czego więc wynika różnica w cenie za ten sam projekt? I tutaj odpowiedź jest tylko jedna - jakość, przyjęte założenia i podejście do jego realizacji.

Oczywiście, wszystko zależy, jak podchodzisz do swojego projektu. Jeśli ma to być projekt, który jest kluczowy w twojej organizacji i który będzie rozwijany przez kolejne lata - jakość bez wątpienia ma tutaj znaczenie. Pozwoli Ci w dłuższej perspektywie zaoszczędzić zarówno pieniądze, jak i zapewnić spokój, że twój biznes oparty jest o stabilnie działające oprogramowanie.

Jeżeli z kolei nie wiążesz dłuższej przyszłości z projektem i nie jest on kluczowy w Twojej organizacji - możesz zaryzykować napisanie oprogramowania niskiej jakości, aczkolwiek i w tym przypadku warto się nad tym zastanowić. W dłuższej perspektywie może to być zły wybór. Nie możesz być pewny, czy jednak w przyszłości nie zajdzie potrzeba rozwijania tego projektu lub czy też nie osiągnie on swojego pułapu wydajnościowego, ze względu na błędne założenia architektoniczne i konieczne będzie stworzenie go od nowa (bo koszty naprawy okażą się bardzo wysokie).

A czym konkretnie jest jakość? Przecież oprogramowanie otrzymasz takie samo, niezależnie czy zrobi to niewielki zespół czy też większy. W obu zespołach mogą być nawet tacy sami, równie profesjonalni specjaliści. Diabeł tkwi w szczegółach procesów i osobach, które koordynują projekt. W przypadku, gdy oba zespoły mają taki sam poziom zaawansowania i doświadczenia, w teorii powinny powstać tak samo dobre jakościowo linie kodu. Dlatego kluczowa będzie sama organizacja i podejście do pracy zespołowej.

Dodatkowe osoby w zespole

Większe firmy mają bardziej rozszerzone zespoły, przede wszystkim o takie osoby, jak kierownik projektu (Project Manager, PM), lider technologiczny (Tech Lead, TL) czy dedykowani testerzy. W mniejszych firmach, tego typu osoby zazwyczaj nie występują, nie są więc potrzebne dodatkowe etaty, dlatego cena realizacji projektu jest zazwyczaj niższa. A jakie są role i jakie korzyści daje obecność tych osób w projekcie?

Kierownik projektu (Project Manager) - z tą osobą będziesz mieć bardzo częsty kontakt. Będzie się do Ciebie zgłaszać i dociekać, gdy coś będzie niejasne w założeniach. Będzie też osobą, do której zawsze będziesz mógł się zwrócić, jeśli będziesz chciał dowiedzieć się czegokolwiek na temat projektu lub zmodyfikować coś w jego założeniach. Po stronie wewnętrznej, PM będzie koordynował i pilnował projektu, tworzył zadania dla członków zespołu oraz pilnował roadmapy realizacji, koordynował zespół, interweniował i rozwiązywał problemy. Jednym słowem - dbał o to, aby projekt przebiegał zgodnie z wcześniej ustalonym planem. Bez project managera, projekt realizowany jest tylko przez zespół programistów, którzy nie mają wyczucia i spojrzenia projektowego, bo skupieni są tylko na pracy nad kodem (czyli stricte technicznej).

Tech Lead (TL) - jest osobą techniczną, która ma największe doświadczenie w zespole, i która zrealizowała w swoim życiu zawodowym wiele projektów, rozwiązała wiele problemów, a jej wiedza pozwala na uniknięcie wszelkich potencjalnych problemów technologicznych w twoim projekcie. Tech Lead ma ścisły kontakt z project managerem, spaja zespół programistów i udziela im wsparcia na każdym kroku. Odpowiada również za przygotowanie, razem z programistami, głównej architektury projektu. Sprawdza jakość wykonywanych prac, patrzy również na projekt z biznesowego punktu widzenia, a nie tylko technicznego. Jego obecność w projekcie pozwala na zbudowanie stabilniejszego oprogramowania, uniknięcie ryzyka i długu technologicznego, jak i zapewnienie optymalnej skalowalności projektu w przyszłości.

Dedykowani testerzy (QA) - tester nie zajmuje się niczym innym, jak dokładnym przejrzeniem wytworzonego oprogramowania i to na każdym etapie jego produkcji (nie tylko finalnej wersji). Dodatkowo, testerzy są zaangażowani już od etapu analizy samego projektu, dzięki czemu dokładnie rozumieją projekt, jak i już na tym etapie są w stanie podnieść ewentualne zagrożenia zaprojektowania danej funkcjonalności, bazując na swoim wcześniejszym doświadczeniu. Firma bez działu QA ryzykuje tym, że dostarczone oprogramowanie nie będzie należycie przetestowane oraz że nie wszystkie przypadki i scenariusze testowe zostały uwzględnione. Co za tym idzie, istnieje znacznie większe prawdopodobieństwo, że w pewnym momencie oprogramowanie może zacząć działać niewłaściwie lub nie tak, jak oczekuje tego klient.

Myślę, że już po przedstawieniu tych trzech kluczowych pozycji w projekcie, można łatwo wywnioskować, skąd bierze się wyższa wycena realizacji projektu i że nie wynika ona z przepłacania. Jest to natomiast dodatkowa opłata za etaty oraz jakość, dzięki czemu dostajemy lepsze oprogramowanie, którego nie jest w stanie dostarczyć firma, która wyżej wspomnianych osób w projekcie nie posiada. Bez ich udziału, projekt oczywiście powstanie na pierwszy rzut oka taki sam, ale z pewnymi zastrzeżeniami (które oczywiście mogą, ale nie muszą wystąpić):

• jego jakość wykonania nie będzie na tym samym poziomie - kod może być napisany gorzej (brak code-review przez doświadczoną osobę), jednocześnie będzie zapewniona gorsza wydajność i bezpieczeństwo (brak założeń brzegowych, brak wnikliwych testów)
• pewne procesy działania aplikacji mogą po czasie okazać się niewłaściwe (bo nikt po drodze tego nie przewidział i nie dopytał)
• architektura aplikacji będzie na niższym poziomie, niezabezpieczona przed różnymi, szczególnymi przypadkami ekstremalnego działania
• oprogramowanie będzie trudniej skalowalne i rozwijane w kolejnych iteracjach - z biegiem czasu dług technologiczny może być na wyższym poziomie
• aplikacja nie będzie dokładnie przetestowana na każdym możliwym poziomie
• utrzymanie aplikacji będzie mniej elastyczne - z uwagi na gorszą wydajność i nieprzewidzenie potencjalnych zagrożeń, koszty utrzymania infrastruktury serwerowej mogą być droższe i trudniejsze w utrzymaniu

Przyjęte założenia

Gdy przychodzisz do wykonawcy usługi z dobrze przemyślaną i szczegółową dokumentacją, taką jak specyfikacja funkcjonalna i techniczna, możesz zakładać, że podczas wyceny założy on realizację dokładnie takiego zakresu. Co jednak, gdy nie posiadasz dokumentacji, a twoje założenia to wyłącznie prosty brief lub zbiór ogólników? W takim momencie, profesjonalny wykonawca powinien zaoferować Ci najpierw warsztaty projektowe i etap analizy, które pozwolą poukładać Twój pomysł i doprecyzować szczegóły projektu. W innym przypadku, otrzymana oferta może być bardzo mocno szacunkowa, tzw. ballpark estimate i znacząco (nawet kilkunastokrotnie) zmienić się, gdy szczegóły zostaną ustalone lub finalnie otrzymasz projekt, który w ogóle nie spełnia Twoich oczekiwań. Każda firma, a nawet każdy programista, gdy nie opiera się na precyzyjnych założeniach zawartych w dokumentacji, przyjmuje własne założenia, jak dana funkcjonalność powinna wyglądać i działać.

Najlepiej zobrazować to prostym przykładem. Gdy realizując projekt, w założeniach wpiszesz "komunikator umożliwiający rozmowę pomiędzy użytkownikami" i nie określisz żadnych szczegółów to firma realizująca projekt może założyć:

1. Pojedyncze roboczodni pracy na bardzo uproszczony moduł umożliwiający prostą, choć małą wygodną wymianę wiadomości pomiędzy pojedynczymi użytkownikami, bez żadnych statystyk, logów, opcji moderacji czy innych funkcjonalności dodatkowych.
2. Wiele miesięcy pracy całego zespołu nad rozbudowanym komunikatorem o wysokiej wydajności, jak np. Messenger.com, z wieloma dodatkowymi możliwościami, np. wyszukiwanie, emotikony, cytowanie, przesyłanie wiadomości dalej, kasowanie wiadomości, wyciszanie, przesyłanie zdjęć, GIFów nagrywanie i wysyłanie audio, rozmowy video itp. A także zaawansowanym panelem administracyjnym, pozwalającym zarządzać całą komunikacją.

Przedstawiony przykład opisuje skrajne przypadki, ale w obu na koniec otrzymasz "komunikator umożliwiający rozmowę pomiędzy użytkownikami". Czas i koszty realizacji, a przede wszystkim efekt końcowy będą jednak diametralnie inne.

Innym ważnym czynnikiem, gdzie przyjęte założenia mają ogromny wpływ to wybór bazowych rozwiązań i technologii. Wspomniany komunikator może być napisany w przemyślany sposób i solidnie od podstaw, a może także zostać zrealizowany na darmowym rozwiązaniu niskiej jakości i nieznacznie zmodyfikowany pod założenia projektowe. Dobrym przykładem jest tutaj napisanie dedykowanego komunikatora na silniku CMS WordPress z darmowymi pluginami. Jak najbardziej się tak da, ale rozwiązanie te jest dalekie od profesjonalnych praktyk. Oba rozwiązania na pierwszy rzut oka będą działać tak samo, ale gdy tylko przyjdzie moment rozbudowy komunikatora lub skala jego działania się zwiększy (więcej użytkowników zacznie ze sobą pisać), to może się okazać, że zastosowane rozwiązania architektoniczne, dług technologiczny oraz słabej jakości kod źródłowy sprawi, że dalszy rozwój komunikatora będzie praktycznie niemożliwy lub nieopłacalny. Aby sprostać nowym wymaganiom biznesowym, trzeba będzie komunikator napisać od nowa, z zachowaniem całkiem innego, bardziej profesjonalnego podejścia. Warto tutaj również wspomnieć, że samo bezpieczeństwo działania może być na niewystarczającym poziomie i nie mamy żadnej gwarancji, że nie dojdzie do ataku hakerskiego lub innego wycieku danych. Pozorna początkowa korzyść w postaci taniego projektu, zazwyczaj szybko okazuje się rozwiązaniem dużo droższym i stratą czasu. W dodatku narażamy się na ryzyko niewłaściwego działania, a co za tym idzie, utraconą reputację projektu i firmy.

Procesy projektowe

Innym istotnym aspektem są także procesy. Im większa firma, tym jest bardziej uporządkowana procesowo. Każdy ułożony proces z kolei sprawia, że firma jest mniej chaotyczna, a proces tworzenia oprogramowania opiera się o przestrzeganie ściśle określonych reguł, które pozwalają na zbudowanie dużo lepszej jakościowo aplikacji.

Procesy to również dodatkowe koszty, które ponosi firma, dlatego stąd założenie, że marża takiej firmy jest niższa - firma inwestuje w siebie, aby być lepsza. Wiele ofert nie zawiera także codziennych krótkich spotkań programistów z Tech Leadem oraz Project Managerem, na których wspólnie poruszają zauważone problemy, dyskutują o wizji projektu, najlepszych rozwiązaniach - czego brak może mieć fatalne skutki w dalszej przyszłości projektu. Podobnie jest z procesem wytwarzania dokumentacji projektowej - wiele firm nie uwzględnia tego w swoich procesach wytwarzania oprogramowania, a dokumentacja to ważny element. Gdy przyjdzie moment na dalszą rozbudowę projektu lub wdrożenie kogoś nowego, skutki jego braku będą wtedy bardzo kosztowne i narażone na powstawanie błędów w funkcjonowaniu oprogramowania.

Podsumowanie

Gdy otrzymana wycena jest droższa od pozostałych, zastanów się, czy pozostałe oferty na pewno zawierają to samo. Dopytaj szczegółowo, czy uwzględniają takie osoby jak PM, TL w projekcie i jeśli tak - to na jak duży angaż.Zapytaj również o proces testowania - czy rozwiązanie zostanie należycie przetestowane przez dedykowane osoby i w jaki sposób te testy będą wyglądać. Jeśli nie było specyfikacji, a Twoje założenia są ogólne, koniecznie dowiedz się, jakie założenia zostały przyjęte, co realnie otrzymasz i dlaczego w takiej sytuacji wykonawca nie oferuje Ci ani warsztatów, ani etapu analizy.

Dopytaj także, czy firma posiada odpowiednie procesy jakościowe w zespole, jak i w całej organizacji. To wszystko może uratować Cię przed błędnym wyborem i stratą czasu, jak i pieniędzy. Doświadczona firma, dostarczająca usługi na wysokim poziomie, bez problemu szczegółowo udzieli Ci informacji i przedstawi cały proces. Im bardziej szczegółowo dopytasz, tym będziesz miał większą świadomość i pewność, że podejmiesz dobrą decyzję - czy to jednak decydując się na tańszą ofertę, jak i zarówno decydują się na droższą.

Najważniejszy jest Twój biznes i by działał on stabilnie. Koniecznie więc przemyśl, czy jeśli otrzymana droższa oferta, mimo wszystko mieści się w założonym przez Ciebie budżecie, to czy warto zaoszczędzić, wybierając tańszą ofertę. Być może będzie to tańsze tylko pozornie - na pierwszym etapie, a w dłuższej perspektywie czasowej koszty mogą okazać się znacznie większe, niż przy wyborze początkowo droższej oferty, która pozwoli na stworzenie stabilnej aplikacji i dużo większą elastyczność jej utrzymania i rozwijania w przyszłości.