Developing in the clouds

Dzień w dzień dostaję mnóstwo wiadomości na LinkedIn z propozycją pracy. Staram się przeglądać te wiadomości i w miarę na bieżąco odpisywać. Z reguły kulturalnie mówię “nie, dziękuję, nie jestem zainteresowany”, jednak od czasu do czasu znajdzie się jakiś rekruter, który mnie zaciekawi i chwilę z nim porozmawiam. Czasami można złapać z kimś fajny kontakt rokujący na przyszłość, a czasami to tylko przekopiowana wiadomość, wysłana jeszcze do 10 innych osób (często nawet moje imię się nie zgadza). Przeglądając te wiadomości można trafić na rozmaite projekty. Jedne z nich mają po kilkanaście lat, inne dopiero się zaczynają. Nie lubię robić kroku w tył, więc zawsze interesują mnie te nowe – pełne możliwości rozwoju, dobrania nowych technologii i rozwiązań, pracy z fajnymi ludźmi z którymi wspólnie można rozwiązywać kolejne problemy biznesowe. Czy taki projekt może się nie udać? No właśnie.

Dobre złego początki

Abstrahując od LinkedIn, być może po prostu wybrałeś firmę, z którą chcesz współpracować. Zaczynasz nową pracę, #LudzieJużSą, wybieramy technologie i rozwiązania. Jest pięknie, uczysz się nowych rzeczy, pracujesz z kompetentnymi ludźmi o dużej wiedzy i doświadczeniu. Czujesz, że się rozwijasz, a aplikacja może być czymś naprawdę fajnym. Niestety jak to w każdym projekcie (prawie) trzeba konsultować się z klientem. Tu nagle pojawia się problem. Klient nie wie czego chce i ciężko zebrać jakieś wymagania biznesowe… Ale chwila, przecież to idealny scenariusz pod Scrum! Róbmy to iteracyjnie, zbierajmy wymagania ze sprintu na sprint. Budujmy backlog i działajmy, planujmy. Gdyby nie ten deadline…

Karuzela IT

Na rynku jest tak wielkie zapotrzebowanie na programistów, że rotacja pracownikami w firmie to chleb powszedni, a ludzie przychodzą i odchodzą. W jakiś sposób trzeba się przed tym zabezpieczyć – zatrudnić nowe osoby lub (jeśli pracujesz w większej firmie) dobrać programistów z innych lokalizacji. Generuje to kilka problemów. Jednym z nich jest wdrożenie nowych osób w istniejący kod. Jest to czasochłonne, szczególnie dla osób z innych lokalizacji, gdy aplikacja jest w zaawansowanej fazie rozwoju. Załóżmy, że projekt prowadzony jest w lokalizacji A, kolejni programiści przychodzą z miejscowości B, C i D w Polsce. Pojawia się nowa osoba w jednej z nich i trzeba ją wprowadzić. Opowiadanie o kodzie i założeniach biznesowych zajmie pewnie chwilę, ale odpowiadanie na pytania i doradzanie co, gdzie i jak działa, to kolejne godziny spędzone w słuchawkach. Siłą rzeczy czas, który można poświęcić na pisanie kodu traci się na wdrażanie nowych osób. Czy to wartość dodana? To zależy od tego ile nowa osoba będzie w stanie wnieść do projektu po czasie wdrożenia. A co jeśli taka osoba nie sprawdzi się, a w tym czasie decyzję o odejściu podejmą kolejne osoby? Karuzela kręci się.

Trochę Agile – Fixed Scrum

Działamy w Scrum, a karuzela kręci się tak szybko, że kolejne osoby odchodzą, a nowe potrzebują sporo czasu, żeby wejść w odpowiedni tryb pracy. Nagle okazuje się, że dostarczenie sporej części funkcjonalności jest zagrożone. Klient bardzo późno określa wymagania biznesowe, a deadline nie zmienia się – wręcz zbliża wielkimi krokami, ponieważ jesteśmy z nim związani umową. Zaczyna się dorzucanie ludzi na ostatnią chwilę. Czy to ma sens? Jeśli do zespołu dołączy pięciu nowych programistów zamiast tego jednego, który znał go od podstaw, czy na dwa miesiące przed deadlinem projekt ma szansę zakończyć się sukcesem? A czy 9 kobiet jest w stanie urodzić dziecko w jeden miesiąc? Czy to dalej scrum, jeżeli mamy deadline na dostarczenie określonych funkcjonalności i mimo planowanych sprintów okazuje się, że nie jesteśmy w stanie dostarczyć nawet MVP w terminie? Czy to już nie jest fixed price?

Wykolejony pociąg

Jako programista wybrałeś się w podróż luksusowym pociągiem. Siedzisz w pierwszej klasie. Obsługa podała Ci najnowsze technologie w cenie biletu (plus kawę), a Ty komfortowo podróżowałeś do celu. Niestety, na stacjach pośrednich wysiadło kilka osób, a kolejni pasażerowie kupili bilety na przejazd drugą klasą, a część w ogóle się spóźniła i nie udało im się wsiąść. Co gorsze – najważniejsze osoby postanowiły odbyć podróż samolotem i totalnie zignorowały jadący pociąg. Na samym końcu dochodzi do tragedii – pociąg się wykoleja, projektu nie udało się ukończyć. Ludzie wysiadają z samolotu i nie są w ogóle świadomi tragedii jaka się wydarzyła.

Kilka lat ciężkiej pracy

Wyobraź sobie, że otwierasz oddział swojej firmy w jakiejś wybranej miejscowości w Polsce. Budowanie takiego oddziału to ciężka praca wielu osób. Może to trwać latami. Budujesz zespoły, szukasz im projektów w tej lokalizacji. W pewnym momencie widzisz duży potencjał w ludziach, którzy tam pracują. Jest to solidny fundament, który mógłby ten oddział utrzymać przez kolejne lata – udało się. Do ludzi, którzy rozpoczęli tam pracę trafia właśnie taki projekt, który ma się w przyszłości wykoleić. Nagle z oddziału odchodzi jedna osoba, potem druga. Na ich miejsce trafiają nowe osoby, ale z innych lokalizacji. Żeby załatać takie dziury trzeba zatrudnić nowe osoby w to miejsce. Niestety do tego potrzeba zgody tych ważniejszych osób z samolotu, ale one zignorowały jadący pociąg. Lata wysiłku włożone w budowanie czegoś fajnego powoli idą na marne. Smutne.