Cześć, dzień dobry. Witam was w podcastzie IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce.Podcast IT i Biznes kieruje do właścicieli firm oraz menedżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 33. Wybór technologii do nowego projektu IT.

Prosta decyzja czy kluczowy wybór? Twój projekt IT startuje. Czy wybór technologii to tylko detal? Oczywiście, że nie. Źle podjęta decyzja może kosztować cię czas, pieniądze i utrudnić ci dalszy rozwój twojego biznesu.

W tym odcinku dowiesz się jak uniknąć pułapek i dobrze wybrać technologię do nowego projektu. I tak naprawdę czym właściwie jest start projektu IT? Czy to jest moment kiedy programiści zaczynają pisać kod a środowiska już są skonfigurowane? Według mnie nie. Według mnie start projektu IT zaczyna się znacznie, znacznie wcześniej.

Zaczyna się w momencie kiedy w twojej głowie już pojawia się jakiś koncept, jakaś wizja. Być może w momencie kiedy jeszcze nie masz wszystkich szczegółów. Może nie wiesz jak dokładnie wszystko ma działać.

Ale wiesz jedno. Wiesz jakie cele biznesowe chcesz osiągnąć lub jaki problem chcesz rozwiązać. I tutaj właśnie pojawia się kwestia wyboru technologii.

I to jest decyzja, która no niejako pokieruje czy zadecyduje o wielu aspektach projektu. Zarówno od czasu wdrożenia po możliwość rozwoju w przyszłości. I dlatego warto przyjrzeć się temu bliżej i podejść do tematu z głową.

W tym odcinku podzielę się z wami sprawdzonymi strategiami, takimi przykładami z życia i wskazówkami jak podejść do tego procesu, żeby uniknąć wspomnianych sytuacji. Dobra. Bez zbędnej teorii i dalszego wstępu serdecznie zapraszam do wysłuchania konkretów.

Zaczynajmy. Cześć. Dzień dobry.

Witam was serdecznie w kolejnym odcinku podcastu IT i biznes. Dzisiaj trochę wrócimy do tematu doboru technologii do nowego projektu IT. Czyli do takiego trochę tips and tricks jak do tego podejść.

Każdy projekt IT no de facto opiera się na technologii. Nieważne czy jest to mała aplikacja czy jakiś ogromny system na przykład dla korporacji. Ale musimy pamiętać, że technologia to nie tylko narzędzie, którym się posługujemy.

To niejako też decyzja, która wpływa na cały projekt i wpływa też na twój biznes. Bo wpływa na to oczywiście ile zapłacisz za projekt. Ale nie tylko teraz, ale też później w fazie tak zwanego utrzymania i rozwoju.

Kiedy przyjdzie na to czas to też na to wpływa. Właśnie ten dobór technologii. Po drugie jak szybko uda się dostarczyć produkt.

Czyli czy zespół będzie mógł działać sprawnie a ty będziesz mógł bardzo szybko wejść na rynek. Lub będziesz mogła. Czy twój system wytrzyma próbę czasu.

Czyli przede wszystkim czy sprosta wymaganiom gdy twoja firma będzie się rozwijać. I czy ten system będzie się skalował zgodnie z tym jak będzie skalowało się twój biznes. Dlaczego to takie ważne? Źle dobrana technologia potrafi skutecznie utrudnić życie.

Wyobraź sobie, że próbujesz przewieźć meble rowerem. Może to jest głupie, ale da się? Pewnie, że się da. Zależy też jakie meble i jakim rowerem.

I czy rowerem z przyczepką czy bez. Ale czy to będzie wygodne i sensowne? Kompletnie nie. Z technologią jest o tyle trudniej, że tego nie da się tak łatwo przedstawić jak właśnie ten obraz mebla na rowerze.

Natomiast wybierając technologię firmy często patrzą tylko na te koszty na starcie. Problem tutaj jest taki, że tanio na początku może się bardzo szybko zamienić w drogo w dłuższej perspektywie. Po prostu.

Dwa przykłady, które mogą to zobrazować. Załóżmy, że wybierasz niszową technologię, bo początkowo wydaje się tańsza i po prostu wystarczająca dla ciebie. Ale np.

rok czy dwa lata później okazuje się, że znalezienie programistów znających tę technologię z uwagi na to, że jest niszowa kosztuje krocie, bo jest tych programistów bardzo mało dostępnych na rynku. Drugi przykład, który też się zdarza to to, że decydujesz się np. na system, który jest z atrakcyjną ceną licencji na start i wszystko wygląda super do momentu, gdy dostajesz jakąś np.

pierwszą fakturę za roczne wsparcie. Okazuje się, że koszty utrzymania tego systemu mogą przekraczać budżet. Tutaj może być też jeszcze jeden problem, to znaczy problem uzależnienia się od jednego dostawcy, który ten system ci na etapie takiej umowy licencyjnej czy w formie takiej umowy licencyjnej udostępnia, co powoduje, że niekoniecznie musisz mieć w ramach tej licencji możliwość rozbudowy tego systemu dalszej lub w ogóle przekazania tego systemu do innej firmy.

Takie zjawisko nazywamy vendor lockiem i tego vendor locka powinniśmy się stanowczo wystrzegać, czyli tego uzależnienia od jednego dostawcy długoterminowo. No bo co, jeżeli ten dostawca np. nie wiem, jego firma upadnie albo po prostu nie będzie chciał z jakiegoś powodu z nami dobrze współpracować z perspektywą czasu.

To jest właśnie ta kwestia. No i to są właśnie takie decyzje, które wydają się fajne na tu i teraz, fajne na dziś, ale często się mogą okazywać problemem takim nie do przeskoczenia już za jakiś czas. I teraz jednym z tematów, który poruszyłem był temat skalowalności.

No i tutaj umówmy się, nie każda technologia potrafi rozwijać się razem z twoim biznesem. Np. takie popularne systemy no-code'owe, o których też nagrywałem już odcinek, są super na początek, szczególnie dla małych projektów, szczególnie w miejscu, kiedy chcemy zwalidować jakiś pomysł na rynku, zobaczyć na ile on jest ok, a na ile nie.

No ale co się stanie, gdy twoja aplikacja będzie obsługiwała tysiące użytkowników? Trzeba tutaj być świadomym tego i planować do kiedy ta platforma no-code'owa faktycznie będzie dla ciebie wystarczająca. I to jest jak najbardziej ok, żeby z niej skorzystać, tylko żeby właśnie z niej skorzystać w sposób świadomy, zaplanowany. I teraz wyobraź sobie taką sytuację, że np.

startup tworzy aplikację do zarządzania zamówieniami na platformie no-code'owej. Tutaj na początku wszystko będzie działać idealnie, ale problem pojawi się, gdy liczba użytkowników urośnie, np. pięciokrotnie, dziesięciokrotnie.

I wtedy system na pewno będzie działał wolniej, będzie działał mniej stabilnie, lub po prostu będzie to nieopłacalne kosztowo, jeżeli chodzi o sam koszt utrzymania tej platformy no-code'owej. No i wtedy faktycznie trzeba być świadomym po prostu tego, że taką aplikację trzeba przepisać na np. jakiś inny framework.

I jeżeli da się to przewidzieć, że ten wzrost użytkowników taki będzie, no to warto po prostu o tym pomyśleć już wcześniej i być może akurat na takim poziomie pewności niekoniecznie wdrażać platformę no-code'ową na starcie, tylko na starcie wdrożyć już coś, co będzie lepsze do skalowania w przyszłości. Druga kwestia, którą poruszałem, to był temat czasu wdrożenia. No i tutaj wybierając technologię do stworzenia MVP, czyli tzw.

Minimum Viable Product, czyli takiej minimalnej wersji produktu, która daje już jakąś jedną określoną wartość, zazwyczaj robimy to dlatego, żeby postawić na szybki start. Czyli chcemy, by projekt ruszył jak najszybciej, dlatego wybieramy takie technologie, które pozwalają nam na jak najszybsze błyskawiczne wdrożenie. Jednak co w takim przypadku, jeżeli po osiągnięciu pierwszego sukcesu będziemy chcieli dalej rozwijać ten system? No i tutaj właśnie przychodzi kwestia tego typu, że powinniśmy dobrać taki system, który będzie OK dla MVP, bo MVP powinniśmy potraktować jako od strony biznesowej, rozwiązanie jakiejś jednej konkretnej sytuacji, dostarczenia jakiejś jednej dużej, konkretnej wartości dla klienta.

Natomiast jeżeli później będziemy chcieli dołożyć kolejną wartość i kolejną i kolejną, kolejną wartość, czyli mam na myśli jakąś funkcjonalność, która pozwala na wprowadzenie, czy danie wartości na jakiś problem, rozwiązanie jakiegoś problemu w biznesie klienta, no to powinniśmy być w stanie to zrobić albo wiedzieć, co trzeba zrobić, żeby być w stanie to zrobić. Czyli albo powinniśmy móc to zrobić, ja to powtórzę, bo to jest turbo istotne tutaj, czyli albo powinniśmy mieć tak od strony technologii zaprojektowane MVP, że jesteśmy w stanie je rozszerzać bez zbędnych komplikacji lub znamy ograniczenia technologii i wiemy, co trzeba będzie zrobić, żeby te ograniczenia zdjąć i móc rozwijać MVP dalej. Według mnie to jest bardzo istotne.

No i przykładem z mojego podwórka ja wywodzę się z języka PHP, tutaj funkcjonują takie dwa frameworki, czyli takie właśnie bazy kodu, które się nazywają Symfony i Laravel i one na przykład mogą wydawać się podobne, ale tak naprawdę różnią się w kilku aspektach. Bądź co bądź, musimy do tego podejść jak do narzędzia, czyli każdy taki frajmwork jest po prostu narzędziem i to też w zależności od tego, jak z niego skorzystamy, skorzystamy tym lepiej z danego narzędzia, im większą wiedzę o nim mamy, czyli wiadomo, że jeżeli ktoś programuje całe życie w Laravelu, to będzie lepiej znał Laravela niż Symfony. Natomiast generalnie taka opinia, jaka się utarła jest taka, że Laravel będzie świetny dla systemów, które są gdzie zależy ci na takim szybkim wdrożeniu i prostocie, czyli właśnie są idealne do rozwiązań typu MVP, a też dzięki temu, że jest dużo bibliotek gotowych, dużo już rozwiązań takich no po prostu open source'owo udostępnionych, jest on też przyjazny dla programistów.

Z kolei na przykład Symfony, to jest taka bardziej rozbudowana opcja, nazwijmy to, taki większy framework, który może wymagać nieco więcej pracy na początku, tak to możemy rozumieć, ale będzie oferował też większą elastyczność i lepszą skalowalność w takim już dłuższym czasie, w dłuższej perspektywie. I to jest taki frajmwork, który sprawdzi się w dużych, złożonych projektach. Dzięki temu, że też wiele rzeczy jest niejako wymuszone, jeżeli chodzi o dbanie o jakość kodu, no to tym lepiej też będzie to funkcjonowało długoterminowo, ale z reguły jest tak, że projekty na Symfony na początku trwają troszeczkę dłużej niż projekty na Laravelu, o podobnym stopniu skomplikowania, czyli w momencie, kiedy mamy podobny zakres prac do wykonania.

I choć obie te technologie pozwalają tak naprawdę na podobny start w Symfony troszeczkę dłużej, z reguły coś trwa, ale to też nie jest tak, że to jest różnica razy dwa, razy trzy, to mimo wszystko długoterminowe możliwości rozwoju tych frameworków i ich wykorzystania mogą być różne. I tutaj wybór odnośnie generalnie takiego podejścia jakby między narzędziem A a narzędziem B jest taki, że wybór powinien być zależny od tego, jak ambitne i realne są plany na przyszłość i jakie potrzeby rozwojowe są przewidywane dla swojego projektu, ale tak patrzyłbym na to bardziej pesymistycznie niż optymistycznie, czyli jednak nie marząc o tym, że po prostu wszystko pójdzie idealnie i z tej perspektywy patrzyłbym na to, tylko patrzyłbym na to raczej z perspektywy tej takiej pesymistycznej, że najgorszy możliwy scenariusz jest taki, że będziemy rozwijać na przykład tylko te kwestie i teraz czy do tego potrzebujemy technologii już na przyszłość dostosowanej. Mniej więcej w taki sposób bym do tego podszedł.

Teraz pytanie, jak w ogóle uniknąć takich sytuacji, czy jak sobie pomóc w takich sytuacjach? Gdy już wiesz, że ważna jest dobrze dobrana technologia, to w takim wypadku jak uniknąć błędów, które mogą się pojawić w przyszłości? Kluczem będzie tutaj myślenie długoterminowe, czyli można sobie przeanalizować, czy dana technologia już jest długo na rynku, jak bardzo jest rozwijana. Można sobie też przeanalizować opinie na temat danej technologii, chociaż z tymi opiniami też jest różnie. Wiadomo, że one są w pewnym sensie stronnicze, bo programista danej technologii zawsze będzie ją gdzieś tam bardziej podkreślał i proponował, no to jest nieuniknione.

Ale ważna jest taka kwestia, żebyś nie kierował, nie kierowała się tylko tym, co jest wygodne w tej chwili, czyli nie tylko tym, co działa teraz, bo to może nie wystarczyć, gdy projekt będzie się rozwijać. Więc warto sprawdzić oprócz tego, jak popularna jest technologia, jak bardzo jest rozwijana, sprawdzić też ilu specjalistów ją zna, jakie są stawki na rynku na przykład dla tych specjalistów, bo wbrew pozorom to też może powiedzieć trochę o tym, jakie będą koszty projektu wykonanego w danej technologii, jak duże jest wsparcie społeczności dla danej technologii, jak duże jest jej wykorzystanie w ogóle na rynku. To też może mieć znaczenie.

I teraz jak w ogóle podejść do tego wyboru technologii oprócz tego, żeby na początku zadać sobie te pytania, które przytoczyłem wcześniej. Jeżeli nie skupiłeś, nie skupiłaś się na tych pytaniach, to cofnij sobie tą minutkę, półtora i przesłuchaj jeszcze raz te pytania, bo one są ważne w kontekście takim, nazwijmy to finansowo stabilnym odnośnie danej technologii, na ile ona jest stabilna, na ile też finansowo będzie stosunkowo droga albo może stosunkowo niedroga, to trzeba sobie po prostu sprawdzić. No i teraz jak podejść do wyboru technologii już dalej, bo te pytania to uznajmy, że to jest taki krok zerowy.

Następnie pierwszy krok to będzie takie zrozumienie przede wszystkim wymagań biznesowych i technicznych, czyli każdy projekt IT powinien się zaczynać od celu biznesowego i dobrego zrozumienia i zdefiniowania tego celu biznesowego. Czyli to, że chcesz mieć marketplace, to nie jest cel biznesowy. To już jest jakiś tam skutek czy wynik, który chcesz osiągnąć, ale teraz dlaczego chcesz mieć marketplace? Odpowiedzenie sobie na te pytanie i sprawienie, żeby ludzie, którzy będą ten marketplace na przykład budować byli w stanie ci to jakby też odpowiedzieć na to pytanie, jaki jest cel biznesowy budowy tego marketplace'u? Czy z czego wynika w ogóle budowa marketplace'u na przykład? To to jest coś, co jest szalenie istotne, turbo istotne na start i decyzje dotyczące tej technologii powinny wtedy ten cel biznesowy wspierać.

Tutaj bez jasno określonego celu, technologia stanie się tylko przypadkowym wyborem. Naprawdę musisz mieć jasno określone, co chcesz osiągnąć. I w tym wypadku kluczowe pytanie, jakie warto sobie zadać, to po pierwsze właśnie o tym celu biznesowym, czyli dlaczego chcemy to wykonać? Co ma nam to dać? Po czym poznamy, że wdrożyliśmy poprawnie ten marketplace na przykład z tego przykładu? I dopiero dalej zadajemy sobie pytania na temat już samego systemu, samego marketplace'u czyli tego, co ma robić system? Czy to jest aplikacja bardziej dla klientów? Czy to jest bardziej aplikacja nasza wewnętrzna? Czy ona ma przyciągać nowych użytkowników? Czy ma generować sprzedaż? Czy ma to być jakaś automatyzacja? To są rzeczy, które wynikną no właśnie z tego celu biznesowego niejako.

Następnie jakie będą kluczowe funkcjonalności? Tutaj warto sobie zrobić rozróżnienie na tak zwane must have'y, czyli takie funkcjonalności krytyczne, bez których projekt nie będzie miał sensu i tak zwane nice to have, czyli takie funkcje, które fajnie jakby były, ale jak ich nie będzie na start, to też damy radę. No bo tutaj umówmy się, zbyt rozbudowany zakres na start stanowczo wydłuża wdrożenie i nie jest nikomu potrzebny. Lepiej zrobić do porządku must have'y, z nimi wystartować i potem system rozbudowywać, niż zrobić must have'y, nice to have'y i jeszcze mnóstwo pomysłów na rzeczy, które niekoniecznie są zwalidowane z rynkiem.

No bo bądź co bądź, na koniec dnia twoim rynkiem będą twoi użytkownicy, czy to pracownicy w firmie, czy klienci marketplace'u, czy klienci jakiejkolwiek innej platformy, na przykład e-learningowej i bądź co bądź, w momencie kiedy to od nich dostaniesz feedback, że na przykład czegoś brakuje, coś można zrobić lepiej, to wtedy lepiej wdrażać takie rzeczy, niż wdrażać je po prostu bez tego feedback'u, bez tego zderzenia z rynkiem niejako. No i kolejne pytanie, jakie warto sobie zadać, to jakie są ograniczenia, też i zarówno biznesowe ograniczenia, które są akceptowalne, czyli jakby na jakie kompromisy możemy pójść ze strony biznesu, co nie jest dla nas istotne, na co nie będziemy zwracać uwagi i dopiero wtedy też warto sprawdzić ograniczenia od strony technologii. Czyli dla przykładu, jeżeli chcemy jakiegoś, nie wiem, zaawansowanego czata, który działa w trybie rzeczywistym, to na przykład tutaj dobór technologii PHP niekoniecznie będzie tak dobry, jak na przykład dobór Node.js'a. Czyli jakby użycie technologii w kontekście danej rzeczy, czy danego zadania jest tutaj istotne, żeby na to zwrócić uwagę, przy czym też należy pamiętać, że da się zrobić coś takiego, że na przykład platformę, nie wiem, wyobraźmy sobie, że chcemy marketplace z chatem, to marketplace można zbudować na przykład na PHP jako podstawę, a sam chat dobudować na przykład w Node.js'ie. Czyli tu mam na myśli to, że te technologie da się ze sobą miksować i warto mieć to po prostu na uwadze, że nie musimy się skupiać typowo na jednej technologii, tylko jest na stole w cudzysłowie opcja tego, żeby na przykład skorzystać z dwóch, trzech różnych technologii, przy czym to też za sobą oczywiście niesie ryzyka i to też trzeba przeanalizować, czy w Twojej konkretnej sytuacji to na pewno będzie OK.

No i a propos przeanalizowania, to też należy przeanalizować dostępne opcje technologiczne, no bo tutaj każda technologia będzie miała swoje plusy i minusy. I kluczem jest dopasowanie technologii do Twoich specyficznych wymagań i ograniczeń. To jest trochę to, o czym wspomniałem na przykładzie marketplace'u i chatu.

I teraz zanim zdecydujesz, którą technologię wybrać, warto też zastanowić się nad różnymi kategoriami dostępnych technologii. No i teraz tak, mamy kategorię na przykład open source, czyli technologię, której plusem będzie to, że mamy brak kosztów jakichś licencji, z reguły mamy społeczności, które wspierają dane oprogramowanie, mamy elastyczność, mamy dostęp do kodu, nie jesteśmy ograniczeni tym tak zwanym vendor lockiem, o którym wspomniałem wcześniej, czyli tym ograniczeniem od jednego dostawcy. I z reguły możemy takie rozwiązanie dostosować w stu procentach do swoich potrzeb.

Natomiast z minusów no to jest konieczna znajomość tej danej technologii, żeby na niej działać. No i jest też to, że każdy może z tej technologii skorzystać, czyli też każdy może z niej znaleźć na przykład jakieś problemy bezpieczeństwa, które będzie trzeba rozwiązywać. Ale znowu, jeżeli jest ogromna społeczność, to raczej jest to rozwiązywane i tym bym się akurat aż tak w kontekście szczególnie dużych open source'ów dostępnych na rynku nie przejmował.

Przykładem technologii open source może być wspomniane Symfony czy Laravel, może być język PHP, może być na przykład React jako taki framework do wykorzystania na tak zwanym frontend'zie, czyli w tej warstwie interfejsu użytkownika. Może to być na przykład Python, może to być na przykład Java. Drugą kategorią dostępnych technologii będziemy tutaj mieli technologie komercyjne, czyli takie gotowe systemy na licencje, które oferują pełne wsparcie i gotowość czy dostępność od zaraz tak naprawdę do wdrożenia.

Z plusów takich technologii jest to, że one mają na pewno wydajną stabilność, mają szybkie wsparcie techniczne z reguły, powinny mieć bogatą dokumentację, która powinna umożliwiać łatwiejsze wdrożenie. Z minusów mamy na pewno koszt licencji, mamy często ograniczenia w dostosowywaniu systemu do swoich potrzeb, no bo jesteśmy uzależnieni od danej firmy, no i też często zdarza się właśnie ten vendor lock, czyli jak ktoś ma jakiś swój system, który wdraża pudełkowo do twojej firmy, no to możemy być uzależnieni od jednej firmy, bądź bardzo wąskiej grupy firm, które dany system obsługują. Tutaj przykładem może być SAP, który jest wdrażany w wielu, wielu dużych firmach, natomiast kto o wdrożeniu SAP-a słyszał, ten wie, że tu raczej nie ma łatwych wdrożeń, to raczej są procesy skomplikowane, oprogramowanie stosunkowo duże, no i żeby SAP-a poprawnie wdrożyć, trzeba trochę nad tym posiedzieć.

Trzecia grupa, którą tutaj wybraliśmy, to grupa technologii no-codowych, low-codowych, czyli to są technologie dla projektów, które chcemy bardzo szybko wypuścić na rynek. One są idealne do stworzenia MVP, czyli tej właśnie takiej minimalnej wersji produktu, którą chcemy pokazać komuś na przykład takiej klikalnej do takiego prototypowania i to jest, dzięki temu możemy wdrożyć taki system bez potrzeby zaawansowanego kodowania i to są na pewno plusy. Z minusów może być to, że mimo wszystko są ograniczone możliwości dostosowania, bo to jednak opieramy się o gotowe elementy z reguły, no i przy dużych projektach wydajność, elastyczność będą problematyczne, plus koszty potem utrzymania takiej platformy przy dużej liczbie użytkowników też są stosunkowo wysokie.

I tutaj każda z tych technologii będzie miała swoje miejsce tak naprawdę i swój sposób użycia, ale ważne by wybrać taką technologię, która najlepiej będzie odpowiadać dla twoich celów, na tu i teraz i na przyszłość, na twoje zasoby dostępne do tego, żeby realizować te tematy i zasoby mam na myśli przede wszystkim wiedzę o danej technologii, ale też powinniśmy uwzględnić czas twoich specjalistów, których masz dostępnych do tego, żeby z tą technologią działali, jeżeli ich masz, no i też potrzebom rozwoju projektu, które to potrzeby warto w ramach takiej roadmapy sobie przygotować. No i tutaj też, jeżeli chodzi o właśnie to, bo wspomniałem o tych tutaj podejściu na tu i teraz i na przyszłość, to w pewnym sensie trzeba się tutaj zastanowić, czy przewidzieć przyszłość technologii, no bo wybór technologii to jest taka inwestycja w przyszłość niejako, no bo rozwijasz swój biznes po to, żeby on w przyszłości coraz bardziej się rozwijał, coraz lepszy przychód i dochód generował, więc warto zadbać, aby ta technologia była jak najbardziej odporna na czas. I teraz jak to zrobić? Pierwszym krokiem będzie tutaj sprawdzenie popularności technologii, coś o czym wspomniałem wcześniej, czyli zwróć sobie uwagę na liczby projektów np.

open source'owych, na aktywność społeczności, na dostępność materiałów edukacyjnych. Jeżeli technologia ma dużą bazę użytkowników, no to jest duża szansa, że ona się będzie gdzieś tam rozwijać, dostosować do nowych wyzwań, no i po prostu dzięki temu minimalizujesz ryzyko, że nagle ta technologia zniknie z rynku. Po drugie kwestia kosztów utrzymania.

To nie będą tylko serwery i licencje, no ale też koszty wynagrodzeń dla specjalistów. Myślę, że tutaj przede wszystkim to jest główny koszt wytwarzania oprogramowania. No i teraz np.

Javascript będzie stosunkowo tani w utrzymaniu, no bo jest bardzo dużo programistów. Względem np. programistów Java, bo tutaj dla osób nietechnicznych powiem, że Javascript i Java to nie jest ten sam język.

Warto to zapamiętać, bo są one diametralnie różne, ale co ciekawe, są projekty, gdzie można użyć jednego i drugiego i tak naprawdę może być nawet dość trudno wybrać, którego użyć, więc to taki taki smaczek nazwijmy to a propos tego. No i też wsparcie społeczności to taka kolejna kwestia, na którą warto zwrócić uwagę. Sprawdź sobie tutaj, czy powstają nowe wersje tej danej technologii języka, no bo ta społeczność to jest coś, co trochę tu powtarzam, ale to jest naprawdę ważne, żeby na to zwrócić uwagę, bo szczególnie w technologiach open source'owych ta społeczność ma ogromne znaczenie, jeżeli chodzi o to, w jakim kierunku rozwój danej technologii pójdzie.

I na koniec chciałbym jeszcze Wam opowiedzieć o takich typowych pułapkach przy wyborze technologii. Mam takie trzy, które chyba się najczęściej pojawiają. Pierwsza to wybór technologii z polecenia, ale od programisty, czyli często słyszę, że na przykład znajomy polecił nam tę technologię.

Problem w tym, że po pierwsze to, co działa w jednej firmie, niekoniecznie sprawdzi się akurat w Twojej firmie. Po drugie, programista programujący w Javie raczej rzadko poleci PHP. To znaczy, mam na myśli to, że programiści często kierunkują się na jakiś konkretny jeden bądź dwa języki i ich zdaniem żaden inny język często może nie mieć sensu w Twoim przypadku, bo nie do końca, niedostatecznie dobrze mogą znać nawet te inne języki.

I tutaj w tym wypadku warto zasięgnąć rady CTO, a niekoniecznie programisty, no bo CTO to z reguły jest osoba, która spojrzy na to wszystko trochę z lotu ptaka i będzie chciała dobrać taką technologię, która będzie dobra po prostu dla Twojego biznesu, a nie, że akurat w tej konkretnej technologii czy języku lubi programować. I tutaj zanim zdecydujesz, warto sobie przemyśleć, czy to rozwiązanie będzie odpowiadało Twoim unikalnym potrzebom. Rozwiązanie mam na myśli ta konkretna technologia.

Druga kwestia, czy druga pułapka to nadmiar funkcji. I tutaj naprawdę unikaj takich technologii, które oferują wszystko. Mam tu na myśli bardziej takie systemy, które są wdrażane, czyli spotykamy się z takimi przypadkami, gdzie firma wdraża skomplikowany system np.

RP, który w mojej firmie niekoniecznie będzie potrzebny aż tak rozbudowany, albo np. zespół nie korzysta w ogóle z funkcjonalności praktycznie większości, które w tym systemie są. Lub w ogóle zespół już od razu jeszcze przed wdrożeniem narzeka na system i zaraz po wdrożeniu też narzeka i robi wszystko, byle tylko z tego systemu nie korzystać.

Tutaj warto zwrócić pod uwagę w ramach tego punktu, że wdrażanie oprogramowania to jest też przejście przez proces zmiany i ten proces zmiany też trzeba zaplanować, też trzeba go zorganizować, ale to jest temat na pewno na zupełnie inny odcinek, więc tutaj się zatrzymam. Trzecia pułapka to jest ignorowanie integracji, czyli jeżeli twoje rozwiązanie ma współpracować np. z innymi systemami, to na pewno warto się upewnić, że jest to po prostu możliwe, czyli że dany system wystawia jakieś swoje API, jakieś interfejsy, czy te interfejsy są nowoczesne, czy raczej stare, bo to też będzie powodowało potem to, że to będzie miało wpływ na koszty wdrożenia, na czas realizacji tego wdrożenia no i na stopień skomplikowania i trudności w utrzymaniu tej integracji później po wdrożeniu.

Więc to też warto z kimś technicznym skonsultować na ile dana integracja jest możliwa sensownie do zrobienia, no i też ją po prostu zaplanować. I na koniec jak tutaj Ci pomóc jako osoby nietechnicznej podjąć te decyzje w wyborze technologii. Myślę, że kluczowy jest dobrze przemyślany proces wyboru technologii w pewnym sensie i tutaj znowu jeszcze takie już na koniec trzy konkretne kroki, które warto moim zdaniem przejść, zanim te rozważania o technologii zamienią się w decyzje niejako.

Po pierwsze organizuj warsztaty, czyli zbierz sobie zespół techniczny, biznesowy, interesariuszy generalnie projektu, by wspólnie omówić wymagania. No i tutaj przede wszystkim zacznijcie od celów biznesowych, zdefiniujcie je najlepiej jak to możliwe. O metodzie SMART pewnie każdy słyszał i warto z niej skorzystać, żeby sobie cele biznesowe wyjaśnić.

I jeżeli na przykład, nie wiem, planujesz współpracę z Software House'em, to też zwróć sobie uwagę, czy na przykład potencjalny partner zada pytania o te kwestie biznesowe i też czy podczas warsztatów będą realizowane notatki, czy potem otrzymasz to w formie jakiegoś podsumowania, które będzie spójne z całością i też czy warsztaty są realizowane z osobami, które później docelowo będą realizować Twój projekt. To też jest istotne moim zdaniem. Jeżeli któryś z tych punktów nie jest wzięty pod uwagę, warto zasięgnąć rady na przykład CTO, po to, żeby ocenić, czy tu wszystko na pewno jest zorganizowane w dobry sposób.

Tutaj warto pamiętać, że ryzyka przewidziane na etapie już planowania, czy na etapie wstępnych rozmów to jest największa oszczędność w realizacji projektów IT, bo jeżeli tych ryzyk się nie przewidzi, no to potem tutaj niestety pojawiają się problemy. Drugi punkt, czy druga kwestia oprócz organizacji warsztatów to właśnie konsultacja z ekspertami zewnętrznymi. Ja tutaj często zalecam to, żeby w momencie, kiedy z jedną firmą, czy z jednym zespołem realizuje się jakieś prace, to przynajmniej raz na jakiś czas skonsultować je z kimś z zewnątrz, bo osoba z zewnątrz naprawdę może zidentyfikować rzeczy, o których nikt nie pomyślał w ramach tak zwanej bieżączki, w ramach realizacji bieżących działań i to pozwoli uniknąć błędy, które mogą kosztować nawet setki tysięcy złotych, jeżeli ktoś coś źle przemyśli i powstanie coś, co nie powinno powstać, albo w zły sposób zostanie to zbudowane.

I tutaj naprawdę spojrzenie z zewnątrz często daje nowe takie cenne perspektywy i gorąco polecam, żeby z takiej pomocy skorzystać. I tak naprawdę niezależnie, czy projekt startuje, czy projekt już funkcjonuje, to wbrew pozorom w obu tych przypadkach ma to z reguły sens. I po trzecie prototypuj, zamiast decydować na podstawie swoich przekonań, przetestuj rozwiązania w praktyce, budując jakąś aplikację, czy jakiś system, postaraj się ją zbudować w taki sposób, żeby jak najszybciej zweryfikować ją z danym rynkiem i też zweryfikować wybraną technologię, czy na pewno działa poprawnie.

Podsumowując dzisiejszy odcinek, dobór technologii to jest taki proces, który wymaga czasu, wymaga przemyślenia, wymaga analizy, no bo te decyzje podjęte na tym etapie będą miały wpływ na każdym aspekcie już później dalszym realizacji projektu. Kilka wskazówek w ramach tego podsumowania. Zaczynaj od wymagań biznesowych.

Technologia to jest narzędzie do osiągania twoich celów, a nie odwrotnie. Jasne cele biznesowe to jest podstawa twoich decyzji i od tego trzeba zawsze wyjść. Myśl tu i teraz, ale myśl też długoterminowo.

Rozważ sobie różne opcje, bo dzięki temu, jeżeli rozważysz różne opcje, to może się okazać, że w perspektywie dwóch, trzech lat dany wybór okaże się po prostu skuteczniejszy. I trzecia rzecz, weryfikuj kompetencje partnerów. Jeżeli planujesz współpracę z Software House'em lub konsultantem lub z zespołem wewnętrznym, upewnij się, że wybrane osoby rozumieją specyfikę twojego biznesu i potrafią dopasować technologię do twoich potrzeb i że rozumieją nie tylko twoją potrzebę, tylko rozumieją też z czego ona wynika i jak wpływa na twój biznes.

Pamiętaj, że dobrze dobrana technologia to nie jest tylko fundament projektu, ale to jest też szansa na sukces tego projektu w dynamicznie rozwijającym i zmieniającym się świecie. I to też możliwość oszczędności w perspektywie czasu. Jeżeli macie jakiekolwiek pytania dotyczące wyboru technologii, chcecie omówić swój projekt, swoje cele biznesowe, czy po prostu potrzebujecie wsparcia CTO na godzinę, śmiało, serdecznie zapraszam do kontaktu, z przyjemnością pomogę, będzie to dla mnie naprawdę ogromna przyjemność.

Dzięki raz jeszcze za wysłuchanie dzisiejszego odcinka i do usłyszenia, ale już nie za tydzień, bo za tydzień mamy święta, więc pojawi się odcinek, no właśnie, tutaj będzie mały spoiler, pojawi się odcinek, który w którym zakończymy ten rok, zrobimy tutaj króciutkie podsumowanie, pojawią się życzenia świąteczno-noworoczne i wówczas zrobimy dwutygodniową przerwę, także jeżeli się o tym dowiedziałeś bądź dowiedziałaś na koniec odcinka, to tym bardziej serdecznie dziękuję za jego wysłuchanie do końca i cóż, do usłyszenia w takim razie jeszcze króciutko za tydzień. Cześć!

‍