Gdzie się warto zatrudnić?

Skąd pomysł

Od dłuższego już czasu sam sobie jestem pracodawcą, toteż nie rozglądam się za typowo rozumianą pracą. Natomiast często osoby, które spotykam w ramach realizowanych projektów i szkoleń zadają pytanie, gdzie się warto zatrudnić.

Ponieważ w ciągu ostatnich kilku lat miałem do czynienia z kilkudziesięcioma firmami, toteż postanowiłem się pokusić o małą typologię firm pod kątem zatrudnienia. Spotkałem firmy, w których osobiście nie chciałbym pracować za żadne skarby, a także takie, w których zatrudniłbym się bez wahania. Poniższa typologia ma charakter czysto subiektywny oraz jest efektem grubych generalizacji. Chętnie usłyszę Wasze głosy, jeśli poniższe generalizacje nie aplikują się do waszych sytuacji.

Wielkość firmy

• Duże firmy (aka korporacje) bardzo często realizują duże projekty, co też często implikuje, że projekty te mają za sobą długą historię. W praktyce oznacza to, że masz duże szanse na utrzymywanie i rozwój kiepsko napisanego systemu w nie najświeższej technologii. Mam też własną hipotezę, iż średni poziom umiejętności jest w większych firmach niższy niż w mniejszych. Więcej w nich polityki i czasu spędzanego na spotkania. Duże firmy mają jedną, niezaprzeczalną zaletę – rozpoznawalną nazwę, co bardzo dobrze wygląda w CV. Drugą zaletą jest to, że zazwyczaj mogą zapłacić więcej (choć to nie jest reguła). Jeśli jednak jesteś craftsmanem i zwolennikiem nowinek, w dużej firmie trudno znaleźć wystarczająco przestrzeni na tego typu rzeczy.

• Średnie firmy pomijam, gdyż tu bywa bardzo różnie. To co się tu dzieje dryfuje albo w stronę wad i zalet małej lub dużej firmy.

• Małe firmy dzielę na dwa typy. Pierwszy typ to kompletna prowizorka, brak reguł, zasad.  Jeśli do tego dojdzie zidiociały szef (często właściciel firmy) oraz nieumiejętność pracy z klientem, to istna masakra. Drugi typ to forma ideału. To rodzaj firmy to wykorzystanie całej mocy niedużej firmy – zwinności, przystosowywania się do zmian i stosowania nieco nowszych technologii i podejść. Jeśli jesteś craftsmanem, to może być miejsce dla Ciebie. Za to zazwyczaj nieco gorzej wygląda kwestia wynagrodzenia oraz firmy tego typu nie dają takiego blasku w CV. No chyba, że jesteś właścicielem, ale wtedy potrzebna będzie smykałka do biznesu.

Software House czy dział w firmie

• Dla software house’u tworzenie oprogramowania to core biznesu. Stanowiska techniczne mają znaczenie i cała firma się „tym” zajmuje, więc większość osób, z którymi pracujesz wie na czym polega tworzenie systemów informatycznych. Oznacza to również, że masz większe szanse na szkolenia, wymianę wiedzy i nabrania sensownego doświadczenia oraz na to, że projekty będą realizowane bardziej „po bożemu” (ale tu nie możesz mieć pewności).

• Niestety działy w firmie są w dużo gorszej sytuacji. Zazwyczaj są działem, który jest traktowany jako koszt oraz ciągle następuje ważenie, czy czasem konsultanci zewnętrzni nie będą się bardziej opłacać. Zazwyczaj zespoły nie są zbyt duże i posiadają mniejszą bazę kompetencji. Więc możliwości rozwoju też są dużo mniejsze. Najtrudniejsza jest jednak współpraca z klientem, który w tym przypadku jest ewidentnie biznesem. Dość często się zdarza, że nie jest to współpraca partnerska.

Firma z Polski lub z zagranicy

Tutaj generalizacje mogą być zawodne, więc na to uczulam. Dużo zależy od tego, czy polski oddział jest uznawany za równorzędnego partnera czy jako tania siła robocza ze wschodu.

• Jeśli polski oddział to równorzędny partner, to jest to bardzo korzystna sytuacja. Bo to oznacza, że z dużym prawdopodobieństwem kultura organizacyjna z kraju macierzystego została przeniesiona do Polski (np. benefity, wygląd biura, dobre praktyki projektowe, wymiana wiedzy i umiejętności). Jeśli firma macierzysta używa Scruma, ty też prawdopodobnie będziesz. Na zachodzie podejścia zwinne są zazwyczaj wdrożone bardziej po bożemu.

• Jeśli polski oddział jest uważany za tanią siłę roboczą, to jest przerąbane. Z dużym prawdopodobieństwem będziesz utrzymywał system, na który nikt nie chce nawet patrzyć w żadnym cywilizowanym kraju. Oprócz tego Twoi koledzy z zagranicy będzie uznawali kontakt z Tobą i dzielenie się wiedzą, jako zło, którego będą unikać za wszelką cenę. Trochę przesadzam, ale ziarno prawdy w tym jest.

• Jeśli chodzi o firmy z Polski trudno wyróżnić mi jakieś konkretne składniki. W wielu firmach (szczególnie tych nie zaliczających się do grupy „duże”) funkcjonuje mentalne poczucie braku, co oznacza bezustanne niedoszacowywanie projektów, praca po godzinach, pewien dość istotny poziom chaosu i dezorganizacji. To są firmy, które ciągle gonią, choć nie zawsze wiedzą za czym. Duże polskie firmy mają bliżej do swoich zachodnich odpowiedników, jedynie wynagrodzenia są nieco mniejsze. Jest również większa szansa, że użytkownikami Twojego systemu będą rodacy a nie Niemcy, Holendrzy czy Amerykanie (którzy nigdy nie wiedzą czego chcą). Ponieważ jesteś swojakiem, jest większa szansa, że będziesz (Twój zespół) miał większy wpływ na wybór technologii czy podejścia do projektu.

Co wybrać?

Zależy kto co lubi. Jeśli chcesz się rozwijać i mieć kontakt ze świeżymi technologiami, to wybieraj software house’y, raczej nie te największe i z Polski. W CV zdecydowanie lepiej wyglądają większe firmy, ale tu jest sporo ryzyko, że będziesz odgrzewał archiwalia i walczył z korporacyjną rzeczywistością. Jeśli cenisz bezpieczeństwo to duże firmy też będą lepsze, gdyż mniejsze są mniej stabilne finansowo. Ale z kolei duże są bardziej podatne na perturbacje globalne, chociażby w przypadku firm zagranicznych, problemy głównej siedziby oraz to, że swojacy będą ważniejszych od obcych. Unikaj firm międzynarodowych, w których Polska jest traktowana jako tania siła robocza. Resztę możesz wywnioskować sobie sam.

A jak jest u Was?

Read More

Unknown 22:29  5 comments

Master... Master...

bynajmniej nie Master of puppets, choć niektórym to by się marzyło.

Rola Scrum Mastera

W świecie rzeczywistym można spotkać wiele wariantów tej roli. Czasami jest to osoba z zespołu, czasami jest to kierownik, czasami jest to osoba spoza zespołu, czasami jest to ktoś kto specjalizuje się w byciu Scrum Masterem, a również spotkałem się z rozwiązaniem, kiedy rola ta jest przechodnia w zespole. No to w końcu - kto to? Po co toto?

W świecie inżynierów oprogramowania nie brakuje świetnych pomysłów. Powiedziałbym, że jest ich aż nadto. Programiści, projektanci, architekci to ludzie ogromnie kreatywni... czasami aż za bardzo. Jednak jest pewno ALE. Otóż dobre pomysły niewiele znaczą. Podobnie jak z intencjami, mogę się założyć, że również dobrymi pomysłami jest wybrukowane piekło. Proszę Państwa, ogłoszę teraz szokującą prawdę, która jest największym sekretem sprawnych zespołów: pomysły trzeba wdrażać w życie oraz wkładać energię, w to aby przetrwały wszelkie trudności. Innymi słowy - nie wystarczy wymyślić, trzeba to zrobić! Już słyszę te głosy: To żeś dokonał wielkiego odkrycia! Ano dokonałem...

Podam pewien przykład (z życia). Kiedyś pracowałem z jednym zespołem nad zmianami w architekturze. Po godzinie pracy, dowiedziałem się, że oni już mają całkiem sensowny projekt zmian, narysowany w formie diagramów. No to pytam: - A kiedy on powstał?
- No ... ponad pół roku temu...
- A ile spędziliście nad tym czasu?
- No będą jakieś 2 tygodnie czterech osób?
- I co z tym później zrobiliście?
- No... nic jakoś tak nie było jak się za to zabrać...
- Czyli nic nie zrobiliście?
- No... tak...

I tak często bywa, szczególnie ze zmianami w architekturze i refaktoryzacji, a także w wielu innych obszarach. My, osoby techniczne, lubimy rozwiązywać zagadki, problemy i tworzyć rozwiązania, ale jeśli chodzi o wdrażanie ich w życie, szczególnie jeśli potrzebny jest szerszy plan i interakcja z innymi osobami, to już gorzej.

I po to jest Scrum Master... żeby się działo... Żeby dosypywać węgla do pieca... Żeby nawet jak się wali, nie odpuszczać i przestrzegać przyjętych założeń. Każdej zmianie, każdemu projektowi potrzebny jest lider, bo to on sprawia, że rzeczy się dzieje, posuwa sprawy do przodu, pomaga rozwiązywać problemy. Nie musi być kierownikiem, po prostu pilnuje czy sprawy idą do przodu.

Zatem które z  wymienionych na początku rozwiązań jest dobre? Każde. Jeśli tylko jest ktoś (lider) lub coś (także zespół), kto dba o to żeby się działo (pilnuje procesu i pomaga rozwiązać problemy).

Mały dodatek na koniec. Pewnie wielu z Was zastanawia się, co z tym przechodnim Scrum Masterem... Powiem Wam w sekrecie... że choć rola była przechodnia, to stał za tym wszystkim ... lider, choć robił dużo, żeby tego nie było widać...

Read More

Unknown 15:34  No comment

Scrum jakiego nie znacie

Ale nie mamy Product Ownera! Product Owner jest niedostępny! Pracujemy w kilku projektach w danym momencie! Terminy nam się przesuwają. Testerzy nie mają czasu, żeby testować nasz kod.

I co Scrum na to? Nic! Choćbyś się prężył, wytężał, biadolił, nic! Ortodoksyjni Scrumiści powiedzą, to nie jest zgodne ze Scrumem. Powiedzą, że jeśli macie problemy to z tego powodu - że Scrum nie jest wprowadzony w całości.

Ale wprowadzenie praktyk Scrumowych jest trudne, o czym możecie przeczytać w artykule Michała. Natomiast czy ortoksyjni Scrumiści mają rację? Czy sam fakt, że nie wszystko zostało wdrożone zgodnie z zasadami Scrum, powoduje, że się on nie powiedzie? Otóż, temu chcę zaprzeczyć.

Dawno, dawno temu, kiedy poznawałem Test-Driven Development, usłyszałem takie zdanie (ciągle promowane przez Uncle Boba): "Nie wolno napisać ani jednego wiersza kodu, do którego nie istnieje test". Czy to prawda? Nie! Oczywiście, że wolno. Oczywiście, że wolno i powie to każdy wprawiony adept TDD, jednak, aby robić to z głową, potrzeba nielada doświadczenia i wyczucia.

I podobnie jest ze Scrumem. Być może nie dostaniesz stempelka "Scrum Certified", ale możesz to robić równie dobrze.

Główny problem wynika z tego, że w większości przypadków używając danego czy innego podejścia, skupiamy się na zasadach, na literze prawa, a nie na duchu... A wtedy mamy dwa wyjścia: albo się całkowicie podporządkować literze, albo zacząć ją łamać, usprawiedliwiając swoje błędy.  

Ortodoksyjni Scrumiści (Ci którzy wydają certyfikaty), zawsze będą mówić, że musisz działać wedle litery. Bo tylko wtedy mogą zagwarantować, że to zadziała. Jak robisz własne przeróbki, to tracisz gwarancje.

A co nam może stanąć na przeszkodzie?

Zatem mamy zielone światło co do przeróbek, jednak chciałbym Cię ostrzec. Przeróbki to duża odpowiedzialność, gdzie na przeszkodzie stoi nam nasz największy wróg, czyli my sami. A dokładniej chodzi o mechanizm racjonalizacji.

Mam okazję prowadzić od czasu do czasu szkolenia i mam do czynienia z tym mechanizmem bardzo często. Pojawia się on między innymi w sytuacjach, kiedy mówimy o jakimś rozwiązaniu, narzędziu czy podejściu, które wymaga dużego wysiłku, żeby go wprowadzić w życie. Wtedy uczestnicy często szukają usprawiedliwień i uzasadnień, dlaczego tego nie można u nich zrobić, dlaczego się nie da. Najczęściej oznacza to, że:

• po prostu potrzeba sporo czasu, żeby to zaczęło działać,
• jest to trudne do wykonania (trzeba negocjować z wieloma osobami, jest ryzyko, że dostaniemy po głowie),
• już kiedyś próbowaliśmy i się nie udało, jednak prawdopodobnie dlatego, że nie wiedzieliśmy, jak to zrobić.

Dlatego w pierwszej kolejności, jeśli chcesz coś usunąć ze Scruma lub zmienić (np. namówić swojego Product Ownera (klienta/osobę z biznesu), żeby był bardziej dostępny, bo jest za oceanem i nie ma zbyt wiele czasu), to bądź ze sobą brutalnie szczery i przeprowadź ze sobą taką dyskusję (nie rób tego zbyt głośno, bo Twoi współpracownicy będą dziwnie na Ciebie patrzyć ;-)):

• może mi po prostu brakuje odwagi, żeby to zrobić?
• może musiałbym być asertywny wobec szefa i nie wiem jak zareaguje, albo obawiam się, że źle zareaguje?
• może obawiam się, że dostanę po tyłku, jak zaproponuję inne rozwiązanie?
• gość zawsze wrzeszczy, więc pewnie będzie wrzeszczał tym razem!
• a jak mnie wywali z roboty?

Niestety (albo stety), prawdziwy powód, że się nie da, w 90% przypadków leży właśnie tu, więc dobrze się zastanów czy czasem właśnie nie stosujesz plastra na ranę (w formie zmian procesu Scrumowego), zamiast podjąć leczenie.

Co jest potrzebne?

Załóżmy jednak, że jesteś przekonany i obiektywnie pewny, że trzeba jednak coś zmienić w zasadach. Kluczem jest to, żeby zrozumieć, jaki duch stoi za zasadami zapisanymi w Scrum Guide (czy jakimkolwiek innym podejściu typu TDD, BDD, DDD, Kanban etc.) A to nie jest łatwe, bo nie zawsze jest to wprost wypowiedziane przez twórców metody. Często wręcz sami twórcy nie do końca wiedzą, dlaczego to jest potrzebne, mimo że intuicyjnie są przekonani, że tak musi być. A później community przez wiele lat próbuje nadać temu sens.

Dlatego pokrótce chciałbym przyjrzeć się owym Scrumowym zasadom. Temat ten będzie rozproszony na kilka postów. Dzisiaj zaczniemy od Product Ownera.

Product Owner

To chyba najbardziej newralgiczna część implementacji Scrum. Bardzo rzadko udaje się spełnić oczekiwania postawione przez metodę. Scrum mówi o roli, która jest związana z biznesem. Kogoś kto odpowiada za projekt od strony biznesu/klienta i podejmuje decyzje z tego punktu widzenia. Dla mnie główne przesłanie tej roli jest następujące:
W KAŻDYM PROJEKCIE PROGRAMISTYCZNYM, JEŚLI MA ON MIEĆ SZANSE POWODZENIA, MUSZĄ BYĆ DOBRZE USTAWIONE RELACJE Z BIZNESEM.

Co to konkretnie oznacza:

• jest jeden punkt odnośnie decyzji biznesowych - jest jedna osoba (lub jeden byt), który podejmuje decyzje odnośnie dalszych losów projektu oraz wymagań). Często praktycznym problemem jest to, że wymagania przychodzą z wielu źródeł (np. różne departamenty w firmie, różne osoby) i to zespół musi sobie z tym radzić. To nie jest dobre. Zespół nie ma w większości odpowiedniej perspektywy biznesowej, żeby takie decyzje podejmować. Ale może podpowiadać, sugerować lub namawiać i to jest ok. 
• biznes jest dostępny na konkretnych zasadach - ideałem Agile jest tzw. customer on-site, który pracuje bezpośrednio z zespołem, co jest rzadko wykonalne (choć warto o to walczyć do upadłego). Ważne jest, żeby ustalić konkretne zasady współpracy up-front. Te zasady powinny dotyczyć takich tematów:

• kiedy zespół może się komunikować z osobą decyzyjną, 
• z jakimi sprawami, 
• jakiego zaangażowania ze strony tej osoby potrzebuje zespół, 
• jak będą rozstrzygane sytuacje sporne, 
• jak będą rozwiązywane problemy
• jak będziemy uwzględniać zmiany
• w jaki sposób wymieniamy się informacją zwrotną (tu Scrum proponuje gotowce w formie Scrum meetingów oraz Sprint Review oraz Sprint Retrospective).

Kluczowe jest to, że określić dlaczego dla obu stron te zasady są ważne.
Zatem czy mamy kogoś kto nazywa się Product Ownerem czy nie, nie ma znaczenia. Jeśli jesteśmy w stanie ustawić odpowiednio relacje z biznesem, to jesteśmy w domu. Jeśli nie, żadna metoda nam nie pomoże.

To na początek. Reszta w kolejnych postach.

Read More

Unknown 12:18  No comment