Dobór trenera cyberbezpieczeństwa dla firmy software’owej

Zaawansowany zespół nie potrzebował szkolenia z półki.

W wielu organizacjach IT standardowa oferta szkoleniowa nie pokrywa realnych potrzeb. Trener musi rozumieć konkretną technologię, poziom dojrzałości grupy i wymagania programu KFS.

Klient zgłosił się z precyzyjną listą zagadnień dla zespołu technicznego: cyberbezpieczeństwo, administracja systemami Linux, zarządzanie sieciami oraz dodatkowe obszary wynikające ze stacku technologicznego firmy.

• Zaawansowani specjaliści IT
• Konkretny stack technologiczny
• Finansowanie KFS
• Ograniczony czas

Temat szkolenia był znany. Ryzykiem było pozorne dopasowanie.

To nie był przypadek, w którym wystarczyło wpisać w agendę hasło „cyberbezpieczeństwo”. Grupa miała wysoki poziom techniczny, a zakres obejmował kilka obszarów, które musiały zadziałać razem.

Źle dobrany trener mógł poprowadzić poprawne formalnie szkolenie, które nie dałoby uczestnikom praktycznej wartości. W projekcie finansowanym z KFS to oznacza stratę czasu, środków i zaufania zespołu.

Pytanie nie brzmiało: „czy macie szkolenie z cyberbezpieczeństwa?”

Mamy zespół specjalistów IT, określoną listę zagadnień, ograniczony czas i wymogi KFS. Kto poprowadzi to tak, żeby uczestnicy wyszli z realną wartością?

To przesunęło punkt ciężkości z tematu szkolenia na jakość dopasowania eksperta, agendy i sposobu pracy z grupą.

Największym zagrożeniem był wybór osoby „najbliższej tematycznie”.

Agenda mogła ominąć krytyczne zagadnienia z listy klienta, jeśli trener miał tylko częściowe doświadczenie w wymaganych obszarach.

Specjaliści IT szybko wyczuwają brak praktyki produkcyjnej, dlatego ważne było sprawdzenie doświadczenia, a nie tylko nazwy specjalizacji.

Merytoryka musiała iść razem z dokumentacją, zakresem szkolenia i wymogami KFS, a presja czasu nie mogła obniżyć jakości decyzji.

• Niepełny program
• Zaawansowana grupa
• Wymogi KFS
• Presja czasu

Najpierw rozebraliśmy potrzebę na części. Dopiero potem szukaliśmy trenera.

Rozbiliśmy listę zagadnień klienta na moduły i określiliśmy wymagany profil doświadczenia trenerskiego.

Następnie wytypowaliśmy ekspertów ze specjalizacją w cyberbezpieczeństwie i administracji Linux, a rozmowy merytoryczne poświęciliśmy praktyce, pełnemu zakresowi i sposobowi pracy z zaawansowaną grupą.

Rekomendacja obejmowała jednego trenera oraz agendę zbudowaną wokół listy klienta, nie wokół gotowego programu.

• Analiza zakresu
• Preselekcja ekspertów
• Rozmowy merytoryczne
• Rekomendacja i agenda

Szkolenie odbyło się zgodnie z zakresem i na realnych scenariuszach.

Projekt został zrealizowany w ramach środków KFS. Uczestnicy pracowali na przykładach odpowiadających ich codziennemu środowisku pracy, co było jednym z warunków klienta.

Program szkolenia został zbudowany wokół listy klienta, a nie wokół gotowej agendy trenera.

Pierwsze szkolenie otworzyło rozmowę o cyklu rozwojowym.

Klient zgłosił zainteresowanie ustrukturyzowanym programem obejmującym kolejne tematy z obszaru cyberbezpieczeństwa i administracji infrastrukturą.

Rozmowa nie dotyczy już pojedynczego wydarzenia, tylko konsekwentnego porządkowania kompetencji zespołu technicznego.

Dobór trenera jest decyzją projektową, nie logistyczną.

Trenera dobieramy do potrzeb klienta, a nie klienta do trenera z bazy.

W realiach KFS łączymy merytorykę z wymaganiami formalnymi programu.

Model współpracy to cykl rozwojowy, nie pojedyncze szkolenie.

• Dopasowanie do potrzeb
• Merytoryka i formalności
• Cykl rozwojowy