Sytuacja kobiet w IT w 2024 roku
20.04.20227 min
Paulina Lipska
BCG Platinion

Paulina LipskaIT KonsultantkaBCG Platinion

Jak pies z kotem, czyli jak dobrze skomunikować IT z biznesem

Sprawdź, jakie są modele organizacyjne oraz jak stopniować skalowanie, by IT i biznes osiągnęły wspólnie założone cele.

Jak pies z kotem, czyli jak dobrze skomunikować IT z biznesem

Opowiem Wam historię

To się znowu stało. Przyszedłem do pracy, odpaliłem JIRE, przejrzałem taski na dziś i zabrałem się do pracy. W słuchawkach muzyka, godziny lecą na pisaniu kodu, niczym niezmącony dzień. I nagle ich widzę. Idą w moim kierunku.

Po twarzach widzę, że czegoś chcą. Podeszli do mojego biurka i zaczęli mówić, ale nie bardzo rozumiałem, o co im właściwie chodziło. Gdy już się wyjaśniło, że chodzi o nowy raport, poprosiłem o zgłoszenie w JIRA. Ale okazało się, że to nie wszystko – oni oczywiście mieli już cały scenariusz, JAK ja mam ten raport przygotować.

Znowu przyszli nie tylko z problemem, ale i z rozwiązaniem. I znowu nie najlepszym. Ale oni chcą tak i już. No i co ja mam zrobić?

Dla wszystkich nietechnicznych osób pozwólcie, że posłużę się odwołaniem do kultury w celu przedstawienia, jak Biznes może wyglądać z punktu widzenie dewelopera. I odwrotnie. Oglądaliście „Zagubionych” lub „Grę o Tron”? A pamiętacie innych? No właśnie. 

Problemy współpracy Biznesu i IT

I tu pojawia się pierwszy problem we współpracy Biznesu i IT. Często bywa tak, że Biznes przychodzi nie tylko z problemem, ale również z propozycją rozwiązania. Nie powinno się tak jednak dziać, ponieważ od rozwiązania problemu jest właśnie IT.

Dlatego, nawet jeśli Biznesowi wydaje się, że zaproponowane rozwiązanie jest właściwe, bo z pozoru spełnia wymagania i odpowiada na potrzeby, niekoniecznie jednostki biznesowe mają wiedzę, by to jednoznacznie stwierdzić. Z punktu widzenia IT ważne jest, by kwestionować to, z czym przychodzi Biznes i starać się zobaczyć pełen obraz sytuacji. 


Posłużmy się przykładem z historii

Biznes przychodzi z zapotrzebowaniem na nowy raport. Ma już propozycję, jak ten raport powinien wyglądać, w jakim narzędziu chciałby z niego korzystać, kto powinien dostać do niego dostęp itd.

O ile spisanie wymagań i ich uszczegółowienie jest jak najbardziej przydatne i pożądane, o tyle przekraczanie cienkiej granicy pomiędzy sformułowaniem wymagań a zaproponowaniem rozwiązania już nie. Dlatego warto zawsze wymagania Biznesu analizować, by dostarczyć rzeczywiście najbardziej adekwatne rozwiązanie, a nie takie, które tylko z pozoru na takie wygląda.

Warto w tym celu zadawać pytania:

  • Kto i w jakim stopniu będzie z tego raportu korzystał?
  • Czy dane mają być odświeżane w interwałach, czy dostępne w czasie rzeczywistym?
  • Czy za miesiąc te wymagania mogą się zmienić i raport trzeba będzie ponownie dostosowywać?
  • Może nie jest więc potrzebny raport, a kostka?


Takie podejście nie tylko zapewni lepsze dostosowanie rozwiązania i spełnienie potrzeb Biznesu, ale oszczędzi pracy samemu IT. 

Porównanie z historii jakoby ludzie nietechniczni mówili w innym języku, niż IT nie jest aż tak przesadzone. Biznes postrzega problemy w innym wymiarze, nie ma bowiem obowiązku znać się na technicznych kwestiach rozwiązania problemu. Powinien jednak umieć przedstawić problem w sposób klarowny i równie jasno przedstawić swoje oczekiwania.

Oczywiście znajdą się tacy przedstawiciele biznesu, którzy zrozumieją różnicę pomiędzy raportem a kostką, ale co do zasady IT nie powinno tego od jednostek biznesowych oczekiwać, tak samo, jak Biznes nie powinien oczekiwać od dewelopera definicji logiki biznesowej, zawartej we wspomnianym raporcie.

Dlatego wiele firm decyduje się na zatrudnianie analityków biznesowych, którzy z założenia powinni być na tyle techniczni, by móc dogadać się z IT, jednocześnie mając na tyle rozwinięte kompetencje miękkie, by w klarowny sposób przedstawić skomplikowane problemy biznesowi.

Jest więc to jedno rozwiązanie na problemy komunikacyjne pomiędzy Biznesem i IT – wypełnienie luki kompetencyjnej i zatrudnienie analityków biznesowych pracujących na styku tych dwóch funkcji. 

Modele operacyjne

Dla części Czytelników oczywistym rozwiązaniem wydaje się wprowadzenie modelu operacyjnego odpowiadającego metodykom zwinnym. I z założenia, oczywiście, zespoły Scrumowe mają być na tyle samowystarczalne, by bez konieczności angażowania osób z zewnątrz dostarczyć produkt, nad którym pracują. W teorii wydaje się to być odpowiedzią na problemy komunikacyjne Biznesu i IT, dlaczego więc tyle firm ma wciąż problemy z egzekucją Agile’a? 

Na polskim rynku struktura organizacyjna Biznes versus IT jest bardzo głęboko zakorzeniona. Firmy przywykły już do takiego modelu operacyjnego, a transformacja Agile to nie jest rodzaj projektu, który zamyka się w kilka tygodni. Transformacje takie często trwają całe lata, a żeby w ogóle je rozpocząć, muszą zostać przeznaczone na nie środki.

Transformacja Agile przegrywa często na tym etapie z tymi projektami strategicznymi, których planowane wyniki i wartości dla organizacji są łatwiej mierzalne, jak np. wdrożenie nowego kanału sprzedażowego. Dlatego coraz częściej firmy decydują się na tzw. bottom-up approach gdzie, zamiast transformować od razu całą organizację, podchodzi się do transformacji małymi krokami, zaczynając od utworzenia pilatożawego zespołu.

I tak dobrym rozwiązaniem może być np. restrukturyzacja obecnego zespołu deweloperskiego składającego się w 100% z IT na zespół semi-agile poprzez dołączenie do niego Product Ownera z Biznesu. W takiej sytuacji Biznes i IT nie figurują jakie dwie oddzielne jednostki, a jako jeden zespół, samo to więc stymuluje komunikację i rozwiązywanie problemów, które zaczynają być wspólne, zamiast wzajemnego obarczania winą.

Jest wspólny cel, budżet oraz problemy, a więc i ich rozwiązanie leży w gestii wszystkich członków zespołu. Łatwiej jest też przekonać zarząd do inwestycji w taką transformację – nakład budżetowy jest zdecydowanie mniejszy, niż w przypadku transformacji całej organizacji, korzyści są widoczne dużo szybciej, a samo skalowanie struktury na kolejne zespoły jest z operacyjnego punktu widzenia łatwiejsze. 

Stopniowe skalowanie

Niezależnie od tego, czy firma decyduje się na transformację Agile rozumianą jako restrukturyzacja całej organizacji, czy poprzez stopniowe skalowanie, do czasu wprowadzenia zmian w życie warto zadbać o sformalizowanie procesu współpracy Biznes-IT.

Firmy mogą na przykład stworzyć kontrakt współpracy, czyli zbiór zasad, według których przebiega współpraca tych dwóch jednostek. Takie rozwiązanie sprawdzi się również wtedy, gdy transformacja Agile w ogóle nie jest brana pod uwagę, a zatem struktura Biznes versus IT jeszcze przez długi czas pozostanie niezmieniona.

Transformacja Agile nie jest bowiem jedyną odpowiedzią na problemy komunikacyjne na ścieżce Biznes-IT, a wspomniany kontrakt współpracy może być z powodzeniem wykorzystywany przez przedsiębiorstwa niezależnie od stopnia wdrożenia metodyk Agile’owych. 

Kontrakt współpracy powinien być na tyle ogólny, by można było go wykorzystać niezależnie od projektu. Najważniejsze elementy, które warto w takim kontrakcie zawrzeć, to:


Roadmapa

Roadmapa, czyli plan rozwoju projektu wyrażony na osi czasu. Dobrze przygotowana roadmapa powinna zawierać tzw. milestones, czyli wydarzenia projektowe, których niewykonanie lub wykonanie z opóźnieniem może wiązać się z powstaniem ryzyka operacyjnego, ponieważ zwykle od milestone’ów zależy kolejna faza projektu.

Przykładem milestone’u może być zakończenie poszczególnych faz projektowych jak np. fazy analizy biznesowej lub testów wewnętrznych. Jednak milestone’y mogą również odpowiadać kluczowym postępom rozwoju produktu, np. funkcjonalnościom aplikacji.

Oznaczenie ich na roadmapie ułatwia dostrzeżenie zależności pomiędzy nimi, a co za tym idzie, pozwola zoptymalizować proces planowania. Roadmapę warto zaprezentować na spotkaniu typu kick-off meeting, w którym powinni uczestniczyć wszyscy interesariusze projektu.


Sign-off 

Formalna akceptacja jest tak samo ważna w przypadku projektów prowadzonych w metodologii waterfall, jak i Agile, jednak w obu tych przypadkach sign-off będzie wyglądał inaczej. W przypadku projektu waterfall sign-off zwykle oznacza akceptację specyfikacji funckcjonalnej sporządzonej na początku projektu.

Ze względu na swoją specyfikę, w projektach prowadzonych w metodologii Agile specyfikacja funkcjonalna kompletnego rozwiązania zwykle nie powstaje na początku projektu. Dlatego w przypadku projektów zwinnych sign-off może przebierać różne formy, najczęściej jest on wyrażony jako akceptacja poszczególnych części produktu dostarczonych w danej iteracji.

Proces akceptacji ułatwiają w tym przypadku kryteria akceptacji (ang. Acceptance criteria) oraz definicje ukończenia (ang. Definition of done), szeroko stosowane we frameworku Scrum. I tak o ile w projektach prowadzonych waterfallowo sign-off zwykle oznacza jednorazową akceptację, w przypadku Agile’a częstotliwość zatwierdzania wymagań jest zdecydowanie wyższa, a co za tym idzie, zakres ewentualnych zmian proporcjonalnie się zmniejsza.


Ustrukturyzowanie testów UAT

Testy akceptacyjne użytkowników powinny mieć jasno określoną odpowiedzialność po stronie Biznesu. Często bywa tak, że IT wspiera użytkowników biznesowych w testach UAT, co może prowadzić do współdzielenia odpowiedzialności za nie.

Z definicji testy UAT powinny być od początku do końca wykonane przez użytkowników biznesowych, bo to oni finalnie akceptują (bądź nie) zmiany. Pomocne w tym przypadku jest wykorzystanie narzędzi do zarządzania projektami, w których można przypisać konkretne osoby w organizacji do zadań, jakimi mogą być poszczególne przypadki testowe.

Po przypisaniu do konkretnego zadania osoby z Biznesu może ona zaakceptować wynik testu poprzez zamknięcie zadania lub opatrzyć je odpowiednim komentarzem i przypisać do odpowiedzialnego członka zespołu IT w przypadku identyfikacji błędów.

Podsumowanie

Współpraca jednostek biznesowych i IT wciąż jeszcze bywa problematyczna. Prawdziwie zwinne organizacje eliminują problemy poprzez tworzenie takiej struktury organizacyjnej, w której Biznes i IT współtworzą zespoły, zamiast działać jako dwie odrębne jednostki.

Jednak dojrzałe, zwinne organizacje to wciąż nisza na rynku, a przecież jakoś pracować ze sobą trzeba. Dlatego niezależnie od tego, czy firma zdecyduje się na transformację organizacyjną, warto korzystać z narzędzi i metod, m.in. wymienionych w powyższym artykule, by współpraca jednostek biznesowych i IT przebiegała możliwie jak najsprawniej. 

<p>Loading...</p>