Transkrypcja
Wprowadzenie i metafora zmiany
Cześć Wojtek.
Cześć Michał.
To już drugi raz się spotkamy na tych naszych rozważaniach. I o ile w zeszłym tygodniu rozmawialiśmy o takich bardzo ogólnych sprawach, jak to mamy w rozpisce naszej tajnej misji zgrabnie opisane: ogólne pitu pitu o designie, to dzisiaj bym proponował rozważyć takie rozważania kulinarno-budowlane o zmianie w projekcie IT.
O zmianie, o zmianie, która może być kulinarno-budowlana, się rozwinie od czegoś. Chodzi o to, że może użyję tabletki na koniec, albo na środek, albo na zewnątrz, bo tam pewnie jakaś metafora z tego nam się urodzi.
I ten aspekt budowlany to już pewnie wnikliwy czytelnik jest w stanie odkryć od razu, że chodzi tutaj o beton, a właściwie jego kruszenie. A ten aspekt kulinarny to to pewnie gdzieś tam nam wyjdzie z naszych rozważań. I tak zaczynamy od tej potrzeby zmiany.
Bo mówiliśmy o niej też poprzednim razem, że zmiana jest potrzebna i właściwie całe nasze zmagania z designem — mniej lub bardziej radosne — z kodem pod spodem i ze wszystkimi innymi rzeczami, które się z tym wiążą, jedno z drugiego wynika, przenikają. Cały czas tutaj walczymy, żeby to wszystko jak najlepiej skomponować, żeby to sobie cudnie działało.
Geneza potrzeby zmiany
Ale skąd to się bierze? To się bierze z potrzeby zmian, naszej, nie. Bo raczej takie akademickie rozważania to się na studiach snuje, że można by napisać jakąś aplikację, która robi coś, bo jest potrzebna na zaliczenie. Ale tak na co dzień mamy jakieś potrzeby biznesowe, o których też sobie poprzednio wspomnieliśmy.
Te potrzeby biznesowe rodzą nam potrzebę zmiany. No i cóż my mamy z tym począć? Musimy jakoś chyba nadążyć za nią i musimy zacząć tę zmianę wprowadzać.
Czyli najpierw tak. Można by powiedzieć, że żeby w ogóle móc mówić o jakiejś zmianie, którą musimy zaimplementować w naszym rozwijanym sofcie, musi zaistnieć ta potrzeba. I ta potrzeba, jak już zaistniała, musi zostać poddana weryfikacji.
Zasadność zmiany
Pierwszy, pierwszy punkt, gdzie możemy zacząć sprawdzać, czy nasza potrzeba w ogóle ma sens, można by nazwać zasadnością tej zmiany.
I co byśmy mogli o tej zasadności powiedzieć? Czy to jest w ogóle potrzebne? Co to jest zewnętrzne? Czy potrzeba potrzebuje zasadności?
Już tłumaczę. To chyba też zależy od tego, skąd ta zmiana nasza wynika. Bo potrzeba zmiany może być zewnętrzna: jakaś zmiana regulacyjna, jakaś zmiana pewnych standardów czy czegoś, co po prostu przychodzi z zewnątrz. Z taką potrzebą zasadności to nie ma co dyskutować. To jest po prostu potrzebne. Dana zmiana jest konieczna do wykonania. Bez niej wszystko zginie.
Czy bez niej nie będziemy zgodnie z jakimiś tam regulacjami, czy z jakimiś narzuconymi zewnętrznymi wymogami. Natomiast zmiany czasami są takie troszkę bardziej wewnętrzne. Sami chcemy coś zmienić, sami chcemy wprowadzić jakiś nowy framework, jakąś nową, może technologię, jakieś nowe podejście, rozwiązać jakieś rzeczy w troszkę inny sposób niż do tej pory robiliśmy. No i teraz pytanie: czy ten nowy sposób faktycznie jest lepszy od tego starego?
No, jak jest nowy, to jest lepszy. Wiadomo, lepsze jest wrogiem dobrego. To to jest trochę przeciwna zasada.
Więc to są takie zmiany, można powiedzieć, troszkę związane z jakimś refaktorem. Słowo nielubiane w kręgach biznesowych, bo oznacza najczęściej…
No tak, ale wiadomo, refaktor to to, z czym delikatnie należy się obchodzić, gdyż często nie niesie ze sobą żadnej wartości dodanej, biznesowej. Więc wiadomo, po co to robić?
Ale tego typu zmiany też są. Też są potrzebne i zwykle sygnalizowane gdzieś tam przez zespół deweloperski, przez poszczególne osoby. I też to są zmiany, które gdzieś tam musimy w systemie wprowadzić i znaleźć na nie czas, znaleźć budżet, znaleźć miejsce, gdzie też mogą być potrzebne. Więc trzeba zastanowić się, czy faktycznie wtedy taka zmiana jest potrzebna.
To też zależy w dużej mierze od pewnie miejsca w systemie, gdzie chcemy tę zmianę wprowadzić. Bo jednak nie każde… Systemy najczęściej składają się z takich kawałków kodu, które są jednak w dużej mierze używane i odpowiadają za główną funkcjonalność tego systemu. Ale obrzeża, czyli pewnie gdzieś tam standardowo dobre 80% kodu, jest raczej rzadko zmieniane, rzadko w ogóle się tam zagląda.
I pytanie, czy gdzieś tam deweloper błądzący po tych obrzeżach i widzący potrzebę, de facto coś strasznego, widzący coś strasznego… Pytanie, czy zmiana w takim miejscu jest zasadna z takiego punktu widzenia zwrotu z inwestycji, że tak pod finansowo powiem.
Czyli takie standardowe pytanie: kiedy to się zwróci? Kiedy to się zwróci?
To jest właśnie dobre pytanie. I o ile deweloperzy, czy ogólnie inżynierowie, może rzadko patrzą na ten aspekt, bo wiadomo, to nie jest ich rola, żeby taką potrzebę uzasadniać biznesowo. No ale czasami czas spojrzeć dość tak obiektywnie, powiedzmy, na ten swój kod i na tę swoją aplikację. I rzeczywiście zastanowić się, czy zmiana w tym miejscu, czy zmiana tych klas, de facto dodanie czegoś tam, czy faktycznie ma swoje uzasadnienie.
Już pominiemy nawet aspekt bezpieczeństwa tej zmiany, czyli to, o czym w tym pierwszym odcinku rozmawialiśmy, czy faktycznie tam są testy, czy ja mogę tę zmianę przeprowadzić tak w ciemno, że tak powiem.
Nie ma testów, to się napisze… Jak nie ma testów, to się napisze okaz.
Ile tych testów potrzebujemy? Tak naprawdę 100%. 100%.
No tak, więc to trzeba jednak dobrze, dobrze się zastanowić, czy ta zmiana jest potrzebna, co ona nam wniesie, gdyż to są argumenty przekonujące innych za tą zmianą. Bo jednak czasami trzeba kogoś przekonać, żeby daną zmianę zrobić, więc… I tym kimś czasami jest też sam…
Sami jesteśmy kimś. Myślę, że sami przekonujemy się, czy ta zmiana rzeczywiście jest potrzebna. Udać się na pustkowie, pomedytować i wrócić z natchnieniem.
Ale tutaj w międzyczasie nam się pojawiło kolejne pytanie, bo pierwsze pytanie: kiedy to się zwróci? Wiadomo, to z punktu biznesowego. Ale drugie pytanie: na co to komu? Też jest dość zasadne i do tej naszej zasadności zmiany ono się tu może wpisać, bo nam się może wydawać, że nam to się bardzo przyda. Taki mamy super framework. No i wszyscy już koledzy dawno i koleżanki w tym frameworku piszą, tylko my nie. To co, my będziemy gorsi? My sobie zrobimy tę zmianę, wprowadzimy framework i przecież to się zwróci w przyszłości.
Ale kiedy to… już nie wiadomo. Nie wiadomo. Zwróci, bo tak naprawdę to się może nie zwróci, ale my pokażemy: jest super, wprowadziliśmy zmiany i jest git.
Nie tylko teraz przychodzi do nas ten właściciel produktu, popularnie zwany Product Owner, i pyta: na co to komu? I gdzie on ma tę wartość biznesową z tego, co właśnie to, o czym powiedziałeś?
Tak, to jest trudne pytanie, bo tu zahaczamy już o skalę zmian. Opowiadam po prostu. De facto, to tak naprawdę nie wymaga czasem jakiejś fizyki argumentacji, jeśli jeśli jest to miejsce, gdzie często zaglądamy, często coś zmieniamy i tak naprawdę możemy nawet w historii Gita bardzo łatwo gdzieś tam listę plików czy listę najbardziej hotspotów wygenerować. I wtedy wiem, że to są miejsca, gdzie jeśli coś zmienimy, to raz będzie niebezpiecznie, ale dwa, może się to zwróci.
Więc ta nasza skala zmiany też tutaj troszkę, troszkę nam wchodzi, wchodzi w paradę. Więc jeśli to jest, mówimy o zmianie jakiegoś frameworka, zmianie jakiegoś podejścia, pewnie się trzeba trochę lepiej przygotować, pewnie wytoczyć jakieś argumenty, powiedzieć, czemu obecne rozwiązanie, w jaki sposób się nie sprawdza. Co nam da to lepsze rozwiązanie? Z tego zrobię sobie listę, gdzieś tam streszczenie dla kierownictwa, czy dla kogokolwiek innego, żeby, żeby, żeby to jakoś fajnie uargumentować.
Tak, to tak, to tak, to bym widział. No bo inaczej, jeśli chcemy zmienić wersję czegokolwiek, albo w ogóle zmienić jakiś kawałek naszego tutaj technologicznego stacka, i naszym argumentem jest: bo tak, albo bo już jest nowa wersja, no to trochę pytanie, na ile to jest zasadne.
Są takie podejścia i są takie zespoły, dla których takim trochę driverem architektonicznym jest jak najszybsza zmiana i ogrywanie stacku, czyli wchodzimy i zmieniamy nowe wersje bibliotek i wersje frameworków po to, żeby wiedzieć, że nasz produkt jest rzeczywiście aktualny. Jest na bieżąco z nowymi, z nowymi technologiami, z nowymi frameworkami. Również jest na bieżąco z jakimiś lukami bezpieczeństwa, gdyż to zwykle oznacza, że mamy już te najnowsze, najnowsze biblioteki. No i dzięki temu wiemy, że możemy powiedzieć, że nasz framework jest… Nasza aplikacja jest jakoś tam nowoczesna.
No bo jakby trochę nie patrzeć, jeśli ten nasz stack zostawimy na dłuższy czas bez zmiany, to będzie tak trochę jak z takim branczem, który gdzieś tam mamy na boczku, żeby później tego brancza naszego przysłowiowego zmarnować z naszym masterem. To może być dużo konfliktów, więc podobnie jest z naszym stackiem. Jeśli go sobie zostawimy na boczku i nie będziemy go edytować z najnowszym stanem stacka, który jest dostępny, no to będzie, będzie, będzie coraz trudniej, jakby wrócić do tych najświeższych wersji wszystkiego.
Czasem to właśnie to, o czym mówisz, czyli taka technika czysto techniczna, bo tutaj dążymy do takiej czysto technicznej teraz zmiany. Nie, bo oczywiście, ale z tych szlachetnych pobudek, bo to oczywiste.
Bo czasem może być tak, że mamy po prostu jakieś narzędzie ustawione na samej górze i pokroju Vera Code. I on w momencie tuż przed releasem zechce nam zrobić jakieś review tego naszego stacka i nagle się okaże, że mamy biblioteki nie w tych wersjach co trzeba, bo właśnie wyszedł jakiś tam. Gdzieś tam się pojawiło zgłoszenie, że to czy tamto cacko, które mamy użyte u nas, już się zdeprecjonowało. No i nagle na czerwono mamy taką ostateczną weryfikację przed sobą, więc tutaj może być w ogóle bez dyskusji całkiem.
I ja przez to przechodziłem. Ja właściwie byłem w pewnym projekcie odpowiedzialny za ten końcowy fragment całkiem niedawno i widziałem, jak to od kuchni wygląda, że już mi wszystko przechodziło. Takie rady testowe na tych urządzeniach to trwają i trwają. Więc mi się tam to sprawdzało, sprawdzało. I już dostałem zielone światło. Wszystko pięknie, to możemy odczuwać. Nagle ktoś wrzucił jakąś jeszcze poprawkę, więc zabawa. Powtórka z rozrywki, można by powiedzieć. I w tej powtórce z rozrywki czerwono, bo dosłownie dzień wcześniej pojawiła się jakaś łata na jakąś bibliotekę ze Spring Security czy coś w ten deseń, już nie pamiętam dokładnie. Więc się okazało, że wersja się nie zgadza i do domu i trzeba było podnieść wersję.
I tutaj to jako ilustracja takich zmian czysto technicznych, ale niezbędnych do wykonania, bo inaczej nic z tym nie zrobimy. To jest chyba dobry przykład. Natomiast taka nasza frywolna działalność, że kurka wyszedł nowy framework, a ja tu jeszcze w starym grzebię, tudzież wersja nowa się pojawiła. Jestem na wersji 2.0, a tam już 3.5 jest. No to można by wreszcie dorównać. Może tak, z takimi wersjami to trochę przesadziłem. Może tu trzeba by było, ale jestem na wersji 2.1.1, a tam się pojawia 2.1.1. A dajmy na to, to już trochę gorzej, że było tam jakiś ultra ciekawy feature, który akurat mi się przyda i zajmie mi refactoring powiedzmy z 2 dni. Ale nie mam wartości biznesowej z tego.
No i jak opowiem moim dzieciom, że właśnie wprowadzam taką zmianę, to one na pewno ich zapytają: a dlaczego? I wtedy powiem: nowa wersja się zmieniła z 1 na 1b. A dlaczego? Jeśli to jest taka… To jest taki dobry sposób, chyba, wydumany, czy faktycznie ta zmiana jest dobra? Nie, tekst jest zdania: a dlaczego? I wtedy może możemy dojść do tej potrzeby.
Tutaj jeszcze o tych zależnościach wspomnieliśmy liczbowych. Jest taka reguła 20/80 i ten… I może się okazać, że akurat właśnie ten nasz kod, który jest najczęściej używany, to właśnie to, co możemy sobie sprawdzić w systemie kontroli wersji, czy w jakimkolwiek innym narzędziu, które takie statystyki nam daje. I że nagle ten jeden kod, właśnie akurat poprawienie tego czy tamtego, faktycznie nam się zwróci i ta potrzeba zmiany jest uzasadniona.
Ale jeszcze tutaj dostrzegam taką jedną pułapkę, bo zależnie od naszej domeny możemy mieć np. kodzik, który się dość rzadko zmienia, ale jest bardzo często używany produkcyjnie. I on się rzadko zmienia, bo jest już na tyle okrzepnięty. Tam domena się powiedzmy, domena nie ewoluuje jakoś tam dramatycznie, więc stosunkowo rzadko jakieś poprawki są tam wrzucane. A jednak na produkcji to po prostu jest serce silnika. Tak więc tutaj trzeba też mieć na uwadze jakieś pewnie konsekwencje wprowadzania tej zmiany, czy na zasadzie: a co, gdyby nam się to jednak sypnęło? Nie to…
Jednak trzeba mieć świadomość, że to może pociągnąć za sobą gdzieś tam uderzenie rykoszetem. Coś, bo problem z operacjami na sercu jest taki, że to jest dość wrażliwy organ, więc tutaj…
To czasami jest właśnie ten problem, że jeśli coś działa, to lepiej tego nie ruszać. W sensie… Tak głosi ludowe porzekadło. Więc czasami jest tak, że nie ruszamy tych elementów. I to jest takie już trochę stare, długo działające serce. No ale faktycznie, jeśli to jest sedno naszego systemu, to też warto zastanowić się, czy gdzieś tam już świat nie poszedł do przodu i ten element też nie wymaga jakiejś modernizacji. I sprawdzania, czy może już jakieś nowsze, nowsze biblioteki, czy inne rzeczy się nie pojawiły i czy nie warto jednak troszkę pójść do przodu.
Tutaj to głównie, jeśli mamy reguły w stylu właśnie wykrywanie jakichś łatek bezpieczeństwa czy czegoś takiego, no to z automatu najczęściej jest to robione, to co wspomniałeś. Argument jest prosty: słuchajcie, jest taka i taka luka. Musimy to podnieść, bo tak. Przecież kiedy rok temu wyszła luka w maju i nagle każdy projekt miał z Jamesem przygodę i wszyscy musieli poprawiać, mimo że większość ludzi nie ma żadnego procesu w związku z podnoszeniem wersji i wykrywaniem luk bezpieczeństwa, to luki są znajdowane regularnie, ale akurat ta zyskała dość dużo rozgłosu i wszyscy bardzo mocno podnosili swój stack, więc jest to jakiś tam element takiego, powiedzmy, zdrowego podchodzenia do swojej aplikacji i dbania o to, żeby jednak było na bieżąco w kontekście takich nawet bezpieczeństwa czy innych elementów z tym związanych.
Strategie wprowadzania zmian
I znowu kluczowego słowa użyłeś, bo to zdrowe podchodzenie. Zdrowe podejście to jest chyba to coś, co powinno tą zmianą sterować i to na każdym poziomie. To zresztą o tym już zrobiliśmy pewnie wzmiankę poprzednim razem, czyli poczynając od tego biznesu, z którego ta zmiana ma się wywodzić głównie. Będzie głównie z pominięciem zmian technicznych, które my tutaj wprowadzamy sami. To jednak przechodzi ten nasz Product Owner i on musi mieć już tę swoją zmianę zweryfikowaną.
Czyli on też nie może sobie wymyślić czegoś jakiegoś totalnie odjechanego, bo akurat tak jest fajnie i akurat w sąsiedniej aplikacji też tak mają. W sąsiedniej konkurencji, mówiąc krótko, tylko trzeba, żeby to jednak miało biznesowy sens i jeżeli ma to przynieść jakiś dobry efekt, no to to się musi obronić też na papierze. Stąd biznes. To co my robimy tutaj w kodzie, czy tam z designem, też się musi obronić od strony tego kodu czy designu. Czyli za każdym razem trzeba, trzeba wiedzieć, że noże to się musi obronić.
No i teraz mamy coś takiego, co się już obroniło. Idziemy z tym wyżej po ten beton. I co? Bo to nowe, to coś zmienia. A kiedy to się zwróci, mówimy, że to się zwróci w przeciągu tam X miesięcy. O, przepraszam. I dalej nic. A co to komu? No bo to jest nam potrzebne, bo tu biznes idzie do przodu. To mamy beton. No bo wtedy musimy chyba znaleźć trochę strategii, jak taki beton skruszyć, skruszyć i jakoś tam delikatnie go chociaż począć, czasem zmiękczyć, czasem zmiękczyć. Polać go wodą.
Wiadomo jest też, że nie możemy na pewno takich zmian… Im większa zmiana, tym tak naprawdę wolniej będzie wprowadzana. No nie da się rewolucji przeprowadzić bardzo szybko, a przynajmniej nie bez ofiar.
Otóż to. Więc wiadomo, że jeśli to będzie jakaś grubsza inicjatywa, to to będzie wymagało trochę czasu, ale jest kilka strategii i pewnych podejść, jak takie zmiany ugryźć lepiej. I tak troszkę, troszkę możemy tutaj opowiedzieć o naszych doświadczeniach z kilkoma podejściami, które mieliśmy i tak naprawdę, przekładając to na taki język metaforyczny, gdybym był klasą postaci w systemie RPG, jaki musiałbym mieć charakter, żeby przeprowadzić daną zmianę?
I np. wyobrażam sobie, że taki praworządny, dobry paladyn, no to pewnie zacząłby od takiej solidnej ewangelizacji na temat danej zmiany. Czyli mamy jakiś pomysł, mamy jakąś ciekawostkę? Oczywiście tu mówimy o takiej grubszej zmianie, bo jeśli chcemy zmienić nazewnictwo metod, czy nazewnictwo klas, to tu pisać nie będziemy. Wszem i wobec, z waszego biurka na całe osiedle mówić, że słuchajcie, dzisiaj zmieniam Nelson. Zmieniam nazwę. Tutaj trzeba oczywiście dobrać środki do skali problemu.
3 typy charakterów w procesie zmiany
Natomiast tutaj mamy na myśli bardziej taką zmianę, troszkę systemową, wciąż pewnie trochę techniczną. Bo też zmiany biznesowe może troszkę innego podejścia wymagają. Ale jeśli, jeśli chcielibyśmy wprowadzić jednak grubszą zmianę techniczną, to najpierw pewnie trzeba przygotować troszkę gruntu pod pod tę zmianę. Gdzieś zasiać ziarno nadchodzącej zmiany, jakąś taką incepcję w głowach kilku osób.
I to nie jest proces szybki, to nie jest też proces wdzięczny, no bo wiadomo, opór ludzki przed zmianą jest już powszechny. I tutaj wiele osób w organizacji taką zmianę może łatwo odrzucić, zwyczajnie bojąc się nowych zmian, bojąc się nowego podejścia, czasami bojąc się utraty jakiś wpływów, czy czy czegoś takiego. No bo też wiadomo, zmiany powodują, że niektórzy tracą jakieś swoje kawałki, ulubione, ulubione, czy swojej wiedzy, czy nad czymś, nad czym pracują, czy coś takiego często. To jest to jest bardzo łatwa do dość trudna do wprowadzenia i łatwo to jest bardzo, bardzo ukrócić.
To Martin Fowler chyba w swoim blogu tak fajnie to określił, że w takich dużych organizacjach jest coś takiego jak takie przeciwciała, które tak jak w organizmie odrzucają wszystkie nowe czynniki, nierozpoznane. To coś nam próbuje zainfekować.
Tak. To są takie same korporacyjne przeciwciała, jak to, jak to Martin Fowler określa. I one też po prostu szukają w naszej organizacji tych zmian i próbują je odrzucić. I te przeciwciała to niekoniecznie muszą być ludzie. To są czasami procesy, które działają w jakiś utarty sposób, które po prostu blokują tę zmianę. To mogą być oczywiście ludzie, albo po prostu jest jakaś tam zasada działania organizacji, która bardzo usztywnia i troszkę blokuje wprowadzanie zmian.
Jeśli mamy takie procesy, to jest jeszcze szansa pewnie, żeby je też zrefaktorować jakoś w ten czy inny sposób. Bo to jest taki scenariusz, kiedy mamy ogólne zrozumienie, że my to musimy zrobić. I tak to zazwyczaj bywa, żeby tutaj jakoś nie mieszać, nie siać defektów, to po prostu raz na jakiś czas może nam się zdarzyć ktoś taki, kto tę zmianę nam zablokuje, ale przeważnie właśnie nam to blokują jakieś takie czynniki, z którymi nikt wcześniej nie miał może czasu, albo okazji, albo w ogóle odwagi, czy czegoś, czegoś tam nie miał, żeby się z nimi zmierzyć. I nagle się okazuje, że my już nie mamy wyjścia i musimy się z tym zmierzyć, więc musimy to po prostu rozłożyć na czynniki pierwsze.
I jeżeli to są właśnie same te procesy, no to jest jeszcze w miarę okej, bo my to sobie zaplanujemy, w mapę wrzucimy i powiedzmy za rok mamy naszą zmianę zrobioną. To, że ona tam jest nam potrzebna za dwa miesiące, jakoś się wytłumaczy, ale po prostu, jeżeli nie ukrywam, że to ciągle nawiązujemy do legacy systemów, ale to wtedy ten nasz dzielny paladyn może sobie działać. Wszyscy mu tam płatki róż pod okute w zbroje stopy sypią, a on sobie kroczy i zmierza do tej bestii. I on jest taki właśnie praworządny, dobry.
Nie. Tylko że teraz jakby tak się przyjrzeć temu, co z… Zresztą nawet jak my mieliśmy w projekcie, to nie zawsze tylko takie jakieś tam skostniałe procedury, czy tam inne procesy bronią nam dostępu do tego czy innego, ale jednak jest gdzieś tam na samej górze ten najwyższy władca. My go umownie nazywamy: „jego miłość”. Niech on będzie na potrzeby tej dyskusji w formie męskiej na razie. I ten nasz „jego miłość” mówi, że nic z tego nie zrobimy, bo nie.
Jesteśmy paladynem praworządnym, dobrym. Paladyn praworządny dobry mówi: tak jest wasza miłość. Nic z tego nie będzie. I cały projekt ma upaść. I co? Co wtedy? Możemy jakoś ten nasz charakter odrobinę podrasować, żeby to jednak się udało?
Oczywiście, że możemy. Mamy też charakter neutralny. Powoli, powoli idziemy. Tak więc tutaj troszkę, troszkę schodzimy z tej praworządności, ale oczywiście wciąż wszystko odbywa się zgodnie z przepisami. Oczywiście tutaj nie mówię o żadnych niecnych praktykach, to to wykluczone. To trzecia postać, więc czasami chcąc pewną zmianę wprowadzić, może nie do końca… Nie chcę powiedzieć, żeby ukrywać, bo to nie o to chodzi, ale pewne rzeczy, pewne szczegóły techniczne może czasami warto pominąć na potrzeby tej czy innej dyskusji, żeby też nie zaburzać pewnego obrazu, który chcemy przekazać. Bo to jest sedno naszej zmiany. Jest pewna zmiana, pewna zmiana procesu i podejścia.
I to techniczne detale, które gdzieś tam przebijają się i są oczywiście ważną częścią tego procesu, mogą niektórym zaburzyć pewne spojrzenie, albo wręcz wzbudzać lęk, zburzyć, wzbudzić lęk. Bo może ten nasz rozmówca, czy to biznesowy, czy może to jest też rozmówca techniczny, ale to często będzie jeden i drugi, czy może jego miłość będzie miał swoich zaufanych współpracowników? Może on ma inne spojrzenie stricte techniczne i słuchając nas, i słysząc, że tutaj mówimy z perspektywy jakiejś innej technologii, czy innego podejścia, nagle bardzo mocno się zamknie na tę zmianę, bo widzi, że my chcemy już wygryźć kawałek jego podwórka.
A to nie o to chodzi, bo my nie chcemy tutaj wygryźć podwórka. My chcemy ogólnie usprawnić pewien proces, ogólnie usprawnić jakiś kawałek oprogramowania. I tu nie chodzi o to, żeby pokazać, że ktoś coś robił źle, bo to nie znaczy, że ktoś coś robił źle, ktoś coś robił tak jak na dany moment.
Czyli tutaj nie stosujemy metafory budowlanej: o panie, kto panu…
To oczywiste. Nie, nie, nie. To jest to, co pan zrobił, pan dobrze na tamten czas, ale teraz już jest. Nie było, więc, więc pewne szczegóły techniczne można by troszkę bardziej oględnie, że tak powiem, wyłuszczyć, a bardziej przedstawić taki szeroki obrazek, żeby, żeby tutaj sedno naszej zmiany i zalety też po tej zmianie bardziej były ewidentne niż same szczegóły implementacji tej zmiany.
I to dobrze opisuje charakter naszej kolejnej postaci, czyli takiego neutralnego zawodnika, który jego głównym celem jest wprowadzenie tej zmiany i on ani nie upiększa, ani nie deprecjonuje niczego. Po prostu mówi jak jest. Mówi o rzeczach najbardziej istotnych i ma nadzieję tym przekonać jego miłość do tego, żeby wyraził wreszcie zgodę. Bo…
No tutaj akurat ten przykład dobrze ilustruje, jak to się działo w naszym projekcie, o którym wspomniałeś, bo tam oczywiście też były jakieś tam procedury, procesy, wszystko było skostniałe. Na swój sposób to był ładnie legacy system, ale głównym czynnikiem, który nas do główkowania zmuszał, był właśnie ten „jego miłość”, którego trzeba było ładnie podejść, czasami też neutralnie. Bo na początku próbowaliśmy z pozycji paladyna, ale żeśmy się odbijali troszkę za bardzo, więc później zastosowaliśmy nieco metodę neutralną.
No i byliśmy zbyt szczerzy. Tak, byliśmy zbyt szczerzy. I tutaj niestety wzniosłe pobudki nie wystarczyły, jak się okazało, bo jego miłość miał bardzo dobrą dokumentację wprowadzającą na ziemię. Za każdym razem nie będziemy tutaj przytaczać, broń Boże, w jakich słowach, jakkolwiek zawsze bardzo kulturalnych, uprzejmych, to oczywiście absolutnie nie ma tutaj… nie wolno wręcz niczego zarzucić jego miłości. No i musieliśmy zastosować ten nasz charakter neutralny, żeby tu i ówdzie coś przemycić.
Ale w końcu dotarliśmy do takich obszarów, gdzie już nawet nasza neutralność nie wystarczała. I co wtedy? No to już chyba pozostaje nam uciec się do dywersji i jako dywersja to oczywiście wchodzi charakter chaotyczny, wyrafinowany, ale wyrafinowany. Dokładnie. To wciąż nie jest zły charakter, bo tu nie chodzi nam o dywersję taką niszczącą, tylko taką dywersję konstruktywną, konstruktywną. O ile dywersja może być konstruktywna, więc tutaj…
Tutaj najczęściej ta dywersja jest taka długofalowa, bo na krótki, na krótki taki okres to też niewiele nam się uda osiągnąć i tylko bardziej, bardziej wprowadzimy chaos, zgodnie z charakterem naszej postaci. Ale taka dywersja długofalowa bardziej polega na gdzieś tam wprowadzaniu tych naszych zmian, które przemycają lub wręcz przemycają tak troszeczkę gdzieś tam, gdzieś tam pokątnie, o ile oczywiście jest taka, taka możliwość i to nie szkodzi całemu systemowi, bo to jednak musimy wziąć pod uwagę, że… No ale to możemy się mylić, oczywiście, ale tu też nasz zawodnik jest wyrafinowany, więc potrafi ocenić, czy dane rozwiązanie przyniesie więcej szkody, czy więcej pożytku. Jednak stosuje chaotyczne metody.
W tym dobrym znaczeniu. A tak naprawdę to nie są chaotyczne metody. Tutaj małe sprostowanie się już należy na tym etapie: tylko metody bardzo uporządkowane. Bo tak jak powiedziałeś, my musimy wprowadzać te zmiany małymi kroczkami, tak żeby się „jego miłość” nie zorientował, że coś się dzieje, ale aż tu nagle osiągniemy to, co było potrzebne. Bo już miałem na końcu języka to, co chcieliśmy. Ale wiadomo, wychodząc z pozycji paladyna, mamy zawsze chcemy tego, co jest potrzebne, więc tutaj to, co chcieliśmy, było potrzebne i tę zmianę rozłożyliśmy na ileś tam składowych. Przez ileś tam czasu wprowadzaliśmy je sobie po cichutku i wtedy oczywiście, kiedy była możliwość na to. No i w końcu wylądowaliśmy w takim miejscu, że już możemy zacząć powoli używać tych naszych narzędzi zbudowanych. Zgromadzonych podczas tych przygotowań.
I ten nasz charakter wyrafinowany, chaotyczny, może nawet z powrotem przejść na poziom neutralnego, żeby później na samym końcu dotrzeć znowu do paladyna i obwieścić w chwale: Oto dokonało się!
No tak, i wtedy ciekawe przyjęcie. Natomiast ten element długofalowo poniekąd chyba do wszystkich trzech podejść pasuje. No bo jakby nie patrzeć, jeśli mówimy o jakiejkolwiek zmianie po raz kolejny, takie grubsze zmiany, to zawsze ten element długoterminowości będzie. No bo jak tak sobie pomyślimy o systemie, nad którym pracujemy, to każdy z nas będzie miał jakiś kawałek, który go mocno bolał i przez wiele pewnie miesięcy czy wiele tygodni gdzieś tam robiło się wkoło tego kawałka.
I tak naprawdę, gdybyśmy każdego z tych dni albo każdego nawet tygodni w tym roku, gdzie pracowaliśmy, budowali jakiś mały element poprawiający coś, tak jak zwykle głosił zasadę skauta: popraw coś na swoim podwoziu. Miałem przytoczyć jedną małą rzecz, jedną małą rzecz, żeby było lepiej niż było, żeby było dokładniej i żeby było lepiej niż było. I o ile wujkowi Bobowi chyba bardziej chodziło o taką ogólną zasadę czyszczącą bez jakiegoś konkretnego kierunku, że tak powiem: usuń jeden argument metody, bo akurat ma osiem, a dokładnie siedem. To my możemy przyjąć jakiś konkretny kierunek i ten nasz kierunek rozdzielić na dużo takich małych kroczków, które powolutku sobie będziemy wprowadzać i niezauważenie nagle wylądujemy tam, gdzie będzie ktoś tam, gdzie było trzeba.
Oczywiście nie to, że chcieliśmy to, to, to, to. Czasami nie doceniamy. Zwykle ludzie przeceniają to, co są w stanie zrobić w krótkim okresie czasu, a bardzo mocno nie doceniają tego, co da się zrobić w ciągu pół roku, w ciągu roku. Więc jeśli faktycznie, jeśli faktycznie nas coś boli w systemie i narzekamy, że po roku czy po dwóch latach nas wciąż to boli, to czemu tego nie zrobiliśmy? Czemu nie poprawiliśmy tak w ciągu tych dwóch lat nic? Przecież nie było, nie było wolno, nie było kiedy, nie było wolne, nie było kiedy jego miłośnik się obrazić. Nie tutaj. Wystarczyło to i owo przemilczeć, dyskretnie tam coś dopisać, gdzieś tam wrzucić jakiegoś eventa. I niech on sobie na razie w kosmos leci. Nieważne.
Eksperymenty i Proof of Concept
Czasem może to być w jakimś fragmencie kodu, który jest pod feature switchem wyłączonym. Z tego przetestowaliśmy dyskretnie gdzieś tam na jakimś środowisku staging, czy coś w ten deseń. Tak żeby mieć pewność, że on jednak ruszy. No i wtedy kilka takich fragmentów spiętych w całość nagle, w tym kluczowym momencie pokazuje nam, że feature działa. Udało się zrobić. A jak już feature działa, dało się zrobić. Jego miłość może powiedzieć tylko: dobra robota.
Dobra robota. Jak już wspomniałem, filozoficzna, wyszedłem z tego zdania i to też się wykazałem.
Tak, to są takie fajne, drobne elementy, które pozwala też mogą ułatwić. Jedną z osi czasu to nam dają pewne bezpieczeństwo tego, że ten nasz kodzik, który gdzieś tam sobie pokątnie zrzucamy możemy, możemy sobie odseparować od właściwego działania.
Innym podejściem na takie grubsze zmiany jest też robienie proof of concept czy eksperymentów. W ogóle nazywanie rzeczy eksperymentem albo proof of concept jest bardzo silnym, takim ułatwieniem do wprowadzania zmian. No bo przecież jeśli robimy eksperyment, to nikt nam nie powie, że… Ej, to nie będzie działać na produkcji. Mnie to nie obchodzi. To jest eksperyment. Nie ma być on, nie ma być na produkcji.
To jest bardzo fajne narzędzie na dywersji. Polska obca dywersja, ale sprawia, że mamy troszkę więcej swobody, mamy troszkę więcej możliwości, żeby tę zmianę wprowadzić. Mało tego, nikt nas nie zgani, jak to nie zadziała.
Dokładnie, to nie musi. Eksperyment nie udał się. Udał się. Robimy następnych.
Dokładnie. Więc to jest to. Jest takie fajne, fajne podejście, które nam wprowadza jakieś pewne zmiany. Oczywiście ktoś może powiedzieć: no dobrze, ale ja mam cały backlog historii i nie mam czasu robić tych eksperymentów, tych proof of concept. Tylko wtedy, wtedy możemy sobie to zrobić niejako na boku. Czasami może nawet po godzinach. I nawet jeśli coś się nie uda, zrobię sobie z tego eksperymentu wpis na blogaska. Zrobić z tego eksperymentu jakiś własny, prywatny projekcik?
Jeśli chcę przetestować podejście, nowy, jakiś nowy framework, albo sprzedać to Microsoftowi, może być dosyć. Dokładnie. To nie jest czas stracony dla nas jako dla autora tego eksperymentu. Tak czy siak, możemy go sobie gdzieś tam… Nie mówiąc już o doświadczeniu, jakie wyciągamy z takiego. Zwłaszcza jeżeli to się nie powiodło, to co nam daje do myślenia? Dlaczego to się nie powiodło? Jak się powiodło? No to daje nam do myślenia, dlaczego się powiodło? Nie powiodło się, bo dobrze to wymyśliliśmy, a jak źle to wymyśliliśmy, no to musimy główkować dalej. Więc to jest dobre paliwo do dalszego, dalszej rozkminy.
I taki jeden, drugi, trzeci eksperyment zapuszczony w końcu da nam coś fajnego, coś, co będziemy nawet mogli obronić. Może to jest w tę stronę? Czyli jak pójdziemy do „jego miłości” z następnym objawieniem i mu wyłuszczymy, to nawet możemy mieć lepszą argumentację i wtedy jego beton od razu się skruszy i powie: Dobrodzieju, nareszcie z tym przychodzisz! I sypnie tam złotem. Wyjdziemy, o prominenci jego glorii i moc,
i możemy już sobie w tej właśnie paladyńskiej formie działać, z pewnym namaszczeniem, bez żadnych łotrzykowskich sztuk. Nasza reputacja już będzie na tym poziomie, że wszyscy będą nam ufać i wtedy już każdy eksperyment będzie klepany z góry.
Tak, tak, tak. A tu, żeby nie było znowu pułapki, bo we wszystkim może tkwić pułapka. Tak samo jak było wcześniej wspomniane w ocenie, tak samo później w jakiejś tam reputacji. Żeby jednak nie było, że mamy kogoś w organizacji, kto ma nieposzlakowaną reputację i wszyscy ufają w to, co on powie, a nikt tego naprawdę nie zweryfikował, bo wtedy tutaj właśnie nasza żyłka chaotycznego cybersamca może się przydać. Żeby jednak kiedy chcemy rzucić wyzwanie takiemu komuś lub czemuś, bo to może być jakaś koncepcja, np. dobrze oparta koncepcja…
I nie wiem, dlaczego to teraz mi nie przychodziło do głowy, ale na pewno coś tam się znalazło. Wszyscy tak robią, wszyscy tak robili, dziadowie i pradziadowie, więc my też tak robimy i koniec, kropka. No i tak ma być dobrze, bo to, co się sprawdziło nam 30 lat temu, od tamtej pory… Pierwszego postawiliśmy w Kabulu i dobrze było, to zaraz i działa do tej pory, działa do tej pory. To po co mamy to zmieniać? Także żeby też nie popaść w taką pułapkę.
Podsumowanie i dalsze kroki
No i dobrnęliśmy do tego kruszenia betonu. Zmieniliśmy już, wprowadziliśmy tę naszą zmianę i możemy przechodzić następne zmiany, bo to oczywiście pewnie na jednej zmianie się nie skończy, jak to zazwyczaj kończy się nocną zmianą. Na nocną zmianę sami, żeby tę zmianę wprowadzić, to trzeba troszkę nocki, oczywiście też nie za dużo, ale też nie za dużo, więc…
Ale udało się. Miejmy nadzieję. Miejmy nadzieję. I pewnie następnym razem też się może udać. No i teraz wypadałoby ten tytuł pewnie wytłumaczyć, bo powiedziałem, że kulinarno-budowlane rozważania, bo tutaj cały czas o betonie. Ale ta atmosfera kulinarna wzięła się od tego, że w poprzednim odcinku mieliśmy wrzucone wszystko, co się nawinie i jak do bigosu weszliśmy bez żadnego bigosu.
Nawet sobie z tym bigosem piwa. No i przeszliśmy do rozważań budowlanych o kruszeniu betonu. Wszystko się spina, przywalił. To wszystko się spina, to wszystko ma jakiś tam sens, więc nawet i ewangelizacyjne. Tutaj trochę było tak, że musiała być jakaś podbudowa do tego paladyna. Tak więc mamy zmianę wprowadzoną i pewnie za jakiś czas porozmawiamy sobie o jakichś rzeczach, które już nie wymagają kruszenia betonu. Przeszliśmy ten etap. Znajdziemy sobie jakiś fajny temat do rozkminy. Na pewno.
To dzięki, Wojtek.
Dzięki, Michał.
Do następnego razu.
Do następnego.
Cześć.
Cześć.