Redakcja
Jeżeli w organizacji pojawiają się silosy, często zaczynają one mieć zupełnie inne priorytety i cele do zrealizowania - pomimo tego, że jest to może nawet ta sama jednostka w organizacji. Odpowiedzialność za stworzenie silosów często spoczywa na managerach różnych działów lub departamentów, którzy mniej lub bardziej świadomie zaczynają oddzielać swoje obszary kompetencyjne od innych, tworząc organizację w organizacji. Wynika to z braku komunikacji na zewnątrz, braku woli współpracy lub też chęci wyróżnienia się na tle innych jednostek. Managerowie zaczynają więc gromadzić informacje, ale się nimi nie dzielić i odcinać swoje procesy od procesów innych zespołów. Takie działanie w krótkim czasie doprowadzi do utraty motywacji przez pracowników, a w dłuższym okresie może skutkować niepowodzeniem w dostarczaniu produktu i upadkiem całej organizacji.
Patrząc z tej perspektywy widzimy w jakim silosie kompetencyjnym testerzy i programiści tkwili do niedawna. Datowana na koniec XX wieku wzajemna niechęć tych grup, podsycana przez organizacje standaryzujące i certyfikujące, ma swoje echa jeszcze dziś. Co więcej mentalność wielu managerów niewiele się zmieniła. Czasy Agile pokazały, że management średniego szczebla przestaje być niezbędny, a odpowiedzialności kierownicze przekazywane są do krosfunkcjonalnych zespołów. W tym środowisku managerowie zaczynają tworzyć atmosferę „otoczonej twierdzy”, w której nasza odpowiedzialność musi być broniona przed zakusami złych z zewnątrz. Ci źli chcą w ich mniemaniu zniszczyć to, co udało nam się zbudować np. odebrać nam naszą testerską autonomię i wcielić nas w „bezstanowiskowe” zespoły, gdzie zamiast czytelnych odpowiedzialności mamy rozproszoną odpowiedzialność zbiorową.
Takie działania można określić jedynie jako kompletny brak kompetencji, strach przed nowym lub strach przed utratą pracy. Swoją odpowiedzialność za taki stan rzeczy mają również managerowie wyższego szczebla, którzy albo nie dostrzegają albo po cichu przyzwalają na tworzenie się silosów w organizacji.
Jeżeli wspólnie uznamy, że efektywne dostarczanie produktów w dużej mierze koncentruje się na skutecznej komunikacji, jeżeli dorzucimy do tego, że przenikanie się odpowiedzialności nie zostawia niezagospodarowanej luki i pozwala nam na większą transparentność projektową, to naturalnym działaniem będzie burzenie istniejących silosów lub zapobieganie ich powstawaniu. Jest to kierunek, w którym zmierza współczesne IT starając się łączyć kompetencje w zespołach Scrumowych, definiując współpracujące role jak trzech amigo (programista, tester, analityk), czy zbliżyć wytwarzanie do obszaru powdrożeniowego w DevOps.
Przy całej satysfakcji z tego jak na projektowym horyzoncie upadają kolejne silosy, jednocześnie pod własnym nosem budujemy nowe, testerskie silosy. Nie tylko powstały zamknięte kręgi, w które zostali wtłoczeni testerzy automatyzujący i testerzy manualni, ale są one coraz bardziej separowane informacyjnie. Przestają kooperować na rzecz wspólnej wysokiej jakości i zaczynają zwalczać się wzajemnie, obrzucając się inwektywami o nieefektywności. Wydaje się, że trend jest na tyle silny, że tylko przebudzenie i aktywne działanie managementu może nas z tego zaogniającego się konfliktu kompetencji wyciągnąć. Ze swojej strony musimy pamiętać, że dobry tester to osoba, która w swojej codziennej pracy nie tylko posługuje się narzędziami, ale potrafi też wyeksplorować oprogramowanie. Wydaje się to być jedynym słusznym kierunkiem w otoczeniu dynamicznie zmieniającego się świata IT. To próbują zrobić ludzie (re)definiujący współczesne odpowiedzialności testerów.
Autor: Radek Smilgin
