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 posiedzieć z Januszem – naszym projektem open source 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 pracują tylko nad jednym projektem. Jesteś Designerem lub QA-em? Przewidujemy dla Ciebie dwa mniejsze lub jedno duże wyzwanie.

  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 C&P (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:
  • (w pierwszej kolejności) rozwoju naszych własnych projektów Open Source Janush
  • 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?

Pogadaj z nami!