Jak rozwijamy projekty?

Lubimy wyzwania, ale nie lubimy walczyć z wiatrakami. Dlatego o przyjęciu projektu decyduje wiele czynników i z góry odrzucamy te wątpliwe. Jednak kiedy na coś się decydujemy, nie ma zmiłuj. Angażujemy się w projekt na całego!

Zasady alokacji do projektu

Krótko i na temat

24h_3b3745c2ff.svg

Wejście do projektu

Nie ma kodu bez pieprzu. Dlatego projekt musi Ci pasować, a nie na odwrót. Twoje zdanie dotyczące klienta i technologii ma znaczenie.

rakieta_53c882ddb0.svg

Wyjście z projektu

Z niewolnika nie ma pracownika. Jeśli projekt nie spełni Twoich oczekiwań, znajdziemy dla Ciebie nowe wyzwania. Najważniejsze jest Twoje zadowolenie.

lawka_848a7824cd.svg

Ławka

Czasem nawet najlepsze gwiazdy muszą usiąść na ławce rezerwowych. Nie oznacza to jednak zwolnienia tempa lub zmiany wynagrodzenia. Możesz w tym czasie wspierać nasze wewnętrzne aktywności lub pracować nad swoim rozwojem.

Najważniejsze informacje

  1. Jeden model współpracy

    Wiemy, że kluczem do sukcesu jest zespół. Dlatego stawiamy na usługę Team Augmentation, w ramach której wspólnie z zespołem klienta rozwijamy większy produkt.

  2. Liczba projektów

    Jakość zależy od ilości czasu, który możesz poświęcić na zadanie. My dobrze to wiemy! Dlatego nasi programiści i testerzy pracują tylko nad jednym projektem.

  3. Zmiana projektu po roku, bez podawania przyczyny

    Minął rok, a Ty nadal pracujesz w tym samym projekcie? Czujesz, że to czas na zmianę? Żaden problem! Poinformuj o tym swojego lidera i zmień projekt bez podawania przyczyny.

  4. Twoje zdanie ma znaczenie

    Koduj i pieprz po swojemu! Miej wpływ na narzędzia i projekt, w którym będziesz pracować. Chętnie wdrożymy Twoje usprawnienia, dzięki którym projekt ruszy z kopyta.

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.
  1. O planach wejścia danej osoby do projektu jest ona uprzedzona i ma szansę wypowiedzieć się na temat tego planu.
  2. 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).
  1. W danym momencie dany inżynier jest zaangażowany w jeden projekt.
  2. 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).
  1. 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ń).
  2. Dany inżynier może być od czasu do czasu zaangażowany w procesy rekrutacyjne (ocena zadań, rozmowa z kandydatami).
  3. 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.
  1. 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.
  1. 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).
  1. 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.
  1. 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.

Masz pytania?

Odezwij się do nas!