Polityka alokacji

Preambuła

1. W Code & Pepper realizujemy projekty typu Team Augmentation, gdzie liderem procesu developmentu jest klient. Nasi inżynierowie dołączają do zespołu klienta i w bezpośredniej kooperacji wspólnie pracują nad produktem. Skład zespołu jest konsultowany z klientem i klient może współdecydować o wejściu i wyjściu danej osoby z projektu.
2. Projekty typu Team Augmentation mogą trwać od kilku miesięcy do kilku lat.
3. Niniejsza polityka dotyczy wszystkich inżynierów (niezależnie od specjalizacji, stacka technologicznego i aktualnie realizowanego projektu).
4. Wszystkie kwestie alokacyjne nieporuszone w niniejszej polityce należy poruszać indywidualnie ze swoim bezpośrednim przełożonym.

Wejście do projektu

1. Osobą mającą decydujący głos o wejściu danej osoby do projektu (a także realizacji zadań poza projektami) jest jego bezpośredni przełożony (Project Manager jego aktualnego lub ostatniego projektu w przypadku pobytu na ławce).
2. Decyzja o wejściu danej osoby do projektu podejmowana jest w oparciu o następujące kryteria:

• aktualne kompetencje (twarde i miękkie) danej osoby i ich dopasowanie do potrzeb projektu,
• preferencje danej osoby dot. rodzajów wykonywanych projektów,
• potrzeby rozwojowe danej osoby i możliwość ich zaadresowania w projekcie,
• (w przypadku kontynuacji projektu z przeszłości) doświadczenie w pracy z danym produktem.

3. O planach wejścia danej osoby do projektu jest ona uprzedzona i ma szansę wypowiedzieć się na temat tego planu.
4. Zaangażowanie danej osoby do projektu może poprzedzać weryfikacja kompetencji danej osoby przez klienta. Odbywa się to na następujących zasadach:

• znamy metodę weryfikacji kompetencji stosowaną przez klienta i jest o niej też uprzedzona osoba biorąca udział w tej weryfikacji,
• wynik weryfikacji kompetencji przez klienta nie ma wpływu na ocenę danej osoby wewnątrz Code & Pepper (ignorujemy ten wynik w kontekście naszej własnej oceny kompetencji).

5. W danym momencie dany inżynier jest zaangażowany w jeden projekt.
6. Dany inżynier może być tymczasowo alokowany do większej liczby projektów (niż ta określona w p. 5) w następujących sytuacjach:

• w okresach przejściowych między projektami (które trwają zazwyczaj 1 miesiąc).

7. Dany inżynier może być od czasu do czasu zaangażowany w procesy sprzedaży nowego projektu (ocena jakości kodu klienta, ocena procesów i kultury pracy klienta, opiniowanie rozwiązań).
8. Dany inżynier może być od czasu do czasu zaangażowany w procesy rekrutacyjne (ocena zadań, rozmowa z kandydatami).
9. W przypadku jednoczesnej pracy w więcej niż jednym projekcie lub realizacji zadań poza projektami o priorytetach oraz podziale czasu na te zadania decyduje bezpośredni przełożony (do niego należy się zwracać w przypadku niejasności lub problemów z bieżącym obciążeniem projektami).

Wyjście z projektu

Z inicjatywy inżyniera

1. Zachęcamy osoby pracujące w projektach, aby sygnalizowały niedogodności lub problemy wpływające na jej motywację do pracy w danym projekcie do swojego bezpośredniego przełożonego.

• Przełożony jest zobowiązany dokonać próby diagnozy i rozwiązania problemu / zmiany sytuacji w projekcie w celu wyeliminowania czynników wpływających na motywację danej osoby.

2. Każdy inżynier ma prawo zgłosić chęć zmiany projektu przed upływem roku od rozpoczęcia pracy w projekcie

• Chęć zmiany projektu w takim przypadku musi być uzasadniona,
• Do wyjścia z projektu w takiej sytuacji następuje nie później niż po upływie trzech pełnych miesięcy od momentu zgłoszenia chęci zmiany.

3. Każdy inżynier ma prawo zgłosić chęć zmiany projektu po roku czasu pracy w nim i prośba ta jest zawsze realizowana niezależnie od przyczyny

• Do wyjścia z projektu w takiej sytuacji następuje nie później niż po upływie trzech pełnych miesięcy od momentu zgłoszenia chęci zmiany.

Z inicjatywy C&P

1. W gronie osób decydujących o alokacjach do projektów może powstać potrzeba zmiany alokacji danej osoby. Zdarzyć się to może w następujących przypadkach:

• Jeżeli jest plan alokacji danej osoby do innego projektu (zmiana projektu),
• W przypadku zmiany potrzeb w projekcie,
• Jeżeli ocena performance-u danego inżyniera pozostaje przez dłuższy czas negatywna (pomimo przekazywanego feedbacku i prób naprawy/rozwiązania problemów).

2. W przypadku opisanym w p. 1 a. (przejście do innego projektu) plan ten jest konsultowany z daną osobą. Jeżeli wyraża ona chęć pozostania w projekcie, ta prośba jest zawsze uwzględniana.

Pobyt na ławce

1. Po zakończeniu się aktualnego projektu lub po wyjściu z projektu osoba trafia na tzw. ławkę
2. Czas spędzony na ławce wykorzystywany jest do:

• Realizacji indywidualnych planów rozwojowych (kursy/szkolenia/certyfikaty),
• Udziału w procesach sprzedażowych i marketingowych,
• Udziału w procesach rekrutacyjnych.

3. Jako organizacja dążymy do tego, aby:

• Pobyt na ławce (z perspektywy indywidualnego inżyniera) był możliwie najkrótszy lub w ogóle nie występował. Wyjątkiem od tej reguły może być indywidualnie ustalony z przełożonym danej osoby planowany pobyt na ławce (np. w celu umożliwienia realizacji zadań rozwojowych, regulacji obciążenia projektami),
• Na ławce znajdował się minimalny zespół pozwalający na jak najszybsze uruchomienie nowego projektu.