Czy możemy przewidzieć przyszłość?

Niedawno przeczytałem na blogu Donalda Norman wpis, w którym polemizuje on ze słynnym stwierdzeniem Dennisa Gabora:

„The future cannot be predicted, but futures can be invented.”

Norman pisze:

„The future cannot be predicted, not even by trying to invent it. Although inventions can change the future, their long-term impact cannot be predicted.”.

Zacząłem zastawiać się, które stanowisko jest mi bliższe. Jeszcze parę lat temu, gdy na świat informatyki i projektowania patrzyłem w sposób mniej krytyczny niż teraz, pewnie stał bym na stanowisku, że laureat Nobla ma rację. Przecież to my, ludzie od IT, jesteśmy od tego by świat zmieniać, by wynajdywać dla wszystkich wokół lepszą przyszłość. To my tworzymy elektryczne samochody, egzoszkielety i algorytmy pozwalające szybciej stawiać właściwe diagnozy. Niestety świat IT to nie tylko takie projekty, a i konsekwencje tych projektów nie są oczywiste.

Ostatnie kilka lat pracy pokazało mi jednak, że w tym cały hypie na UX, cyfrową transformację, appki, startupy i drukarki 3D, nie tylko bardzo często brakuje uzasadnienia biznesowego, ale również brakuje jakiekolwiek refleksji na temat oddziaływania na przyszłość. Mało kto zadaje pytanie „po co?”, a jeszcze mniej pytanie „i co wtedy?”.

Trudności w przewidywaniu wpływu wynalazku

By coś nazwać wynalazkiem, musimy wykazać, że Wynalazek rozwiązuje problem techniczny w sposób nowatorski*.

Skoro Wynalazek ma rozwiązywać problem techniczny, to możemy powiedzieć, że ma on pełnić jakąś określoną funkcję. W momencie, w którym jesteśmy w stanie określić zbiór zastosowań (funkcji) Wynalazku, jesteśmy również w stanie określić grupy interesariuszy, na których będzie oddziaływać zmiana wywołana wdrożeniem owego Wynalazku. Dlaczego? Ponieważ funkcja Wynalazku już istnieje w świecie, jest tylko realizowana przez inny wynalazek.

Przykład: Komputer z edytorem tekstu to wynalazek, który spowodował szybkie wyparcie z powszechnego użycia maszyn do pisania. Podstawowa funkcja maszyny do pisania i edytora tekstu była taka sama.

To, co sprawia, że wynalazek faktycznie coś zmienia, to fakt, że może on realizować określoną funkcję sprawniej, inaczej, szybciej, pełniej, ciekawiej… etc. A co za tym idzie, że może zastąpić istniejące rozwiązanie. A to może wywołać zmianę wśród interesariuszy obecnego rozwiązania. Już sama analiza interesariuszy (oczywiście dobrze przeprowadzona) pozwala określić i ocenić początkowy wpływ, jaki może mieć wynalazek. Nieco trudniej jest zidentyfikować grupy interesariuszy, które wyłonią się dopiero, gdy wdrożenie wynalazku wygeneruje nowe potrzeby, możliwości czy problemy.

Zdecydowaną trudnością w przewidywaniu przyszłości są pochodne zmiany, które pociągnie za sobą Wynalazek. Niekoniecznie będą to kolejne wynalazki. Równie dobrze mogą to być zmiany społeczne czy ekonomiczne. Dodatkowo, Wynalazek „po wyjęciu go z laboratorium”, zacznie się zmieniać, na skutek zderzenia ze „światem zewnętrznym”. Wynalazek będzie zmieniać świat, a świat będzie wpływać na zmiany w Wynalazku. Po jakimś czasie będzie niezwykle trudne określenie, która zmiana wynika z czego. Nastąpi zjawisko koewolucji. To znacząco utrudni analizę wpływu Wynalazku na świat, bo zatrze się granica pomiędzy Wynalazkiem, a światem. Będzie on już jego częścią.

Myślenie o przyszłości w oparciu o dane z przeszłości

Kolejnym problemem związanym z przewidywaniem przyszłości jest to, że często w przewidywaniach opieramy się na danych historycznych.

„Mam tylko jedną lampę, która prowadzi moje stopy. Jest to lampa doświadczenia. Jedynym sposobem sądzenia o przyszłości jest wiedza o przeszłości.” – Patrick Henry

W podejściu tym istnieje założenie, które Gerald Weinberg nazwał aksjomatem doświadczenia:

„Przyszłość będzie podobna do przeszłości, ponieważ w przeszłości przyszłość była podobna do przeszłości.”

Aksjomat ten wspaniale obrazuje Nassim Nicholas Taleb w Czarnym Łabędziu:

„Wyobraźmy sobie indyka, który codziennie dostaje paszę. Każde karmienie utwierdza ptaka w przekonaniu, że w jego życiu obowiązuje pewna ogólna zasada: przyjaźni przedstawiciele rasy ludzkiej codziennie go karmią, ponieważ „jego dobro leży im na sercu”, jak powiedziałby polityk. W środę po południu, tuż przed Świętem Dziękczynienia, indykowi przydarzy się coś nieoczekiwanego. Będzie musiał zrewidować swoje poglądy.”

Przewidzieć, a przewidywać

Skoro nie możemy przewidzieć przyszłości, to czy powinniśmy podejmować jakiekolwiek próby jej przewidzenia?

Decyzje projektowe, które podejmujemy dzisiaj mają wpływ na przyszłość. Fakt, że nie możemy ani przewidzieć przyszłości ani jej wynaleźć, nie powinien powodować, że zaczniemy ignorować pytania o wpływ, odpowiedzialność czy konsekwencje naszych działań czy wynalazków. Uważam, że wręcz przeciwnie! Nasza twórczość i pomysłowość muszą opierać się na pogłębionej refleksji na temat przyszłości. Powinniśmy spekulować, zastanawiać się, wątpić, dyskutować, przewidywać, ponieważ otwiera to nowe drogi myślenia o zmianach, które wyrządzamy w świecie. A to przekłada się na bardziej świadome decyzje projektowe.

Czy popełnimy błąd albo nie przewidzimy wszystkiego? Tak. Mimo to, lepiej będziemy rozumieć jakie potencjalnie zmiany wywołamy, jakie stworzymy zagrożenia, jakie szanse. Bo jeżeli naszym działaniem naprawdę zmienimy świat (a w jakimś stopniu tak się stanie), to warto już teraz myśleć nad odpowiedzią na pytanie „i co wtedy?”.

*Wynika z tego, że wszechobecna (sic!) innowacja nie zawsze jest wynalazkiem (tak naprawdę rzadko jest wynalazkiem, a równie rzadko jest faktyczną innowacją). Odkrycie naukowe też nie jest wynalazkiem, jednak często wynalazki pomagają dokonywać odkryć naukowych, a odkrycia naukowe tworzyć wynalazki. 

 

Kilka pytań dot. dobrej współpracy UXa i Product Ownera – pytania z Agile Silesia #12

Wczoraj na Agile Silesia #12 miałem wielką przyjemność opowiedzieć o moich doświadczeniach ze współpracy z Product Ownerami, z którymi pracowałem przez ostatnie 7 lat. Była to polska wersja wykładu, który już wcześniej prowadziłem na Agile by Example 2015 i Product Development Days 2015. Zainteresowanych odsyłam do slajdów i nagrania z ABE15.

Podczas wykładu, który planowo miał trwać około 20 minut, a razem z dyskusją przeciągnął się do godziny, padło wiele bardzo dobrych pytań. Bardzo Wam za nie dziękuję. Trzy z nich postanowiłem dodatkowo omówić na blogu.

„Common” approach:

Zrzut ekranu 2016-02-03 o 23.28.19

„Caring” approach:

Zrzut ekranu 2016-02-04 o 08.47.31

1.Czy to aby nie Scurm Master, albo Agile Coach powinni wyjaśnić głównym zainteresowanym jaki jest zakres odpowiedzialności Product Ownera i UX Designera, a potem przypilnować, by osoby w tych rolach robiły to co do nich należy? Czy wtedy, zaprezentowany przez Ciebie model dalej ma sens? Dodatkowo, czy model nie jest oparty tylko na Twoich doświadczeniach, przez co może nie sprawdzić się w innym kontekście? 

Bardzo dziękuję za te pytania. Wszystko, o czym opowiedziałem na wykładzie to moje osobiste doświadczenia. Nie lubię nie swoich case’ów, a przez ostatnich 7 lat udało mi się zebrać ich na tyle dużo, że mogę długo o nich opowiadać. To, co jest bardzo celne w tym pytaniu, to fakt, że specyfika firmy, w której pracowałem i relacje biznesowe z klientami, w jakich uczestniczyłem, nie są podręcznikowe, ale mocno życiowe. Wykład odnosił się do specyficznego kontekstu mojej pracy, dlatego z pewnością część problemów, o których opowiadałem w innym kontekście mogłoby być rozwiązanych przez dobrego Scrum Mastera, czy Agile Coacha.

W innym kontekście, taki Scrum Master mógłby spokojnie pomóc określić zakres odpowiedzialności i przypilnować, by każdy w zespole robił to w czym jest najlepszy i sprawnie tworzył wartość dla produktu. Wtedy zaprezentowane przeze mnie wskazówki nie musiałyby być aż tak istotne, ponieważ niedopowiedzenia czy ryzyko konfliktu na linii UX Designer – PO byłyby minimalizowane przez podejmowane przez Scrum Mastera działania.

Jednak w złożonych relacjach biznesowych, w których uczestniczyłem, gdzie zespół był rozproszony nawet po kilku krajach, sam klient (PO) był na stałe np. w Wielkiej Brytanii i dodatkowo projekty nie były robione w czystym Scrumie, wtedy, by praca szła do przodu, należało się skupić na zbudowaniu dobrej relacji, a nie na twardym trzymaniu się swojej roli.

Z moich doświadczeń w takich projektach, UX Designer często wchodził w rolę proxy PO (sic!). Podchodząc do ustawienia współpracy w taki sposób, jaki zaprezentowałem podczas wykładu, UXowiec zaczynał odgrywać kluczową rolę w projekcie.

Rzeczywistość, którą poznałem często uciekała podręcznikom i dobrym praktykom, które z powodzeniem działają w wielu przypadkach, za to wymagała dużej pokory i wielu długich tygodni, a nawet miesięcy budowania opartej na zaufaniu relacji z Product Ownerem.

2.Czy model, który pokazujesz, odnosi się też do innych ról w projekcie, np. developerów albo testerów?

Tak. To jest bardzo prosty i zdroworozsądkowy model, który można zastosować do wielu ról projektowych. Ba, można na nim oprzeć bardzo wiele innych sytuacji, gdzie współpracują / współegzystują ze sobą ludzie. Pewnie jakby się dobrze zagłębić w literaturę, albo przeszukać internet, to można by znaleźć podobny model, tylko pewnie dotyczący innego kontekstu. To co jest w nim najważniejsze, to wskazanie, że pokrywające się kompetencje, wcale nie muszą prowadzić do konfliktu. Natomiast, mogą, a nawet powinny prowadzić do synergii.

3.Skąd mamy dowiedzieć się o rzeczach, o których istnieniu nie wiemy, a które mogą być istotne dla sukcesu produktu?

Podczas wykładu zaznaczyłem, że w ramach współpracy należy mocno skupić się na tym, by jak najszybciej identyfikować niewidoczne zagadnienia, które mogą okazać się bardzo istotne dla sukcesu produktu.

Na początku każdego projektu większość rzeczy, które określamy jako istotne, to tak naprawdę nasze założenia. Rzeczy, których jesteśmy naprawdę pewni jest bardzo niewiele. Dodatkowo, na samym początku wymagania są najczęściej wysokopoziomowe i dosyć trudno jest stwierdzić, czy są one w ogóle poprawne. Zwinne metodyki odgrywają dużą rolę w ograniczaniu niepewności związanej z poprawnością wymagań, ponieważ umożliwiają ich dosyć szybką weryfikację. Dodatkowo, badania i prototypy wykonywane przez UX Designerów pomagają tę niepewność jeszcze szybciej i jeszcze taniej zmniejszać.

Jak się dowiadywać o rzeczach, o których nie wiemy? Jak to powiedział Steve Blank: „In a startup no facts exist inside the building, only opinions.”  Dlatego polecam, by tak często jak to możliwe, rozmawiać z użytkownikami, budować prototypy,  testować je z udziałem użytkowników, a następnie wyciągać z tych testów wnioski. Dzięki temu będziemy szybciej podejmować właściwe decyzje biznesowe. Dobrze prowadzony proces projektowy i świadome wsłuchiwanie się w to, co mówią do nas użytkownicy, pozwala nam poznać ich potrzeby. Rozumiejąc te potrzeby możemy budować produkty, które mają szansę odnieść rynkowy sukces.

12654507_1011335485603655_1989787995538281329_n

Bardzo dziękuję za wszystkie pytania. Było mi na prawdę miło uczestniczyć w 12-tej edycji Agile Silesia. Do zobaczenia!

Ciągły rozwój

Pod ostatnim postem pt. Kilka faktów o „IT-arystokracji” pojawiło się wiele ciekawych i merytorycznych komentarzy, za co wszystkim komentującym bardzo dziękuję. Dały mi sporo satysfakcji, jak również sporo do myślenia. Postanowiłem, że dzisiaj odniosę się do wątku, który przewinął się kilkakrotnie w dyskusji pod postem. Tym wątkiem jest potrzeba „ciągłego rozwoju” w branży IT.

Wiele osób podkreślało, że 8 godzin dziennie w pracy, to zdecydowanie za mało, żeby być na bieżąco, dlatego informatycy potrzebują poświęcać dużo czasu po pracy, by nadążyć za tym, co dzieje się w świecie technologii. Z drugiej strony, pojawiły się głosy, mówiące, że wszystkie zawody spoza tzw. low-skilled mają dokładnie tak samo: wymagają ciągłego doskonalenia.

Od 5 lat zajmuję się projektowaniem User Experience (czyli działam na styku technologii, designu, biznesu i użytkowników końcowych) i przez te 5 lat poświęciłem setki godzin swojego prywatnego czasu by się uczyć i rozwijać. Poświęcę tysiące kolejnych.

Czy tylko IT?
Nie. Wydaje mi się, że potrzeba ciągłego rozwoju jest mniej zależna od wykonywanego zawodu, a bardziej dotyczy indywidualnego podejścia, jednak z pewnością w branży takiej jak IT, wiedza bardzo szybko się dezaktualizuje – to co dzisiaj jest wiodącą technologią, jutro jest reliktem.

W poprzednim poście poruszyłem wątek zmiany pracy wśród informatyków, nie ze względu na kasę, tylko ze względu na realizowany projekt. Dla osób z branży IT, projekt, który nie jest rozwojowy, ale jest np. dobrze płatny, bardzo często jest mniej atrakcyjny, niż projekt gorzej płatny, ale np. oparty o nowszą technologię, wymagający nauki nowej domeny, wykorzystujący ciekawe algorytmy, zaawansowane struktury danych, czy mający większy wpływ na świat. Jednak rozwój w pracy, to nie wszystko.

Osoby, które dążą do (nieosiągalnej) doskonałości w tym co jest nie tylko ich pracą, ale też życiową pasją, będą inwestować w swój rozwój, niezależnie od branży w jakiej działają. Podobnie jak sportowcy w dużym stopniu podporządkowują swoje życie pod trening, tak samo informatycy, projektanci, naukowcy, osoby żyjące z pasją, poświęcają swój prywatny czas na rozwój, w tych dziedzinach, które ich interesują.

Dobrym przykładem rozwoju, a przy tym zdrowego perfekcjonizmu jest Jiro, który śni o Sushi (o którym wszyscy mówili podczas konferencji UX Poland 2013).

Dobra, ale co to w ogóle znaczy rozwijać się?
Rozwój jest procesem przemiany, która ma nas udoskonalać i która zachodzi wewnątrz i na zewnątrz nas. Rozwijamy się ucząc się nowych rzeczy, doskonaląc swoje umiejętności w tym, co robimy od lat czy też doświadczając rzeczy, których nigdy do tej pory nie mieliśmy odwagi zrobić. Rozwój to zmiana, która rozpoczyna się gdy zdamy sobie sprawę z naszej niedoskonałości czy niewiedzy, zdecydujemy się nad nią pracować i zaakceptujemy fakt, że nigdy nie osiągniemy doskonałości. To jest droga, która nie ma końca i jakby się nad tym zastanowić, to może i nie ma jakiegoś łatwo mierzalnego celu, ale jak pisał Andrzej Sapkowski:

Lepiej bez celu iść naprzód niż bez celu stać w miejscu, a z pewnością o niebo lepiej, niż bez celu się cofać.

Oczywiście, czasem warto też po prostu odpuścić i włączyć pełny relaks, ale to jest temat na inny post.

20h ekstra ponad 40h na etacie
W zeszłym tygodniu byłem na spotkaniu, podczas którego Patryk (znajomy programista) opowiadał o potrzebie rozwoju po pracy. W swojej wypowiedzi powołał się na Roberta C. Martina (znanego również w branży IT jako Uncle Bob), który w książce „The Clean Coder” napisał, że jeżeli pracujemy 40 godzin tygodniowo, to powinniśmy poświęcać jeszcze dodatkowe 20 godzin na rozwój. Sporo.

Czyli 10 godzin w tygodniu, nie pozwoli się rozwinąć? A 2 godziny to już w ogóle bez sensu? Nie. Większe znaczenie ma regularność (np. poświęcamy na rozwój 4 godzin w każdym tygodniu) oraz nasze nastawienie – to ma być przyjemność, a nie walka. Nie znam osób, które byłyby w stanie regularnie poświęcać 20 godzin tygodniowo na doskonalenie. Jednak już te kilka godzin tygodniowo w dłuższej perspektywie dadzą bardzo dobre efekty. BTW. podobno 20 godzin wystarczy, żeby w bardzo podstawowym zakresie opanować każdą nową umiejętność – tak przynajmniej twierdzi autor poniższego TED Talka.

Rozwój to nie nadgodziny
Należę do tych osób, które spędzają sporo czasu po pracy na naukę, jak również wiele razy zdarzało mi się pracować po godzinach. Nie pamiętam sytuacji, żeby ktoś stał nade mną z batem i mówił: „Pracuj!”. Jak brałem nadgodziny, to wynikało to z mojego zaangażowania w projekt nad którym pracowałem, jak również z moich zainteresowań.

W dyskusji pod ostatnim postem często pojawiały się też komentarze dotyczące fragmentu, w którym napisałem, że informatyk jest w pracy, nawet jeżeli nie jest w pracy – oczywiście, nie dotyczy to tylko informatyków czy projektantów, ale również wielu innych zawodów, gdzie pracuje się głównie głową. Wyzwania z pracy zabieramy ze sobą do domu, knujemy nad nimi godzinami, czasem z ich powodu nie potrafimy zasnąć, albo budzimy się w nocy, bo przyśniło nam się rozwiązanie (miałem tak kilka razy).

Nie udało mi się jeszcze oddzielić życia zawodowego od życia prywatnego. Nie wiem czy kiedykolwiek mi się uda, bo nie próbuję. Mam tylko jedno życie i nie chcę udawać, że po wyjściu z firmy, nic mnie już nie obchodzi. Jasne, że mnie obchodzi. Tak samo jak po przyjściu do pracy moja rodzina jest dla mnie tak samo ważna, jak wtedy gdy jestem w domu.

Ostatnio przeczytałem książkę „Rework” autorstwa Jasona Frieda i Davida Heinemeiera Hanssona, założycieli słynnej firmy 37signals. Jason i David napisali trochę cierpkich słów na temat osób, które robią nadgodziny:

To, że dużo pracujesz, nie oznacza, iż bardziej Ci na pracy zależy albo że więcej zrobisz. Po prostu: poświęcasz pracy dużo czasu.

Przyznam, że ta książka skłoniła mnie do kilku refleksji. Postanowiłem zmienić swoje dotychczasowe podejście. Większość swoich nadgodzin traktowałem jako rozwój, jednak teraz chcę rozgraniczyć ten czas, by mieć większą satysfakcję z pracy jak i z nauki. Wierzę, że efekty mojej pracy mogą być lepsze, gdy będę się wystrzegał pracy po godzinach, a mój czas po pracy, jeżeli tak zdecyduję, poświęcę na dodatkową naukę. Z resztę dokładnie o tym mówi Uncle Bob – przeznaczaj 20 dodatkowych godzin na rozwój, a nie 20 nadgodzin na pracę nad projektem. Czy mimo tego będę rozkminiać o pracy po pracy? Z pewnością. Po prostu postaram się nie pracować po godzinach i wracać do tematu następnego dnia. Zobaczymy, czy mi się uda.

Rozwój to nie wyścig szczurów
Rozwój powinien być umotywowany wewnętrznie, a nie zewnętrznie. To jest nasz czas, który chcemy poświęcić na coś, co jest dla nas ważne, co jest naszą pasją. Rozwój jest w nas, a nie w naszym lęku przed innymi.

Problemem w wyścigu szczurów jest to, że nawet jeżeli wygrasz, to ciągle jesteś szczurem.
– Lily Tomlin

Nie wiem, czy osoby, które gonią za czymś i nie czerpią satysfakcji z godzin spędzonych na kursach, czy nad książkami, mogą mówić o rozwoju, czy bardziej o zmęczeniu i wypaleniu w danym temacie. Wyścig szczurów jest bardzo absorbujący, a przy tym destrukcyjny i w gruncie rzeczy bezcelowy.

Jak się rozwijać?
W sumie, to jak każdemu wygodnie. Ja dużo czytam, jeżdżę na meet-upy i konferencje, zderzam się myślami z wieloma osobami, posiadającymi przeróżne poglądy, wiedzę czy doświadczenia. Często wychodzę dużo szerzej poza świat technologii, czy designu. W moim przypadku najskuteczniejszy sposób na rozwój po pracy to realizacja projektów, w które angażuję się czy to jako wolontariusz (np. współpraca z IKS Jeźdźcy), czy działając z młodymi start-upami, czy realizując własne projekty. W tych działaniach mam możliwość nauczyć się bardzo wielu rzeczy, których nie mam czasu uczyć się w pracy. Uzyskany w trakcie takich działań feedback pomaga mi wzrastać, a przede wszystkim to satysfakcja jest olbrzymia, gdy mogę swoją pracą komuś pomóc.

Jak nie wiesz jak zacząć, to zacznij od godziny w tygodniu, którą przeznaczysz na naukę nowego narzędzia,  języka programowania, rozwijanie własnego pomysłu na biznes, albo na czytanie artykułów z interesującej cię domeny, nawet niekoniecznie związanej z twoją pracą. Ot, cała filozofia.

Źródło tytułowej grafiki: http://adkuchni.blox.pl/2012/06/Sprytna-motywacja.html

Kilka faktów o „IT- arystokracji”

Przeczytałem właśnie artykuł Pana Tomasza Molgi z natemat.pl pod tytułem: IT-arystokracja. Najbardziej zepsuta pensjami i przywilejami grupa zawodowa. Póki jestem „na świeżo” po lekturze tego tekstu, postanowiłem go skomentować.

Ponieważ jestem z branży IT, podobnie jak większość moich znajomych – „IT-arystokratów, zepsutych przywilejami, którzy bez mrugnięcia okiem przejdą do konkurencji za 500 zł podwyżki”, postanowiłem opisać kilka faktów, o których autor zapomniał wspomnieć.

Wiem, że można pisać teksty oparte na sprawdzonych danych, wiedzy i sensownych przemyśleniach. Mocno liczę, że jeżeli ktoś naprawdę jest zainteresowany stanem branży IT w Polsce, to podejmie merytoryczną dyskusję w tym temacie.

Nie chcę swoim postem udowodnić, że wszyscy informatycy są fajni i szlachetni. Oczywiście, że nie. Nie chcę jednak, żeby większość zbierała baty za zdecydowaną mniejszość. Większość osób, z którymi miałem i mam przyjemność pracować od kilku ładnych lat, to zupełnie normalni ludzie. Oczywiście, jak wszędzie, zdarzają się osoby, które robią wiochę, ale to nie jest kwestia bycia informatykiem, tylko co najwyżej kwestia złej kultury wyniesionej z domu i kwestia bycia burakiem.

A teraz fakty, których zabrakło w tekście.

Fakt 1: Informatykiem trzeba najpierw zostać.
Czytając artykuł w natemat.pl można odnieść wrażenie, że jest w Polsce jakaś grupa rozwydrzonych osób, które skądś nagle się pojawiły i każą sobie płacić dużo pieniędzy. A przy tym jeszcze ubierają się w ponaciągane sweterki i flanelowe koszule jak jacyś bezdomni.

Fakty są zgoła inne. Większość osób, które w swoim dorosłym życiu pracuje w zawodzie programisty / QA / managera projektów IT etc., swoją przygodę z informatyką zaczęły już w bardzo młodym wieku. Pamiętam jak sam w szkole podstawowej pisałem swoje pierwsze programy w Pascalu i dłubałem stronki w HTML. Podobnie zresztą jak większość moich kolegów. Obecnie świetnych specjalistów z branży. Nauka przedmiotów ścisłych przez całą młodość, dobrze zdana matura z matematyki i fizyki, dobra znajomość angielskiego to kolejne elementy, które teraz procentują. Następnie 5 lat, wcale nie najprostszych, studiów. Kto kończył informatykę ten wie.

Co do wieku, w którym zaczyna się przygodę z informatyką, to polecam zobaczyć ten filmik.

Tuż po studiach, lub często jeszcze w trakcie studiów, wielu młodych informatyków zaczyna swoją pierwszą pracę, i tu uwaga: nikt wcale nie chce dużo płacić. (Ja zacząłem pracę w IT tuż po drugim roku studiów. Zarabiałem porównywalną kasę do tej, którą zarabiałem jako kelner w jednym z Gliwickich pubów;)) Kasa jednak nie ma znaczenia, bo w tej pierwszej, wymarzonej pracy, wiele osób mogłoby pracować za darmo, ponieważ dopiero będąc w firmie, niezależnie czy w dużej korporacji IT, czy startupie, człowiek dowiaduje się o co w tym wszystkim chodzi. W tak młodym wieku, to właśnie możliwość zdobywania doświadczenia od starszych kolegów i koleżanek z branży jest tak niezwykle cenna. Kto nie pamięta pierwszego czerwonego builda, błędnie przetestowanej formatki, zarwanych nocy i świętowania udanego release’u wspólnie z całym teamem?

Dodam jeszcze tylko, że większości osób, z którymi się przyjaźnię od lat, którzy podobnie jak ja kończyli informatykę, nigdy się w domu nie przelewało. Wszyscy widzieli, jak rodzice muszą ciężko pracować, by związać koniec z końcem. Właśnie przez to, tak wielu z nas ma bardzo duży szacunek do pracy. Ci co nie szanują pracy, bardzo często mieli po prostu wszystko podane pod nos. Nie znam zbyt wielu takich osób w IT.

Fakt 2: Informatyk informatykowi nie równy.
Tekst nie wyjaśnia, kim w zasadzie jest ten cały informatyk.

Za Wikipedią:

Informatyk (łac. informare, -atum: obrazowo opisać) – osoba, która wykształciła się na specjalistę w dziedzinie nauk komputerowych, posiadającego wiedzę i umiejętności na temat ogółu metod tworzenia, przetwarzania i przekazu informacji oraz znającego budowę i zasady działania urządzeń komputerowych, a także potrafiącego tworzyć, przekształcać i przekazywać dane za pomocą programów komputerowych, wykorzystujących umieszczone w nich informacje do określonych działań. Zwykle jest to osoba o wysokim stopniu świadomości ogólnych i szczegółowych zasad tworzenia urządzeń i tworzenia oprogramowania, znająca języki programowania i potrafiąca stosować wiedzę teoretyczną w praktyce.

Ja dodam od siebie tylko tyle. W mowie potocznej informatyk to zarówno Senior Java Developer jak i pan Janek, który instalował Worda pani Basi z księgowości. Pisząc tekst do szerokiej publiczności, warto wyjaśnić odbiorcy o kim się dokładnie pisze.

Fakt 3: Nikt nie zmienia pracy 2 razy w roku.
Ja przynajmniej nigdy nie spotkałem się z takimi osobami. No chyba, że były to bardzo słabe osoby i zmiana pracy nie była tylko i wyłącznie spowodowana ich decyzją. Wdrożenie się w projekt trwa od kilku tygodni, do nawet kilku miesięcy. Projekty w IT potrafią trwać lata, dlatego jeżeli ktoś już wchodzi w jakiś temat, to pracuje nad nim przez dłuższy okres.

W najlepszych na świecie firmach IT rotacja pracowników (dobrowolne odejścia) wynosi około 3% w skali roku. Przeciętnie ten wskaźnik nie przekracza 7 – 8%. Jeżeli rotacja jest powyżej 15% to znaczy, że z daną firmą jest coś nie tak. Patrząc na te liczby jasno widać, że mało jest osób, które „bez mrugnięcia zmienią pracę za 500 zł podwyżki”. Zmiana pracy wiąże się z dużymi wyrzeczeniami, często też ze sporą odwagą.

Jeżeli ktoś decyduje się w końcu zmienić pracę, to albo czuje, że przestaje się rozwijać w tym, co w danym momencie robi, albo np. przeprowadza się do innego miasta, albo naprawdę dostał bardzo dobrą ofertę z innej firmy, która nie tylko wiąże się z wyższym wynagrodzeniem, ale również z ciekawszym wyzwaniem. Dla informatyków dużo częściej znaczenie ma projekt, przy którym się pracuje, niż kasa, którą się zarabia. Kilku moich kolegów zrezygnowało z pracy w firmie, by w tym czasie rozwijać własne projekty, za które przez spory kawałek czasu nikt im nie chciał płacić.

Fakt 4: To wiele osób na około robi zamieszanie, a nie informatycy.
Potwierdzam informację podaną w tekście, że brakuje dobrych specjalistów do pracy. Technologia jest teraz podstawą funkcjonowania naszego świata. Dobrzy programiści potrzebni są wszędzie, ponieważ technologia weszła w nasze życie tak bardzo, że nie potrafimy bez niej żyć i funkcjonować. Poza tym, nie piszę się jednego programu, który później działa przez 100 lat. Technologię trzeba utrzymywać i rozwijać, by lepiej spełniała oczekiwania ludzi i pomagała rozwiązywać ich problemy. Oczywiście, sporo z nią jest też zamieszania, ale nie o tym chciałem teraz pisać.

Największą wartością dla firm IT są ludzie. Brak dobrych specjalistów dostępnych na rynku pracy sprawił, że firmy w różny sposób starają się przyciągać do siebie ludzi. Niektórzy oferują więcej kasy, niż obecny pracodawca, inni, jak cytowany Prof. Filipiak biegną i kupują 100 Renault, a jeszcze inni budują fajną atmosferę w firmie i starają się ludziom zapewnić ciekawe projekty. W zależności od podejścia, jedne firmy przyciągają do siebie albo ludzi, z pasją, inne tych kierowanych motywacją finansową, a jeszcze inne przyciągają ludzi większym poczuciem stabilności.

Fakt 5: Praca w IT wydaje się być pracą marzeń…
Jasne, przecież większość programistów siedzi przy kompie, pisze te robaczki w nawiasach i jeszcze połowę czasu w pracy spędza grając piłkarzyki. Bądźmy poważni, praca w IT, to jest ciężka intelektualna praca, która podobnie jak inne prace, które głównie opierają się na myśleniu, nie kończy się z momentem, w którym wstajemy od komputera.

W nowoczesnych firmach IT praca wygląda inaczej niż w większości innych branży. Wynika to z tego, że ludzie, którzy w IT są od lat, na bieżąco wyciągają wnioski z tego jak realizowane są projekty, co wpływa na ich sukces etc. Głównym składnikiem sukcesu projektu są ludzie, nie technologia, dlatego każdy rozsądny project manager, czy właściciel firmy IT mocno pracuje nad tym, by tworzyć przyjazne środowisko pracy.

Dobra atmosfera przekłada się na na kreatywność i zaangażowanie ludzi, a to przekłada się na sukces.
Zwinne metodyki prowadzenia projektów, ciągłe doskonalenie, praca zespołowa, miła atmosfera, to coś, co z pewnością przydałoby się wdrożyć wszędzie. Boli mnie fakt, że tak mało osób spoza IT,  korzysta z tych prostych, skutecznych i sprawdzonych sposobów pracy. To naprawdę się sprawdza i wiele rzeczy działało by zdecydowanie lepiej, gdyby sposób pracy w IT przenieść do innych branży.

Fakt 6: Polscy inżynierowie rulez.
Mamy w Polsce z kogo być dumni. Polscy inżynierowie wygrywają międzynarodowe konkursy. Jako naród nie powinniśmy mieć żadnych kompleksów jeżeli chodzi o nasz potencjał intelektualny. Wystarczy popatrzeć na kilka ostatnich niusów:

Podobnych artykułów mógłbym tutaj wrzucić dużo więcej.
Szkoda, że większość z tych osób za chwilę wyjedzie za granicę. W Polsce przydałaby się duża i merytoryczna dyskusja, co zrobić, żeby zatrzymać największe talenty w kraju. Szukanie tanich sensacji ku wątpliwej uciesze tłumów, wcale tej dyskusji nie pomaga. Ale cóż się dziwić, „taki mamy klimat”.