O tym, że na rynku pracy brakuje informatyków wiedzą wszyscy. Nie wszyscy jednak zdają sobie sprawę o jak dużych liczbach mówimy. Szacuje się, że w Polsce brakuje ich około 50 tysięcy, a w Unii Europejskiej prawie 500 tysięcy. Dla startupów są to wiadomości dobre (bo oferując outsourcing poza granicami kraju mamy dużą szansę znaleźć klientów), jak i złe (bo gdy programista odejdzie, trudno będzie znaleźć osobę na jego miejsce).
Zdjęcie royalty free z Fotolia
Przed dalszą lekturą zachęcam do zapoznania się z dwuczynnikową teorią Herzberga, mówiącą o tym czym są czynniki higieny pracy (zakładam, że są one spełnione) a czym motywatory (na nich skupia się dalsza część tekstu). Przeczytaj cytaty „anty szefa” i zobacz jak nie powinno się zarządzać zespołem programistycznym.
1. Oczekiwanie rzeczy niemożliwych i składanie deklaracji w imieniu zespołu przez kierownictwo
„Posłuchajcie, po raz trzeci mówię, że potrzebujemy tego na jutro. Schowajcie te głupie karty do plannig pokera – nie bawmy się jak dzieci. I nie wyskakujcie z tekstem, że to niby podobne do metody delfickiej – ten temat zostawcie filozofom. Jesteśmy poważna firmą i składamy poważne deklaracje, których musimy dotrzymywać. Klienci wymagają dużo i na wczoraj – takie czasy.” Składanie niemożliwych do spełnienia deklaracji w imieniu innych osób demotywuje. Ignorowanie nowych metodyk i sprawdzonych technik estymacyjnych, świadczy o tym, że firma się nie rozwija. Postawa życzeniowa oraz nadawanie powagi deklaracjom wyssanym z palca nie ma żadnego związku dobrym zarządzaniem. Tyle wystarczy, żeby zmienić pracodawcę.
2. Niekończące się projekty
„Tak wiem, że ten projekt ciągnie się trzy lata. Wiem, że można by go poprowadzić iteracyjnie albo zwinnie, ale zrozum: u nas to nie zadziała i już. I nie mów, że Ci się znudziło: wcześniejsze pokolenie całe życie pracowało w jednej firmie. Pytasz dlaczego musisz notorycznie zostawać po godzinach? Bo jesteśmy po terminie, a budżet został już przekroczony – dlatego!” Długi projekt potrafi wypalić zawodowo każdego programistę. Prowadzony w trybie waterfall dodatkowo wydłuża okresy beztroski (początek projektu) oraz stresu (końcowe etapy projektu). Deweloperką po godzinach trudno jest nadgonić błędy spowodowane złym zarządzaniem lub brakiem analizy.
3. Niska jakość analizy biznesowej
„Wiem, że nasz analityk nie jest najwyższych lotów. Materia też nie jest łatwa i nie da się wszystkiego precyzyjnie opisać. Ale od ciebie jako programisty oczekuję, że aplikacja będzie działała dobrze! Co to znaczy dobrze? Nie żartuj – sam to powinieneś wiedzieć.” Aplikacje powstają na podstawie wymagań. Rolą analityka jest dostarczenie wymagań precyzyjnych i zrozumiałych. Jakość pracy programisty powinna być oceniana na podstawie kodu jaki tworzy a nie tego co robi aplikacja – za to odpowiada Analityk (ewentualnie tester). Trudno jest spełnić oczekiwania, gdy nie są one znane.
4. Brak feedbacku o jakości pracy
„Znowu zawaliłeś termin. Nie próbuj się tłumaczyć, że ostatni projekt skończyłeś przed czasem, że w tym robiłeś po godzinach i nie chcesz za to pieniędzy ani tym, że kod jest napisany zgodnie z MVC i testy jednostkowe pokrywają 60 LOC. Mówisz, że w innych firmach jest system ocen pracowniczych, wyznaczanie celów i świętowanie sukcesów? Jesteś baba czy programista?” Programista powinien otrzymywać informację zwrotną bez względu na jakość jego pracy. Docenienie wysiłku spowoduje, że wysiłek będzie wkładany dalej. Informacja negatywna, pozwoli zidentyfikować obszary rozwoju. Nie wiesz jak? Zacznij od feedback sandwich.
5. Brak możliwości rozwoju zawodowego
„Pracujesz już u nas sześć miesięcy i masz największy staż w firmie – najwyższa pora, abyś został liderem technicznym zespołu.. tj. architektem. Z objęciem tej roli oczekuję, że będziesz poświęcał trochę wieczorów na samokształcenie. Nie będę Cię wysyłał na szkolenia, bo badania wykazują, że najwięcej uczymy się w miejscu pracy oraz podczas nauki własnej. Jak trafisz na jakiś problem zapytaj google lub stack overflow!” Większość programistów jest osobami nastawionymi na ciągły rozwój. Najszybciej uczymy się w miejscu pracy spędzając czas z osobami o większych kompetencjach. Jeżeli takich nie ma, pozostają szkolenia, których atutem są przerwy kawowe i dyskusje podczas których uczestnicy wymieniają się doświadczeniami (i uczą). Strony www można traktować jako suplement, nigdy jako substytut.
6. Bałagan w kodzie
„Dlaczego ta funkcjonalność zajmie aż siedem dni? Przecież to tylko zmiana pola na formatce. Mówisz, że to spaghetti code i przydałby się refactoring? To wszystko wina Kowalskiego, który już u nas nie pracuje. Zrób to na jutro, a jak będzie chwila to kiedyś zrobimy ten „refaktor”. Zdarzyło mi się rozmawiać z programistami, którzy po kilku dniach pracy w nowej firmie odchodzili z uwagi na zbyt niską jakość kodu aplikacji, którą mieli rozwijać. Wraz ze wzrostem doświadczenia, rosną oczekiwania do jakości pracy – a jednym z jej wyznaczników jest jakość kodu. Czysty kod jest również tańszy w utrzymaniu.
7. Łączenie roli testera i programisty w jedną
„Pamiętaj, aby przetestować to dobrze, zanim pójdzie na produkcję. To kluczowa funkcjonalność dla klienta i od niej zależy dalsza współpraca. Nie próbuj ściemniać, że testerzy są specjalistami w swojej dziedzinie, przetestują to z szerszej perspektywy i dokładnie udokumentują – w końcu jako autor powinieneś najlepiej znać tą funkcjonalność. ” Komentarz znajduje się w punkcie 8.
8. Przełączanie połączeń z helpdesku do programistów
„Kiepsko napisałeś, to teraz wyjaśnij pani Dyrektor z firmy X dlaczego nie można się zalogować. Co? Nie ta przeglądarka? I jeszcze mówisz, że pierwsza linia wsparcia mogłaby to załatwić i że niby taniej by było? Zapomnij, ja tu jestem managerem – nie stać nas na to.” Rolą programisty jest programowanie: w tym celu podejmuje tą pracę. Gdyby chciał zostać konsultantem, aplikowałby na stanowisko konsultanta. Jeżeli to Cię nie przekonało, zorientuj się w stawkach godzinowych pracy dewelopera oraz osoby pracującej w pierwszej linii wsparcia.
Cezary Kamiński
Scrum Master w Sii
W branży IT od 2009 roku. Przez ponad 2 lata zarządzał działem rozwoju oprogramowania wytwarzającego systemy typu CMS, DMS i Workflow. Specjalizuje się w zwinnych metodykach produkcji oprogramowania oraz szeroko pojętym wsparciu zespołów deweloperskich. Autor bloga: cezarykaminski.pl
