W tym odcinku omawiam różne rodzaje usług, które możesz zrealizować w branży IT w zróżnicowanych budżetach – od godziny aż po 10000 godzin!

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 28. Co otrzymasz w godzinę, a co w 10000 godzin od specjalistów IT? Jedną z większych trudności w prowadzeniu biznesu polegającego na wytwarzaniu oprogramowania jest uświadomienie klientom jaki jest jego koszt i z czego on wynika. Nie chodzi oczywiście o taką bezpośrednią przyczynę, bo w naszej branży, w branży software house’ów, wiadomo, że wynika ona przede wszystkim z kosztów pracy specjalistów, a nie na przykład, nie wiem, surowców, amortyzacji drogich maszyn, wynajmu hal, itd., więc w pewnym uproszczeniu – bo oczywiście pewne dodatkowe koszty są, jak najbardziej – natomiast w pewnym uproszczeniu koszt projektu w naszej branży możemy rozumieć jako w dużej mierze iloczyn stawki, stawek specjalistów, w tym oczywiście programistów, pomnożonych przez czas potrzebny na realizację.

I o ile o stawkach, no, można rozmawiać, można dyskutować i kto jaką chce robić marżę, ile zarabiają programiści, programistki w konkretnych technologiach to dyskusja, no, może nie jest łatwa, nie zawsze jest łatwo przekonać klienta, ale przynajmniej zasada jest prosta: jest jakaś stawka, jest jakaś, powiedzmy, przeciętna stawka w branży, jest jakaś marża, więc no, zasada przeliczania jest łatwa. Dużo trudniej tłumaczy się za to czas potrzebny na realizację oprogramowania, czyli ten drugi czynnik w naszym mnożeniu, bo wytwarzamy, tworząc programowanie, wytwarzamy coś, no, niematerialnego. Tutaj sporo zależy od tego jak bardzo od podstaw tworzone jest oprogramowanie. Taką jedną z częstszych przyczyn dlaczego zdarzało nam się w przeszłości przegrywać deale, tak, przegrywać jakieś kontrakty jest, była sytuacja kiedy wykonawca, konkurent nasz w danym postępowaniu miał już doświadczenia w podobnej branży i na przykład miał część projektu, de facto, zrealizowaną i mógł wlicencjonować taką część klientowi, co po prostu z reguły wychodziło taniej niż tworzenie tego od zera. Natomiast nawet jeżeli nie mamy takiej sytuacji i trzeba stworzyć projekt jednak właśnie od podstaw to trudno jest osobom spoza branży zrozumieć dlaczego właściwie stworzenie takiej czy innej aplikacji mobilnej, webowej, chmurowej zajmuje właśnie tyle i wcale się temu nie dziwię. Czasami można znać się na technologii a i tak na przestrzeni lat zmieniają się one tak szybko, że mimo sporego doświadczenia można się zdziwić, jeżeli akurat jakiejś nowej technologii nie śledziło się w ostatnich latach ze szczególną uwagą.

Po tym dość długim chyba wstępie pozwolę sobie przejść do meritum tego odcinka, czyli chciałbym przybliżyć ci meandry wyszacowań godzinowych. Natomiast w dość nietypowy sposób. Ostatnio w Makimo zastanawialiśmy się jak rozjaśnić obraz wycen w sposób, który można łatwo zapamiętać i doszliśmy do wniosku, że nie będziemy mówić o wycenach w stylu 200, 300, 500, 1200 godzin, bo są to wartości takie no może trudne do zapamiętania, trudne do szybkiego takiego intuicyjnego zrozumienia, dlatego postanowiliśmy zacząć rozmawiać o wartościach będących, de facto, rzędami wielkości. Ustaliliśmy więc co da się zrobić w czasie jednej godziny, 10 godzin, 100, 1000 i 10000 godzin. Oczywiście istnieje ogromna przestrzeń pomiędzy tymi progami, można powiedzieć. Tak naprawdę nie mamy też na myśli stricte wartości 1, 10, 100 godzin, co bardziej właśnie chodzi o rząd wielkości kilku, kilkudziesięciu, kilkuset, kilku tysięcy, czy wreszcie i nawet, no, kilkudziesięciu tysięcy godzin, natomiast takie podejście powinno ułatwić zrozumienie różnych procesów jakie wiążą się z wytwarzaniem oprogramowania i co faktycznie można w takich przedziałach, takich rzędach wielkości godzin osiągnąć.

Na początek zaczniemy od odrobiny matematyki, ale naprawdę niewielkiej; przeliczmy te wartości godzinowe na jednostki, którymi, zwłaszcza przy większych projektach z reguły się posługujemy. No cóż, godzina to godzina. Tutaj za bardzo nie ma o czym gadać. 10 godzin to, zwróćmy uwagę, nieco ponad dzień pracy, a 100 godzin to 2,5 tygodnia pracy jednej osoby. Przy tych kolejnych rzędach wielkości możemy je oczywiście przeliczać na pracę jednej osoby, ale to są z reguły już takie projekty, przedsięwzięcia, które angażują więcej osób, więc tak przykładowo: 1000 godzin to będą, z grubsza, dwa miesiące pracy zespołu 3-osobowego. Natomiast 10000 godzin można ułożyć na wiele sposobów, natomiast przykładowo jest to rok pracy dla pięciu osób. W Makimo mamy doświadczenie w tych wszystkich wolumenach, od godziny aż po rzędy wielkości 10000 godzin, choć, no, niekoniecznie akurat w takich proporcjach zespołowych, bywa różnie, ale faktycznie przy tych dużych projektach można dynamicznie układać zespół. Ta budowa, kompozycja zespołu może się też zmieniać – oczywiście w czasie.

No to zacznijmy od godziny – w godzinę, naturalnie, nie da się zrobić cudów. Może gdyby zrobić sobie taki challenge, wyzwanie, można by uruchomić stronę na WordPressie, wgrać jakiś motyw graficzny, może zainstalować jakąś wtyczkę jak ktoś się naprawdę zna i się spręży. Natomiast oczywiście trudno myśleć o pojedynczej godzinie, no, czy nawet kilku godzinach w kontekście wykonawczym. Przede wszystkim jest to czas, w ramach którego można przeprowadzić na przykład spotkanie, krótsze bądź dłuższe, które pozwoli na zapoznanie się z jakimś pomysłem biznesowym, technologicznym, z pomysłem, z którym przychodzi klient. Takie spotkanie – ono nie musi trwać godzinę. Czasem trwa i półtorej, i dwie. Tak jak mówiłem, tu chodzi o pewien rząd wielkości. Takie spotkanie pozwala na szybką walidację, weryfikację pomysłu czy dany pomysł ma sens techniczny. Również też może w pewnym zakresie biznesowy. Można na przykład zweryfikować czy przede wszystkim w ogóle da się osiągnąć pewne efekty techniczne. Miałem kiedyś sytuację – tutaj z uwagi na może nawet nie podpisaną NDA, ale zaufanie znajomego, też klienta, nie będę mówił dokładnie czego dotyczyło, ale chodziło o wykonanie pewnej aplikacji, która była związana z dość ciekawym użyciem pewnej możliwości telefonów komórkowych, smartfonów, a konkretnie nawet IPhone’ów. Natomiast okazało się, że dostęp do pewnej funkcji smartfona był co prawda możliwy z poziomu aplikacji, ale nie był możliwy w tle. W tle, czyli gdy dana aplikacja nie działa tylko, no, korzystamy na przykład z innej aplikacji. No i niestety, chociaż w zasadzie, gdyby się zastanowić, to technicznie nie byłoby problemu, żeby napisać aplikację, nie byłoby problemu z zaprogramowaniem, ale niestety jakby ograniczenia formalne sprawiły, że musiałem temu koledze powiedzieć, że no przynajmniej w tej chwili aplikacja nie jest możliwa do zrobienia, bo formalnie, od strony takiej formalnej, nie jest to możliwe. Z drugiej strony była też sytuacja bardziej pozytywna, gdy znajoma, właścicielka siłowni, przyszła do mnie z prośbą o wycenę, no, modułu, aplikacji do zrobienia, która, z tego co pamiętam, miała umożliwić zapis na zajęcia grupowe. Po krótkiej rozmowie okazało się, że ta moja znajoma korzysta już z pewnego oprogramowania do obsługi siłowni w innym zakresie i tak naprawdę to to oprogramowanie ma już w standardzie tę funkcję tylko ona była w pewien taki sposób ukryta i w zasadzie nawet nie musiała dopłacać za włączenie tej funkcji owa koleżanka, więc dzięki takiej krótkiej rozmowie, to nawet nie była godzina, okazało się, że mogła zaoszczędzić; zamiast w ogóle poruszać temat napisania dla niej dedykowanego rozwiązania.

10 godzin, czyli nasz kolejny próg; od razu wyjaśnię, że to od strony technicznej dalej nie jest dużo. Na 10 czy kilkanaście nawet, małe kilkadziesiąt, natomiast, no, wyklikanie jakiegoś prostego prototypu w narzędziach do prototypowania. Być może tutaj, chociaż też uczciwie powiem, że nie jest to na ten moment obszar mojej jakiejś szczególnej znajomości, ale wyklikanie prostego rozwiązania typu No-Code, ale też raczej w charakterze prototypu powinno być możliwe. Natomiast z pewnością 10 godzin, czy kilkanaście godzin to dobry czas, aby na przykład w gronie jednej, a nawet dwóch osób, choćby w konfiguracji takiej jak analityk plus specjalista od User Experience, czy specjalista UX w połączeniu z konsultantem technologicznym, przeprowadzić na przykład pierwszy warsztat projektowy i spisać wnioski. To jest, można powiedzieć, taka rozszerzona wersja tej jednej godziny, ale już w te 10 czy kilkanaście godzin, co dalej w sumie jest tak naprawdę niewielkim wydatkiem, jesteśmy w stanie doprecyzować potrzeby, wytworzyć pewne pierwsze efekty takie, powiedzmy, deliverables mówi się po angielsku, czyli pewne konkretne wymierne efekty – nie tylko rozmowę, ale jakąś postać dokumentacji, które mogą na przykład posłużyć do przygotowania dokładnej oferty lub przy konstruowaniu zapytania ofertowego w dużej firmie, czy też organizacji publicznej.

Przy 100 godzinach wchodzimy w ten rząd wielkości, który daje już możliwość stworzenia pewnych bardzo uproszczonych wersji oprogramowania, tzw. Proof of Concept. 100 godzin to może i jeszcze mało, powiedziałbym, że bliżej 160-200, taki roboczomiesiąc to już jest naprawdę w miarę przyzwoita wartość jeśli chodzi o taki rodzaj konceptu, pomysłu do implementacji, ale jeżeli dysponujemy dobrą dokumentacją, na przykład wytworzoną w wyniku tych wcześniejszych kroków, to już 100 godzin na stworzenie takiego Proof of Concept, zwłaszcza przy użyciu jakichś gotowych narzędzi powinno pozwolić na wytworzenie czegoś, co da się pokazać choćby na w ramach jakiegoś pitcha na konferencji startupowej, czy na spotkaniu w korporacji celem pozyskania dalszych funduszy na rozwój. Proof of Concept to, jak sama nazwa wskazuje, pewien dowód, studium wykonalności pewnego projektu, pewnego konceptu. To nie jest coś co można już uruchomić, co będzie działać. Natomiast, no, jest to na przykład dobry koncept, dobra forma do pokazania na przykład obsługi jednego, głównego procesu biznesowego bez przewidywania, bez obsługi wszystkich pobocznych scenariuszy, np. możemy tutaj rozważyć proces zamawiania produktów w jakimś nowym sklepie internetowym, chcemy przedstawić nową ścieżkę zamawiania – pokazujemy właśnie w ramach Proof of Concept taką ścieżkę jakby to faktycznie by wyglądało, natomiast nie skupiamy się na obsłudze wszystkich możliwych błędów płatności, nieprawidłowego adresu, weryfikacji stanów magazynowych, tylko pokazujemy ten główny, skuteczny przypadek dzięki czemu na przykład decydenci czy inwestorzy mogą stwierdzić „OK, to wygląda fajnie, możemy w to iść, teraz można to dorobić”. Równie dobrze, skoro już jesteśmy przy e-commerce, można by zrobić na przykład jakieś prościutkie demo aplikacji mobilnej, która pozwoli na wdrożenie nowej formy płatności. Wtedy też nie tworzymy całego e-commerce’u tylko pokazujemy bardzo konkretny proces w formie na przykład nowej aplikacji mobilnej, ale powiązanej z już istniejącym systemem.

1000 godzin; no tutaj aż chciałem troszkę zatrzeć ręce, ale to mogłoby dziwnie zabrzmieć w podcaście. To już jest taki przyzwoity budżet: 1000, no rząd wielkości ponad 1000, 2000 godzin, które zdecydowanie pozwala już na stworzenie rozwiązania w pełni działającego, aczkolwiek też w pewien sposób o ograniczonym zakresie. Najczęściej używa się takich budżetów do stworzenia tzw. MVP – Minimum Viable Product. Czym różni się MVP od PoC, od Proof of Concept? Różnica jest taka, że Proof of Concept pokazuje, że w ogóle coś da się zrobić, natomiast MVP jest już, co do zasady, w pełni działającym rozwiązaniem tylko w ograniczonym zakresie. Jakby taką zasadą podstawową, którą powinno się kierować przed tworzeniem MVP – czy to w startupach, czy znowu rozwijając na przykład jakiś nowy produkt, nowa usługę już w istniejących, dużych firmach jest to, aby ten MVP dawał klientom bardzo konkretną wartość; aby, krótko mówiąc, kupując, czy otrzymując dostęp do tegoż MVP oni mieli pewną korzyść. Ona nie musi być rozbudowana, to nie musi być rozwiązanie, które nawet w swojej klasie będziemy pojmować jako kompletne, ale oni powinni mieć już pewną realną wymierną korzyść ze stosowania tego oprogramowania i oczywiście obietnice rozwoju w przyszłości. No ale, że przy tym rzecz jasna pamiętać, że po wytworzeniu takiego oprogramowania konieczne jest jego dalsze utrzymanie i to też będzie pewien koszt. On z reguły już zauważalnie mniejszy. No ale założenie jest takie, że jeżeli oprogramowanie daje wartość, jest wytworzone i możemy pozyskiwać klientów to i koszt takiego wsparcia powinien być pokryty z przychodów klientów lub no chociaż z inwestycji inwestorów, którzy są zainteresowani wsparciem danego rozwiązania.

No i wreszcie dochodzimy do 10000 godzin. Jeżeli zacierałem ręce przy poprzednim punkcie to te 10000 budzi piękny uśmiech, mam nadzieję, że piękny, na mojej twarzy, bo no to jest budżet nie tylko na stworzenie, wdrożenie i utrzymanie produktu przez jakiś czas, ale tu w zasadzie przy projektach takiej skali mówimy o utrzymaniu dużego zespołu na lata. To naprawdę są takie najfajniejsze deale, najfajniejsze projekty i często też utrzymanie takiego projektu, utrzymanie zespołu u siebie wiąże się z istnieniem też zespołu po stronie klienta, bo przy takiej skali wydatków, już nie ważne czy mówimy o korporacji czy o startupie to inwestycja staje się zbyt duża, aby projekt traktować w jakikolwiek sposób eksperymentalnie, no bo przy MVP jeszcze jest to gdzieś tam możliwe. No i właśnie – projekty tego typu to już z reguły są projekty realizowane, finansowane przez duże korporacje. W przypadku startupów, w przypadku firm takich teoretycznie mniejszych, o mniejszych przychodach to raczej mówimy o sytuacji, w której startup zaczyna skromnie, a przez lata rośnie, staje się scaleup’em, czyli takim już dojrzałym startupem no i po prostu cały czas potrzebuje tego developmentu, przez co można powiedzieć, że nasz zespół, nasz udział rośnie razem z klientem. Zwrócę tylko uwagę, że ja tak mówię o startupach i o korporacjach; są też firmy, oczywiście, pośrodku i też zdarza się, że rozwój oprogramowania – są takie w sumie najciekawsze historie, kiedy oprogramowanie rośnie razem z firmą. Dynamiczny rozwój firmy wiąże się z dynamicznym rozwojem oprogramowania no i też pośrednio dynamicznym rozwojem dostawcy. Natomiast z mojego doświadczenia to są takie, powiedzmy, projekty, które nie jest łatwo zdobyć, no bo też trudno przewidzieć, który, na przykład, mniejszy projekt u małego klienta będzie rósł tak dynamicznie, razem właśnie z klientem, no bo trudno też przewidzieć organiczny rozwój naszych klientów.

No i dotarliśmy do końca; kolejna potęga 10-tki, czyli 100000 to już, no to oczywiście takie projekty też mogą się zdarzać, ale też nie będę tutaj w tym momencie postulował, że mam na ich temat jakąś większą wiedzę. Takimi projektami się nie zajmowaliśmy, natomiast jednocześnie powtórzę tak na zakończenie, że nie należy tutaj przywiązywać się do tej jedynki z przodu. Mówimy o rzędzie wielkości, zwyczajowo pokazuje się, przedstawia raczej właśnie w kontekście dziesiątki, jedynki z przodu. Natomiast, oczywiście, te wielkości godzinowe przemnożone przez jakieś tam stawki pokazują o jakiej wielkości wydatków mówimy w przypadku poszczególnych usług i projektów informatycznych.

Mam nadzieję, że ten odcinek pomoże ci lepiej zorientować się w gąszczu wycen i kosztów w branży IT, zwłaszcza w branży wytwarzania oprogramowania. Zachęcam oczywiście do kontaktu, jeśli chcesz zrealizować projekt i nie wiesz, jak zabrać się do tematu wyceny, to chętnie pomogę, przyjrzę się. W końcu to jest mój chleb powszedni.

Na dziś to już wszystko. Bardzo dziękuję za uwagę, kłaniam się nisko i do usłyszenia.

KONIEC