Pracownik IT ma generować zyski

Dziś będzie brutalnie. Dlaczego pracodawca miałby Tobie dużo płacić? "Bo to IT"? Dobre żarty. "Bo znam się na X"? Ha ha ha! Otóż pracodawca może dużo zapłacić, jeśli czuje, że zarobi na Tobie jeszcze więcej. :-)

Jak można zarobić na pracowniku IT?

• Można go komuś odsprzedać z marżą. Popularny motyw w różnych informatycznych stonkach. Firma ma dojście do koryta, a studenci lubią pracę po nocach bo chcą zarobić na piwo.
• Można też wykonać jego rękami zmiany, które przyniosą realne oszczędności w firmie. I taki jest sens istnienia IT w firmie: obniżać koszty poprzez automatyzację, umożliwiać poprzez informatyzację.

Płyną z tego pewne oczywiste wnioski dotyczące zarobkowania w IT:

• nie idziesz do stonki po kasę, a co najwyżej po know-how
• jeśli IT w firmie jest tylko kosztem, to mogą mieć kiepski budżet na płace
• jeśli sprzedajesz się do jakiejś firmy, nie skupiasz się tylko na tym co umiesz, ale także na tym, ile to pozwoliło poprzednim firmom zaoszczędzić/zarobić pieniędzy
• im bardziej niszowa i gówniana technologia, tym lepiej dla portfela (choć gorzej dla satysfakcji)
• warto być blisko koryta (prawidło uniwersalne)
• dobrze jest wynajmować tanich wyrobników w Polsce B, sprzedawać ich za dobrą stawkę w Polsce A i odcinać kupony od podjętego ryzyka

Porcja linków

Krucho z czasem na pisanie, na szczęście na czytanie jeszcze czas znajduję. Powielę zatem sprytny chwyt kilku innych blogerów i opublikuję posta z porcją ciekawych linków. ;)

Porównanie implementacji systemu plików ZFS w systemach: Solaris 11 Express, Nexenta, OpenSolaris i FreeBSD: "ZFS Feature/Dist table". Różnice potrafią być dosyć znaczne. :)

Jak zarobić w Internecie? Wywiad z Rafałem Agnieszczakiem, twórcą m.in. serwisu fotka.pl: "Nie dostrzegam jeszcze własnych niedoskonałości". Można też błysnąć w Sieci inaczej, czyli wywiad z Kominkiem: "Chcę być najdroższy".

Wprowadzenie języka Lua do systemu bazowego NetBSD: "The Lua Scripting Language". Według mnie to bardzo nowatorskie posunięcie, nic dziwnego, że wzbudziło kontrowersje. Jednym z interesujących skutków może być tworzenie w Lua dodatków do jądra (Lunatik).

"Poor man's profiler"—czyli jak biedny deweloper można sobie radzić, gdy wielowątkowa aplikacja robi nie wiadomo co. ;)

Co robić po IT? Czyli o tym, że starszy człowiek w IT nie piastujący stanowiska kierowniczego wygląda dziwnie: kariera w IT na forum Gazety. Właśnie teraz, póki mam daleko do 40-tki ;) jest czas na zaplanowanie kierunków swojej kariery. Zmiana branży może być obarczona dużym kosztem wejścia i  poważną utratą zarobków.

O grudniowym kolapsie sieci Skype: "Lessons Learned from Skype's Outage". Osobiście nie lubię, gdy oprogramowanie aktualizuje mi się samo. ;)

Do mas nadal nie dociera, że musimy wejść w IPv6: "Piętnaście lat IPv6". Karty zostały rozdane. ;) Ciekawe, ile lat będziemy optymalizować obecne wykorzystanie IPv4 broniąc się przed IPv6? Spodziewam się, że zaskakująco długo...

Wydaje się, że architekura ARM wskoczyła na swoją falę i nic już tego trendu nie zatrzyma: "Windows NT on ARM: It's a Server Thing". Pamiętam, że gdy lata temu we FreeBSD pojawił się port arm, dziwiłem się że ktoś traci czas na takie pierdoły. ;)

Terytoria IT

Kilka dni temu wysłałem IT do psychiatry. Dziś serwuję (za Just Enough Developed Infrastructure) IT wraz z otoczeniem zobrazowane na mapie - The Map is not the Territory: The IT-World Anno 2010. Klienci, użytkownicy, wielka czapa wszelkich form zarządzania, rozwój, testowanie i utrzymanie, bezpiecznicy, service desk oraz infrastruktura.
Ładnie to wygląda, ale co to oznacza w praktyce? W realnym świecie mamy np.:

1. Podział na biednych i bogatych. Jeden dział ma lepsze "przełożenie" i konsumuje pieniądze potrzebne innym działom.
2. Strefy skażenia. Nikt nie chce ich nawet dotykać (syndrom "to nie moje").
3. Wojenki. Jeden lokalny kacyk robi na złość drugiemu za nie swoje pieniądze i trzeba go jakoś obchodzić, żeby dopiąć celu.
4. Każdy sobie rzepkę skrobie. Brak zdolności współpracy w obliczu nadciągającej katastrofy.

Brzmi znajomo?

Motywowanie w IT

Polecam lekturę artykułu Radość i satysfakcja poświęconego motywowaniu pracowników branży IT.

Niestety, zwolennicy systemów motywowania bazujących na premiach finansowych wysnuli z tego błędny wniosek, że skoro brak pieniędzy demotywuje, to same pieniądze motywują. Niestety, są w błędzie. Niestety, gdyż pomysł ten szerzy się jak zaraza i doprowadza coraz częściej do tego, że informatycy zastanawiają się nad tym jak udowodnić, że efektywnie pracują, zamiast po prostu efektywnie pracować.

Wybrane spostrzeżenia:

1. Za pewną granicą pieniądze już nie motywują.
2. Praca powinna dostarczać przyjemności i być wykonywana z pasją.
3. Ważne jest poczucie realnego wpływu na projekt od momentu jego powstania.
4. Projekt powinien budować wrażenie, że robimy coś sensownego.
5. Szkolenia powinny być zgodne z oczekiwaniami pracownika, a nie tylko doraźnymi potrzebami pracodawcy.
6. Dostarczone narzędzia pracy powinny być dobrej jakości i pomagać, a nie przeszkadzać.
7. Miejsce pracy powinno zapewniać wygodę i możliwość skupienia się.

Link do artykułu znalazłem na Blogu rekrutacyjnym, który sam w sobie również wydaje się godny polecenia.

DevOps - utopia czy źródło przewagi konkurencyjnej?

Czy deweloperzy powinni mieć dostęp do systemów produkcyjnych?
Odpowiedź na to pytanie wydaje się prosta. Oczywiście, że tak/nie! (zależnie, kto odpowiada). ;-)

 

W dużych firmach o strukturze silosowej zwykle podział ten jest "naturalny". Z kolei w małych firmach, gdzie wszyscy zajmują się wszystkim, podziału takiego nie ma. Rozdzielenie rozwoju systemów od ich utrzymania ma niewątpliwie pewne zalety, ale wydaje się, że zyskuje ostatnio na popularności trend odwrotny - nazwany DevOps.

Aby dobrać właściwy model, należy przeanalizować potrzeby i ograniczenia konkretnej organizacji. Osobiście skupiłbym się przede wszystkim na następujących czynnikach:

• niezawodność/dostępność - deweloperzy bez doświadczenia utrzymaniowego mogą zwyczajnie zagrozić stabilności środowiska produkcyjnego
• integralność - deweloper majstrując przy wnętrzu aplikacji na produkcji może np. rozspójnić dane
• poufność - deweloper z dostępem do produkcji to dodatkowe potencjalne źródło wycieku danych
• wymogi formalne - przepisy prawa mogą wymuszać na danej organizacji wyraźne odseparowanie rozwoju systemów od środowiska produkcyjnego
• generyczność aplikacji - system może być rozwijany pod to jedno, konkretne wdrożenie i wymaga głębokiej wiedzy o zachowaniu systemu na produkcji
• zmienność - systemy bywają modyfikowane bardzo często lub np. raz na kilka lat
• skuteczność - rozwiązywanie problemów bez dostępu do produkcji może być trudne, długotrwałe, a przez to kosztowne
• procedury i struktura firmy - procedury bywają stosowane bezmyślnie, dodatkowo rozdział rozwoju od utrzymania generuje więcej stanowisk dla menedżerów, którzy mogą mieć słabą komunikację lub wręcz konkurować

Tak więc należy ustalić, czy w danej sytuacji deweloper na produkcji bardziej szkodzi czy pomaga? I jeśli nie ma naprawdę dobrych powodów uzasadniających ścisłą separację rozwoju od eksploatacji, tej separacji warto po prostu unikać jako szkodliwego narzutu. :)

Niektórzy idą dalej i łączą obie funkcje: rozwój i eksploatację (we code and run). Wydaje mi się, że to nie zawsze ma sens, np. w przypadku aplikacji biznesowych, gdzie duży wysiłek dewelopmentu to prace analityczne. Ale w przypadku aplikacji webowych, tolerujących krótkotrwałe przestoje i zdolnych testować nowe funkcjonalności na końcowych użytkownikach - jak najbardziej.

Sporo ciekawych uwag na ten temat można przeczytać we wpisie Should Developers have Access to Production? oraz jego komentarzach.

 

Tematyka zaszczepiania DevOps nie tylko przy utrzymaniu środowisk web, ale w organizacjach typowo biznesowych (w tym przekonywania menedżerów do tego podejścia), jest także tematem niniejszych paneli InfoQ:

• DevOps outside of Web Operations
• Making the Business Case

Uczestnicy zwracają w nich uwagę m.in. na:

• model DevOps to nie zwykła zmiana organizacyjna lecz zmiana kultury (rozbijanie silosów) i nie należy jej wprowadzać odgórnie, raczej przez dobry przykład
• można pokazać DevOps jako podejście ułatwiające osiągnięcie celów biznesowych organizacji
• istotne jest wcześniejsze ustalenie dobrych metryk (KPI) - bez tego nie da się menedżerom pokazać, czy zmiana cokolwiek poprawiła (np. skrócony TTM)
• metryki należy monitorować i stopniowo doskonalić organizację
• dla menedżerów wyższego szczebla często nie liczą się już liczby, lecz zaszczepienie wizji

 

Podsumuję cytatem z posta What Is This Devops Thing, Anyway?

Devop requires a certain state of mind. It's an attitude which says: I'm going to make a difference, I'm going to cooperate and communicate, and I'm going to understand that in the business of delivering great software, we're all in it together. If you're a sysadmin, this means spending time with the developers. (...) If you're a developer, go and make friends with your sysadmins. Don't view them as lower life forms, or as people to lob problems to. Go and join in - pair with them.

Brzmi jak utopia? ;-)

Migracja zawodowa w IT

Zdarzyło mi się zmienić miejsce zamieszkania celem uzyskania dostępu do lepszego rynku pracy IT (czytaj: przeprowadziłem się do Warszawy). Nigdy jednak nie rozważałem serio wyjazdu z Polski. Powodów jest kilka:

• w Polsce są rodzina, znajomi i przyjaciele
• odwiedziny kogoś w innym mieście zwykle są w zasięgu kilkugodzinnej podróży
• w Warszawie można uzyskiwać bardzo dobre dochody
• pomijając niektóre sklepy, koszty życia w Polsce są stosunkowo niskie
• bariera językowa - angielskiego używam głównie do czytania dokumentacji technicznej

Jednak od czasu do czasu dociera do człowieka impuls, który każe się zastanowić, czy nie lepiej byłoby stąd wyjechać do jakiegoś milszego kraju, np.:

• majstrowanie rządu przy VAT i OFE
• oszołomstwo obrońców krzyża i innych
• tor przeszkód między żebrakami, wszelkiej maści cwaniaczkami i agresywnymi pijanymi wyrostkami, jaki trzeba czasem zaliczyc idąc przez Centrum
• śmieci na trawnikach, palenie papierosów na przystankach i inne przejawy buraczanej mentalności
• irracjonalnie wysokie wyceny nieruchomości w Warszawie

Do tego dodałbym czynniki strategiczne:

• fatalne perspektywy demograficzne i praktycznie pewne załamanie systemu emerytalnego
• brak klasy rządzącej z prawdziwego zdarzenia i długofalowej strategii rozwoju Państwa
• podtrzymywanie iluzji dobrobytu poprzez bieżące przejadanie majątku narodowego
• mentalność "Państwo powinno mnie wspomóc" i silne poparcie polityków, którzy obiecują rozdawnictwo
• potencjalnie groźnych sąsiadów

Mówiąc wprost, o ile nie nastąpi jakaś istotna zmiana, perspektywy Polski za 20-30 lat widzę w barwach raczej ciemnych niż jasnych.
 
Wracając jednak do migracji zawodowej - do podjęcia rozważań i umieszczenia tego posta zainspirowali mnie rekruterzy firm zagranicznych, którzy zechcieli do mnie zagadnąć. Oczywiście, zagadują oni pewnie wiele osób, a tylko niektórym faktycznie udaje się przejść rekrutację (po czym jeszcze mniej z nich faktycznie decyduje się na przeprowadzkę). Konkretnie, poproszono mnie o wysłanie CV w następujących kierunkach:

1. Dublin (Irlandia)
2. Zurych (Szwajcaria)

Przyznam, że nigdy nie byłem w tych krajach i nie wiem o nich wiele. Szybkie skojarzenia miałem następujące:
 
Irlandia

• w niedalekiej przeszłości przepychanki z Wielką Brytanią i bieda
• wielka migracja Polaków w tym kierunku
• załamanie na rynku nieruchomości i ogólnie kryzys
• zdolność do szybkiego powstawania z kryzysów i rozwoju (ich kiełbasa łatwo przegoni naszą)
• niskie podatki, którymi narażali się UE
• są za wodą i jeżdżą po złej stronie ulicy

 
Szwajcaria

• neutralność i bezpieczeństwo, broń pod łóżkiem a za oknem góry
• jedno z centrów finansowych świata
• obywatelskie społeczeństwo
• autonomia - własna waluta, "nie" dla meczetów i UE
• bardziej przyda się tam niemiecki (którego nie znam) niż angielski

Podsumowując szybkie skojarzenia - oba kraje wyglądają fajnie, ale Szwajcaria bardziej, tyle że asymilacja jest zapewne trudniejsza/niemożliwa.
 
Oczywiście, wyboru nie podejmuje się na podstawie danych tak marnej jakości. ;) Zacząłem się więc zastanawiać, jakimi kryteriami posłużyć się przy bardziej szczegółowej analizie - o ile zdarzyło by się, że faktycznie stanę przed takim dylematem.

Wymyśliłem na razie następujące:

1. obecny stan i prognozowany rozwój (demografia, gospodarka)
2. bezpieczeństwo geopolityczne
3. bezpieczeństwo fizyczne
4. system podatkowy
5. czystość środowiska
6. zamożność społeczeństwa, liczność i realny wpływ warstw domagających się tzw. socjału
7. zarobki minimalne, średnie i średnie zarobki w IT
8. realne koszty pobytu i życia (żywność, komunikacja, rozrywki)
9. ceny nieruchomości i ceny najmu, dostępność
10. kultura społeczeństwa
11. łatwość i koszt podróżowania między Polską a danym krajem

Coś jeszcze? W tzw. wolnej chwili może jeszcze do tego wrócę.