Istnieje wiele dobrych artykułów na temat możliwych ścieżek kariery, które możesz obrać w IT. Nie widziałem wielu, które mogłyby być użyte jako rzeczywiste wskazówki, jak awansować po szczeblach kariery. W prawie każdej bardziej lub mniej dojrzałej firmie IT typowa ścieżka kariery dla inżyniera oprogramowania jest liniowa. Dalsza ścieżka kariery będzie zależeć od twoich skłonności, tego, co lubisz robić, i tego, czy jesteś gotowy na zmianę sposobu pracy.
Istnieje wiele dobrych artykułów na temat możliwych ścieżek kariery w branży IT, jednak nie widziałem zbyt wielu, które mogłyby posłużyć jako rzeczywiste wskazówki, jak piąć się po szczeblach kariery.
Obecnie pracuję w firmie, która ma bardzo jasne wymagania dotyczące awansu inżynierów i co może być wykorzystane jako wystarczający dowód spełnienia tych wymagań. Połączenie tych dwóch czynników dało mi pomysł, że dodatkowe informacje na ten temat mogą pomóc innym inżynierom zatrudnionym w firmach, które ich nie mają, w opracowaniu strategii, która pozwoli im przejść na następny poziom.
W niemal każdej, mniej lub bardziej dojrzałej firmie informatycznej, typowa ścieżka kariery inżyniera oprogramowania jest liniowa i wygląda niemal identycznie:
Stanowisko Associate Software Engineer jest opcjonalne i może, ale nie musi być uwzględnione w typowej strukturze działu IT z bardzo prostego powodu: przez pierwsze 12 miesięcy jest ono ujemne netto, ponieważ wymaga dużo prowadzenia, a nie wszystkie firmy mają zasoby i czas, aby umożliwić takie stanowiska w swoich strukturach.
Dalsza ścieżka kariery zależeć będzie od Twoich upodobań, tego, co lubisz robić, i tego, czy jesteś gotowy na zmianę sposobu pracy.
Nie ma nic złego w pozostaniu starszym inżynierem oprogramowania, jeśli chcesz poświęcić większość swojego czasu na kodowanie. Jednak jeśli czujesz potrzebę wspierania innych i przewodzenia, to jest właściwy moment, aby rozważyć wszystkie oczekiwania dla każdej roli, swoje mocne strony, rzeczy, które Cię napędzają, i wybrać najbardziej odpowiednią ścieżkę dla siebie.
Pomimo wizualnej prostoty powyższych utworów, nie jest jasne, jak zbliżyć się do właściwego końca. Poniższe spostrzeżenia będą dotyczyć firm, które mają:
struktura hierarchiczna, w której każdy pracodawca ma swojego kierownika liniowego
autentyczne zainteresowanie rozwojem pracowników
Dlaczego powyższe jest ważne? Odpowiedź jest dość prosta: od pierwszego dnia masz sojusznika – swojego kierownika liniowego .
Efektywność każdego kierownika liniowego opiera się na wynikach pracy każdej osoby, która mu podlega: im szybciej się rozwijasz, tym większe są twoje wyniki, tym lepsza jest efektywność kierownika liniowego. Biorąc to wszystko pod uwagę, prędzej czy później, po dołączeniu do firmy, kierownik liniowy podejdzie do ciebie z pytaniem: „Gdzie widzisz siebie po pewnym czasie?”. Jeśli tak się nie dzieje i masz regularne spotkania w cztery oczy, możesz dodać to jako temat do dyskusji w programie.
Wyrażenie swoich intencji i wyznaczenie celu to tylko pierwszy krok na twojej drodze. Następnym krokiem jest zebranie listy wymagań na wyższe stanowisko i skompilowanie listy osiągnięć, które mogą służyć jako dowód twoich kwalifikacji, których możesz użyć jako przewodnika, którym powinieneś podążać, aby dostać się z punktu A do punktu B. W firmach z przejrzystymi procesami awansu powinno to być już na miejscu.
Jeśli tak nie jest, Ty i Twój menedżer możecie to napisać. Pamiętaj, że ten proces jest korzystny dla obu stron: otrzymujesz umowę, że po pewnych osiągnięciach zostaniesz pochwalony awansem, a Twój menedżer liniowy może uzyskać zwiększoną wydajność zespołu, więc jest to sytuacja korzystna dla obu stron.
Różne firmy mogą mieć różne wymagania dla pewnych stanowisk, a ja nie twierdzę, że te poniżej są uniwersalne i będą pasować każdemu. Głównym celem jest danie ci wyobrażenia, jak może wyglądać, jeśli potrzebujesz takiego, który można dodatkowo dostosować do twoich potrzeb.
Wytyczne dotyczące dowodów mogą być używane jako mapa drogowa, która doprowadzi Cię do pożądanego celu. Następne kroki na wspólnej ścieżce mogą być
Sprawdź plan działania zespołu pod kątem odpowiednich projektów lub wniosków o zmiany, które mogłyby odpowiadać celowi dowodów.
Powiedz o swoich zamiarach kierownikowi liniowemu, aby mógł pomóc w odpowiednim przydzieleniu projektu, dostarczyć informacji o jego priorytecie, wartości biznesowej i terminie, w którym można go przejąć do realizacji.
Zidentyfikuj wszelkie potencjalne obszary wymagające udoskonalenia w kodzie, możliwości obserwacji, rozszerzalności i perspektywach bezpieczeństwa i zgłoś je jako zgłoszenia własnościowe.
Zapoznaj się z obecnym procesem rekrutacji w swojej firmie i poproś o obserwację podczas sesji rekrutacyjnych. Poproś o zmianę ról, gdzie ktoś bardziej doświadczony będzie Cię obserwował i poproś o opinię.
Poniżej znajduje się krótka lista ról, które będą objęte wymaganiami/wytycznymi dotyczącymi perspektyw dowodowych:
Wspólna ścieżka
Wymagania dla młodszego inżyniera oprogramowania
Wymagania dla inżynierów oprogramowania
Wymagania dla starszego inżyniera oprogramowania
Ścieżka inżynierska
Wymagania dla głównego inżyniera
Wymagania dla starszego kierownika ds. inżynierii
Ścieżka zarządzania
Kierownik ds. inżynierii
Dyrektor ds. inżynierii
Wymagania dla młodszego inżyniera oprogramowania
Obszar
Wymagania
Wytyczne dotyczące dowodów
Dostawa
Dostarcza zadania · Potrzebne są jasne wymagania (biznesowe i systemowe) · Projektuje/wdraża rozwiązania techniczne o ograniczonym zakresie · Wymagane jest ograniczone przewodnictwo
1. Lista wykonanych zadań Zadania powinny być na tyle złożone, aby można było o nich wspomnieć o Terminy są dotrzymywane o Brak poważnych problemów z jakością o Zadania były wykonywane bez prowadzenia za rękę 2. Informacje od kierownika liniowego potwierdzające spełnienie wszystkich wymagań.
Jakość
Stosuje najlepsze praktyki · Uczy się i stale stosuje najlepsze praktyki · Znajomość różnych narzędzi programistycznych · Bada i naprawia skomplikowane problemy/błędy
Opinia przełożonego i współpracowników potwierdzająca spełnienie wszystkich wymagań.
Wymagania dla inżynierów oprogramowania
Obszar
Wymagania
Wytyczne dotyczące dowodów
Dostawa
Dostarcza żądania zmian (funkcje) · Przyjmuje wymagania biznesowe jako dane wejściowe · Dzieli pracę na zadania, zapewniając wystarczający poziom szczegółowości rozwiązania (co należy zrobić i kiedy to zrobić) i implementacji (jak to powinno zostać zrobione). · Zapewnia dokładne szacunki na poziomie zadania/historii użytkownika · Współpracuje z innymi inżynierami, aby dostarczać szybciej
Lista dostarczonych wniosków o zmianę, zgodnych z następującymi wymaganiami: 1. Żądanie zmiany zostało w całości zrealizowane, a termin dotrzymany. 2. Część informacyjną wykonał pracownik (zgłoszenia, szacunki). 3. Żądanie zmiany jest na tyle złożone z technicznego punktu widzenia (jednemu inżynierowi zajmie to ponad 2 tygodnie). 4. Wniosek o zmianę ma istotny wpływ na działalność firmy. 5. Wniosek o zmianę został zatwierdzony przez firmę i jest wdrażany w środowisku produkcyjnym. 6. Pracownik wykazał się wystarczającym poziomem autonomii i jakości (na podstawie opinii kierownika technicznego i kierownika ds. inżynierii).
Projektowanie systemu
Usługi projektowe · Projektuje i wdraża mniejsze usługi, biorąc pod uwagę wszystkie aspekty niefunkcjonalne (rozszerzalność, bezpieczeństwo, obserwowalność itp.) · Pisze wysokiej jakości kod, w pełni stosując praktyki i metodologie inżynierskie · Bierze udział w przeglądach kodu w celu egzekwowania najlepszych praktyk · Naprawia przyczyny błędów i napotkanych problemów
Co najmniej dwie usługi zaprojektowane zgodnie z następującymi wymaganiami: 1. Może to być nowa usługa lub całkowity projekt nowej usługi istniejącej. 2. Może to być samodzielna usługa, biblioteka lub komponent wykorzystywany przez inne usługi. 3. Usługa nie powinna być trywialna z punktu widzenia projektowania. 4. Inżynier powinien postępować zgodnie z formalnym procesem projektowania: · Uzyskaj wymagania biznesowe i systemowe · Zidentyfikuj ograniczony kontekst · Zidentyfikuj wymagania niefunkcjonalne · Rozbij kontekst na usługi · Uzyskaj opinię na temat rozwiązania · Wdrożyć 5. Usługa została wdrożona i działa w produkcji.
Starszy inżynier oprogramowania
Obszar
Wymagania
Wytyczne dotyczące dowodów
Dostawa
Dostarcza fazy projektu (eposy) · Przyjmuje jako dane wejściowe wymagania i projekt systemu wysokiego poziomu · Tworzy projekt systemu dla usługi lub komponentu, decyduje o technologiach i praktykach inżynieryjnych, które mają być wykorzystane · Dzieli pracę na zadania lub historie użytkowników, zapewniając wystarczający poziom szczegółowości rozwiązania (co należy zrobić i kiedy to zrobić) oraz implementacji (jak należy to zrobić) · Zapewnia dokładne szacunki na poziomie zadania/historii użytkownika · Kieruje małym zespołem w celu realizacji zakresu · Odblokowuje swój zespół, rozwiązuje problemy i usuwa przeszkody
Lista dostarczonych faz/epików projektu, zgodnych z następującymi wymaganiami: 1. Faza projektu/eposu została w pełni ukończona, a termin dotrzymany. 2. Część informacyjną wykonał pracownik (zgłoszenia, szacunki). 3. Faza projektu/eposu jest wystarczająco złożona z technicznego punktu widzenia (wymaga co najmniej 2 inżynierów przez >= 2 tygodnie). 4. Faza projektu/eposu ma istotny wpływ na biznes. 5. Funkcjonalność została zatwierdzona przez firmę i jest uruchomiona w środowisku produkcyjnym. 6. Pracownik wykazał się wystarczającym poziomem autonomii i jakości (na podstawie opinii kierownika technicznego i kierownika ds. inżynierii). 7. Inżynier brał udział w realizacji projektu jako lider techniczny.
Projektowanie systemu
Projektuje podsystemy · Jest to to samo, co dla inżyniera oprogramowania, ale skupia się na bardziej złożonych usługach lub podsystemach · Znajomość projektowania i wdrażania systemów chmurowych i rozproszonych
Co najmniej 3 usługi zaprojektowane zgodnie z następującymi wymaganiami: 1. Może to być nowa usługa lub całkowity projekt nowej usługi istniejącej. 2. Może to być samodzielna usługa, biblioteka lub komponent wykorzystywany przez inne usługi. 3. Usługa nie powinna być trywialna z punktu widzenia projektowania. 4. Inżynier powinien postępować zgodnie z formalnym procesem projektowania: a. Uzyskaj wymagania biznesowe i systemowe b. Zidentyfikuj ograniczony kontekst c. Zidentyfikuj wymagania niefunkcjonalne d. Podziel kontekst na usługi e. Uzyskaj opinię na temat rozwiązania f. Wdrożyć 5. Usługa została wdrożona i działa w produkcji.
Zmiany w prowadzeniu pojazdu
Proponuje zmiany · Kwestionuje status quo i przyjęte założenia · Znajdowanie sposobów na ulepszenie platformy, procesów, środowiska pracy i całego zespołu technicznego
Zaproponowano co najmniej trzy istotne zmiany, które mogą mieć postać: 1. Funkcjonalność: zaproponowano prośbę o zmianę, której nadano priorytet i którą wdrożono (prośba o zmianę powinna być na tyle obszerna, aby można ją było uznać za zmianę, a nie zmianę kosmetyczną). 2. Ludzie: przeprowadzono wywiad z inżynierem, który został zatrudniony i przeszedł okres próbny (młodszy inżynier oprogramowania lub wyższe stanowisko, uważane za zmianę w zespole). 3. Własność: zaproponowany projekt własnościowy (uwzględniony w planie własnościowym, zatwierdzony przez CTO).
Wymagania dla głównego inżyniera
Obszar
Wymagania
Wytyczne dotyczące dowodów
Dostawa
Lider techniczny projektów (propozycji projektów) · Przyjmuje wymagania biznesowe jako dane wejściowe · Znalezienie najskuteczniejszego rozwiązania dla danego problemu biznesowego (badanie alternatyw, weryfikacja rozwiązań przy użyciu podejść no-code/low-code) · Tworzy projekt systemu dla nowej usługi lub podsystemu, decyduje o technologiach i praktykach inżynieryjnych, które mają zostać wykorzystane · Dzieli pracę na etapy z odpowiednim poziomem szczegółowości rozwiązania (co należy zrobić i kiedy to zrobić) i implementacji (jak to powinno zostać zrobione) · Zapewnia dokładne szacunki na poziomie projektu, zobowiązuje się do przestrzegania dat · Pełni funkcję lidera technicznego całego projektu · Odblokowuje swój zespół, rozwiązuje problemy i usuwa przeszkody · Zarządza ryzykiem technologicznym, wdrożeniowym i operacyjnym
Lista zrealizowanych projektów, spełniających następujące wymagania: 1. Rozwiązanie problemu zostało zaproponowane przez pracownika i jest uważane za skuteczne. Tj. oceniono wiele alternatyw, a najlepszą alternatywę wybrano na podstawie walidacji low-code/no-code. 2. Część informacyjną wykonał pracownik (zgłoszenia, szacunki). 3. Rozwiązanie zostało zaprojektowane przez pracownika. 4. Projekt musi być projektem „specyficznym” zainicjowanym poprzez propozycję projektu. 5. Inżynier uczestniczył w procesie wdrażania jako lider techniczny (więcej szczegółów znajduje się w kolumnie „Wymagania”).
Zmiany w prowadzeniu pojazdu
Kieruje zmianami technicznymi (zespół) · Proponuje i wdraża inicjatywy mające na celu poprawę jakości systemu i zmniejszenie zadłużenia technicznego · Proponuje i wdraża zmiany mające na celu poprawę doświadczenia i produktywności programistów · Propaguje i egzekwuje czysty kod i czystą architekturę
Lista najważniejszych wprowadzonych zmian (zwykle co najmniej cztery), zgodnych z następującymi wymogami: 1. Zmiana zapewnia znaczącą poprawę jakości systemu (np. ulepszenia platformy), doświadczenia programisty lub produktywności programisty. Zmiana dotyczy całego zespołu. 2. Inżynier nie musi być tym, kto zaproponował zmianę. Inżynier powinien być główną siłą napędową zmiany (np. projektować, działać jako lider techniczny, uczestniczyć we wdrożeniu). Zmiana może być dostarczona przez inżyniera lub jako wysiłek zespołowy. 3. Zmiana powinna zostać w pełni wdrożona i wykorzystana przez drużynę/platformę (zmiana powinna być „trwała” i zapewniać wystarczającą wartość, aby ją zachować). 4. Zmiana powinna być na tyle znacząca, aby można było o niej wspomnieć.
Ludzie
Mentor · Mentoruje i wspiera mniej doświadczonych inżynierów · Skutecznie przeprowadza wywiady techniczne · Działa jak „magnes” przyciągający świetnych inżynierów podczas rekrutacji (jest decydującym czynnikiem w sytuacji, gdy konkurujemy o dobre talenty z inną firmą)
Możliwe dowody: 1. Inżynierowie, którzy zostali przesłuchani, zatrudnieni i przeszli okres próbny. 2. Opinie wysoko wykwalifikowanych inżynierów. 3. Organizowane/prowadzone są sesje szkoleniowe dla całego zespołu technicznego (np. Tech Sync, Engineering Dojo). 4. Podczas kierowania grupą roboczą można wykorzystać jako dowód listę zmian zaproponowanych/wdrożonych w zakresie działania grupy roboczej.
Starszy Lider Inżynierii
Obszar
Wymagania
Wytyczne dotyczące dowodów
Dostawa
Lider techniczny projektów złożonych (propozycje projektów) To samo co Inżynier Główny, ale koncentruje się na problemach złożonych z perspektywy technicznej, organizacyjnej lub biznesowej · Projekt wymaga koordynacji pomiędzy wieloma drużynami · W projekt zaangażowany jest zewnętrzny dostawca technologii lub interesariusz (np. partnerstwo) · nowy produkt jest tworzony, gdy produkt znajduje się w trybie odkrywania · projekt o wysokim priorytecie/pilności z ustalonymi terminami i wieloma nieznanymi
Lista zrealizowanych projektów, spełniających następujące wymagania: 1. Projekt uznaje się za złożony (patrz przykłady po lewej stronie). 2. Projekt został w całości dostarczony (wszystkie produkty dostarczane + DoD), a termin został dotrzymany. 3. Rozwiązanie problemu zostało zaproponowane przez pracownika i jest uważane za skuteczne (tj. oceniono wiele alternatyw, a najlepsza z nich została wybrana na podstawie walidacji z niskim kodem/bez kodu). 4. Część informacyjną wykonał pracownik (wymagania systemowe, zgłoszenia, szacunki). 5. Rozwiązanie zostało zaprojektowane przez pracownika. Projekt ma wysoką złożoność z perspektywy projektowania systemu. 6. Inżynier uczestniczył w implementacji jako lider techniczny.
Zmiany w prowadzeniu pojazdu
Napędza zmiany techniczne (tech) · Tak samo jak E5, ale na poziomie technicznym · Właściciel systemu, co najmniej w odniesieniu do jednego aspektu niefunkcjonalnego (np. bezpieczeństwa, obserwowalności itp.).
Lista głównych wprowadzonych zmian (zwykle co najmniej 4), zgodnych z następującymi wymaganiami: 1. Zmiana zapewnia znaczącą poprawę jakości systemu (np. ulepszenia platformy), doświadczenia programisty lub produktywności programisty. Zmiana dotyczy wielu drużyn (np. przyjęcie technologii). 2. Inżynier nie musi być tym, kto zaproponował zmianę. Inżynier powinien być główną siłą napędową zmiany (np. projektować, działać jako lider techniczny, uczestniczyć we wdrożeniu). Sama zmiana może być dostarczona przez inżyniera lub jako wysiłek zespołowy. 3. Zmiana powinna zostać w pełni wdrożona i wykorzystana przez wiele drużyn (zmiany powinny być „trwałe” i zapewniać wystarczającą wartość, aby je zachować). 4. Zmiana powinna być na tyle istotna, aby o niej wspomnieć. Powinna być śledzona na stronie „nadchodzące projekty” jako projekt własnościowy (własność w tym kontekście oznacza zmiany na platformie, narzędziach, procesach itp., a nie tylko zmiany związane z platformą). 5. Co najmniej 2 zmiany powinny dotyczyć aspektu niefunkcjonalnego posiadanego przez daną osobę.
Ludzie
Uznany ekspert · Uznany ekspert w danej dziedzinie specjalizacji na poziomie firmy, pełniący funkcję punktu kontaktowego ds. technicznych w swojej dziedzinie specjalizacji · Monitoruje trendy/technologie w obszarze swojej specjalizacji i przekazuje aktualizacje i ustalenia · Aktywnie i regularnie dzieli się swoją wiedzą z innymi inżynierami (warsztaty, rozmowy techniczne, szkolenia) · Ułatwia współpracę w celu znalezienia rozwiązań złożonych problemów (grupy robocze itp.) · Skutecznie przeprowadza wywiady techniczne · Mentoruje i wspiera mniej doświadczonych inżynierów, kieruje ich karierą z perspektywy rozwoju zawodowego · Działa jak „magnes” przyciągający świetnych inżynierów podczas rekrutacji (jest decydującym czynnikiem w sytuacji, gdy konkurujemy o dobre talenty z inną firmą)
Możliwe dowody: 1. Przeprowadzono wywiady z inżynierami, którzy zostali zatrudnieni i przeszli okres próbny. 2. Opinie wysoko wykwalifikowanych inżynierów. 3. Organizowane/prowadzone są sesje szkoleniowe dla całego zespołu technicznego (np. Tech Sync, Engineering Dojo). 4. Kierując grupą roboczą, można wykorzystać jako dowód listę zmian zaproponowanych/wdrożonych w zakresie działania grupy roboczej.
Kierownik ds. inżynierii
Obszar
Wymagania
Wytyczne dotyczące dowodów
Dostawa
Dostarcza mapę drogową drużyny · Dowodzi oddziałem składającym się z 3-6 inżynierów · Działa jako kierownik projektu dla wielu równoczesnych inicjatyw · Możliwość dostarczania wyników przy wykorzystaniu wyłącznie wymagań biznesowych (możliwość tworzenia i zatwierdzania wymagań systemowych) · Koncentruje się na wpływie na działalność gospodarczą, napędzanym przez wartość biznesową · Komunikuje zobowiązania, status i ryzyko interesariuszom biznesowym · Upewnia się, że wszyscy członkowie drużyny mają wszystkie potrzebne im informacje · Komunikuje się z osobami trzecimi w zakresie inicjatyw/własności · Znajduje właściwą równowagę pomiędzy dostarczaniem funkcji a jakością systemu · Wszystkie wymagania dla starszego inżyniera oprogramowania
Nowe projekty dostarczone przez drużynę, spełniające następujące wymagania: 1. Projekt zainicjowany poprzez propozycję projektu. 2. Projekt osiągnął zakładane wskaźniki oddziaływania, a zobowiązanie publiczne zostało spełnione. 3. Projekty zgłoszone w poprzednim cyklu promocyjnym nie mogą zostać uwzględnione na liście.
Wydajność
Kieruje zmianami w zarządzaniu (zespół) · Mierzy i stale poprawia wydajność drużyny · Identyfikuje i ustala najlepsze praktyki w zespole, kładąc nacisk na produktywność · Utrzymuje wysoką jakość dostaw · Zapewnia przejrzystość postępów, ryzyka i wyników
1. Wartości wskaźników produktywności (wydajności) drużyny. 2. Wprowadzono istotne zmiany (co najmniej 4), zgodne z następującymi wymaganiami: a. Rozwiązuje problem związany z posiadanym oddziałem lub plemieniem, problem musi zostać uwzględniony w TOP 5 problemów i uzgodniony z kierownikiem liniowym. b. Zmiana powinna być w pełni wdrożona i wykorzystana przez drużynę (zmiana powinna być „lepka” i zapewniać wystarczającą wartość, aby ją utrzymać). c. Zmiana powinna zapewnić znaczącą poprawę produktywności, zaangażowania lub jakości dostaw. d. Menedżer nie musi być osobą, która zaproponowała zmianę. EM powinien być główną siłą napędową zmiany. Zmiana może zostać dostarczona przez inżyniera lub jako wysiłek zespołowy.
Ludzie
Kierownik liniowy (>=3 bezpośrednich podwładnych) · Zarządza 3-6 bezpośrednimi podwładnymi · Trenuje i wspiera inżynierów · Wspiera i kieruje rozwojem kariery · Godzi różnice zdań i pomaga zarządzać konfliktami oraz je rozwiązywać · Promuje pozytywną kulturę zespołową i współpracę
1. Wartości wskaźników zaangażowania drużyny. 2. Lista inżynierów, którzy zostali zatrudnieni i przeszli okres próbny (można pominąć, jeśli nie zatrudniamy, EM powinien być kierownikiem ds. rekrutacji).
Dyrektor ds. inżynierii
Obszar
Wymagania
Wytyczne dotyczące dowodów
Dostawa
Dostarcza plan działania dla wielu oddziałów · Zapewnia dostawę do 2-3 oddziałów · Pełni rolę Kierownika ds. Inżynierii w jednym z zespołów · Posiada partnerstwa z podmiotami trzecimi · Wszystkie wymagania od Kierownika ds. Inżynierii
Nowe projekty dostarczone przez zespoły spełniające następujące wymagania: 1. Projekt zainicjowany poprzez propozycję projektu (nie jest to działanie BAU). 2. Projekt osiągnął zakładane wskaźniki oddziaływania, a zobowiązanie publiczne zostało spełnione. 3. Wyniki projektu zaprezentowano w formie sesji Tech Feature. 4. Projekty zgłoszone w poprzednim cyklu promocyjnym nie mogą zostać uwzględnione na liście. 5. Przynajmniej 2 projekty powinny zostać uznane za kluczowe na poziomie firmy (np. nowy produkt itp. można potwierdzić z CTO).
Jazda ze zmianą
Wprowadza zmiany w zarządzaniu (wiele oddziałów/technologii) · Wszystkie wymagania z zakresu inżynierii, ale w wielu oddziałach · Właściciel systemu przynajmniej dla jednego procesu (np. wsparcia itp.)
1. Wartości wskaźników produktywności (wydajności) zespołów w różnych zespołach. 2. Wprowadzono istotne zmiany (co najmniej 6), zgodne z następującymi wymaganiami: a. Rozwiązuje problem związany z drużynami lub plemieniem, problem musi zostać uwzględniony w TOP 5 problemów i uzgodniony z kierownikiem liniowym. b. Zmiana powinna być w pełni wdrożona i wykorzystana przez drużyny (zmiana powinna być „lepka” i zapewniać wystarczającą wartość, aby ją utrzymać). c. Zmiana powinna zapewnić znaczącą poprawę produktywności, zaangażowania lub jakości dostaw. d. Menedżer nie musi być osobą, która zaproponowała zmianę. Dyrektor ds. inżynierii powinien być główną siłą napędową zmiany. Zmiana może zostać dostarczona przez inżyniera lub jako wysiłek zespołowy. e. Co najmniej 2 zmiany powinny być związane z procesem, za który odpowiada dyrektor.
Ludzie
Kierownik liniowy (>=10 podwładnych, wliczając podwładnych pośrednich) · Wszystkie wymagania dla Kierownika Inżynierii · Trenuje i wspiera inżynierów · Wspiera i kieruje rozwojem kariery · Zarządza odejściami, zmniejsza „niepożądane odejścia”
1. Wartości wskaźników zaangażowania oddziałów w wielu oddziałach. 2. Lista inżynierów, którzy zostali zatrudnieni i przeszli okres próbny (można pominąć, jeśli nie zatrudniamy). 3. Lista awansowanych inżynierów (można pominąć, jeśli nie ma potrzeby biznesowej przeprowadzania awansów).
