#14 — Software nie ma wartości? / Michał Moroz (Makimo)

W tym odcinku po raz pierwszy rozmawiam z gościem – Michałem Morozem, CIO z Makimo – o wartości oprogramowania – czy oprogramowanie w ogóle ma wartość?

💡
Spodobał Ci się ten odcinek? Zasubskrybuj mój podcast na swojej ulubionej platformie i podziel się nim ze znajomymi!

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.

Ten odcinek jest odcinkiem wyjątkowym z dwóch powodów - po pierwsze, już nie tylko możecie mnie posłuchać, ale także i zobaczyć z uwagi na pewne inwestycje, które poczyniliśmy w infrastrukturę. Jest to pierwsza okazja, w której nagrywamy nie tylko audio, ale i wideo. A druga ważna sprawa - zacząłem, że zobaczycie i posłuchacie mnie - ale tak naprawdę zobaczycie i posłuchacie jeszcze mojego gościa, bo jest to pierwsza taka okazja, w której nie tylko ja się będę wypowiadał, ale będziemy rozmawiać. A dokładniej będziemy rozmawiać we dwóch. Moim gościem dzisiaj jest Michał Moroz.

Michał jest moim przyjacielem ale też wspólnikiem i partnerem w Makimo, jest naszym Chief Innovation Officerem, czyli odpowiada za innowacje, za usprawnianie procesów, za to, aby firma rozwijała się w jak najlepszym kierunku. Prywatnie Michał jest też niezwykle zaangażowany w różne działania, różne organizacje; był członkiem NZS, zrzeszenia studentów, jest członkiem organizacji Toastmasters. A nawet poznaliśmy się w dawnych czasach w liceum na zajęciach chóru szkolnego, więc dość nietypowo jak na dwóch informatyków. Michał, witam cię bardzo serdecznie.

Michał Moroz: Dzięki wielkie, Krzyśku, za wprowadzenie i witam wszystkich naszych słuchaczy.

Dodam tutaj, że jeśli chodzi o temat odcinka będziemy dzisiaj rozmawiać o wartości oprogramowania, o tym czy ta wartość istnieje, bo Michał napisał ciekawy artykuł, w którym podjąłeś taką tezę, że oprogramowanie nie ma wartości. I w sumie tutaj od tego może zacznijmy, bo prowadzimy ten biznes już 12 lat prawie, w zasadzie nagrywamy tuż przed 12. rocznicą, więc, gdy widzowie, słuchacze zobaczą, usłyszą, to będzie już 12 lat. Michał, powiem szczerze, jak to jest, że prowadzimy tę firmę 12 lat, świadczymy usługi i dostarczamy coś, co teoretycznie nie ma żadnej wartości? Oczywiście, jak widać, klienci jednak płacą nam za nasze usługi, więc chyba jednak jakąś wartość w tym widzą. Jak to jest?

MM: Krzyśku, dobrze, że poruszasz ten temat, ponieważ mamy tutaj pewną niejednoznaczność dotyczącą samego pojęcia wartość. Bo wartość usługi z jednej strony jest narzucona, m.in., przez waszą firmę czy przez wszystkich usługodawców. Ona wynika, m.in., z kosztów, jakie zostały poniesione, z tego, co trzeba zakupić, żeby tę usługę wykonać. Ale jednocześnie wykonanie usługi służy czemuś dla wszystkich naszych klientów i wszystkich klientów wszelkich usług, które możemy sobie wymyślić. Jeżeli wymyślimy sobie np. usługę pójścia do warsztatu samochodowego, ponieważ chcemy naprawić nasz samochód, to nie sama usługa jest warta, tylko to, że nasz samochód może jeździć. I teraz przełóżmy sobie to na kontekst tych rzeczy, które mamy dookoła siebie i którymi się posługujemy. Weźmy pod uwagę chociażby ten oto zszywacz. Powiedz mi, jaka jest wartość tego zszywacza?

Kosztował może, nie wiem, 10-20 złotych.

MM: A jaka jest wartość tego zszywacza dla ciebie?

Jeżeli nie mam żadnych dokumentów do spięcia, to w zasadzie nie ma dla mnie za bardzo wartości. Ale z kolei, gdybym miał uporządkować dokumenty, to podejrzewam, że byłby praktycznie bezcenny.

MM: Dokładnie. Jeżeli używasz tego zszywacza, jak zresztą każdego narzędzia czy każdego przedmiotu, z którego korzystasz, to ten zszywacz ma dla ciebie dużą wartość, ponieważ możesz z nim coś zrobić. Możesz dokonać pewnej czynności, którą chcesz wykonać, np. posegregować swoje własne dokumenty. I tak samo jest, chociażby, z naszymi samochodami. Samochody służą nam do tego, żebyśmy się transportowali nimi. Bardzo rzadko zdarza się samochód, który posiada wartość samą w sobie; są to stare odrestaurowane samochody. I tylko nieliczne z samochodów posiadają jakąś wartość, która rośnie z czasem. A wszystkie pozostałe samochody w momencie ich kupienia - okej, możemy jakoś zmierzyć ich wartość tym kosztem, który poczyniliśmy, kupując je, ale ta wartość zaczyna spadać. I teraz przekładając to na poziom oprogramowania, my, jako kupujący oprogramowanie, nigdy nie kupujemy oprogramowania dla samego siebie. Nie kupujemy oprogramowania po to, żeby ono stało i się kurzyło, tylko po to, żebyśmy mogli zacząć z niego korzystać i robić coś, czego nie byliśmy w stanie robić do tej pory. I teraz pojawia się kilka takich zastosowań, które możemy przypisać oprogramowaniu; jedno oprogramowanie np. zbiera dane, drugie oprogramowanie pozwala nam wykonać jakąś czynność, której nie potrafiliśmy wykonać wcześniej, trzecie pozwala nam wyciągnąć nowe, nieznane dotąd wnioski z tego, co już mamy, np. z tych danych, które zebraliśmy. I dopiero wtedy, kiedy oprogramowanie jest używane - najlepiej od momentu startu, czyli od momentu, kiedy to oprogramowanie dostajemy - jeżeli ono jest używane, jeżeli my je wykorzystujemy i jeżeli z pomocą tego oprogramowania zbieramy te dane, analizujemy je, wyciągamy odpowiednie wnioski, podejmujemy decyzje biznesowe, dopiero wtedy możemy powiedzieć o jakiejkolwiek wartości płynącej z oprogramowania.

Tutaj w zasadzie przypomniał mi się taki jeden wyjątek potwierdzający regułę, bo w czasach początków aplikacji mobilnych na iPhone’a pamiętam, że była taka apka za 1000 dolarów, która wyświetlała tylko obrazek i była po prostu dowodem, że kogoś stać na taką aplikację. Ale oczywiście to był taki żart, zresztą zdaje się, że oni usunęli tę aplikację, natomiast faktycznie 99,99% aplikacji to są takie aplikacje, które muszą udowodnić, de facto, że są przydatne i wtedy mają wartość. Właśnie, bo poruszyliśmy temat tej wartości bezwzględnej, natomiast taka druga hipoteza, którą też stawiasz w swoim artykule to jest to, że oprogramowanie również może tracić wartość, że ta wartość z czasem staje się coraz mniejsza. Tutaj bardzo podobały mi się te porównania samochodowe, sam często w rozmowach z klientami lubię ich używać, bo nawet jak ktoś nie czuje oprogramowania, to z reguły z samochodami jest dużo prościej. Właśnie, jeśli chodzi o to, że samochód traci na wartości z każdym rokiem to jest to zjawisko bardzo typowe, to jest wręcz oczywiste. Natomiast mam wrażenie, że przez to, że oprogramowanie jest samo w sobie niematerialne, to jest coś, co funkcjonuje na komputerze - ale właśnie, to nie jest komputer, który jest fizyczny, który może się zepsuć, zakurzyć, spalić - oprogramowanie istnieje w świecie wirtualnym. I teraz przez to klienci, czy też w ogóle osoby, które nie znają się na oprogramowaniu, myślą, że oprogramowanie raz stworzone powinno niczym perpetuum mobile działać w nieskończoność. Z czego wynika to, że oprogramowanie również może się, de facto, zużywać?

MM: Wróćmy jeszcze do tych tematów samochodowych, bo myślę, że one znajdą tutaj dobrą analogię. Wyobraź sobie, że potrzebujesz skorzystać z warsztatu samochodowego, żeby coś naprawić. Idziesz do tego warsztatu i płacisz za usługę, samochód jest naprawiony i w tym momencie możesz tym samochodem jechać. Porównaj sobie to z tym, że masz warsztat, który budujesz samemu, czyli posiadasz jakieś pomieszczenie czy budynek, gdzie możesz zostawić samochód, kupujesz narzędzia, kupujesz też wszystkie potrzebne płyny, oleje, smary i inne rzeczy, które mogą być potrzebne do naprawiania twojego samochodu. I w momencie, kiedy pojawia się problem z twoim samochodem, jesteś gotowy na to, żeby na ten problem zareagować odpowiednio. Tak samo też dzieje się z oprogramowaniem, tzn. ludzie zazwyczaj o oprogramowaniu myślą, że to jest np. takie pudełko typu Excel, kupujemy coś z półki i możemy już od razu tego używać. Ale kiedy mówimy o systemach informatycznych, mamy tutaj trochę inną sytuację, ponieważ wraz z tą częścią, która odnosi się do używania tego oprogramowania mamy jeszcze całą infrastrukturę, którą ktoś musi utrzymywać. Mamy też sytuacje takie, że oprogramowanie nam przestaje z czasem realizować nasze zamierzenia, ponieważ nie dopasowuje się do realiów rzeczywistych, biznesowych, i nie odzwierciedla tego, co faktycznie chcemy zrobić. Z czasem nasze procedury się zmieniają i system informatyczny musi też to odzwierciedlać. Jest dużo różnych przyczyn, dla których dane oprogramowanie może wymagać zmian, a jednocześnie też mogą przyjść czynniki zewnętrzne, np. mówiłeś tutaj o aplikacji na Apple’a, to Apple Store może nam powiedzieć, że aplikacje od tego i tego dnia nie spełniają już wymogów, dopóki nie zostanie coś w nich zmienione, i wtedy trzeba to poprawić. Różne mogą być czynniki, zewnętrzne, wewnętrzne, związane z nieprzystawaniem do rzeczywistości czy np. z regulacjami prawnymi i tak dalej. To wszystko są czynniki, które mogą powodować, że tym oprogramowaniem trzeba się zająć. I kiedy myślimy o tym, że to jest jak z Excelem, który przecież mamy i możemy go używać od razu, to pojawia się taka sytuacja, w której porównujemy jabłka do gruszek. Bo my nie powinniśmy porównywać Excela do systemu informatycznego, który sobie zakupiliśmy, tylko powinniśmy porównywać Excela wraz z komputerem, na którym się on znajduje, wraz z osobą, która, używając Excela jest w stanie coś zrobić dla nas wartościowego. I dopiero ten tercet możemy sobie porównać z systemem informatycznym. Dlatego, podsumowując, oprogramowanie traci wartość, ponieważ to nigdy nie jest oprogramowanie; zawsze to jest oprogramowanie plus infrastruktura, plus metody komunikacji, plus procedury korzystania z tego, plus instrukcje, i plus czynniki zewnętrzne, środowiskowe. Więc nagle tego jest dużo.

Tak, jak wspomniałeś o Excelu, to od razu przypomniał mi się nie jeden system, który tworzyliśmy, gdzie okazywało się, że - to jest częsty przypadek - rozwiążmy problem, dobrze, to zróbmy jakiś arkusz w Excelu. I to na początku jest naprawdę dobre rozwiązanie, przecież my w Makimo czasem korzystamy z Excela czy z Google Sheets po to, żeby rozwiązać proste problemy. Ale potem się okazuje, że np. u jednego z klientów Excel urósł nam do takich rozmiarów, że się nie otwierał po prostu, dane były zduplikowane, niespójne i tak naprawdę dopiero wprowadzenie systemu pomogło rozwiązać te problemy. Więc rozpatrywanie samego Excela i porównywanie go np. do systemu jest faktycznie pewnym problemem.

MM: I zauważ tutaj jedną bardzo ważną rzecz. Kiedy używamy Excela, zrobiliśmy sobie arkusz, ale ktoś musi być odpowiedzialny za wstawienie tego arkusza we właściwym miejscu, za ogłoszenie wszystkim osobom, że to jest ten arkusz i tak na nim pracujemy. Więc jest dużo pracy organizacyjnej, która często jest częścią tych systemów informatycznych, które wymieniają to, co znajduje się w arkuszu Excela.

Właśnie, bo ja tak troszkę zacząłem, a czy mógłbyś przytoczyć przykłady? Bo rozmawialiśmy sobie o tych warsztatach samochodowych, ale może jednak też - biorąc pod uwagę nasze doświadczenia wspólne - moglibyśmy co nieco powiedzieć o przykładach, w których ta wartość oprogramowania czasem maleje z tym czasem. Mógłbyś podać jakieś?

MM: Jasne. Okej, mam taki przykład z początków funkcjonowania naszej firmy - oprogramowanie, które trwało 7-8 lat - jeżeli dobrze pamiętam linię czasową - przy którym byłem zaangażowany w jego tworzenie. Klient potrzebował od nas e-commerce’u, który był nietypowy, bo to jeszcze były czasy, w których e-commerce’y nie były aż tak mocno usługowione jak dzisiaj, bo to były mniej więcej lata 2013, 2014, dzisiaj tych usług jest dużo więcej i jest duża szansa, że ten klient dzisiaj znalazłby sobie usługę, która by mu odpowiadała. W ramach tego, co zbudowaliśmy zrobiliśmy platformę e-commerce’ową, która była bardzo otwarta na to, co można było na niej zrobić, w szczególności w kwestii marketing automation. Byliśmy przygotowani praktycznie na bardzo dużo możliwości, z których można byłoby skorzystać. Platforma zaczęła działać, więc tutaj jest bardzo duży plus tego, że od momentu, kiedy platforma wystartowała jej wartość zaczęła też rosnąć. Ale jednocześnie koszty zmian zaczęły również rosnąć. I to jest pewna ważna kwestia, którą warto też wziąć pod uwagę - że jeżeli w ramach prac utrzymaniowych, jeżeli w ramach zajmowania się tym oprogramowaniem nie dokonujemy pewnych czynności, które są dość rutynowe - chociażby takich przeglądów oprogramowania - to może się okazać, że za kilka lat prosta wymiana czegoś będzie kosztowała troszeczkę więcej niż kosztowała do tej pory. Ale jeżeli ktoś już się nie zgadza w pierwszym momencie, to w tym drugim momencie, kilka lat później może się nie zgodzić tym bardziej. Chyba że ta osoba to przemyśli i że dojdzie do wniosku, że tak, warto jest porozwijać to oprogramowanie. Więc koniec końców wartość samego oprogramowania jak zawsze szybuje w dół. Ale ze względu na to, że to oprogramowanie działało, zarabiało to wartość danych w tym oprogramowaniu i w czynności zakupów dokonywanych balansowała to. Więc dla klienta było to oprogramowanie, które było wartościowe.

Jak tak ciebie słuchałem, to przypomniał mi się taki jeden przykład, którym nawet możemy się pochwalić, bo niestety o części projektów nie możemy mówić zbyt jawnie. Ale pamiętam, jak jeden z pierwszych projektów, które realizowaliśmy dla Ministerstwa Kultury - skądinąd byliśmy wtedy szczęśliwi, bo byliśmy małą firmą i pamiętam, jak zdobyliśmy ten temat z ulicy, można powiedzieć, nikogo nie znając. A dlaczego o nim wspominam? Bo chodziło przepisanie systemu, w którym były opisywane, przedstawiane takie inwestycje związane z kulturą właśnie, i problem polegał na tym, że tych inwestycji było kilkadziesiąt w całej Polsce, ale dodanie nowego obiektu - co oczywiście na przestrzeni lat się działo - wymagało pracy ze strony programistów. To jest pytanie, czy to nie było działanie celowe, natomiast klient, czyli ministerstwo musiało za każdym razem prosić się o interwencję programistów, interwencję dostawcy. A myśmy wdrożyli tam nawet jakiegoś prostego CMS-a, natomiast dzięki temu w zasadzie urzędnik potem, dysponując podstawowymi informacjami, mógł po prostu dodać nowy punkt i on był od razu widoczny na tej mapie tych inwestycji. Więc nawet to w tej małej skali pokazuje, że to oprogramowanie - z tego, co pamiętam, ono było potem jakieś ładne parę lat używane, nie wiem, jak to wygląda teraz, ale to było z dziesięć lat temu. Było to też takie poczucie dostarczenia naprawdę fajnej wartości, w tym przypadku właśnie dla Ministerstwa Kultury.

MM: To jest też ciekawy temat jeżeli pomyślimy sobie w ogóle o wszelkiego rodzaju start-upach. I tutaj mogę też przytoczyć jeden przykład, niestety przykład taki, który może być trochę bardziej przestrogą. Start-up w branży social media, w ramach którego my zajmowaliśmy się zrobieniem części wideo i aplikacji mobilnej. To był bardzo ciekawy start-up pod kątem technologicznym i dla nas, myślę, że był bardzo wartościowym wyzwaniem, ale - i tutaj jest pułapka start-upowa, o której opowiem, przytaczając taki mem. Przeczytałem kiedyś takiego mema, który był po prostu konwersacją na Facebooku. Ktoś prowadzący start-up pytał się: „hej, jakie są drogi pozyskiwania finansowania dla start-upów poza inkubatorami i venture capital?”, na co pierwsza odpowiedź była: „klienci”, kolejna odpowiedź: „ale jak to?”, i kolejna odpowiedź: „no tacy ludzie, co płacą za twój produkt”. I tutaj zachęcam wszystkie start-upy - jeżeli słuchacie naszego podcastu to zachęcam was do tego, żeby w momencie, kiedy to oprogramowanie powstaje, kiedy ono jest nawet w pierwszych powijakach, nie wiem, może pojawiły się już jakieś grafiki opisujące, jak to będzie wyglądało, może już zaczęły się pierwsze prace programistyczne nad tym start-upem, myślcie o tym, w jaki sposób pozyskać klientów. Bo kiedy to oprogramowanie będzie już działało i będzie już na takim poziomie, że będzie można je otworzyć dla wszystkich, to świetnie by było, gdyby już na nim zaczęło działać te pierwsze 100-1000 osób, a nie że dopiero wtedy zaczniemy się zastanawiać, jaki jest nasz plan marketingowy i w jaki sposób moglibyśmy to zrobić. To opóźnia o kilka miesięcy, rok pozyskanie tych użytkowników, którzy mogliby być pozyskani już wcześniej, a start-upowi to generuje koszty wynikające z tego, że to oprogramowanie nie jest używane, więc tak naprawdę nikomu do niczego nie służy w tym momencie.

To prawda, też z licznych rozmów z różnymi inwestorami, z aniołami biznesu, czy też właśnie z funduszami, czy na etapie pre-seed czy późniejszych wynikają podstawowe pytania: „Czy macie już jakiś klientów? Jaki macie miesięczny przychód?”. To wszystko są standardowe pytania, ale niestety czasami start-upy dopiero po fakcie zaczynają się zastanawiać, że dobrze by było mieć jakichś klientów. Zmierzając powoli do końca - jak wiesz, tego podcastu słuchają, teraz też będą oglądać, różne osoby, zarówno programiści, jak się dowiadujemy, osoby techniczne, ale też osoby, które chcą poszerzyć swoją wiedzę z zakresu styku biznesu i IT, tak jak to mówię w czołówce, czyli różnego rodzaju dyrektorzy, być może właściciele firm - co doradziłbyś właśnie takim osobom? W jaki sposób podchodzić do tego oprogramowania, aby ono jak najdłużej dostarczało wartość?

MM: Tutaj myślę, że mogę podzielić się dwoma spostrzeżeniami, które będą dość wartościowe. Po pierwsze, miejmy przygotowane wszystko, żeby jak najszybciej, od momentu wypuszczenia tego oprogramowania ono zaczęło być używane. Jeżeli może być używane jeszcze przed wypuszczeniem przez odpowiednie osoby, to jak najbardziej, wtedy mówimy o beta testach, pierwszych użytkownikach, którzy dostają zniżkę w przypadku start-upów. A w przypadku aplikacji wewnętrznych, intranetów, czy takich, które firma po prostu tworzy dla siebie mamy do czynienia z pracownikami czy z poszczególnymi działami, które będą korzystały z tej aplikacji. Niech te osoby korzystają jak najwcześniej z tej aplikacji. Bo bardzo często też się zdarza taka sytuacja, że okej, mamy gotową aplikację związaną ze specyfikacją, która powstała gdzieś tam wcześniej, ale koniec końców zaczynamy omijać tę aplikację. Zaczynamy korzystać tylko z części jej funkcji, bo część jej funkcji była przemyślana, ale zapomnieliśmy o tym i o tym wyjątku. I to jest druga rekomendacja, którą chciałbym zaszczepić we wszystkich osobach, które nas słuchają, że od czasu do czasu, periodycznie, np. co rok albo co dwa warto zadać sobie pytanie: „Czy ta aplikacja faktycznie realizuje nasze cele? Czy ta aplikacja jest zgodna z rzeczywistością, w której się znajdujemy?”. Bo często może być tak, że aplikacja, w szczególności te aplikacje wewnętrzne, intranetowe, realizuje procesy biznesowe, które mieliśmy spisane dwa lata temu. A od tamtego momentu te procesy się rozwinęły, trzeba je okrążać, trzeba w tej aplikacji zrobić tylko połowę rzeczy, a resztę i tak się robi Excelem. I potem wychodzą z tego różne dziwne sytuacje. Czasami te informacje nawet nie dochodzą do managementu, bo wszyscy i tak już się nauczyli, że to trzeba omijać. Więc warto przyglądać się tym aplikacjom, i nie mówię tutaj o tym, żeby od razu szukać usług jakiegoś konsultanta informatycznego, bo oni i tak chcą sprzedać swoje usługi, więc zawsze coś znajdą. Aczkolwiek, jeżeli ktoś ma ochotę na zrobienie jakiegoś brainstormingu, to wtedy właśnie tacy konsultanci techniczni mogą podrzucić nowe pomysły, co jeszcze w tej aplikacji mogłoby być. Ale chociażby wewnętrznie warto przyjrzeć się tej aplikacji, zobaczyć, czy te cele, z którymi została zrobiona nasza aplikacja faktycznie są spełniane, czy nadal są spełniane, czy przypadkiem ta aplikacja nie odstaje od tych procesów, które ma realizować, albo w przypadku start-upów, czy nasi klienci nie potrzebują bardzo mocno czegoś innego, w szczególności takich rzeczy, których nie oferuje konkurencja, bo znalezienie czegoś takiego to jest złoto. Bo często za pomocą zbierania informacji zwrotnej od naszych użytkowników dowiadujemy się, że oni faktycznie potrzebują czegoś innego. I wtedy warto tę aplikację dopasować do tego, co jest faktycznie potrzebne.

Nie da się ukryć, że jest to temat trudny, nawet myślę, że w niektórych przypadkach częściej niż raz na rok warto się pochylić nad tym, ale też warto śledzić opinie faktycznych użytkowników. Jeżeli pracownicy zaczynają choćby troszkę marudzić, mówiąc wprost, to faktycznie jest to taki moment, aby się nad tym pochylić i zastanowić. Michale, bardzo ci dziękuję za dzisiejsze nagranie, za spotkanie, i za tę okazję, bo myślę, że ta rozmowa jest bardzo dobrym uzupełnieniem artykułu, który opublikowałeś. A was, drodzy słuchacze, mogę powiedzieć już też drodzy widzowie, gorąco zachęcam do zapoznania się z tekstem Michała, związanym właśnie z dzisiejszym odcinkiem. Link znajdziecie w opisie. Cóż, odcinek dobiega końca. Oczywiście nie jest to jednorazowa sytuacja, będziemy co jakiś czas publikować odcinki zarówno w wersji audio jak i wideo, również wywiady. Na teraz pozostaje mi podziękować za uwagę, za wysłuchanie i też może właśnie obejrzenie. W imieniu swoim i Michała kłaniam się nisko i do usłyszenia, do zobaczenia.

MM: Do usłyszenia, do zobaczenia.

Zasoby

Depreciation of value of software — Makimo – Consultancy & Software Development Services
As any other machinery, it is an asset that depreciates in value over time. Read more if you are considering purchase or development of a software product.
Michał Moroz – Software Consulting and Development Services
My name is Michał Moroz and I’m a CIO and co-founder of Makimo, a custom software development company.