Panel dyskusyjny z udziałem ekspertów Linux Polska, Kamila Góreckiego i Radosława Żaka-Brodalko. Dyskusja jest próbą odpowiedzi na pytanie, czy samo wdrożenie metod i narzędzi jest wystarczające w cyfrowej transformacji, czy potrzebna jest jednak zmiana modelu współpracy i kultury organizacyjnej.
Transkrypcja
Lektor. Yin i Yang to pojęcie wywodzące się z filozofii chińskiej, opisujące przeciwstawny, ale wzajemnie powiązany, samonapędzający się cykl. Yin i Yang można traktować jako uzupełniające się siły, które oddziałują na siebie, tworząc dynamiczny system, w którym całość jest większa niż suma części. Yin i Yang nie wykluczają się wzajemnie. Wszystko ma swoje przeciwieństwo, jednak nigdy całkowite, a jedynie względne. Żadna rzecz nie jest nigdy w pełni Yin ani całkowicie Yang. Każde z nich zawiera w sobie pierwiastek swojego przeciwieństwa. Uważny obserwator, znający arkana informatyzacji przedsiębiorstw zwróci uwagę na podobieństwo tej podstawowej koncepcji filozoficznej do sytuacji rozwoju i operacji usług informatycznych, czyli całego cyfrowego dobrodziejstwa, z którego chętnie korzysta sfera biznesu. Tak jak w przypadku Yin i Yang, obszary tworzenia i operacji są od siebie wzajemnie zależne oraz stanowią nierozerwalną, uzupełniającą się całość. Tak jak Yang, czyli jasna, nasłoneczniona i gorąca strona rzeczywistości, obszar rozwoju aplikacji IT to technologiczna witalność, innowacje i naturalne dążenie do wprowadzania nowości. Jego uzupełnienie i przeciwieństwo zarazem to Yin, czyli strona ciemna i chłodna, oznaczająca kalkulację, zachowawczość i stabilizację. To niewątpliwe przymioty obszaru operacji odpowiedzialnego za jakość działania i niezawodność. Pamiętajmy jednak, że to dzięki wspomnianym różnicom i wzajemnemu oddziaływaniu informatycznych Yin i Yang w rezultacie dostajemy jednocześnie nowoczesne i stabilne rozwiązania przynoszące nam korzyść.
Kamil Górecki, ekspert IT, Linux Polska. Słuchaj Radku, trafiła mi się ostatnio ciekawa sytuacja. Zadzwonił do mnie zaufany klient, którego pewnie znasz. Zaczęliśmy rozmawiać na temat wdrażania rzeczy związanych z DevOpsem. W czasie naszej rozmowy okazało się, że firma chciałaby wdrożyć Shift-left, cały DevOps…
Radosław Żak-Brodalko, ekspert Linux Polska. Cały DevOps?
KG. Cały DevOps.
RŻB. Czyli nie tylko śrubki i nakrętki?
KG. Pewnie chcieliby śrubki i nakrętki, ale dochodzi nam tutaj analiza kodu, wrzucenie tego w jakąś pętlę CI/CD, automatyzacja tego wszystkiego.
RŻB. A coś więcej mógłbyś mi powiedzieć o tej organizacji?
KG. Wiesz, jeszcze jestem przed podpisaniem NDA-ki, więc ciężko będzie cokolwiek powiedzieć. Myślę, że skończy się to na takim typowym wywiadzie środowiskowym na początek, żebyśmy się dowiedzieli cokolwiek, jak to tam u nich wygląda.
RŻB. Kwestie organizacyjne są najważniejsze w tym wszystkim. To, że ktoś ma świetne narzędzia, to niewiele wnosi z punktu widzenia DevOpsu. Ja tak przynajmniej uważam.
KG. Ale jak to niewiele wnosi? Zrobisz sobie CI/CD i od razu taki developer ma więcej czasu na pracę i inne rzeczy.
RŻB. On ma więcej czasu na wypełnianie Jiry i wypisywanie wniosków do działu testów, żeby móc testować, żeby te wspaniałe automaty można było uwolnić i żeby one mogły coś zrobić. Pamiętajmy, że DevOps wymaga przede wszystkim ścisłej współpracy dwóch obszarów, czyli rozwoju i operacji. Nie ma DevOpsu bez tej ścisłej, zaznaczam, współpracy.
KG. To, co powiedziałeś, jest dosyć ciekawe. Taki wniosek do testów na przykład. W ogóle nieuwzględnienie działu testów jako części DevOpsu, jako elementu Dev, to takie trochę nieporozumienie.
RŻB. I tu jest właśnie clue tego całego problemu. Dużo firm wdraża narzędzia, automatyzację, kompletnie nie patrząc na okoliczności organizacyjne. Niektórzy to nazywają kulturą organizacyjną. Chodzi o pewne wzorce zachowań w organizacji, pewne relacje, które się buduje. One umożliwiają efektywne wykorzystanie tych narzędzi.
KG. Może zatrzymajmy się przy tym. To wydaje się ciekawe, że musi być stworzona pewna kultura wokół ludzi w danej organizacji. Ale czy to nie jest tak, że te narzędzia pozwalają na odblokowanie potencjału tych ludzi? Żeby oni mogli się organizować wokół jakichś grup, zainteresowań czy projektów? Z tego, co zauważyłem, to mamy tak naprawdę silosy w firmach, które mają problem komunikacyjny. Pytanie, czy właśnie ten DevOps nie rozwiązuje problemu komunikacyjnego, które firmy mają?
RŻB. Wszystko się zgadza, tylko że DevOps go rozwiązuje w pewnych okolicznościach. Żeby on mógł rozwiązać te problemy, to musisz skierować się właśnie we wspomniane okolice w zarządzaniu organizacją. Bo co z tego, że mamy próbę wdrożenia DevOpsu, gdy dalej mamy silosy, tylko one się inaczej nazywają. Zamieniamy kierowników liniowych na liderów, zamieniamy kogoś na jeszcze inną rolę wziętą z journala informatycznego i nic to nie wnosi. Tak naprawdę modus operandi, czyli sposób działania firmy czy organizacji IT, nie zmienia się w ogóle.
KG. To, co mówisz, można by odnieść, parafrazując to troszkę, do Spotify. Czytałem artykuł na ten temat. Oni sobie wprowadzili plemiona, podziały na gildie i tak dalej. Jednak wycofali się całkowicie z tego pomysłu, bo zauważyli, że nie jest to w żaden sposób dla nich efektywne pracowo. Właśnie to moim zdaniem jest dobrym przykładem tego, jak agile powinien działać. Widzimy, że coś nie działa, no to wycofujemy się i robimy to inaczej.
RŻB. To jest prawda. Natomiast patrząc na sam paradygmat zarządzania, na otwartość na zmianę, na akceptację zmian, bo to jest tak naprawdę akceptacja zmiany w dobrym celu, w słusznym celu, to to jest istota tej całej zwinności. I tak jak mówisz, przypadek Spotify jest tutaj idealny. Oni, obserwując jakiś wyimaginowany sposób działania, który pozwalał im w pewnym momencie osiągnąć lepsze wyniki, stwierdzili, że w dłuższym okresie po prostu nie był efektywny. Nie dawał im tego, czego oczekiwali, czego wymagała ich strategia.
KG. Zmiana też nie może iść od samej góry i naciskać na pracowników na dole. Podziały powinny móc się naturalnie wytworzyć od dołu. Od faktycznej wymiany informacji między pracownikami. Dopiero wtedy zostanie uwolniony potencjał kreatywny całego działu, na przykład Dev, i możliwości utrzymania infrastruktury działu Obs.
RŻB. I tutaj mamy ważną zasadę wdrażania zmiany organizacyjnej. Do tego są różne podejścia. Jest na przykład podejście 8 kroków Johna Kottera, gdzie można zobaczyć, jak trzeba zorganizować samą zmianę, żeby ona była skuteczna w organizacji. Zrzucenie odpowiedzialności za zmianę z góry metodą top-down, czyli od samej góry, od szczebla kierowniczego, wyższego poziomu do niższych szczebli i finalnie do zespołów jest przeciwproduktywne. Tak naprawdę w każdym obszarze będzie dochodziło do zniekształcenia tych idei i całego założenia, oczywiście presją różnych tarcz, które w naturalny sposób w organizacji występują.
KG. Prywatnych celów też. Każdy, kto przychodzi do firmy, ma jakiś swój cel, który chciałby zrealizować. W tych wszystkich silosach jest taki problem, że pracownik najniższego szczebla musi iść do pracownika wyższego szczebla, ten znowu do kolejnego, następnie do kierownika, kierownik do dyrektora, potem ci dyrektorzy muszą się spotkać i dopiero podjąć decyzję. A właśnie w zwinnych organizacjach chodzi głównie o to, że jeżeli faktycznie mam ważny temat nawet do prezesa, to powinienem móc pójść bezpośrednio do niego i w samym zarodku załatwić problem.
RŻB. Zgadzam się z Tobą absolutnie. Bardzo trudno jest wykonać czy wdrożyć tak zwaną zwinność w organizacji, w której jest wiele poziomów hierarchii organizacyjnej. Zawsze należy patrzeć na to, żeby jak najbardziej spłaszczać tę hierarchię, czyli mieć jak najmniej szczebli pośrednich. Oczywiście w taki sposób, żeby utrzymać sposób działania czy model operacji, który wspiera procesy biznesowe. Natomiast starać się zawsze redukować poszczególne, zwłaszcza pośrednie, szczeble zarządzania. To jest nieefektywne.
KG. Trafiłem na bardzo ciekawy przypadek, w którym nie było stanowisk w firmie. Byłeś zatrudniany jako jeden z pracowników. Miałeś bardzo szerokie obowiązki, ale oczywiście też z tego wynikające prawa. Dzięki nim mogłeś oddziaływać na organizację. Ciekawe w tym wszystkim było to, że jeżeli ktoś zaczął brać udział w jakimś przedsięwzięciu, to brał odpowiedzialność za swoją działkę bezpośrednio. Tego często brakuje w organizacjach. Problemem jest to, że nie mam jasno powiedziane, że jeżeli ja coś wytwarzam, to biorę za to odpowiedzialność. Nie chodzi o taką odpowiedzialność, że jeżeli coś się zepsuje, to ktoś musi, mówiąc kolokwialnie, polecieć za błąd. Wręcz odwrotnie. Jeżeli za coś odpowiadam, to przykładam się do tego z największą starannością i wiem, że jeżeli cokolwiek się wydarzy, to mogę pójść z tym do kogoś, kto mi z tym pomoże. Każdy będzie wiedział, że ja podejmuję decyzję, a inni działają tutaj wspierająco w organizacji.
RŻB. Tutaj można się właśnie zorientować na model zespołów wielofunkcyjnych, czyli praca w poprzek. Nie w silosach, nie w wertykalnie, tylko w horyzontalnie. Mamy zespoły ułożone w taki sposób, że jeden zespół, który organizuje się, najlepiej samodzielnie, realizuje pewne cele związane z całym łańcuchem wartości biznesu, produktu czy gałęzi produktu w danej organizacji.
Lektor. Zespoły wielofunkcyjne składają się z różnorodnych specjalistów, takich jak analitycy, projektanci, programiści, testerzy i inni. Każdy członek ma unikalne umiejętności i wiedzę, co pozwala na wszechstronne podejście do rozwiązywania problemów. Wielofunkcyjne zespoły wymagają aktywnej komunikacji i współpracy między ich członkami. Dzięki temu można szybko rozwiązywać problemy, wymieniać pomysły i unikać izolacji działów. Dzięki różnorodności umiejętności i perspektyw zespoły wielofunkcyjne są bardziej kreatywne i skłonne do tworzenia innowacyjnych rozwiązań. Wspólna praca nad projektem prowadzi do nowych pomysłów i optymalizacji. Wielofunkcyjne zespoły mogą działać szybciej, ponieważ nie ma potrzeby przekazywania informacji między oddzielnymi działami. Wszystko dzieje się w jednym miejscu, co przyspiesza procesy. Współpraca wielofunkcyjna pozwala na lepsze wykorzystanie zasobów, takich jak czas, budżet i ludzie. Każdy członek zespołu może pracować nad wieloma aspektami projektu. Dzięki różnorodności umiejętności zespoły wielofunkcyjne lepiej rozumieją cele biznesowe i potrzeby klientów. To prowadzi do bardziej trafnych rozwiązań. Wielofunkcyjne zespoły są bardziej elastyczne w reagowaniu na zmiany i wyzwania. Mogą dostosować się do nowych wymagań i szybko reagować na sytuacje. W praktyce IT korzystanie z zespołów wielofunkcyjnych może przynieść wiele korzyści, takich jak skrócenie czasu dostarczania produktów, lepsza jakość oprogramowania i większa satysfakcja klientów.
RŻB. Tutaj polecam zapoznanie się z modelem firmy Haier. Jest taka firma, pochodząca z Chin, duży dostawca rozwiązań AGD, jeden z większych na świecie w tej chwili, który zatrudnia 80 tys. osób. Haier wymyślił sobie ciekawy model, bardzo sprawny i działający od roku 2000. Firma dąży do tego, żeby jak najwięcej tak zwanych mikroprzedsiębiorstw składało się na tę organizację. W pewnym okresie było to około 4 tysięcy mikroprzedsiębiorstw działających samodzielnie i na zasadzie finansowania przez spółkę matkę.
KG. To są tak naprawdę organizacje, które się same organizują w górę.
RŻB. Tak jest.
KG. Zrzeszamy się, bo chcemy. Trochę mi to przypomina model korporacyjno-anarchistyczny, bo tam jest to samo podejście. Faktycznie zrzeszamy się od najmniejszych jednostek do rodzin, rodziny zrzeszają się w miasta, a miasta zrzeszają się np. w państwa. To jest ciekawy model.
RŻB. Ciekawy i działający, dlatego polecam, żeby się z nim zapoznać. Tam specyficznym problem była akurat skala tej organizacji, a więc skala zarządzania. Generalnie chodziło właśnie o to, że to jest zbiór mikroprzedsiębiorstw, które są samodzielne. Wręcz niektóre uzyskały autonomię na poziomie formalnym, czyli zostały wyłączone jako samodzielne organizacje, jako samodzielne jednostki gospodarcze.
KG. Ciekawi mnie to, jak oni to osiągnęli pod względem narzędziowym. Nie możemy mówić o przekształceniach organizacyjnych, kiedy nie mamy tak zwanego młotka, dłuta i śrubokrętu. Wydaje się, że komunikacja w dzisiejszych czasach powinna być głównie prowadzona w sposób asynchroniczny. To, co zrobił Haier, pozwala im w odpowiedni sposób dostosowywać te mniejsze przedsiębiorstwa do zmieniającego się otoczenia. Tak naprawdę nie zważając na to, co spółka matka w tym momencie narzuca. Mają zachowany pewien pęd i mogą zmienić jego kierunek.
RŻB. Zgadza się. To jest właśnie istota tak zwanej zwinności, zdolność dostosowawcza.
KG. Cała ta sytuacja wokół Haiera przypomina mi takie wychodzenie z frameworka. Dużo organizacji bierze sobie taki framework i traktuje go jak świętość. Wdraża element po elemencie – każdy element. Jakby nie bolało, to musi być to wdrożone. Wydaje się to być kontrproduktywne. Powinniśmy to traktować jako zbiór drogowskazów, a nie jako wykute w kamieniu reguły.
RŻB. Pamiętajmy, z czego składa się taki framework organizacyjny. To jest zbiór przeróżnych metod zarządzania. Oczywiście one muszą być spowinowacone ze sobą, zgodne, żeby nie wchodzić w konflikty. Weźmy za przykład SAFe, popularną ostatnią metodę. To jest bardzo istotne, żeby traktować te frameworki jako zbiór dobrych metod zarządzania. Możemy iść na szkolenia z takiego frameworka, dość złożonego, który pokrywa wiele różnych obszarów. Takie szkolenia pozwalają przede wszystkim zapoznać się z tymi metodami, zrozumieć ich istotę. Ja nie muszę zastosować wszystkich metod czy całego frameworka. Już pomijam, że sam SAFe mówi o tym, że mamy kilka poziomów dojrzałości i poziomów wdrażania w organizacji. Nie trzeba od razu wdrażać wszystkiego. Jednak często jest taka tendencja, żeby ta zwinność była zwinnie wdrożona. Tutaj trzeba mieć na uwadze właśnie to, żeby traktować to jako drogowskaz, jako pewną mapę, która pozwala nam na zmianę trasy, obranie innego punktu pośredniego na trasie, itd. Ale ważne jest to, że zmierzamy do jakiegoś celu. Wracając do Johna Kottera i ośmiu kroków, czyli od czego zaczyna się zmiana w organizacji? Od uświadomienia sobie tak zwanej wielkiej szansy, jak on to ładnie nazywa, the big opportunity, która jest tak naprawdę światełkiem w tunelu dążenia organizacji do realizacji strategii. Bez tego nie ma żadnej udanej zmiany organizacyjnej.
KG. To jest ważne, żeby komunikować członkom organizacji, jaki mamy cel wspólny. Żeby nie zostawić tych ludzi w osamotnieniu z nadchodzącą zmianą, bo dla wielu ludzi zmiana to jest ryzyko. Gdy ludzie widzą ryzyko, to wolą od niego uciekać. Tak naprawdę mamy wtedy dwie strony w organizacji. Jedną, która mówi „żadnych zmian”, „będę z tym walczył aktywnie”, „nie będę tego robił” i drugą, która będzie aktywnie zwalczała tę pierwszą i mówiła „nie, to musi być teraz”, „w ten sposób”, „musimy w tym momencie być zwinni”, „musimy zapisywać story poinciki”, „musimy zapisywać wszystkie wydane godziny z naszej pracy”, itd. Wtedy tak naprawdę mamy problem. Jeżeli firma przestaje się dogadywać, to na koniec dnia nie mamy produktu, który moglibyśmy oddać.
RŻB. Masz rację. Całym kluczem efektywności i współpracy jest przede wszystkim zaufanie. To może brzmieć oczywiście szumnie, ale jest to potwierdzone naukowo. Zostały przeprowadzone badania naukowe przez Paula J. Zaka, naukowca, który zajmuje się działaniem mózgu i funkcjonowaniem człowieka w grupie. Badanie te wykazały wprost, że zaufanie jest kluczowym elementem budowania zdrowych relacji w organizacji. Relacji, które prowadzą do rozwiązywania problemów, do osiągania celów przez zespoły na niższym szczeblu oraz w ogóle w organizacji jako takiej.
Lektor. Paul J. Zak, neurobiolog, przeprowadził obszerne badania nad rolą zaufania w wydajności organizacji. Jego wyniki podkreślają kluczowe połączenie między zaufaniem, wydajnością zespołu, a innowacjami. Przyjrzyjmy się naukowym aspektom tego zjawiska. Badania Zaka koncentrują się na związku chemicznym zwanym oksytocyną. Oksytocyna jest związana z tworzeniem więzi społecznych, empatią i zaufaniem. Kiedy wykazujesz zaufanie wobec kogoś, jego mózg uwalnia oksytocynę. To tworzy cykl budowania wzajemnego zaufania. W skrócie, zaufanie rodzi zaufanie. Kiedy liderzy i członkowie zespołu ufają sobie nawzajem, sprzyja to współpracy i pracy zespołowej. Zak zidentyfikował osiem zachowań kierowniczych, które stymulują produkcję oksytocyny i wzmacniają zaufanie w zespołach.
- Jako lider doceniaj i świętuj wybitne osiągnięcia.
- Daj możliwość realizowania wyzwań, które pomagają jednostkom rosnąć.
- Pozwól na autonomię w wykonywaniu pracy.
- Pozwól pracownikom kształtować swoje role zgodne z ich własnymi mocnymi stronami.
- Transparentna komunikacja buduje zaufanie.
- Twórz więzi poza zadaniami zawodowymi.
- Wspieraj rozwój osobisty i zawodowy.
- Liderzy, którzy przyznają się do błędów i wrażliwości, budują zaufanie.
Podsumowując, zaufanie stanowi podstawę, na której opiera się wydajność zespołu i innowacje. Kiedy zaufanie kwitnie, organizacja odnosi sukcesy.
KG. Jeżeli pozbędziemy się w tych organizacjach hierarchii, wypłaszczymy strukturę, to pozbędziemy się tzw. walki o stołki. W takim momencie tworzymy grunt pod budowanie zaufania. Wtedy nikt nie musi rywalizować ze sobą o znaczenie w firmie. Każdy jest znaczący, każdy bierze za coś odpowiedzialność i każdy ma znaczące miejsce w organizacji.
RŻB. Użyłeś ważnego słowa. Walka. Walka wyklucza zaufanie, bo każdy jest potencjalnym wrogiem. Jeżeli mamy na przykład dwa silosy, które mają różne cele, bo one realizują najczęściej cele swoje, cele kierowników, osób zarządzających, to ta walka musi zostać jakoś zmieniona na współpracę.
KG. Ciekawym przykładem jest tak zwany DevOps. Jak to najczęściej wyglądało w firmach? Developerzy pisali kod, zero zmartwień, nic ich nie obchodziło. Napisali program i wysyłali go do administratora: „wgrywaj”. Administrator mówił wprost: „nie będę tego wgrywał”, „nie podoba mi się to”. Tak naprawdę wyglądała walka między dwoma działami, a przecież wcale nie o to chodzi. Jeżeli ktoś coś wytworzy, to najlepiej, żeby to było we współpracy z administratorem. On wie dokładnie, na czym to będzie uruchamiane, w jaki sposób, jakie mamy zasoby dostępne w naszej organizacji, żeby w ogóle móc uruchomić tę nową aplikację. A tak naprawdę Ops bez developera nie uruchomi tego.
RŻB. Po drodze jeszcze ważna rzecz się wydarzyła. Powstał tak zwany ITIL, czyli metody zarządzania, które miały uspójnić, ujednolicić metody zarządzania świadczeniem usług informatycznych. No i te metody, mam tu na myśli ich starszą generację, były stricte procesowe. Wszystko było procesem, było jasno ustalone. Były pewne role, zespoły doradcze, decyzyjne. Na przykład tak zwany CAB, znany w wielu firmach, czyli Change-advisory board, który podejmował niejako decyzje o wdrożeniu zmiany itd. Natomiast to powodowało jeszcze większą izolację tych zespołów. Z punktu widzenia podejścia szczupłego zarządzania, czyli leanu, to było też przeciwproduktywne. Tworzyło cały proces, często przefantazjowany, zbyt skomplikowany w stosunku do tego, jakimi faktycznie ryzykami ten proces zarządzał. Ważne jest to, żeby wiedzieć, że to się też zmienia. Gdy popatrzy na te branżowe metody, czyli chociażby na nową generację ITIL-a, to tam już jest pójście w kierunku metod łagodnych, miękkich, gdzie nie ma właśnie stricte realizowanych procesów, tylko są już praktyki. To są metody, które wstrzykujemy w poszczególne etapy pracy. Praca może być realizowana w sposób ciągły, czyli Continuous Integration, Continuous Testing, Continuous Deployment, czyli różne metody ciągłej pracy, tak żeby nie zaburzać przepływu pracy między poszczególnymi funkcjami w jednym zespole.
Lektor. ITIL, Information Technology Infrastructure Library to zestaw najlepszych praktyk dotyczących budowy i zarządzania organizacją IT. ITIL można porównać do instrukcji obsługi samochodu. Wyobraź sobie, że kupiłeś nowy samochód. W środku znajduje się gruby podręcznik obsługi – to właśnie ITIL. W nim znajdziesz wszystkie informacje na temat tego, jak dbać o samochód, jakie czynności wykonywać regularnie, jak rozwiązywać problemy i jakie procedury stosować. W instrukcji obsługi masz opisane, kiedy należy wymienić olej, sprawdzić opony, czy przeprowadzić przegląd techniczny. To jak rutynowe przeglądy w ITIL. Regularne działania, które pomagają utrzymać usługi w dobrej kondycji. Kiedy coś się zepsuje, sięgasz po instrukcję obsługi. To jak w ITIL, gdzie mamy procedury naprawcze na wypadek awarii. Instrukcja podpowiada, jakie kroki podjąć, aby przywrócić działanie usługi. Instrukcja obsługi nie tylko pomaga w naprawach ale także w optymalnym użytkowaniu samochodu. To jak zarządzanie wartością w ITIL. Dbamy nie tylko o awarie, ale także o to, aby usługi były efektywne i dostarczały wartość dla użytkowników. Tak więc ITIL to taki podręcznik obsługi dla organizacji IT, który pomaga w utrzymaniu i optymalnym zarządzaniu usługami informatycznymi. Swego czasu, w celu uporządkowania procesów, ITIL wprowadził koncepcję cyklu życia usługi, który składał się z 5 faz: strategii usługi, projektowania usługi, zmiany usługi, operacji usługi i udoskonalenia usługi. Podejście to było zorientowane na dostarczenie usług działających zgodnie z umową ustaloną w fazie projektowania, zgodnie z ustalonymi wskaźnikami. Współcześnie ITIL przesuwa się od podejścia cyklu życia do systemu wartości usługi. Podkreśla wzajemne powiązania różnych komponentów podejścia, w tym praktyk, zasad przewodnich, zarządzania i ciągłego doskonalenia. Nowe podejście zorientowane jest przede wszystkim na dużą wartość usług dostarczanych klientowi i jego zadowolenie, nie zaś na samo wypełnienie warunków umowy. ITIL 4 wprowadza siedem zasad przewodnich, które stanowią praktyczne wytyczne pomagające podejmować decyzje i wspierające ciągłe doskonalenie na wszystkich poziomach organizacji. Oto te zasady:
- skup się na wartości: wszystko, co organizacja robi, powinno tworzyć wartość dla interesariuszy. Wartość nie ogranicza się tylko do klientów i użytkowników, ale obejmuje także regulacyjne wymogi, społeczeństwo, udziałowców i pracowników;
- pamiętaj, że wartość to nie tylko aspekt finansowy, ale także doświadczenie klienta i użytkownika;
- zacznij tam, gdzie jesteś: nie zaczynaj od zera i nie buduj czegoś nowego, nie biorąc pod uwagę tego, co masz. Zazwyczaj lepiej jest ulepszać istniejące rozwiązania niż zaczynać od nowa. Oczywiście musisz umieć rozpoznać moment, w którym wymagana jest kompletna wymiana;
- postępuj iteracyjnie z uwzględnieniem opinii zwrotnej: wprowadzaj zmiany krok po kroku, testując je i dostosowując na podstawie opinii zwrotnej. To podejście pozwala unikać dużych ryzyk i umożliwia ciągłe doskonalenie;
- współpracuj i promuj widoczność: współpraca między zespołami i transparentność są kluczowe. Dzięki temu można unikać izolacji i tworzyć lepsze rozwiązania;
- myśl i pracuj holistycznie: patrz na całość, nie tylko na pojedyncze elementy. Zrozum, jak różne części organizacji wpływają na siebie nawzajem;
- prostota i praktyczność: wybieraj rozwiązania, które są proste i praktyczne. Unikaj komplikacji, które mogą prowadzić do zbędnych problemów;
- optymalizuj i automatyzuj: dąż do ciągłego doskonalenia i automatyzacji procesów, aby zwiększyć efektywność i jakość usług.
Zasady te stanowią fundament ITIL 4 i pomagają organizacjom osiągać lepsze wyniki w obszarze zarządzania usługami informatycznymi.
KG. ITIL w wersji 4. bardzo obrósł wokół całej filozofii DevOps, gdzie nie próbujemy wpływać bezpośrednio na naszych specjalistów. Poszukując osoby na dane stanowisko, zatrudniamy kogoś, kto się na tym zna. Chcemy mieć kogoś, kto zna daną materię, którą musimy mieć obsłużoną w organizacji. I tak było w ITIL-u 3, czyli mieliśmy proces, wszystko było sztywne, pracownik nie mógł pewnych rzeczy wykonywać. Tak naprawdę ta osoba była wrzucona w tryby, w których nie do końca musiała się odnaleźć mimo ogromnego doświadczenia. A taki DevOps pozwala na łagodne wejście nowej osobie na dane stanowisko i nawet umożliwiają jej już od samego początku wdrożenie znaczących zmian, które mogą wpłynąć pozytywnie na samą organizację.
RŻB. Pamiętajmy, że są dwa podstawowe filary DevOpsu wyróżniane przez całą literaturę. To jest przede wszystkim współpraca, nastawienie, zorientowanie na współpracę, czyli eliminacja wszelkich barier formalnych, organizacyjnych we współpracy. Przeróżne formalizmy w postaci wniosków o testy czy o wdrożenie itd. To ograniczamy do minimum, maksymalnie jak tylko możemy. Minimalizujemy użycie takich technik, a idziemy w kierunku, tak jak wspomniałem, współpracy i automatyzacji. Przy czym to musi współgrać, bo ta automatyzacja nie będzie funkcjonować poprawnie w sytuacji sztywnego procesu.
Lektor. Tradycyjna organizacja hierarchiczna ma wiele ograniczeń jeżeli chodzi o efektywny przepływ pracy pomiędzy różnymi funkcjami organizacyjnymi. Przepływ pracy jest regulowany na poziomie szczebla kierowniczego w postaci umów formalnych lub nieformalnych, między poszczególnymi zespołami. Pracownicy szczebla kierowniczego kontrolują i regulują w ten sposób przepływ informacji oraz pracy między poszczególnymi zespołami realizującymi funkcje wspierające proces rozwoju i utrzymania usługi informatycznej. Taka hermetyzacja nieuchronnie prowadzi do rozproszenia odpowiedzialności i braku koordynacji w realizacji właściwego celu przedsiębiorstwa. Team Topologies jest podejściem do strukturyzacji i ewolucji organizacji w celu efektywnej współpracy, autonomii, skupienia na dostarczaniu wartości oraz zgodności z produktem w kontekście budowy i utrzymania systemów informatycznych. Według tego podejścia zespoły występujące w IT można utworzyć zgodnie z następującym podziałem ich funkcji organizacyjnej.
Zespół zorientowany na przepływ wartości (Stream-Aligned Team). Zespoły zorientowane na przepływ wartości są związane z konkretnym przepływem pracy, zwykle odpowiadającym segmentowi dziedziny biznesowej. Posiadają pełną odpowiedzialność za cały obszar dziedziny biznesowej, stosując zasadę „Ty to zbudowałeś, ty to utrzymujesz”. Zespoły nie przekazują pracy innym zespołom. Są to kompetentne wielofunkcyjne zespoły wykonawcze, odpowiedzialne za dostarczanie wartości bezpośrednio do klientów. Aby usprawnić realizację zadań zespołu zorientowanego na przepływ wartości, zespoły wspierające pomagają zespołom zorientowanym na przepływ pracy w pokonywaniu przeszkód. Identyfikują brakujące zdolności i pomagają je rozwiązać. Pełnią rolę facylitatorów, zapewniając, że zespoły zorientowane na przepływ pracy mogą pracować efektywnie.
Zespoły obsługujące złożone podsystemy zajmują się obszarami, gdzie wymagana jest znaczna wiedza specjalistyczna, na przykład, obliczeniowa lub techniczna. Skupiają się na skomplikowanych komponentach lub podsystemach, które wymagają specjalistycznej wiedzy.
Zespoły platformy dostarczają wewnętrzny produkt, który przyspiesza pracę zespołów zorientowanych na przepływ wartości. Platformy mogą obejmować współdzielone usługi, infrastrukturę, narzędzia lub inne zdolności, które zwiększają ogólną produktywność. W podejściu tym zespoły współdziałają ze sobą w jednym z trzech trybów:
- współpraca to tryb, w którym zespoły pracują razem przez określony czas, aby odkrywać nowe rzeczy, takie jak API, praktyki, technologie itp.;
- x-jako-usługa, w którym jeden zespół dostarcza coś jako usługę, a inny zespół to konsumuje. Przykłady to platformy wewnętrzne, które zapewniają narzędzia, infrastrukturę lub inne zdolności innym zespołom;
- facylitacja to tryb, w którym jeden zespół pomaga i mentoruje inny zespół. Na przykład udziela konsultacji w konkretnej, wąskiej dziedzinie wiedzy. Tryb współpracy można dobierać w zależności od konkretnych potrzeb na danym etapie pracy.
RŻB. Z takich istotnych rzeczy, które warto poruszać przy okazji transformacji, to jest podejście do zarządzania wiedzą w organizacjach. W powiązaniu z zespołami wielofunkcyjnymi i z tym, jak utrzymywać wiedzę, jak organizować przepływ wiedzy w firmie. Często w organizacjach bywa tak, że ta wiedza jest zapisywana. Tworzymy coś, piszemy, zapisujemy to w jakimś systemie, na przykład w stronach wiki, organizacyjnych itd. Natomiast później ta wiedza na tych stronach ginie. Ona tam pływa, jest skoncentrowana, ale nikt jej ani nie potrafi użyć, nie ma obiegu tej wiedzy. Natomiast obieg wiedzy w organizacji jest kluczowy. Żeby to działało, musi dojść do pełnego cyklu wymiany wiedzy.
KG. Tak, to jest ważne. Nie oszukujmy się, jesteśmy ludźmi. Możemy zachorować, może się cokolwiek wydarzyć. Zresztą jeden z czynników, który nieraz się przedstawia na różnych prezentacjach, to jest tzw. Bus Factor. Czyli ile osób musi zostać pozbawionych życia, żeby firma nie była w stanie dalej funkcjonować przez tzw. autobus. Ta retencja wiedzy jest przedstawiana w taki sposób, że dokumentujemy wszystko, wszystko zapisujemy. Jestem przekonany o tym, że nawet jeżeli w takiej sytuacji trafiłby się Bus Factor dosyć wysoki, to nawet zapisana wiedza nie będzie dostępna dla większości. To musi być zamknięty obieg. Jeżeli ja coś napiszę, zacznę to dokumentować, chowam to jak skarb, do widzenia, skończyłem pracę. Nie, ja muszę o tym innych powiadomić, że to jest w tym miejscu, o czym ten dokument mówi. Żeby inny pracownik mógł tę wiedzę wziąć i zobaczyć, co musi wykonać i móc zrealizować zadanie, które zostało mu powierzone na ten czas.
RŻB. Istnieją dwie główne kategorie wiedzy. Tak zwana wiedza ukryta i wiedza jawna, czyli taka, która została uzewnętrzniona, zapisana, sprowadzona do postaci sformalizowanej, technicznej, materialnej. Bardzo ważną rzeczą, kiedy kieruje się jakąś komórką, kiedy trzyma się pieczę nad przepływem wiedzy w organizacji, jest świadomość, że ważna jest ta wiedza ukryta. To też zostało w wielu badaniach wykazane, że dla innowacji, dla kreatywności w organizacji kluczowa jest wiedza ukryta, a nie jawna. Dlatego, że do jawnej wiedzy można sprowadzić mniej więcej 20%, może 30%, może trochę więcej % tego, co się wie. Reszta pozostaje ukryta. Z różnych powodów: niezdolności do tego, żeby przekazać tę wiedzę, nieumiejętności przekazania wiedzy, bo jest to trudne. Świetnym przykładem są wszelkiego rodzaju umiejętności, które wymagają tak zwanych zdolności manualnych albo wiedzy praktycznej, jak to się czasami skrótowo nazywa. Na przykład upieczenie chleba. Nie da się wszystkiego opisać w książce. Trzeba wiedzieć, jak ugniatać to ciasto. To wymaga praktyki, kontaktu z mistrzem, który robi to dobrze. To jest analogia, która dobrze była opisana w książce Nonaki i Takeuchi’ego o przepływach wiedzy. Mamy tam opisany przypadek japońskiej firmy, która, chcąc wprowadzić na rynek maszynę do pieczenia chleba, wysłała swój dział, który miał się zająć tym produktem, do jednego z najlepszych tokijskich piekarzy. Po to, żeby oni się nauczyli, jak faktycznie tworzy się chleb. Żeby mogli skonstruować maszynę, która choć trochę będzie naśladowała to mistrzostwo. Ale oni musieli tego doświadczyć.
KG. Musieli zrozumieć ten proces, zobaczyć, jak to wygląda.
RŻB. Dokładnie. Tego nie dało się opisać, bo mistrz, który zajmuje się pieczeniem chleba na co dzień, nie będzie pisał opasłych tomów. Prawdopodobnie i tak pominie coś istotnego, z czego nawet nie zdaje sobie sprawy. Wiedza ukryta często jest nieuświadomiona. My to wiemy, ale nie wykazalibyśmy tego w dokumentacji, bo wydaje nam się to oczywiste.
KG. Czyli tak naprawdę proponujesz to, żeby nie tyle dokumentować wszystko, co się da, tylko tak naprawdę organizować spotkania wewnątrzdziałowe, które pozwolą przekazać część kompetencji. Nawet nie w kontekście pełnego przejęcia obowiązków, ale przejęcia części kompetencji. Dzięki czemu dana osoba zaczyna rozumieć, co ta druga osoba tak naprawdę robi na konkretnym stanowisku. Wtedy cokolwiek by się wydarzyło, jesteśmy bezpieczni, bo mamy redundancję odpowiedzialności.
RŻB. I tutaj znowu wracamy do pracy w grupie, w zespole. Jeżeli mamy zespół wielofunkcyjny, który obejmuje cały łańcuch albo większość łańcucha dostarczania jakiegoś produktu, rozwiązania, usługi IT, to tam w naturalny sposób przepływa ta wiedza. Nawet ta wiedza ukryta jest wymieniana przez to, że patrzymy, jak pracujemy. Nawzajem uczymy się różnych rzeczy. Czasem sobie pomagamy. Jest wtedy spełniony ten warunek minimalizacji wspomnianego czynnika autobusowego, czyli czegoś, co może spowodować zaburzenie łańcucha dostaw, a nawet jego zatrzymanie. Warto mieć na uwadze to, że te zespoły wielofunkcyjne wspomagają przepływ wiedzy w organizacji.
KG. Dodałbym do tego też kwestię płaskiej struktury, w której nie ma formalności w kontakcie z drugą osobą. W każdej chwili ktoś może podejść do drugiej osoby i zapytać, co ona w tym momencie robi. Zacząć wypytywać o poszczególne elementy, które mogą się nawet przydać w pracy na przykład developera.
Lektor. Model SECI (ang. Socialization, Externalization, Combination, Internalization) został opracowany przez japońskich profesorów Nonakę Hirotakę oraz Takeuchiego Hiroyukiego w 1995 roku. Jest to jedno z najważniejszych narzędzi w dziedzinie zarządzania wiedzą, które ma istotne znaczenie dla organizacji opartych na wiedzy. Model SECI opisuje proces przepływu wiedzy w organizacji, jako spiralę składającą się z czterech etapów:
- socjalizacja: transfer wiedzy ukrytej między pracownikami poprzez rozmowę, obserwację i udział w społecznościach. Tworzy się tzw. wiedzę społeczną;
- eksternalizacja: przekształcanie wiedzy ukrytej w formę jawną, łatwiej udostępnialną i komunikowalną;
- kombinacja: łączenie różnych źródeł wiedzy w nowe artefakty wiedzy, np. dokumenty, bazy danych itd.
- internalizacja: przekształcanie wiedzy jawnie dostępnej w wiedzę ukrytą poprzez osobiste doświadczenia i praktykę.
Tak naprawdę proces ten ma wymiar indywidualny. To znaczy, że dotyczy indywidualnie każdego uczestnika społeczności. Ma własne, właściwe mu tempo i specyfikę. Zadaniem organizacji jest umożliwienie i usprawnienie poszczególnych trybów konwersji wiedzy.
RŻB. Wprowadzenie testerów do zespołu u jednego z naszych klientów wyśmienicie zwiększyło jego efektywność. Spowodowało wzrost korzyści, która była szybciej dostarczana, czyli Time to Value.
KG. Warto tutaj zwrócić uwagę, jak Time to Market bardzo mocno się skrócił, kiedy nie trzeba było czekać na oficjalne komunikaty: „przetestowałem, nie działa”, albo „przetestowałem, działa”. Kiedy zespół mógł dowolnie, trochę nawet poza organizacją, komunikować się między sobą, żeby dowieźć tę wartość, która obchodzi biznes.
RŻB. To prawda. I tutaj zmierzamy w bardzo ważnym kierunku. Mianowicie do podejścia przesunięcia w lewo. Czyli testy, badanie jakości robimy jak najwcześniej w całym cyklu dostarczania, w całym tym łańcuchu wartości, który ma zbudować działającą usługę informatyczną.
Lektor. Model „V” przedstawia cykle kontroli jakości w rozwoju aplikacji informatycznej. Wyróżniamy 4 rodzaje sprawdzeń wykonywanych przez zespoły realizujące projekt:
- testowanie jednostkowe pozwala na wykrycie wad w tzw. jednostkach, czyli małych elementach całej aplikacji. Sprawdzenia tego typu nie potrafią znaleźć wady we współpracy poszczególnych jednostek;
- testowanie integracyjne pozwala odkryć problemy w technicznej współpracy poszczególnych elementów złożonej aplikacji informatycznej;
- testowanie funkcjonalne pozwala na znalezienie wad na poziomie złożonych funkcji, które ma realizować aplikacja. Do tej kategorii zaliczają się np. testy akceptacyjne przeprowadzane na grupie wybranych interesariuszy;
- testowanie operacyjne to kategoria różnych metod testowania, sprawdzających oprogramowanie w docelowym, często bardzo wymagającym środowisku. Do tej kategorii również można zaliczyć testy prowadzone na wybranej grupie odbiorców końcowych (np. wybranych klientach firmy).
Koszt naprawy wady rośnie wraz z oddaleniem od jej źródła, czyli twórczości programistów. Jej wykrycie wymusza cykl naprawczy, który może niweczyć prace zrealizowane w trakcie oczekiwania na wynik testu. Przesunięcie w lewo (ang. shift-left) to koncepcja, która zyskuje na popularności w świecie tworzenia oprogramowania. Umożliwia wczesne testowanie kodu, co pozwala na szybkie wykrycie błędów i problemów. Dzięki temu można unikać kosztownych napraw w późniejszych fazach procesu. Wczesne testowanie pozwala na eliminację błędów jeszcze przed scaleniem zmiany z gałęzią główną. To z kolei prowadzi do wykrywania większej liczby wad, które nie podlegają weryfikacji w etapach późniejszych, czyli w efekcie do większej niezawodności oprogramowania. Przesunięcie w lewo wymaga bliskiej współpracy między developerami a testerami. To sprzyja lepszej komunikacji i zrozumieniu wymagań oraz oczekiwań. Jest więc kluczowym elementem podejścia DevOps, który pozwala na osiągnięcie lepszej jakości oprogramowania, szybszego dostarczania i większej niezawodności.
KG. W całym tym procesie często umyka nam automatyzacja. Jeżeli ktoś wykonuje wszystko ręcznie, to mamy duże straty na powtarzalnych czynnościach. Wracając do samych narzędzi, CI/CD przy transformacji jest już dzisiaj chyba konieczne. Nie można myśleć o zwinności bez automatyzacji, na przykład CI/CD w tym przypadku.
RŻB. Samo wdrożenie CI/CD reguluje pewne rzeczy w firmie. Po pierwsze motywuje do tego, żeby konkretne sprawy przemyśleć i przeorganizować tak, żeby to było bardziej kompatybilne z podejściem automatycznym. Pamiętajmy, że takie bezwiedne, bezmyślne automatyzowanie złych procesów prowadzi do nieefektywnych, automatycznych procesów. Nie daje to żadnej korzyści organizacji.
KG. CI/CD też może być takim enablerem dla organizacji, jeżeli chodzi o dobre praktyki. Jak spojrzymy na nasz proces, który wytwarzamy, to część developerów będzie uruchamiała testy, część ich nie będzie uruchamiała, tylko będzie od razu przechodziła do pisania oprogramowania. A w przypadku takiego CI/CD, nawet jeżeli ja nie napiszę tych testów albo w ogóle nie podejdę do tematu, a zmienię już jakąś linijkę kodu, to inni developerzy wymuszą na tym jednym, nieposłusznym developerze, pewne reguły, które będą panować w danym dziale czy zespole. Wymuszą na nim to, żeby faktycznie zaczął pisać testy, bo jego kod nigdy nie trafi do głównej gałęzi, gdzie jest dostarczany automatycznie.
RŻB. Na pewno to systematyzuje procesy, umożliwia spojrzenie na optymalność tych procesów i w ogóle na poziom jakości współpracy w działach IT. To może być stymulator zmiany organizacyjnej. Wróćmy do punktu wyjścia naszej rozmowy. To wszystko musi być poparte jakąś wizją, odpowiednim otoczeniem organizacyjnym i chęcią zmiany.
KG. Zgadza się. Jeżeli trafimy na zespół, który nie chce tej zmiany, to nie będziemy w stanie tego przeprowadzić w żaden sposób.
Lektor. Wyobraźmy sobie, że budujemy fabrykę informatycznych aplikacji dla naszego klienta. Naszą linią produkcyjną będzie właśnie ciągła integracja i wdrażanie. W języku angielskim nazywane Continuous Integration and Continuous Deployment, w skrócie CI/CD. Kod napisany przez programistów jest surowcem, podobnie jak metal czy plastik w fabryce. To, co programiści tworzą, jest podstawowym materiałem, który zostanie przetworzony. Ciągła integracja to proces, w którym kod jest automatycznie kompilowany i testowany. To jak montaż na linii produkcyjnej, gdzie różne komponenty są łączone w całość. Ciągłe wdrażanie to proces, w którym z kodu budowana jest aplikacja, a następnie automatycznie uruchamiana na serwerze produkcyjnym po pomyślnym przejściu testów. To jak kontrola jakości na linii produkcyjnej, gdzie sprawdzane są gotowe produkty przed wysyłką. Gdy kod przechodzi przez CI/CD, jest gotowy do użycia przez użytkowników. To jak produkt z linii produkcyjnej, gotowy do dostarczenia klientowi.
Zastanówmy się, jakie kluczowe korzyści niesie ze sobą podejście CI/CD:
- szybsze wdrażanie: dzięki CI/CD skracamy czas między napisaniem kodu a dostarczeniem go użytkownikom i klientom;
- lepsza jakość aplikacji: automatyczne testy sprawdzają, czy nasza aplikacja działa poprawnie, co zwiększa pewność, że nie wprowadzimy błędów;
- skuteczniejsza praca zespołowa: CI/CD zachęca do częstego wdrażania zmian, co sprzyja lepszej komunikacji i współpracy w zespole.
RŻB. Wprowadzenie automatyzacji oczywiście przyspiesza procesy. Ale to jak jazda superszybkim samochodem bez odpowiednich narzędzi monitorowania tej jazdy, systemów kontroli trakcji itd. Zaczyna się robić niebezpiecznie. I tutaj ważne jest to, że oprócz wdrożenia narzędzi, które przyspieszają, automatyzują pewne obszary, niezwykle ważny jest właśnie ten monitoring czy obserwacja. Ciągła obserwacja, czyli cały zestaw technik obserwacji poszczególnych komponentów oraz całego procesu. Tutaj mam na myśli nie tylko obserwację narzędzi technicznych, ale również informacji o tym, jak na przykład błędy wpływają na proces. Tu można skorelować informację zwrotną od klienta z tym, jakie zmiany były wprowadzane.
KG. Cały ten proces, to jest pętla zwrotna, którą będziemy obserwować jeszcze z zewnątrz, żeby móc powiedzieć, co robimy poprawnie, a gdzie musimy się poprawić, żeby udoskonalić ten proces, który w firmie jest naturalnie występujący.
RŻB. To jest istota DevOpsu, mianowicie ciągłe doskonalenie. Często podejście DevOps przedstawia się jako pętla Möbiusa, gdzie mamy przepływ, cyrkulację między rozwojem, kontrolą jakości, wdrażaniem i znowu kontrolą jakości na produkcji w sytuacji realnego wykorzystania oprogramowania. Do tego potrzebne są odpowiednie narzędzia.
KG. Narzędzia są jednym z głównych elementów. Należy je dobrze dobrać i móc je odpowiednio wykorzystać. Jednak potrzebne są też pewne umiejętności samego zespołu. Jeżeli mówimy o obserwacji, musimy też umieć przyznać się do błędu. Często w organizacjach jest tak, że jeżeli pojawia się błąd, to musi znaleźć się winny. A w tym przypadku nie powinno się na to patrzeć w taki sposób. Wręcz przeciwnie, mamy kolejną szansę udoskonalić nasz proces.
RŻB. Trzeba patrzeć na błędy jak na szansę poprawy. Czyli jednak konkluzja jest taka, że chyba najważniejsza w tym wszystkim jest jednak organizacja. Sposób działania ludzi, którzy są zaangażowani w tworzenie usług informatycznych, a nie same narzędzia.
KG. Wszystko musi wyjść tak naprawdę od ludzi i otoczenia organizacyjnego, a narzędzia to są elementy wspomagające czy też odblokowujące niektóre inicjatywy, które można by wokół tego wytworzyć.
RŻB. Czyli tak jak w fabryce, dobrej, nowoczesnej fabryce, wokół tych wspaniałych maszyn nowoczesnych, zautomatyzowanych musi być człowiek, który je albo zaprogramuje, albo pomoże im funkcjonować, czy będzie się nimi zajmował. I ten człowiek musi działać odpowiednio, komunikować się, żeby tak naprawdę wykorzystać w sposób najbardziej wartościowy tę całą maszynerię, którą ma do dyspozycji. Najlepsza fabryka bez obsługi technicznej na odpowiednim poziomie i bez kultury pracy nic nie daje. Wszelkie zmiany należy więc przemyśleć od strony organizacyjnej. Same narzędzia niewiele wniosą.
Źródła:
- Accelerate: Building Strategic Agility for a Faster-Moving World – John P. Kotter
- A Sense of Urgency – John P. Kotter
- Industrial DevOps: Build Better Systems Faster Kindle Edition – Dr. Suzette Johnson, Robin Yeman, Dean Leffingwell, Mik Kersten
- Leading Change – John P. Kotter
- Start-up Factory: Haier’s RenDanHeYi model and the end of management as we know it – Joost Minnaar, Pim de Morree, Bram van der Lecq
- Technology and Knowledge Flow, The Power of Networks – Guglielmo Trentin
- The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation – Ikujiro Nonaka, Hirotaka Takeuchi
