Moja przygoda z tą branżą sprawiła, ze słowo “cybersecurity” w ofercie zacząłem traktować jako sygnał negatywny.
Nigdzie indziej nie czułem takiego braku sprawczości i ignorowania głosu pracowników aż do momentu, gdy problem zgłaszał klient.
To było bardzo frustrujące doświadczenie, ale akurat pod względem finansowym wszystko było w porządku.
Integrację kilku komponentów (rozwijanych w innych zespołach) w gotowy produkt.
Ten etap produkcji software’u to jest takie piekiełko, gdzie wychodzą wszystkie niedociągnięcia i braki testów we wcześniejszych etapach. W żadnym innym projekcie nie spędziłem tyle czasu nad debuggerem.
Nauczyłem się też, że nie każðy jest skłonny bez “walki” zaakceptować istnienie błędu w swoim komponencie. Czasem trzeba było spędzić kilka godzin na dokumentowaniu scenariusza reprodukcji buga, bo wskazanie złej logiki w kodzie nie wystarczało.
Krótko mówiąc “keep calm and blame frontend” (chociaż nie robiliśmy nawet UI).
Podobnie każde przekroczenie deadline’u przez którykolwiek “upstreamowy” zespól stawało się na końcu twoim własnym problemem. Pytania od kierowników odpowiedzialnych za release pojawiały się zanim uzyskaliśmy wszystkie zależności.
Po tym projekcie doszedłem do wniosku, że absolutnie nie sprawdza się “potokowy” model produkcji software’u, jak przy taśmie w fabryce.
Każdy zespół musi wertykalnie odpowiadać za swój produkt, albo cykle wydawnicze każdego komponentu muszą być niezależne (tak żeby downstreamowy projekt mógł odrzucić niedziałające wersje zależności).
“Sec” powinno być jak dział kontroli w księgowości i finansach.
Model produkcji zależy od działalności. Składanie i dostosowywanie gotowych komponentów, różni się od inżynierii, projektowania i kreatywności. Może warto się przyjrzeć jak wyglądają różne etapy w innych branżach? Projektowanie i badania są oddzielone od produkcji. W programowaniu często się to wszystko łączy.
Moja przygoda z tą branżą sprawiła, ze słowo “cybersecurity” w ofercie zacząłem traktować jako sygnał negatywny.
Nigdzie indziej nie czułem takiego braku sprawczości i ignorowania głosu pracowników aż do momentu, gdy problem zgłaszał klient.
To było bardzo frustrujące doświadczenie, ale akurat pod względem finansowym wszystko było w porządku.
Co im dawało utrzymywanie takiego działu i niekorzystanie z jego pracy?
Integrację kilku komponentów (rozwijanych w innych zespołach) w gotowy produkt.
Ten etap produkcji software’u to jest takie piekiełko, gdzie wychodzą wszystkie niedociągnięcia i braki testów we wcześniejszych etapach. W żadnym innym projekcie nie spędziłem tyle czasu nad debuggerem.
Nauczyłem się też, że nie każðy jest skłonny bez “walki” zaakceptować istnienie błędu w swoim komponencie. Czasem trzeba było spędzić kilka godzin na dokumentowaniu scenariusza reprodukcji buga, bo wskazanie złej logiki w kodzie nie wystarczało.
Krótko mówiąc “keep calm and blame frontend” (chociaż nie robiliśmy nawet UI).
Podobnie każde przekroczenie deadline’u przez którykolwiek “upstreamowy” zespól stawało się na końcu twoim własnym problemem. Pytania od kierowników odpowiedzialnych za release pojawiały się zanim uzyskaliśmy wszystkie zależności.
Po tym projekcie doszedłem do wniosku, że absolutnie nie sprawdza się “potokowy” model produkcji software’u, jak przy taśmie w fabryce.
Każdy zespół musi wertykalnie odpowiadać za swój produkt, albo cykle wydawnicze każdego komponentu muszą być niezależne (tak żeby downstreamowy projekt mógł odrzucić niedziałające wersje zależności).
“Sec” powinno być jak dział kontroli w księgowości i finansach.
Model produkcji zależy od działalności. Składanie i dostosowywanie gotowych komponentów, różni się od inżynierii, projektowania i kreatywności. Może warto się przyjrzeć jak wyglądają różne etapy w innych branżach? Projektowanie i badania są oddzielone od produkcji. W programowaniu często się to wszystko łączy.
Pisanie nowego kodu to badania.