Możecie wziąć jeden albo wszystkie. Razem układają się w ścieżkę od projektowania po utrzymanie.
Uczymy zespół znajdować słabe punkty na etapie projektu, zanim powstanie pierwsza linia kodu. Pracujemy metodą STRIDE na diagramie Waszego realnego systemu.
Jak wpiąć kontrole bezpieczeństwa w proces budowania tak, żeby działały w tle i nie przeszkadzały zespołowi. Konfigurujemy je razem, na Waszym pipelinie.
Praktyczne warsztaty dla programistów: przegląd Waszego kodu i wspólne szukanie realnych błędów — z naprawą na miejscu.
Wyznaczamy i przygotowujemy osoby, które w każdym zespole odpowiadają za bezpieczeństwo na co dzień — tak, żeby zawsze miało właściciela. Program działa dalej siłami Waszych ludzi.
Warsztat dla ośmiu osób to inna praca niż dla trzydziestu. Zakres i formę ustalamy po rozmowie — od pojedynczej sesji po program dla wielu zespołów.
Jedna sesja, jeden temat, jeden zespół. Dobry pierwszy krok.
Kilka powiązanych warsztatów rozłożonych w czasie, z zadaniami między sesjami.
Uruchomienie sieci opiekunów bezpieczeństwa w organizacji wielozespołowej.
Każdy warsztat przygotowujemy pod Wasz system — to zwykle kilka dni pracy przed samą sesją. Każdy materiał powstaje na Waszym systemie. Szkolenia zdalne i stacjonarne traktujemy tak samo; przy stacjonarnych dochodzą koszty dojazdu.
Po warsztacie zespół potrafi zastosować to, czego się nauczył, bez naszej obecności. To jest jedyny sensowny miernik skuteczności szkolenia — nie ankieta satysfakcji.
Diagramy zagrożeń, konfiguracje, notatki z warsztatu i lista znalezionych problemów. Zamiast prezentacji w PDF zostają artefakty, których da się od razu użyć.
Warsztat na Waszym kodzie zwykle kończy się listą konkretnych rzeczy do naprawienia — znalezionych przez zespół, nie przez nas. To zmienia podejście trwalej niż jakikolwiek wykład.
Bezpieczeństwo wbudowane w sposób, w jaki Wasz zespół pisze i wydaje oprogramowanie — nie doklej…
Zobacz obszar →Zasady korzystania z narzędzi AI w zespole developerskim — żeby przyspieszenie pracy nie odbywał…
Zobacz obszar →Kontrola nad tym, z czego powstaje Wasze oprogramowanie — i dowód, że paczka u klienta pochodzi …
Zobacz obszar →Domyślnie dla zespołów inżynierskich: programistów, architektów, testerów, DevOps. Prowadzimy też krótsze sesje dla kierownictwa technicznego, jeśli potrzebujecie wspólnego języka między zarządem a zespołem — ale to inna rozmowa i inny materiał.
Do dwunastu osób. Powyżej tego warsztat przestaje być warsztatem i zamienia się w wykład — a wykład nie zmienia sposobu pracy. Przy większych zespołach dzielimy grupę na kilka sesji.
Nie musicie. Z dostępem warsztat jest najbardziej konkretny; bez niego opieramy go na dokumentacji i rozmowie z zespołem. Zakres dostępów zawsze ustalamy pisemnie przed startem.
Jeśli zespół ma kompetencje i czas, sam wdroży to, czego się nauczył. Jeśli wie, co robić, ale nie ma kiedy — wchodzimy z wdrożeniem i zostawiamy działający mechanizm w Waszym procesie. Po warsztacie wspólnie oceniamy, który to przypadek.
Zwykle od dwóch do trzech tygodni od rozmowy do warsztatu. Ten czas idzie na poznanie Waszego systemu i przygotowanie materiału — bez tego warsztat byłby standardowy, a standardowy nie działa.
Wystawiamy imienne zaświadczenie o ukończeniu warsztatu — z zakresem tematów i liczbą godzin, gotowe do akt pracowniczych i jako dowód szkolenia przy audycie albo ankiecie klienta. Certyfikaty branżowe wydają jednostki akredytowane po egzaminie; nasze zaświadczenie potwierdza udział i zakres.