Zarządzanie · 4 min czytania
Ten o bramkach kontrolnych
Innowacje a compliance: dlaczego bramki bezpieczeństwa na końcu procesu blokują zmiany i jak wbudować standardy w pracę zespołów od pierwszego dnia.
Nikt nie planuje blokowania innowacji. Dlaczego więc idą nam one tak słabo?
W wielu firmach odpowiedź leży w modelu „stacji kontrolnej”. Zespół pracuje, a na końcu procesu stoją bramki: bezpieczeństwo, zgodność z regulacjami, architektura, ryzyko. Każda bramka ma dobre intencje i każda chroni firmę przed czymś realnym. Razem potrafią zatrzymać zmianę na miesiące.
Dlaczego bramki na końcu procesu blokują innowacje?
Bo pojawiają się wtedy, gdy zmiana jest już zrobiona, a każda poprawka kosztuje najwięcej. Widzę za tym cztery przyczyny.
1. Binarne podejście do ryzyka. Bramka zna dwie odpowiedzi: „przechodzi” albo „nie przechodzi”. Nie ma w niej miejsca na „przechodzi z ograniczeniem”, „wdrażamy dla 5% użytkowników” albo „wracamy do tematu za miesiąc z danymi”. O tym, ile kosztuje wybór między dwiema skrajnościami, pisałem we wpisie o myśleniu zerojedynkowym.
2. Audyt jako wydarzenie. Kontrola przychodzi raz, na końcu, jak egzamin. Zespół przez kilka tygodni pracuje bez informacji zwrotnej, a potem dostaje listę uwag naraz. Gdyby ta sama wiedza docierała do zespołu na bieżąco, większość uwag nie miałaby szansy powstać.
3. Compliance jako zewnętrzny recenzent. Specjaliści od zgodności i bezpieczeństwa wchodzą do projektu późno i oceniają cudzą pracę. Nie uczestniczą w decyzjach, więc nie znają ich kontekstu. Zespół nie zna z kolei ich wymagań, więc nie może ich uwzględnić od razu.
4. Nikt nie liczy kosztu opóźnienia. Trzy miesiące czekania na zatwierdzenie to trzy miesiące, w których rozwiązanie nie zarabia, nie zbiera danych i nie uczy firmy niczego. Ten koszt alternatywny nie pojawia się w żadnym raporcie compliance. Raport pokazuje tylko ryzyko, którego udało się uniknąć. O tym, jak policzyć koszt miesiąca opóźnienia, pisałem osobno.
Czy bramki na końcu faktycznie zwiększają bezpieczeństwo?
Badania DORA sugerują, że niekoniecznie. Forsgren, Humble i Kim w książce „Accelerate” opisują, że ciężkie procesy zatwierdzania zmian przez zewnętrzne gremium wiążą się z gorszymi wynikami dostarczania, a nie widać, żeby zmniejszały odsetek nieudanych zmian. Lepiej wypadały lżejsze formy kontroli, na przykład przegląd w zespole połączony z automatycznymi testami.
Wniosek brzmi: przenieśmy kontrolę tam, gdzie daje najwięcej, czyli do codziennej pracy.
Jak połączyć bezpieczeństwo z innowacjami?
Dając zespołom standardy od pierwszego dnia, żeby bezpieczeństwo działo się w trakcie pracy. W praktyce to kilka rzeczy:
- Wymagania jawne na starcie. Zespół wie, jakie zasady obowiązują, zanim napisze pierwszą linię kodu.
- Gotowe wzorce. Zatwierdzone komponenty, szablony infrastruktury i biblioteki, z których zespół korzysta bez proszenia o zgodę.
- Automatyczne sprawdzenia. Skanowanie zależności, testy bezpieczeństwa i kontrola konfiguracji przy każdej zmianie.
- Ekspert jako doradca. Specjalista od bezpieczeństwa pomaga w trakcie pracy i uczy zespół, zamiast tylko oceniać efekt.
- Uzgodnione granice. Zespół decyduje sam, dopóki zmiana mieści się w ustalonych granicach. Eskaluje tylko to, co je przekracza, podobnie jak przy tolerancjach w projekcie.
Takie podejście opisuje m.in. amerykański NIST w ramach Secure Software Development Framework: praktyki bezpieczeństwa wbudowane w każdy etap tworzenia oprogramowania, od projektu po utrzymanie.
Co zmienia się dla compliance?
Zmienia się jego rola: zespół compliance staje się autorem standardów, z których korzystają wszyscy. Jego praca skaluje się: jeden dobrze opisany wzorzec obsługuje dziesiątki zmian, zamiast każdej oceniać osobno.
Dwa światy, szybkiej zmiany i bezpiecznej firmy, mogą działać razem. Wymaga to jednak zmiany miejsca, w którym toczy się rozmowa o ryzyku.
A może te dwa światy da się jeszcze jakoś inaczej połączyć?
Bibliografia
- Forsgren, N., Humble, J., Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
- Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
- Souppaya, M., Scarfone, K., Dodson, D. (2022). Secure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218). National Institute of Standards and Technology.
💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem
Tomasz Żelezny
Scrum Master · Agile Coach
Pomagam zespołom robić mniej rzeczy naraz i kończyć więcej. Piszę o przepływie pracy, decyzjach i o tym, gdzie znika wysiłek zespołów.
Twój zespół może więcej niż dowozi.
Zobacz, jak pomagam