Ile kosztuje portal? Tyle samo co dom. Dokładnie.

www portal serwis

Natrafiłem ostatnio na jednej z grup dyskusyjnych poświęconych startupom na dyskusję wywołaną słynnym i nieśmiertelnym pytaniem „ile może kosztować zrobienie portalu takiego jak xxx, tylko dla innej branży”. Tym razem xxx było przykładem z kategorii tych dużych, rozwijanych latami. W dyskusji tej przewinęło się praktycznie wszystko, co sprawia że na rynku dedykowanego oprogramowania, oferty potrafią się różnić pomiędzy wykonawcami ceną nieraz kilkunastokrotnie, a klient próbując dokonać wyboru dostaje kompletnego kręćka. Zwłaszcza, jeśli nie ma możliwości porównać faktycznej zawartości tego co stoi za ofertą, bo nie ma dość doświadczenia w realizacji tego typu projektów albo wiedzy informatycznej.


Czemu piszę, że wszystko? Mamy ogólnie postawione pytanie o cenę (swego czasu często dostawaliśmy w Softhis zapytania brzmiące „ile by kosztował taki Grupon”, dwa razy poprzedzone NDA, serio). Potem uczestnicy zaprezentowali kompletny rozstrzał podejść. Od „jak najtaniej” i „załatwimy to opensource’m”, po rozmowy o systemowym testowaniu i dokumentacji developerskiej. Były próby zdefiniowania zakresu prac na podstawie oglądania frontu innej aplikacji, było że specyfikacja, to droga fanaberia software house’ów, było że „makiety stykną” i owszem, także że „makiety to jednak za mało”, bo aplikacja ma jednak jakiś back-end i trudno go makietami opisać.

Zgodnie z przepisem na klęskę – nie ma przedstawionego przez pytającego jego własnego celu biznesowego i sposobu jego realizacji, czyli co jest jego własnym biznesowym wyróżnikiem uzasadniającym pisanie dedykowanej aplikacji. Zresztą nie jest nawet napisane dla jakiej branży, bo na pewno złowrogie siły tylko czekają, żeby przechwycić pomysł i błyskawicznie zrobić MVP w garażu. Trzeba najpierw „endieja”. Mowa o gwarancji, SLA, czasach reakcji, API, integracjach, pokryciu testami, jakiejś sensownej fazie analitycznej, to zdecydowanie nie na miejscu. Nikogo zatem nie powinno zdziwić, że w dyskusji pojawiły się też liczby, zgodnie z przewidywaniami od 10K do 1 mln.

I niestety dokładnie tak wygląda wiele procesów wyboru dostawcy dedykowanego oprogramowania. Przez 11 lat pracy w software house widziałem ich setki i dyskusja ta była naprawdę esencją. Na końcu klient nie mając możliwości zweryfikować gdzie leży jakość, jakiej dokładnie potrzebuje, nie analizując ze swojej strony jaki jest naprawdę długofalowy cel projektu itp, dokona wyboru patrząc na cenę, więc ceną będą walczyć ze sobą firmy, które mają najdroższe na rynku zasoby ludzkie. Skupią się zatem na wykorzystaniu elementów gotowych, obetną testy, dokumentację i wsparcie powdrożeniowe. Ale za to potem wszyscy pośmieją się z przetargów publicznych i 100% ceny w budowie autostrad i tego, że dalej są strasznie drogie.

Niestety – nie da się odpowiedzieć sensownie na takie pytanie (ile kosztowałby taki portal tylko trochę inny) – bo to pytanie „ile kosztuje dom”. Czy podejmowalibyśmy decyzję o budowie domu w taki sposób? Nie da się wycenić dobrze projektu informatycznego trwającego kilka-kilkanaście osobomiesięcy mając także kilka stron briefu do dyspozycji, albo żądanie wyceny na jutro albo pojutrze. Nie da się też dać dobrej odpowiedzi, jeśli zamawiający w wymaganiach postawi wyłącznie opis funkcjonalności. Bo tę funkcjonalność można naprawdę osiągnąć w różny sposób. Dopiero to jak będzie tworzona, w jakiej jakości, tworzy zbliżoną płaszczyznę na jakiej mogą rywalizować świadomi dostawcy. I właśnie to, jak jest tworzona, decyduje o kosztach użytkowania i rozwoju. A one będą w perspektywie kilku lat większe niż koszt wytworzenia.

Osobnym tematem jest niechęć do analiz i tworzenia szczegółowych specyfikacji, takich zawierających i makiety i scenariusze użycia i dobrze zdefiniowane funkcje – jest jakaś naiwna wiara, że magia słowa Agile pozwala ruszać z wylaniem fundamentów przed decyzją ile właściwie pięter i czy hotel czy apartamentowiec. Nie na tym Agile polega. Tak, planowanie zajmuje to czas. Niesie ze sobą koszta, ale na końcu dzięki temu poświęcasz sumarycznie mniej czasu i pieniędzy. I gdy mowa o budowlance jest to jasne, tylko ten software to przecież nowoczesny jest, więc takie skandalicznie skostniałe uwarunkowania go nie dotyczą. Kiedyś jeden znajomy podsumował to tak: „rok kodowania pozwolił nam zaoszczędzić dwa tygodnie researchu”.

Tworzenie oprogramowania dedykowanego jest drogie. Drogi jest czas dobrych programistów, warto jest zatem używać go sensownie. Aby to było możliwe należy mieć dobry plan, trzeba wiedzieć czego się dokładnie chce, żeby mało rzeczy pisać wielokrotnie i poprawiać i zmieniać. Gdy tworzymy projekt naszego oczekiwanego rozwiązania, powinniśmy go tworzyć w perspektywie nie tylko startu ale i celu do osiągnięcia później. Wtedy możemy mówić o zaplanowaniu i MVP i stopniowej realizacji i rozwoju. Ale ruszanie bez planu, to zawsze, co najmniej, bardzo duże ryzyko niepowodzenia. Niestety wciąż wiele firm traktuje projekty budowy dedykowanego oprogramowania, jakby to było coś typu szybkiej akcji z świata reklamy, ASAP rządzi, a na software house wciąż często mówi się „agencja”. To błąd. Jeśli chcemy dobrze wybrać dostawcę dedykowanego oprogramowania, to musimy stworzyć równe pole rywalizacji dla tych firm, które naprawdę rozumieją i nasz cel biznesowy oraz to jak tworzyć dobry kod. A tego nie da się zrobić na ASAPIE.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn