Zwinność to za mało

Zwinność (Agile) ma ogromne znaczenie dla firm, które starają się sprostać oczekiwaniom klientów oraz nowym trendom biznesowym. Przyjmując podejście oparte na zwinności, zespoły programistyczne mogą szybko tworzyć nowe produkty i usługi, przekształcać procesy, mogą nawet przeobrazić całą organizację. Ale zespołom tym zdarzają się też potknięcia w interakcjach z innymi zespołami oraz wskutek zależności od nich, toteż ważne jest przewidywanie owych zatorów i likwidowanie ich.

Przyjrzyjmy się firmie świadczącej usługi związane z wydawaniem i obsługą kart kredytowych, która chce zaktualizować swoją aplikację mobilną, by klienci mogli łatwo sprawdzać i realizować punkty z programu lojalnościowego. Firma tworzy zwinny zespół złożony z programistów, projektantów oraz właściciela inicjatywy, który rozumie zachowania klientów, a także potrafi zdecydować, na czym trzeba się skupić i jakie są priorytety. Zespół ten w ciągu kilku tygodni dokonuje aktualizacji aplikacji, ale innemu działowi organizacji kilka miesięcy zabiera dostarczenie danych z systemu programu lojalnościowego, a inna część firmy potrzebuje jeszcze dłuższego czasu na zintegrowanie tych zmian w ramach aplikacji, co opóźnia wdrożenie nowych funkcji.

Klientom nowa odsłona aplikacji się podoba, ale teraz chcą także po zalogowaniu móc sprawdzić niedawną aktywność skutkującą zbieraniem punktów. Członkowie pierwotnego zwinnego zespołu zajęli się już innymi sprawami. Ze względu na to, że każdy jest zajęty, skompletowanie nowego zespołu trwa kilka miesięcy. Zespół ten wprowadza zmiany, ale nie zauważa pewnego defektu, który powoduje, że aktualizacja oblewa test podatności na ataki. Gdy wada ta zostaje naprawiona, zespół operacyjny odmawia wypuszczenia kodu bez bardziej szczegółowych testów. Niesnaski pomiędzy zespołem programistycznym a zespołem operacyjnym co do skali testów jeszcze bardziej opóźniają wprowadzenie nowej aktualizacji.

Tego rodzaju historie zdarzają się w wielu firmach bardzo często, nawet jeśli są to firmy silnie zorientowane technologicznie. Kilka lat temu zdarzyło się to w przedsiębiorstwie Target. Firma ta cierpiała z powodu znacznego długu technologicznego narastającego przez wiele lat rozwoju. Najważniejsze działy firmy były obsługiwane przez monolityczną architekturę, która ograniczała tempo wprowadzania innowacji i zmian. Rozwój ten doprowadził do szybkiego wzrostu popytu na zasoby technologiczne – popytu, który Targetowi udało się zaspokoić w znacznym stopniu dzięki zwiększeniu liczebności personelu przy pomocy zewnętrznych zleceniobiorców.

Przeszkody, jakie napotkał Target i jakie spowalniają transformację innych organizacji, prowadzą nas do ważnej lekcji: zarządzanie zwinne ma wielki potencjał, ale to za mało. By dysponować prawdziwie efektywną organizacją cyfrową, należy usunąć wyboje, które spowalniają postępy osiągane dzięki procesom zwinnego zarządzania. Sprawność zwinnych praktyk w większości organizacji hamują przeważnie trzy przeszkody: sztywna architektura, słabe zarządzanie talentami oraz brak produktowego sposobu myślenia. Przeanalizujemy każdą z nich i przedstawimy sposoby ich pokonania.

Sztywna architektura technologiczna

W dziedzinie IT lata tworzenia rozdętych baz kodu źródłowego (code bases) i łatania licznych dziur w oprogramowaniu sprawiły, że wiele firm charakteryzuje się nieelastycznymi architekturami technologicznymi. W większości organizacji aplikacje odpowiedzialne za kontakt z klientami i za działalność operacyjną zostały stworzone, zanim jeszcze przyjęły się nowoczesne podejścia architektoniczne. Dlatego też cechuje je sztywność, wynikająca z tego, że zbyt wiele funkcji jest ze sobą powiązanych wzajemnymi zależnościami. Gdy zmienia się jeden aspekt kodu, może wystąpić efekt domina.

W większości przypadków przebudowywanie wszystkich systemów tak, by spełniały nowoczesne standardy integracji z wykorzystaniem API i mikrousług, było nierealne. Zamiast tego większość organizacji przyjmuje jedno z czterech często spotykanych podejść.

Nie robić nic. Odstąpienie od jakichkolwiek działań, ponieważ niektóre aplikacje są zbyt małe lub zbyt rzadko aktualizowane, by uzasadniało to inwestycję w ich modernizację.

„Opakować i zamknąć” (wrap and trap). Udostępnienie podstawowych funkcji (features) „starych” aplikacji poprzez dobrze zdefiniowane interfejsy (API) z założeniem, że nowe funkcje będą tworzone już w nowoczesnych systemach.

Przebudować lub poddać refaktoryzacji. Zmiana projektu aplikacji, obejmująca rozbicie bazy kodu na wiele odrębnych i niezależnych części funkcjonalnych, oraz usunięcie zakodowanych na sztywno (hardcoded) wartości.

Zastąpić. Opracowanie nowej aplikacji z zastosowaniem nowoczesnych wzorców architektonicznych, takich jak mikrousługi.

W przypadku różnych obszarów architektury będą miały sens różne podejścia. Dlatego też decydując się na wybór ścieżki, menedżerowie powinni zastanowić się nad potencjalną korzyścią. Czynniki do rozważenia obejmują: popyt na nowe funkcje, częstotliwość interakcji między systemami, koszty obecnej złożoności aplikacji, fragmentację cennych danych oraz ryzyko przerw w prowadzeniu działalności.

Target nadał priorytet modernizacji systemów poprzez udostępnienie często stosowanych danych krytycznych, takich jak cena artykułu oraz jego dostępność. Pozostawił natomiast bez zmian systemy przetwarzania transakcji, które dobrze wykonywały swoje zadanie. Pozwoliło to zespołom skoncentrować wysiłki na optymalizacji doświadczenia klienta – które polega na wyszukiwaniu i zakupie przedmiotów – zamiast tracić czas na zastanawianie się, który z siedmiu systemów cenowych posiadał najodpowiedniejszą cenę dla danego przeznaczenia.

Nowe podejście do zarządzania talentami

Talenty stanowią sedno modelu operacyjnego technologii cyfrowych i menedżerowie wyższego szczebla wiedzą, że muszą zatrudnić najlepszych pracowników, na jakich mogą sobie pozwolić. Niestety, niektóre z najlepszych praktyk z dawnych lat tak naprawdę utrudniły angażowanie właściwych ludzi i nie sprzyjały zwinności w działalności informatycznej przedsiębiorstwa.

Na przykład, gdy firmy zaczęły zdawać sobie sprawę z tego, że ich menedżerowie ds. IT nie zawsze patrzą na problemy z perspektywy biznesowej, zaczęły zatrudniać nowe osoby, lepiej znające się na biznesie. Byli to ludzie, którzy potrafili dobrze się komunikować, rozumieli związki między priorytetami biznesowymi a technologią i dobrze zarządzali relacjami z resztą organizacji. Problem polegał na tym, że wielu z nich nie posiadało głębokiej wiedzy technologicznej. Gdy owi menedżerowie zaczęli zatrudniać ludzi sobie podobnych, ucierpiały na tym umiejętności technologiczne wielu przedsiębiorstw.

Do deficytu talentów przyczyniło się także nieskrępowane wykorzystywanie zewnętrznych zleceniobiorców. Jakiś stopień pozyskiwania siły roboczej z zewnątrz jest rzeczą zdrową, gdyż może pomóc organizacjom szybko uzupełnić luki, zdobyć nowe umiejętności lub wykorzystać przewagę płynącą z niższych stawek za pracę. Jednak niektóre firmy potrząsały tą świnką‑skarbonką zbyt często, by sprostać nagłym wzrostom popytu lub ominąć wewnętrzne blokady na liczbę zatrudnianych osób. Gdy pracownicy firmy zaczęli spędzać zbyt dużo czasu, zarządzając zleceniobiorcami, ich własne umiejętności techniczne uległy atrofii. Zleceniobiorcy zyskali nieproporcjonalnie dużą kontrolę nad własnością intelektualną i nad innowacjami, które były w stanie przynieść przewagę konkurencyjną. Jak przekształcić organizację technologiczną, gdy połowa personelu nie jest przez nią bezpośrednio zatrudniana?

Trzeci problem polega na wykreowaniu w organizacjach modeli określających, jak produkty są budowane i serwisowane oraz kto jest odpowiedzialny w sytuacji, gdy dochodzi do awarii. Firmy przyjęły model, w którym oddzielono produkcję od serwisowania, gdyż pozwala im to podzlecić obcym firmom serwis i wsparcie techniczne. Do kogo zatem dzwonić, gdy coś nie działa lub coś się popsuje w środku nocy: do ludzi, którzy napisali kod, czy do tych, którzy są odpowiedzialni za jego serwisowanie? Zintegrowanie działań z zakresu rozwoju, serwisowania i wsparcia technicznego na poziomie zwinnego zespołu pozwala wyeliminować niepotrzebne przekazywanie sobie zadań, a jednocześnie wprowadzić całościową odpowiedzialność. To zasadniczy element zasad DevOps (development and operations).

By wyeliminować te problemy, organizacje technologiczne będą musiały wprowadzić duże zmiany. Powinny wzmocnić swoje umiejętności techniczne, zredukować zależność od zewnętrznych zleceniobiorców oraz jasno określić zakresy odpowiedzialności. Obecnie większość organizacji technologicznych ma trzy typy ról: strażników, wykonawców i myślicieli. Jednak w przyszłości role te będą musiały się zmienić. Szczególnie strażnicy – menedżerowie projektu, analitycy biznesowi, menedżerowie ds. relacji i menedżerowie zasobów – będą musieli przekwalifikować się. Upowszechnienie się idei zwinności i nowych metod pracy będzie oznaczać odbiurokratyzowanie nadbudowy zarządczej, większą odpowiedzialność i przejrzystość oraz mniejsze zapotrzebowanie na tłumaczy pomiędzy personelem biznesowym a technicznym.

Niektóre firmy dostrzegają potrzebę przeprowadzenia rewolucyjnych zmian i przeprojektowują swój model zarządzania talentami, stosując kilka istotnych zasad:

Koncentracja na roli kierownika technicznego (engineering manager). Zorientowanego biznesowo menedżera ds. IT zastępuje kierownik posiadający autentyczną wiedzę techniczną, która pozwala mu sprawdzić kod napisany przez innych. Pracownik ten jest na tyle obeznany ze sprawami biznesowymi, by móc ściśle współpracować z menedżerami produktu i właścicielami firmy. Kierownik techniczny pomaga odbudować wiarygodność i biegłość techniczną, która przyciąga talenty inżynieryjne – zarówno doświadczonych pracowników, jak i absolwentów uczelni.

Przekwalifikowanie strażników. Należy wytypować cenniejsze talenty w tych szeregach i przeszkolić te osoby, by powierzyć im ważniejsze role. Na przykład menedżerowie projektu otwarci na zmiany mogą stać się scrum masterami, a niektórzy analitycy biznesowi – właścicielami produktów. Niestety, w nowym modelu operacyjnym będzie mniej funkcji strażników do obsadzenia niż ludzi, którzy obecnie je pełnią. Wynika to z faktu, że nowy model jest bardziej wydajny i skuteczny, gdyż opiera się na przekazaniu większej władzy i odpowiedzialności zespołom i usunięciu zbędnej biurokracji.

Demokratyzacja odpowiedzialności. Nowy model zarządzania talentami oznacza, że ludzie biorą na siebie szerzej zakrojone role i zakresy odpowiedzialności. Na przykład w większości przypadków rejestry produktu (product backlog) zostają połączone, tak by obejmowały zarówno projektowanie, jak i czynności z zakresu wsparcia technicznego. Gdy jeden z kierowników ds. rozwoju klienta zapytał: „Ile razy waszym zdaniem czołowi programiści będą musieli odbierać telefony w środku nocy z powodu problemów produkcyjnych, zanim odejdą?”, dyrektor informatyczny odparł: „Nie wiem, ile razy będziemy musieli ich budzić w nocy, zanim zaczną pisać lepszy kod”. W momencie gdy owi programiści znaleźli się pod presją, by dostarczyć bogatsze funkcje, ucierpiała na tym niezawodność. Programiści nie odeszli, jak obawiał się tego menedżer, popracowali natomiast nad poprawą niezawodności, ponieważ czuli się w większym stopniu odpowiedzialni za produkt będący wynikiem ich pracy. Równocześnie ci sami programiści pracują razem z zespołem operacyjnym nad usprawnieniem integracji i wdrożenia kodu, skracając czas wprowadzenia aplikacji na rynek przy jednoczesnej redukcji jej wad.

Ograniczenie zależności od zewnętrznych podwykonawców. Innowacje w oprogramowaniu wewnątrz firmy powinny pochodzić od pracowników. Oznacza to posortowanie różnych rodzajów wykonywanej pracy i budowę zwinnych zespołów złożonych ze skompletowanych we właściwej proporcji talentów wewnętrznych i zewnętrznych. Oczywiście, cel nie polega na ślepym redukowaniu liczby podwykonawców w dążeniu do osiągnięcia jakiegoś sztucznego wskaźnika. Firmy powinny podejść inteligentnie do tego, jaki cel chcą osiągnąć, i krytycznie przemyśleć, jaki „miks” pomoże im do tego celu dotrzeć w chwili, gdy gromadzą zasoby niezbędne do zarządzania technologią i do rekrutacji personelu.

Target odkrył, że tradycyjne działania rekrutacyjne nie przyciągnęły talentów inżynieryjnych, których potrzebowała firma, by szybko działać na rynku. Zależność firmy od podwykonawców i od ich uzdolnionych pracowników technicznych ograniczyła obecność firmy w społeczności twórców oprogramowania. By wrócić do gry, Target przyjął technologię otwartego źródła i podał do publicznej wiadomości informację o swoich ambicjach przekształcenia i wyskalowania posiadanej technologii cyfrowej. Prawdę mówiąc, byłoby trudno przyciągnąć wystarczającą liczbę utalentowanych programistów, gdyby firma pozostała przy zamkniętym oprogramowaniu (proprietary code), gdyż wielu najlepszych programistów woli pracować z otwartym źródłem. To pomogło przyciągnąć i utrzymać deficytowe talenty inżynieryjne i ograniczyć zależność firmy od podwykonawców.

Jak zarządzać produktem, stosując metodologię zwinności

W coraz bardziej zwinnym świecie nasilają się słabe strony tradycyjnego, opartego na projekcie, kaskadowego podejścia do programowania (waterfall). W porównaniu ze zorientowanym produktowo podejściem zwinnym metoda kaskadowa jest mniej elastyczna
i wolniej reaguje na potrzeby firmy oraz jej klientów.

Przejście na metody zwinne pozwala zaradzić niektórym problemom, ale nie idzie wystarczająco daleko, by je rozwiązać w przypadku cyfrowych produktów i usług. Zastosowanie praktyk i dyscypliny w zarządzaniu produktami pozwala zlikwidować tę lukę.

Organizuj działania wokół produktów, a nie projektów. Organizacja pracy wokół produktu, a nie projektu, pozwala powiązać procesy rozwojowe bezpośrednio z rezultatami biznesowymi. Produkty są zorganizowane wokół problemów i okazji biznesowych, często wynikających z wprowadzania nowej funkcji lub z poprawiania doświadczenia użytkownika. Zespoły technologiczne i biznesowe powinny ze sobą współpracować przy ustalaniu celów i priorytetów. Każdy produkt dostaje swojego „właściciela”, który jest ostatecznie odpowiedzialny za opracowanie planu działania, zdefiniowanie wskaźników do pomiaru postępów w jego realizacji oraz podejmowanie właściwych decyzji pozwalających na płynne wykonanie wszystkich zadań.

Utwórz stałe zespoły. W podejściu projektowym zespoły tworzy się i rozwiązuje. Natomiast zespoły produktowe trwają przez cały okres życia produktu, gotowe do dalszej pracy nad produktem i nad jego ewolucją. Stabilność ta sprawia, że zespół lepiej reaguje, jest bardziej wydajny i odpowiedzialny.

Finansuj z myślą o długim okresie. Produkty cechują się dłuższym cyklem życia, dlatego powinny być finansowane w ujęciu rocznym, by wspierać ich długofalowe funkcjonowanie. Niektórzy dyrektorzy finansowi i kontrolerzy mogą wystrzegać się tej zmiany, ale model produktowy pozwala w bardziej systematyczny sposób mierzyć rezultaty niż tradycyjne podejścia oparte na tzw. biznesowych uzasadnieniach projektu (business cases), ponieważ wyniki produktu są mierzone w trybie ciągłym. Przegląd finansowania w cyklu kwartalnym pozwala firmom dostosować się do zmiany priorytetów lub do zmian w apetycie inwestycyjnym – czy nawet zająć się innymi produktami o wyższej stopie zwrotu.

Firmy cyfrowe „od urodzenia” zazwyczaj stosują produktowy model zarządzania, ponieważ ich główne produkty i usługi są zazwyczaj oparte na oprogramowaniu, a obecnie koncepcje te przyjmuje coraz więcej tradycyjnych firm. Na przykład Target zorganizował swoją technologię tak, by była zbieżna ze zdolnościami biznesowymi firmy oraz z doświadczeniami klientów. Ponad 250 menedżerów produktu funkcjonuje niczym przedsiębiorcy odpowiedzialni za osiągnięcie wymiernych rezultatów biznesowych. Menedżerowie osiągający lepsze zwroty są nagradzani większymi zasobami oraz ambitniejszym zakresem odpowiedzialności.

Metodologia zwinności to potężna siła kreująca wartość. Ale sama z siebie nie wystarcza, a wiele organizacji z trudem czerpie pełnię korzyści oferowanych przez to podejście w dziedzinie zarządzania technologią, talentami i produktami. Podczas gdy niektórzy krytycy zwinności mogą twierdzić, że podejście to działa tylko w przypadku firm już powstałych jako cyfrowe, my dostrzegamy znacznie większy jego potencjał. Wyeliminowanie sztywności architektonicznej, zasypanie luki w dziedzinie talentów oraz przyjęcie zorientowanego produktowo sposobu myślenia wymaga zaangażowania oraz ustawicznych wysiłków ze strony zarówno przedsiębiorstwa, jak i liderów technologicznych. W sumie jednak metodologie te mogą okazać się czymś tak oczywistym, jak obecnie uzgadnianie priorytetów biznesowych i technologicznych. Do tego czasu korzyści przypadną tylko tym, którzy nie boją się podjąć wysiłku przekształcenia całej organizacji tak, by była gotowa na przyjęcie idei zwinności. 

O AUTORACH:

Will Poindexter i Steve Berez zajmują się technologią i zwinnymi innowacjami w firmie Bain & Co. Pracują odpowiednio w Chicago i w Bostonie.