Trudno jednoznacznie wyrokować, że misja popularyzacji kodowania zakończyła się kompletnym fiaskiem, ale tak czy inaczej cały świat zmaga się z ogromnym deficytem programistów na rynku pracy. Co gorsza, rekruterzy zaczynają narzekać na umiejętności developerów przystępujących do rozmów kwalifikacyjnych. Często ich wymagania finansowe nijak mają się do posiadanych kompetencji. Założenie, że lwia część obywateli zabierze się za pisanie kodu, jeśli się tylko ich do tego odpowiednio zachęci, okazało się dość naiwne. Obecnie więc każda firma bądź instytucja musi zmierzyć się z wyzwaniem, jakim jest niedobór specjalistów IT. Jedną z opcji na rozwiązanie tego problemu jest skorzystanie z usług zewnętrznych. Z kolei bogatsze firmy, aby zatrzymać lub pozyskać developerów, płacą im coraz większe pieniądze.

Jak wynika z niezależnych opracowań na windowanie płac stać tylko nielicznych. Przykładowo, aż 49 proc. menedżerów IT, którzy wzięli udział w badaniu Antal przyznało, że ma problemy z finansowaniem wynagrodzeń. Można też słono zapłacić za gotowy software, ale istnieje inna, nierzadko znacznie ciekawsza alternatywa w postaci platform typu low-code bądź no-code, znacznie skracających czas tworzenia aplikacji. O ile za oceanem tego typu platformy cieszą się dużym uznaniem, o tyle w naszym kraju dopiero przecierają swój rynkowy szlak.

– Popyt na systemy low-code oraz no-code jest w Polsce wciąż umiarkowany. W przeciwieństwie do Stanów Zjednoczonych idea platform niskokodowych jest w Polsce wciąż mało znana. Głównym wyzwaniem w naszych rozmowach z potencjalnymi klientami lub partnerami jest tłumaczenie im na czym polega i jakie korzyści daje sama platforma, a nie czym różnimy się od naszych konkurentów – wyjaśnia Sławomir Gierek, Head of Global Markets w firmie VSoft.

Jednakże na rodzimym rynku systemów low-code pojawiają się też pozytywne sygnały. Dostawcy zauważają, że część firm rozumie potrzebę cyfryzacji procesów w obliczu nieprzewidywalnego i szybko zmieniającego się otoczenia biznesowego. To z kolei przyczynia się do wzrostu zainteresowania narzędziami low-code czy no-code, choć sytuacja jest wciąż daleka od ideału.

– Rozczarowuje nas to, że wiele polskich firm nadal podchodzi do digitalizacji procesów wybiórczo. Zamiast zaplanować długoterminową strategię digitalizacji i dobrze przemyśleć docelową architekturę systemów informatycznych, skupiają się na naklejaniu plasterków tam, gdzie w danej chwili boli – mówi Łukasz Wróbel, Chief Business Development Officer w Webconie.

Low-code na trudne czasy

Platformy niskokodowe zdobywają popularność przede wszystkim ze względu na ich zdolność do szybkiego i ekonomicznego tworzenia i uruchamiania aplikacji biznesowych. Specjaliści zauważają, że w czasie pandemii po platformy low-code bardzo chętnie sięga sektor publiczny. Wprawdzie jak na razie dotyczy to głównie Stanów Zjednoczonych, ale niewykluczone, że w podobnym kierunku niebawem podążą rodzime instytucje samorządowe. Jeśli zaś chodzi o USA, to tamtejsze agencje rządowe i federalne w minionych dwóch latach nie miały gotowych rozwiązań na bardzo szybko zmieniające się przepisy i rozporządzenia. Przykładowo, władze Los Angeles przygotowały – przy wykorzystaniu platformy low-code – aplikacje pozwalające na przetestowanie mieszkańców na Covid-19, uwzględniając ich lokalizację oraz przynależność do określonych grup ryzyka. Od pojawienia się pomysłu do utworzenia aplikacji upłynęły zaledwie 72 godziny.

W Polsce zainteresowanie platformami niskokodowymi przejawiają przede wszystkim podmioty gospodarcze. Na przykład najliczniejszą grupę klientów VSoftu stanowią małe przedsiębiorstwa.

– Najczęściej zgłaszają się do nas małe firmy, które nie mają zespołów IT lub zatrudniają pojedynczych specjalistów. Do tej pory musiały one wybierać pomiędzy drogimi rozwiązaniami a ustępstwami biznesowymi w przypadku produktów pudełkowych. Low-code stanowi dla nich wygodną trzecią drogę – mówi Sławomir Gierek.

Inny polski dostawca, Webcon, w ubiegłym roku zwiększył przychody ze sprzedaży platform low-code oraz no-code w zasadzie w każdym segmencie rynku, począwszy od małych firm rodzinnych, poprzez producentów i usługodawców, aż po uczelnie wyższe. Zresztą podobnie było w przypadku nAxiom, do którego zapytania kierowały zarówno duże banki, jak i sektor MŚP.

– Duże obciążenie działów IT bieżącymi zadaniami, zwłaszcza w zderzeniu z ciągle rosnącymi i wysoko zmiennymi potrzebami biznesu zmuszają do poszukiwania nowych narzędzi i sposobów radzenia sobie z zaistniałą sytuacją – podkreśla Dariusz Pruchnik, dyrektor zarządzający nAxiom.

Dla programisty czy działu biznesu?

Automatyzacja jest jedną z miar ludzkiego postępu. W ostatnich latach na rynku pojawiło się mnóstwo narzędzi technologicznych usprawniających pracę lekarzy, księgowych czy fotografów. Ale chyba najciekawszym przypadkiem jest rozwój branży fotograficznej. Wiele osób stało się dobrymi specjalistami nie dzięki długim godzinom spędzonym w ciemni fotograficznej, lecz smartfonom i ogromnej liczbie filtrów i aplikacji przeznaczonych do obróbki zdjęć. Czy platformy low-code oraz no-code odegrają podobną rolę w branży IT jak smartfony w fotografii?

W 2012 r. Gartner oznajmił, że wszyscy jesteśmy developerami i w ten sposób narodził się trend „Citizen Developer”, czyli osoby zajmującej się rozwiązywaniem problemów poprzez tworzenie aplikacji, pomimo braku umiejętności kodowania. Brzmi to dość niedorzecznie, ale analitycy spodziewali się, że za pomocą właśnie takich narzędzi jak low-code czy no-code uda się zaangażować w proces wytwarzania aplikacji pracowników działów biznesowych. W praktyce nie wygląda to najlepiej – według badania „CIMI Corporation Survey of Organizations” z 2018 r., aż 54 proc. tego typu inicjatyw okazało się niewypałem już w pierwszym roku od ich podjęcia.

– Pracownicy działów biznesowych muszą zrealizować własne zadania i najzwyczajniej w świecie nie mają czasu oraz chęci do nauki nowych zagadnień, które są im całkowicie obce. Oczywiście znajdzie się część pracowników, którzy podejmą się tego zadania, ale będzie to znikomy procent – zauważa Emil Bednarczyk, Client Partner w Havenocode.

Prawda jest taka, że sprawny „citizen developer” powinien mieć wiedzą techniczną oraz dryg biznesowy. O ile obsługa no-code nie powinna nastręczać pracownikom działów marketingu bądź sprzedaży większych trudności, o tyle jedynie osoby obdarzone wyżej wymienionymi cechami poradzą sobie z rozwiązaniami low-code.

– To mogą być programiści, analitycy IT, konsultanci wdrożeniowi czy właściciele biznesowi, którzy wiedzą, co siedzi „pod maską”. Wszystko wskazuje na to, że ta grupa pracowników będzie się powiększać, wypierając tradycyjny podział na IT i biznes – mówi Sławomir Gierek.

Na ciekawy eksperyment zdecydował się Webcon, który opracował narzędzie no-code, będące jednocześnie elementem platformy low-code. Innowacyjność podejścia polskiej firmy polega na tym, że prototyp konfigurowany w narzędziu no-code przez przedsiębiorcę lub analityka (pracującego na pograniczu biznesu oraz IT) jest następnie przenoszony do platformy low-code. Tam zostaje dopracowany przez profesjonalistów i przygotowany do procesu produkcyjnego.

Jak wynika z różnego rodzaju badań, w 9 na 10 przypadków z systemów low-code korzystają specjaliści IT. Choć czasami zdarza się, że programiści krytykują tego typu rozwiązania za brak elastyczności, a opracowywanie własnego kodu wiersz po wierszu pozwala lepiej dostosować aplikację do specyfikacji użytkowników. Większość programów tworzonych za pomocą platform niskokodowych nie wymaga od developerów wirtuozerii, gdyż na ogół są to dość proste rozwiązania. W dużych organizacjach aplikacje często stanowią uzupełnienie systemów ERP lub CRM, zaś w mniejszych służą zazwyczaj do budowy prostych aplikacji biznesowych odpowiadających na konkretne zapotrzebowanie pracowników lub pracodawców. Na nieco inny problem zwraca uwagę przedstawiciel nAxiom.

– Zauważamy obawy części działów lub struktur działów IT przed utratą pozycji w zderzeniu z nowym narzędziem. Wynika to głównie z niezrozumienia tego, że dobrze wykorzystana platforma low-code może stanowić dla nich szansę, a nie zagrożenie – podkreśla Dariusz Pruchnik.

Dwie opcje dla integratora

Na rynku można spotkać różne modele wykorzystania platform low-code bądź no-code. Najczęściej firmy kupują je na własny użytek, a czasami inwestują w tego typu narzędzia, a następnie zlecają wykonanie prac zewnętrznemu podmiotowi. Tak naprawdę wszystko zależy od zasobów personalnych i finansowych. Dlatego na odegranie ważnej roli w tym segmencie mają szansę integratorzy. Dobrym wyborem wydaje się być tworzenie aplikacji dla klientów za pomocą wybranych platform niskokodowych. Taki kierunek obrała między innymi warszawska firma Havenocode.

– Tworzymy programy dla naszych klientów lub dla siebie. Tacy integratorzy jak my są niezbędni na rynku, ponieważ większość firm nie ma ochoty, a także kompetencji, aby realizować to zadanie własnymi siłami. Przedsiębiorcy wolą skupić się na swojej podstawowej działalności. Tak, jak od wielu lat działają na rynku integratorzy systemów Microsoftu czy Oracle’a, podobnie będą rozwijać się agencje no-code, low-code, opracowujące oprogramowanie w stylu zbliżonym do software-house’ów – mówi Emil Bednarczyk.

Głębsze wejście w biznes low-code może stanowić dla integratorów bądź resellerów niepowtarzalną szansę na zmianę profilu z dostawcy sprzętu na firmę oferującą wysokomarżowe usługi. Często integratorzy z wieloletnim stażem posiadają bogatą wiedzę na temat lokalnego rynku i jego potrzeb. Jednak nie zawsze przekłada się to na poziom sprzedaży nowych produktów i usług.

To najczęściej wynika z obaw o ryzyko inwestycyjne związane z rozwojem innowacyjnych rozwiązań, zwłaszcza w perspektywie czasu ich tworzenia. Spóźnienie z wprowadzeniem pomysłu na rynek zwykle kończy się zajęciem drugiego, niepremiowanego zamówieniami miejsca. Platformy niskokodowe są dużo mniej ryzykowną drogą do monetyzacji swojej wiedzy biznesowej – przekonują specjaliści oraz analitycy.

Zdaniem integratora

Dokąd zmierza low-code i no-code

IDC poinformowało, że do 2023 r. powstanie ponad 500 mln aplikacji. Trudno spodziewać się, że programiści sprostają temu zadaniu korzystając z tradycyjnych rozwiązań. Zmienia się nie tylko liczba nowych aplikacji, ale też czas ich tworzenia. W obecnych czasach oprogramowanie powstaje w ciągu kilku miesięcy, a w przypadku prostych aplikacji nawet dni. Jednak aby sprostać nowym wyzwaniom trzeba sięgnąć po nowe narzędzia i metody tworzenia programów. Jednym z trendów jest powolne odchodzenie od klasycznego sposobu opracowywania oprogramowania na rzecz aplikacji opartych na mikrousługach. Na świecie widać również wyraźny wzrost zainteresowania platformami low-code oraz no-code. Według Gartnera sprzedaż tej grupy narzędzi wzrośnie z 13,8 mld dol. w 2021 r. do 29 mld dol. do roku 2025. Ten wzrost jest napędzany przez zakłócenia związane z pandemią, a także hiperautomatyzację i nowe strategie biznesowe.

Zastosowanie narzędzi low-code, no-code pozwala zazwyczaj skrócić czas projektu z kilku miesięcy do kilku tygodni. Prawdopodobnie nie jest to jednak kres możliwości tych narzędzi. Jednym z kierunków ich rozwoju jest łatwość i szybkość dostarczania aplikacji – także takich, które mają obsługiwać zaawansowane scenariusze.

Jak zauważa Łukasz Wróbel szczególnie istotne jest słowo „dostarczanie”, a nie „budowa”. W praktyce oznacza to, że taka platforma powinna wspierać cały cykl życia aplikacji – od prototypowania aż po przenoszenie między środowiskami testowymi oraz produkcyjnymi, czy automatyczną generację dokumentacji powykonawczej.

Innym ciekawym kierunkiem jest usprawnianie i automatyzacja samego procesu tworzenia aplikacji, gdzie podejmowanie wielu decyzji projektowych będzie wspierane przez sztuczną inteligencję. Platformy niskokodowe pozwolą firmom i organizacjom tworzyć rozwiązania bazujące na sztucznej inteligencji bez potrzeby zatrudniania drogich specjalistów. Rozwój tych narzędzi będzie również prawdopodobnie podążać w kierunku ułatwienia obsługi i jeszcze większych możliwości w zakresie skalowalności.

Zdaniem producenta

Łukasz Wróbel, Chief Business Development Officer, Webcon  

Klienci na całym świecie szukają metod na to, by skutecznie włączyć biznes w proces tworzenia aplikacji biznesowych. Wzrost ilości rozwiązań dostarczanych w ciągu ostatnich 18 miesięcy pokazał jednak, że wręczenie biznesowi narzędzi no-code i obarczenie go odpowiedzialnością za tworzenie aplikacji to, co najwyżej, szybka ścieżka do pogłębienia silosów informacyjnych, chaosu architektonicznego i narastających problemów z utrzymaniem i rozwojem powstających w ten sposób rozwiązań. Dlatego dzisiaj uwaga klientów skupia się raczej na narzędziach low-code adresowanych do IT, ale takich, które umożliwiają skuteczne włączenie użytkowników biznesowych w proces wytwarzania oprogramowania.

  

Sławomir Gierek, Head of Global Markets, VSoft  

Dzięki platformom niskokodowym budowanie systemów IT przestaje być „wiedzą tajemną”, zarezerwowaną jedynie dla programistów w dziale IT. Gartner wskazuje, że w 2025 roku już 70 proc. nowych aplikacji będzie powstawało z wykorzystaniem platform low-code i no-code, podczas gdy w roku 2020 było to mniej niż 25 proc. Nie oznacza to jednak, że działy IT przestaną istnieć. Jeżeli pozwolić użytkownikom biznesowym po prostu tworzyć aplikacje, w dużej organizacji może powstać trudny do opanowania chaos. Potrzebne jest stworzenie odpowiednich ram, takich jak architektura, dobre praktyki, zasady bezpieczeństwa i ich konsekwentne pilnowanie.

  

Dariusz Pruchnik, dyrektor zarządzający, nAxiom  

Platformy low-code wspierają i ułatwiają „podróż” na drodze do transformacji działu IT tak, aby był partnerem dla klientów biznesowych. Pozwalają one specjalistom IT oraz przedsiębiorcom uczyć się siebie nawzajem, budować zrozumienie potrzeb i ograniczeń, a wreszcie tworzyć nową wartość dla firmy. Właśnie z tego powodu nie obawiamy się tego, że w najbliższym czasie zainteresowanie platformami niskokodowymi miałoby gwałtownie spadać. Obecnie lwia część zapytań dotyczących możliwości naszej platformy pochodzi od obarczonych ogromem zadań działów IT, które poszukują nowego podejścia do tworzenia i utrzymania aplikacji biznesowych.

  

Emil Bednarczyk, Client Partner, Havenocode  

Z perspektywy pierwszych miesięcy działalności na polskim rynku możemy stwierdzić, że zainteresowanie platformami niskokodowymi ze strony biznesu jest duże. Niestety, pewnego rodzaju problemem jest brak wiedzy na temat tego typu rozwiązań. W związku z tym musimy bardzo często edukować klientów, dokładnie wyjaśniając im na czym polega funkcjonowanie tych narzędzi oraz dlaczego bardziej opłaca się je stosować aniżeli tradycyjne metody. Nasi rozmówcy często nie rozumieją w jaki sposób można tworzyć oprogramowanie bez użycia kodu lub wykorzystując kod w bardzo ograniczonym stopniu.

  

Artykuł Platformy niskokodowe z odsieczą programistom pochodzi z serwisu CRN.

Historię tę opowiedział mi niedawno zaprzyjaźniony Agile Coach z pytaniem dość oczywistym: co z takim przypadkiem robić? Oczywiście coś doradziłem (między innymi zasugerowałem szersze pochwalenie się na świecie kolegą Scrum Masterem – programistą, który tworzy bezbłędny kod – ktoś taki to prawdziwy skarb), miło porozmawialiśmy i być może nawet coś pomogłem. Niemniej pozostało poczucie pewnego niedosytu – miałem wrażenie, że w tej rozmowie nie doszliśmy do sedna sprawy.

Analizując podejście, zgodnie z którym programista nie powinien zajmować się testami (względnie, że zajmowanie się nimi jest poniżej jego godności i statusu społecznego) dochodzę do wniosku, że opiera się ono przede wszystkim na dwóch fałszywych przesłankach.

Edukacyjny grzech pierworodny

Pierwsza z nich to przekonanie, że rolą programisty jest programowanie, a ściślej, że „rolą programisty jest tworzenie kodu”. Takie redukcjonistyczne podejście widzi osobę, która umie programować, tylko w jednym wymiarze – tej właśnie umiejętności. W ten sposób redukuje się tego kogoś do biologicznej maszyny, która ma z punktu widzenia organizacji spełniać jedną funkcję. Nie dziwota, że skoro maszyna „programista” umie tylko jedno – „tworzyć kod” – to trzeba ją odpowiednio nastawić, a więc poprzedzić ją maszyną „architekt”, która „zaprojektuje rozwiązanie” oraz dostarczyć jej półprodukt do przetwarzania, co jest zadaniem maszyny „analityk”, która go tworzy pod postacią „specyfikacji”. Po wyjściu oprogramowania z maszyny „programista” przekazujemy je do maszyny „tes-ter”, której zadaniem jest sprawdzić czy to, co zrobiła maszyna „programista” jest zgodne z tym, co wyprodukowała maszyna „analityk”. Wszystko na podobieństwo łańcucha wytwórczego w przemyśle.

Jak łatwo zauważyć, wszystko jest zoptymalizowane na takie traktowanie pracownika począwszy już od etapu kształcenia (wąska specjalizacja), poprzez rekrutację (stanowiska opisane zadaniem, jakie ma być wykonywane), a kończąc na metrykach (godziny pracy, czyli godziny wykorzystywania umiejętności). Dołóżmy do tego formowanie menedżerów w taki sposób, że każdy z nich niemal instynktownie czuje się zobowiązany do dbania o to, by każda maszyna (zasób) była maksymalnie zajęta – i mamy obraz dysfunkcyjnego mechanizmu, który umacnia to błędne przekonanie – a co za tym idzie, jego konsekwencje.

Nie dziwne zatem, że wykształcona w tym kierunku i rozliczana z godzin programowania maszyna „programista” oburza się, gdy miałaby zajmować się czynnościami innych maszyn lub odpowiadać za ich wyniki. Nie dziwne, że osoba obsadzona w roli maszyny „programista” nie czuje się w pełni zaangażowana w produkt, czy w całość określonej pracy.

Tymczasem tak naprawdę zadaniem programistów, testerów i w ogóle wszystkich innych jest rozwiązywanie problemów użytkowników poprzez oprogramowanie, a więc dostarczanie użytkownikom nowych możliwości, które są dla nich wartościowe. Wymaga to wielu umiejętności i czynności – samo tworzenie kodu (a więc umiejętność przypisywana programistom) jest tylko jedną z nich. Wśród tych umiejętności, poza umiejętnością programowania, mamy także umiejętności analityczne (rozumienie problemu), jak i związane z testowaniem oraz wiele innych. Wszystkie one są potrzebne i ważne, bo bez nich nie może powstać kompletny efekt pracy. Przy czym nie jest nim działające oprogramowanie, ale danie użytkownikowi wartościowych możliwości, których wcześniej nie miał.

Jeśli zbierzemy zespół, to z pewnością różni jego członkowie mieć będą owe umiejętności rozwinięte i wyćwiczone w różnym stopniu. Jest to dobre, pod warunkiem, że będą z sobą współpracować w taki sposób, by wykorzystać swoje silne strony i zminimalizować słabe, dzięki czemu możliwości zespołu będą sumą ich możliwości. To zaś możliwe jest jedynie przy wspólnocie pracy (wszyscy razem tworzymy rozwiązanie dla naszego użytkownika/klienta) i odpowiedzialności za produkt. Innymi słowy, „testera” równie interesuje poprawność rozwiązania co i „analityka”, a „programista” przejmuje się nie tylko kodem, ale i tym, czy ów kod działa oraz czy efekt jego działania spełnia oczekiwania klienta. Łatwiej jest stan taki osiągnąć, jeżeli patrzymy na zespół nie jako na zbiór odrębnych wyspecjalizowanych maszyn, ale jako na grupę ludzi o różnych umiejętnościach, którzy wspólnie coś tworzą. Jak sądzę, taki stan właśnie mieli na myśli twórcy Scruma, kiedy nalegali, by wszystkich członków zespołu nazywać „developer” niezależnie od tego, jaką specjalność reprezentują.

Dojrzałość i odpowiedzialność

Drugą fałszywą przesłanką twierdzenia, że „programista nie powinien zajmować się testami” jest przekonanie, że „w pracy powinienem (względnie powinnam) zajmować się rzeczami przyjemnymi”, połączone z brakiem odpowiedzialności za swoją pracę. Nastawienie takie nie jest szczególnie oryginalne i występuje nie tylko w naszej branży. Przeciwnie, jest ogólną bolączką społeczną naszych czasów z ich naciskiem na fun i endemicznym brakiem zrozumienia dla takich pojęć jak obowiązek.

Temat to – wraz z naszym specyficznym tłem kulturowym – na osobny długi artykuł. Dość powiedzieć, że konieczna jest pewna dojrzałość i odpowiedzialność, która powoduje, że wstydzimy się oddać pracę niekompletną. Oprogramowanie, które nie zostało przetestowane jest w sposób ewidentny niekompletne, zbudowane niezgodnie ze sztuką. Profesjonalny, odpowiedzialny programista powinien się tym przejmować, a nie uważać, że czynności te go nie obchodzą i nie interesują. Nie powinien być zdania, że to jest w porządku, że może oddać coś, bo „u mnie działa”, a sprawa ewentualnych testów to już zajęcie dla kogoś innego, gdyż on jest ponad to…

Warto zauważyć, że w grach zespołowych – a Scrum to ma być „zespołowa gra w rozwój oprogramowania” (stąd nazwa) – choć są specjalności, to jednak zawodnicy, jeśli to konieczne, wychodzą poza nie. Na przykład jeśli obrońca znajdzie się w sytuacji dogodnej do oddania strzału na bramkę przeciwnika to to zrobi, a nie będzie się wymawiał, że on nie jest od tego specjalistą. Podobnie napastnik nie będzie obserwował spokojnie z boku akcji drużyny przeciwnej, twierdząc, że tą sprawą powinni zająć się obrońcy, a jego to nie obchodzi, bo on się w obronie źle czuje i pasjonuje go atak.

Ta metafora dość dobrze pokazuje o co chodzi. Nie idzie o to, że istnienie w zespole osób o specjalizacji bardziej ku testom („testerów”) nie ma sensu – wprost przeciwnie. Niemniej granica nie powinna być tak ostro zarysowana jak to ma miejsce ewidentnie w umyśle osoby, która zainspirowała ten przydługi artykuł. Innymi słowy, nie powinno być podziału w zespole, powinna być współpraca, w ramach której każdy robi to, co umie najlepiej, ale w miarę potrzeby także i to, co robi tylko przeciętnie, najlepiej jak umie, wkładając swój wysiłek w pracę zespołu w danym momencie i na danym etapie. Oczywiście, jest to trudniejsze niż po prostu powiedzenie, że „ja nie będę tego robił”, będące właśnie przejawem braku dojrzałości. W połączeniu z równie fałszywym przekonaniem, że celem metod agile jest, aby pracownikom – a szczególnie programistom – było miło i przyjemnie, prowadzi do wypowiedzi i postaw jak wyżej.

Co zatem należy robić? Po pierwsze, usunąć mechanizmy organizacyjne, które mogą wzmacniać pierwsze przekonanie (przede wszystkim skończyć z naciskiem na to, by wszyscy byli zajęci i idiotycznym liczeniem godzin). Po drugie, zdecydowanie walczyć z niedojrzałością i nieodpowiedzialnością, najlepiej już na etapie rekrutacji.

Andy Brandt  

Jest założycielem i senior consultantem firmy doradczo-szkoleniowej Code Sprinters. Wcześniej był między innymi Country Managerem Swisscom CEE (w Polsce pod marką Air Bites), a także menedżerem i konsultantem w 4pi, Unisys i T-Mobile Polska, jak też pierwszym redaktorem naczelnym „Linux+”.

  

Artykuł Czemu programiści nie chcą testować? pochodzi z serwisu CRN.

Cyfrowa edukacja i nauka kodowania już od 6 lat mogą lepiej przygotować małych obywateli do startu na rynku pracy oraz pomóc w zmniejszeniu niedoboru fachowców w branży informatycznej. W Polsce według różnych szacunków brakuje 50 – 70 tys. specjalistów IT. Niedobory mają pogłębiać się w całej UE. Minister cyfryzacji Anna Streżyńska na początku br. zapowiedziała wprowadzenie w 2017 r. nauki kodowania w szkołach. Do tego czasu wszystkie placówki mają uzyskać dostęp do szerokopasmowego Internetu.

Piotr Woźny, podsekretarz stanu w Ministerstwie Cyfryzacji, podkreśla, że Polska ma światowej klasy fachowców. Według resortu podsumowując ostatnie 26 lat na olimpiadach IT w klasyfikacji medalowej Polska jest na czwartym miejscu po Stanach Zjednoczonych, Rosji i Chinach. Według niedawno opublikowanego rankingu portalu HackerRang w kategorii programowania w języku Java polscy programiści znaleźli się na pierwszym miejscu. W rywalizacji wzięło udział 1,5 mln programistów z całego świata.

Artykuł Polskie dzieci będą uczyć się kodowania pochodzi z serwisu CRN.