W tym odcinku dowiesz się z czego biorą się problemy podczas tworzenia i wdrażania oprogramowania.

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 55. Czemu przy robieniu software'u jest tyle fuckup’ów, ile za nami trochę taka wakacyjna, niewakacyjna spontaniczna, nie spontaniczna przerwa. Nie do końca planowana powiem szczerze, natomiast tym bardziej chciałem po niej powrócić z tematem powiedzmy takim bardziej wyrazistym. Od razu bez bicia się przyznam, że zdaję sobie sprawę, że trochę kaleczę nasz piękny język software tam fuckup’y, natomiast pomyślałem sobie co nieco jak wyglądałby polski tytuł i wyglądałby dziwnie i może jednak nie do końca oddawałby charakter. Poza tym nie da się ukryć, że kiedy realizuje się oprogramowanie, kiedy się je wdraża i coś idzie nie tak, to jednak znacznie częściej daje się ponieść wodzę emocjom i mówi się właśnie trochę bardziej bezpośrednio niż coś w stylu; ach, cóż za irytująca sytuacja.

W tym przypadku, nawet zanim zacząłem sobie planować, układać co chcę poruszyć, co chcę powiedzieć to stwierdziłem od razu, że w jednym odcinku tematu nie wyczerpię. Nie chciałem tworzyć cyklu kolejnych kilku odcinków, natomiast pewne pomysły, które przyszły mi do głowy, a które już dzisiaj się nie zmieszczą zachowam sobie w pamięci można powiedzieć i chciałbym na pewno poruszyć je w stosunkowo bliskiej perspektywie, natomiast w kontekście wywiadu. Bo jednak moje doświadczenia, chociaż liczne i na pewno by się materiał znalazł, fajnie byłoby skonfrontować też z kimś jeszcze. Natomiast póki co poruszę oczywiście też kilka takich ważnych tematów, które już teraz mogę opisać, być może właśnie do nich można nawiązać w ramach jakiegoś przyszłego wywiadu.

No dobrze, to odpowiedzmy sobie na to pytanie, czemu przy robieniu software jest tyle fuckap’ów? Bo ludzie nie wiedzą czego chcą, a dokładnie, bo to jest jakiś dosyć mocny argument, wydaje im się, że wiedzą czego chcą, ale nie wiedzą, czego potrzebują.

No dobrze ale jacy ludzie bo tak ludzie, ludzie. Ludzie jest tu zbiorczym określeniem, bo z jednej strony oczywiście mam tu na myśli klientów, potencjalnych klientów, ale nie tylko, bo czasami należy też pamiętać o użytkownikach i jednocześnie klient to nie zawsze to samo co użytkownik. Klient to ktoś kto płaci za software, użytkownik wiadomo, zwłaszcza w przypadku aplikacji B2Bi to często jest przynajmniej przedstawicielem tej samej organizacji. Ale właśnie często nawet powiedzmy osoby, które sponsorują projekt w ramach organizacji czy są głównym interesariuszem, to nie zawsze będą użytkownicy, a w przypadku branży podejścia B2C to może być tak, że klientem współpracującym tworzącym oprogramowanie jest jakiś startup, a wiadomo użytkownikami będą klienci czy też po prostu użytkownicy tego startupu. W odcinkach bodaj 10-11 opowiadałem o dziesięciu najtrudniejszych frazach występujących podczas tworzenia oprogramowania i motyw braku świadomości tego, jak funkcjonuje dana branża w tym przypadku naszym no wytwarzanie oprogramowania też był wtedy istotny.

Przewrotnie zacznę właśnie od przykładu nie ze swojego podwórka, natomiast z takiego przykładu, który ja znam jako klient, bo tematy też cyfrowe tylko bardziej takie związane z marketingiem, takie jak SEO czyli to, żeby nam się treści fajnie pozycjonowały w wyszukiwarkach czy też na przykład tak zwany outbound marketing, czyli ten rodzaj działań marketingowych, kiedy to my jako firma chcemy dotrzeć do nowych klientów, wysyłamy na przykład jakieś maile, jakieś informacje, zapraszamy na spotkania, czy to w ogóle do rozmów. To są takie obszary, powiedzmy branże działania, które zdecydowanie potrafią działać w wielu przypadkach potrafią przynieść cuda, natomiast na pewno nie w każdej branży będą działać w nie tyle tak samo, co tak samo łatwo. Bo tak jak u nas może pojawić się klient, który przyjdzie i powie, no zróbcie mi apkę, co w jego przypadku może nie mieć sensu. Albo w tym momencie być może po prostu na przykład klient ma zbyt małą organizację, żeby koszt wytworzenia aplikacji był uzasadniony albo w ogóle na przykład grupa docelowa tego klienta nie używa smartfonów, ewentualnie nie używa smartfonów w taki sposób jaki ten klient sobie wymarzył. To tak samo w branży SEO czy outbound marketingu może trafić się klient, którego wypozycjonowanie będzie bardzo trudne, bo na przykład w jego branży nie szuka się po prostu klientów w Internecie. Miałem kiedyś taką sytuację, że połączyłem ze sobą dwie osoby, właśnie znajomą z branży SEO i znajomego, no też z branży softwarowej. Natomiast to była sytuacja, w której znajomy bardzo wyspecjalizowanej takiej wąskiej niszy. I po takiej wstępnej analizie ta koleżanka bardzo tak uczciwa, sensowna osoba powiedziała, że to w zasadzie nie ma sensu, bo w przypadku tej niszy, nisze ogólnie potrafią być fajne w SEO znalezienie dobrej niszy na to, żeby właśnie trafić w te słowa, których ludzie szukają, ale w przypadku tej wysoko wysoko wyspecjalizowanej branży związanej z przemysłem, to nie miało kompletnie sensu, bo po prostu decydenci osoby, które mogłyby otrzymać na przykład wyniki, gdyby szukały takich wyspecjalizowanych firm po prostu nie korzystają z Google czy tam z innych wyszukiwarek, na pewno nie korzystają oczywiście do szukania dostawców takich wyspecjalizowanych. Może szukają sobie fryzjerów, mechaników, ale nie dostawców wysoko wyspecjalizowanego oprogramowania. I to jest właśnie to, że ten nie zawsze nie każda usługa będzie dla każdego i trzeba się z tym zmierzyć.

No dobrze wróćmy już od tego SEO od tego marketingu do oprogramowania. Tak naprawdę, jeśli ktoś chce stworzyć czy wdrożyć gotowe rozwiązanie, czy właśnie stworzyć od zera, to dzieje się to z takich kilku przyczyn. Ja tutaj wymienię trzy też nie uważam, że to jest lista zamknięta, ale takie trzy typy przyszłymi z moich doświadczeń na myśl.

Pierwszy całkiem sensowny to sytuacja, w której osoba zauważyła jakieś rozwiązanie cyfrowe gdzieś na targach, na konferencji, w reklamie, u koleżanki, kolegi, może u dziecka nawet, gdziekolwiek. I po takim przypadkowym mniej lub bardziej zapoznaniu się mógł być taki moment, -acha żaróweczka nad głową, że pewna aplikacja pewne rozwiązanie może rozwiązać problem, czy to osobisty czy też zawodowy, a może dla organizacji, w której się pracuje. I to jest generalnie fajna sytuacja, bo jeżeli ktoś obserwując coś co już istnieje, zapoznając się z tym, wpada na taki pomysł, to znaczy, że taka osoba jest świadoma problemu i jest świadoma jak wygląda potencjalne rozwiązanie. To już na tej skali od zera do fuckup’u nas przesuwa w stronę zera, natomiast oczywiście nie byłoby tego punktu tutaj w tym odcinku, gdyby nie było jakiegoś się jednak pewnego ryzyka, ponieważ problemy mogą pojawić się tutaj z uwagi na konsekwencje wdrożenia czegoś podobnego na zasadzie takiej, że och tam zobaczyłam u koleżanki aplikacje do budżetu domowego, to sobie spróbuję też z niej skorzystać. To jest, powiedzmy, sytuacja mniej ryzykowna, no bo jeżeli ktoś sobie zainstaluję, nawet wyda tę parę paręnaście złotych i stwierdzi, że to jednak nie dla mnie, może jakiś tam zwrot uda się uzyskać, nawet jak nie, to też nie jest kwota, która zrujnuje nam na marginesie ten domowy budżet, można po prostu na przykład nie przedłużyć subskrypcji. No to o ile to nie jest wielki problem, o tyle jeżeli na przykład zobaczymy u znajomych CRM, system do zarządzania relacjami, customer relations management stwierdzimy fajny system, fajnie ten znajomy używa tego systemu w swojej firmie.

Ale ten system będzie, no właśnie dopasowany do tego naszego znajomego do jego organizacji, a my po prostu spróbujemy skopiować to podejście u siebie bez zoptymalizowania czy w ogóle bez analizy procesów, czy to oprogramowanie akurat będzie miało faktycznie sens w naszej firmie? No to niestety to już może dużo bardziej zakosztować, jakby sam koszt wdrożenia zaboleć też czasowo, organizacyjnie, a często te dwie rzeczy niestety łączą się ze sobą.

No dobrze, drugi przypadek to taki, w którym problem został zidentyfikowany. Problem jakiś w organizacji, na przykład jakiś proces trwa za długo. A z reguły, jeżeli trwa za długo, to też siłą rzeczy więcej kosztuje, bo na przykład pracownicy po prostu muszą poświęcić za dużo czasu, żeby obsłużyć na przykład jednego klienta, zapytanie od jednego klienta. Być może działania pracowników nie trwają długo, ale są nieskuteczne, to znaczy jest wysoki odsetek nieprawidłowości, na przykład co piąty klient nie otrzymuje wyceny na czas. Tak już kontynuując, czy to na czas czy no w tym przypadku to może nawet bardziej otrzymuje wycenę, która nie była dostosowana do jego zapytania. Czyli tutaj, gdy chciałbym podkreślić, że czas to jedno i też bardzo kluczowe kryterium, ale też pod kątem jakościowym, nawet jeżeli w czasie wszystko dzieje się w porządku, to jakby jakiś odsetek pomyłek problemów trzeba założyć, ale może być on po prostu za wysoki.

Może być też problem, który de facto jest problemem nie tyle takim powiedzmy związanym z funkcjonowaniem tego, co już jest, ale z brakiem możliwości osiągnięcia nowych rynków czy też dróg dotarcia do klientów. Może być sytuacja, w której na przykład w naszej branży rozwiązania mobilne zostały niezwykle spopularyzowane, konkurencja była w stanie w ten sposób dotrzeć do nowych klientów, a my takiego rozwiązania nie mamy. Czyli można powiedzieć, że to, co jest to działa dobrze, ale de facto można powiedzieć, że standardem staje się posiadanie czegoś dodatkowego.

I teraz tego rodzaju diagnozy to jest bardzo dobry moment, bardzo dobry punkt wyjścia, ale znowu problemy oczywiście się pojawiają, a dokładnie problemy pojawiają się w tym, co dzieje się po dokonaniu takiej diagnozy. Czasami z braku mocy przerobowych. Kto tego w firmach nie doświadcza, że pracownicy są zawaleni, może udaje się na przykład poprosić kogoś z działu technicznego, na przykład, żeby ten sklecił jakąś tam prostą aplikację, proste narzędzie być może skonfigurował coś gotowego tylko z jednej strony pomoże rozwiązać problem na cito w tym momencie, ale będzie trudne w utrzymaniu i rozwoju. Prowizorka jest najtrwalsza, przekonuje się o tym może nie każdego dnia, ale może każdego miesiąca to w zasadzie niemalże tak.

Często jest tak, że proste szybkie rozwiązania faktycznie pomagają, ale w dłuższej perspektywie mogą paradoksalnie przynieść więcej problemu. No bo nawet jeżeli w krótkim terminie taka prowizorka szybko rozwiąże, problem zasklepi  jakąś dziurę w tym naszym statku, jakim jest organizacja, o tyle mając poczucie, że problem został rozwiązany, przestaniemy się nim zajmować. Mogłoby się okazać, że na przykład porządniejsze zajęcie się problemem już na samym początku w krótkim terminie byłoby bardziej problematyczne, bo trzeba było ponieść większe koszty, poświęcić więcej czasu. No to byłby problem oczywiście, ale w dłuższym terminie takie stabilne rozwiązanie byłoby na pewno bardziej sensowne. Z drugiej strony to żeby też nie było, że czasami prowizorka faktycznie jest dobrym rozwiązaniem, o ile oczywiście jej nie zostawimy na dłużej. Natomiast z drugiej strony zdarza się, że ok. zidentyfikowano problem jakiś z reguły, trochę większy, ale firma, chcąc mieć taką pewność, że problem zostanie rozwiązany, dobrze uderza, można powiedzieć zbyt szeroko w związku, z czym postanawia przy okazji może rozwiązać inne problemy, jakie w organizacji się pojawiają postanowiła wybrać jakiś duży, bardzo złożony system, którego wdrożenie zajmuje sporo czasu. Siłą rzeczy też sporo kosztuje i no problem polega na tym, że w takich sytuacjach trzeba oczywiście z reguły zaangażować więcej osób, rozmowy, negocjacje potrafią się toczyć miesiącami. I sam tego doświadczyłem, że po paru miesiącach nawet już, a czasami jeszcze dłużej może zdarzyć się taka sytuacja, że w zasadzie to już zapomnimy, po co właściwie to rozwiązanie było wdrażane. Oczywiście, no nie dosłownie, wiadomo będzie gdzieś to z reguły spisane, jaki był cel pierwotny, ale może się okazać, że organizacja przecież przez ten cały czas też się zmienia, zwłaszcza jeżeli mówimy o organizacjach też szybko rosnących. I może się okazać, że w ogóle ten pierwotny pomysł wdrożenia programowania jest po prostu bezsensowny. Mnie się przypomina taka sytuacja, w której wymienialiśmy projekt dla dużego klienta
i okazało się po naszych analizach, że wdrożenie stworzenie takiej aplikacji nawet większym zespołem zajęłoby powyżej roku na pewno, a firma rozwija się tak dynamicznie, że ta perspektywa na realizację na dowiezienie dość kompleksowego rozwiązania po prostu nie miało sensu. Na szczęście tutaj plusem naszych działań było to, że myśmy do tych wniosków doszli na przestrzeni tam tygodni- dwóch było jedno spotkanie, były rozmowy były nasze wnioski, potem drugie spotkanie. Natomiast jakby klient bardzo szybko dzięki nam doszedł do tego wniosku, że okej to w sumie nie ma sensu, musimy zupełnie zmienić podejście do problemu, który w organizacji był.

No i trzecie podejście może takie powiedziałbym troszkę bardziej w startupach, w mniejszych organizacjach chyba, że mówimy też o osobach no odpowiedniej funkcji w organizacjach większych, chodzi o pasjonatów pasjonatki technologii. Z jednej strony wydawałoby się, że to jest układ jak marzenie my wdrażamy, tworzymy oprogramowanie, no to przechodzimy do firmy, która być może rozwiązuje jakiś problem z bardzo konkretnej dziedziny biznesu, ale trafiamy na pasjonata pasjonatkę technologii super fajnie się gada, nie trzeba tak jakby przechodzić takich często trudnych rozmów w ogóle z przekonaniem do technologii jako takiej, do tego, żeby właśnie wdrażać rozwiązania cyfrowe i to jest super. Ale znowu oczywiście ten problem występuje, mianowicie to co na początku być może jest zaletą staje się problemem, jeżeli na przykład taka osoba ma swoje przekonania odnośnie konkretnych technologii. No i tutaj dochodzimy do momentu, że wewnętrznie w branży IT bardzo często są różne święte wojenki o wyższości Świąt Wielkiej Nocy nad Bożego Narodzenia na temat języków programowania, bibliotek, framework’ów, systemów operacyjnych, w zasadzie na temat wszystkiego, gdzie jest jakiś wybór można powiedzieć. I tu pojawiają się pewne problemy, ponieważ     z jednej strony na ogół taki dostawca oprogramowania jak my wchodzi do danej organizacji jako ekspert powiedzmy organizacja, no wiadomo konkretne osoby, które mają dostarczyć oprogramowanie, też podjąć pewne decyzje. Z drugiej strony trzeba żyć w zgodzie tutaj z jakimś interesariuszem technicznym interesariuszem, którego zdanie jest zapewne bardzo istotne dla organizacji jako takiej. O ile pierwotna diagnoza problemów takiej organizacji jest na ogół okej, z reguły wynika ona z pewnych już wstępnych analiz i ma sens to, że taka organizacja, na przykład startup zgłasza się faktycznie to dostawcy o tyle faktycznie możemy utknąć później na podejmowaniu różnych decyzji. Nie ukrywam, że cenię sobie wysoko zwłaszcza tych klientów, którzy potrafią powiedzieć, że oczywiście niekoniecznie w skali całego projektu i wszystkich decyzji, ale przynajmniej w jakimś zakresie, zdają się na nas, oczekują też propozycji rozwiązań, to jakby nie chodzi tylko o podzielenie się władzą, ale o to, że my mając doświadczenia z bardzo wielu różnych projektów, jesteśmy w stanie po prostu dobrze dopasować rozwiązanie. Generalnie ten scenariusz, ten trzeci, powiedzmy z pasjonatami technologii to mi się kojarzy z takim memem, to po prostu zdjęcie z warsztatu samochodowego, gdzie jest tutaj jakiś koszt usługi, że jakaś tam usługa przy samochodzie to tam powiedzmy 100 zł, a wykonanie tej usługi kiedy klient patrzy to 200 zł, kiedy komentuję do tego to 300 zł a gdy jeszcze próbuję pomóc to 400 zł i chociaż może charakter pracy jest trochę inny u nas to jednocześnie, czy faktycznie może trudno ubrudzić sobie dosłownie ręce smarem natomiast faktycznie często, zwłaszcza z tymi pasjonatami technologii, to tak to wychodzi.

No i się rozgadałem. W sumie pierwszy duży temat, a już wyczerpał niemalże długość normalnego odcinka, natomiast poruszę jeszcze jedną rzecz, żeby tak nie zostawiać tylko z jednym tematem, a resztę moich takich notatek obserwacji sobie zostawię na przyszłość. Może więc odpowiadając na pytanie, czemu przy robieniu software jest tyle fuckup’ów? Bo ludzie nie rozumieją technologii i tutaj odwołam się rzadko w sumie to kogoś cytuję, ale Arthur C Clarke, postać znana dość powszechnie myślę w światku technologicznym, bardziej science fiction oczywiście. Sformułował takie trzy pewne swoje stwierdzenia, z których najbardziej znana wydaje mi się jest, to że każda wystarczająco zaawansowana technologia jest nie odróżnialna od magii. To jest prawda, bo my jako ludzie, jako użytkownicy też zwykli nie techniczni, ale i w sumie techniczni bardzo szybko przyzwyczajamy się do dobrego. Oczywiście, jeżeli na przykład był bum AI na początku wszyscy byli zaczarowani, ale bardzo szybko przywykliśmy, że jest to coś standardowego, coś co działa, a wręcz zaczęliśmy bardzo chętnie przyczepiać się do tych przykładów, które nie działają, zresztą uważam, że bardzo słusznie.

Tak samo przyzwyczailiśmy się do smartfonów. Na początku wydawało się, że posiadanie dostępu do Internetu wszędzie to jest w ogóle jakaś magia, po prostu, a teraz trudno sobie w ogóle wyobrazić dostęp. Chodzi o to, że jak już się do czegoś przyzwyczaimy i tutaj zwłaszcza mam na myśli tych nie technicznych użytkowników, to bardzo łatwo dokonać takiej ekstrapolacji, czyli przyjąć, że jeżeli AI jest w stanie nam wygenerować pewne teksty, to jest w stanie myśleć, jest w stanie w ogóle pracować tak jak zwykły człowiek. No bo czy AI napisze za mnie podsumowanie tekstu, no napiszę wygeneruje powiedzmy, natomiast w takiej sytuacji na pewno będzie w stanie wygenerować cały system informatyczny zaledwie jest kilku zdań opisu.

Z tym spotykam się dość często, że zarówno czy to w firmach, organizacjach czy w życiu codziennym. Na przykład słyszę, że a wydawało mi się, że na smartfonach da się więcej osiągnąć, że te smartfony są bardziej inteligentne, czy że AI to już zasadzie funkcjonuje jak człowiek.

No nie, tak jeszcze nie jest. Natomiast my ludzie, zwłaszcza nie techniczni, właśnie osoby nietechniczne się bardzo do tego potrafią do dobrego przyzwyczaić i założyć, że można osiągnąć więcej niż się da.

Uzmysłowienie sobie ograniczeń technologii, czy też nawet powiedziałbym bardziej też uzmysłowienie innym tych ograniczeń, pokazanie to jedno z najważniejszych zadań kwestii tematów, które trzeba poruszyć przy wdrażaniu programowania i takich rodzajów ograniczeń też jest kilka.

Pierwszy to w sumie rzecz najprostsza, bo są to ograniczenia takie powiedziałbym teoretyczne, wynikające z faktycznych ograniczeń technologii czy to technologii czy wręcz logiki. Na przykład nie będziemy pracować na klawiaturze na smartfonie tak wygodnie jak na laptopie z normalną klawiaturą czy na komputerze stacjonarnym. Póki co na smartfonie nie przeprowadzimy takiej operacji renderowania wideo jak na odpowiednio skonfigurowanej stacji roboczej z odpowiednimi kartami graficznymi. Jak nie ma Internetu to nie obsłużymy aplikacji webowej na telefonie, no zresztą na dowolnym urządzeniu. Jest wiele takich ograniczeń ludziom może się wydaje, że tylko coś się da pokonać, natomiast tutaj to można tylko powiedzieć, słuchajcie, tego się nie da zrobić i nie zawrócimy rzeki niczym. Natomiast to właśnie sprawia, że są to kwestie proste do obejścia. No bo jeżeli nawet ktoś nam nie zaufa, nie uwierzy, no to może poprosić kogoś innego o zdanie może samemu szukać i się okaże, że mówimy po prostu prawdę.

Drugi temat to takie ograniczenia powiedziałbym formalne nie chcę mówić prawne, ale wynikające z pewnych narzuconych reguł gry. Nie da się ukryć, że dotyczy to głównie smartfonów a mówiąc wprost, chodzi o to, że na przykład IPhone o ile go nie zrouterujemy, natomiast tego się z reguły nie robi, zwykli użytkownicy tego nie robią. IPhone w ramach swoich standardowych aplikacji tych, które są instalowane aplikacji mechanizmów takich jak Siri może mieć pewne funkcje, pewne mechanizmy, które nie są udostępnione dla twórców aplikacji zewnętrznych.

I to też nawet ma sens, z naczy to się da zrozumieć, bo chociażby pamiętam był taki moment, to już wiele lat temu, że wdrożono możliwość wymiany danych z Internetem w tle, bo w aplikacjach mobilnych mamy sytuację, że albo aplikacja jest na przodzie jak to się mówi foreground, czyli po prostu korzystamy z niej albo przechodzimy do innej aplikacji i wtedy ta pierwsza jest w tle i te aplikacje w tle generalnie za dużo nie są w stanie robić, bo też chodzi oczywiście o wydajność, znaczy wydajność no wydajność w sumie też, natomiast o czas życia na baterii. Aplikacje w tle dla twórców aplikacji właśnie zewnętrznych są narzucone pewne ograniczenia zostały wdrożone, pewne ograniczenia wiele lat temu i krótko mówiąc, nie można sobie wykonywać dowolnych operacji w tle. Znaczy wtedy, kiedy to wdrożono, to nie można było i budziło to pewne zdziwienie, że owszem były bardzo konkretne scenariusze, na przykład regularne dociąganie danych po to, żeby na przykład aplikacja z aktualnościami zawsze miała aktualny news. Było tam kilka scenariuszy, natomiast te ograniczenia nie musiały dotyczyć aplikacji właśnie takich naturalnych dla Apple, czyli chociażby Siri, no zresztą a propos Siri to jakby tutaj podobna sytuacja. No nie można aplikacje generalnie z tego co pamiętam nie są w stanie, na pewno nie były w stanie, bo to to akurat jakiś czas temu robiłem taki reaserch, nasłuchiwać użytkownika, bo kwestia przede wszystkim prywatności, ale też wydajności. Natomiast Siri jako ta specjalna aplikacja opracowana przez Apple wiadomo, że potrafi nasłuchiwać, bo przecież musi rozpoznawać – hey Siri.

Są oczywiście też ograniczenia finansowe, chyba najbardziej naturalne. Tutaj nie będę już się za bardzo zgadywał, bo cóż, no po prostu da się coś zrobić, ale to będzie kosztować. Natomiast pokrewne do tych są ograniczenia czasowe. Bo jest tak, że powiedzmy ograniczenia czasowe biorą się z tego, że są też ograniczenia finansowe, czyli po prostu nie ma budżetu na zrobienie jakiejś funkcji, więc nie ma po prostu czasu, żeby zrobić daną funkcję, czy też w drugą stronę mamy na przykład miesiąc do wdrożenia i nie zdążymy nawet jeżeli ta kasa będzie, nie zdążymy wdrożyć funkcji. To jest takie, no wydaje mi się dość oczywiste. Natomiast bywają takie ograniczenia naprawdę zewnętrzne, chociażby jeżeli uczymy sieci neuronowe, to oczywiście na przykład w chmurze AWS, z której korzystamy można dobierać bardzo różne modele maszyn z różnymi kartami graficznymi, które krótko mówiąc wraz ze wzrostem stawki godzinowej do nawet kilkudziesięciu dolarów za godzinę…  za godzinę są serwery, gdzie tyle się płaci za cały miesiąc.

Oczywiście jest to zwiększenie prędkości, ale w pewnych sytuacjach, nawet te największe maszyny muszą po prostu swój czas spędzić na uczeniu sieci neuronowych tych oczywiście największych modeli i samo dorzucenie większej ilości kasy w tym przypadku chociaż może pomóc, to niekoniecznie nam na pewno zagwarantuje rozwiązanie problemu w określonym czasie. Tutaj naturalnie to też te ograniczenia czasowe wiążą się takim starym przykładem, żartem w zasadzie, że jak to było, że menedżer to taka osoba, która wierzy, że dziewięć kobiet jest w stanie urodzić dziecko w miesiąc. Wiadomo, nie każdą pracę da się z równolegle zrobić, ewentualnie nawet jeżeli się da, to są pewne granice takiego procesu i to są właśnie też te ograniczenia czasowe.

I na tym kończę ten odcinek. Tak może nie dostosowałem się do reguły trzech, że powinienem mieć trzy duże argumenty, ale z drugiej strony te dwa też były dość rozbudowane, zwłaszcza ten pierwszy.

Powiem tak to jest temat mega otwarty. Z chęcią posłucham, przeczytam, zapoznam się ogólnie rzecz biorąc z Waszymi poglądami na temat przyczyn tych fuckup’ów, które powstają właśnie przy wdrażaniu, czy opracowywaniu software'u. Na pewno nie wyczerpałem tematu, ale to wiedziałem już na samym początku i chciałbym myślę w możliwie jakiejś niedalekiej przyszłości, są wakacje to też nie ułatwia kontaktów międzyludzkich. Natomiast będę chciał w jakiś sposób kontynuować na pewno w formule wywiadu, żeby też skonfrontować swoje doświadczenia z jakimś rozmówcą czy rozmówczynią.

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

KONIEC