Jednym z najtrudniejszych zadań, jakie mogą Cię spotkać, jest określenie wizji dla Twojego projektu. Najczęściej, jako specjaliści, chcielibyśmy zaorać to co istnieje i zbudować aplikację od nowa bo, jak to się mówi – „Kto to panu tak s$%#%doilł?” Problem w tym, że kilkumiesięczny projekt pt. „refactoring legacy” nie ma prawa się udać.
Czasem odrzucamy od siebie temat wizji systemu, bo przecież to jest rola CTO, by taką wizję określić i nam dostarczyć, prawda? Co jeśli w Twojej firmie nie ma takiego człowieka lub jego wizja Ci się nie podoba i uważasz, że coś można zrobić lepiej?
Ani jedno, ani drugie podejście nigdzie Cię nie zaprowadzą! W dzisiejszym odcinku zobaczysz, jak Paweł podjął rękawicę, by stworzyć wizję techniczną dla systemu legacy, z którym pracuje na co dzień. Ta wizja określa kierunek, dzięki czemu każda decyzja, w nawet najmniejszym zadaniu, może przybliżać Was do upragnionego ideału.
Z tego odcinka dowiesz się:
- Dlaczego duży refactoring nie działa i co zrobić w zamian?
- Jak stworzyć wizję dla systemu legacy?
- Jaki horyzont czasowy przyjąć?
- Kogo i jak zaangażować do pracy nad wyznaczeniem kierunku rozwoju aplikacji?
- Jak dojść do kompromisu?
- Jak skutecznie sprzedawać wizję techniczną innym?
- Co zrobić jeśli wizja jest sprzeczna z tym co muszę aktualnie zrobić?
i wiele więcej 🙂
Agenda
00:00 – Intro
00:58 – Wprowadzenie
01:55 – Po co Ci strategia technologiczna?
03:25 – Jak Ty możesz zacząć tworzyć strategię IT?
04:36 – Wizja projektu zamiast tworzenia projektu od nowa
05:59 – Roadmapa to nie wszystko
08:27 – Wizja zespołu zawsze będzie lepsza niż Twoja
09:45 – W jaki sposób przekonać szefa do wsparcia tworzenia strategii technicznej?
10:48 – Zbierz pomysły, problemy i oczekiwania
12:34 – 3 elementy strategii technologicznej
14:12 – Jak pogodzić interesy różnych interesariuszy?
16:37 – Jak może wyglądać struktura wizji waszego projektu?
19:06 – Jak rozwiązywać konflikty w trakcie tworzenia wizji technicznej?
20:55 – Jak zadbać by wizja projektu dotarła do wszystkich?
25:07 – Czy wizja po ponad roku dalej działa?
26:49 – Twój pierwszy krok, jaki możesz wykonać w kierunku strategii
Wersja do słuchania
Linki
- Książka: Filozofia Kaizen. Małymi krokami ku doskonałości – Robert Maurer
- Książka: Software Engineering at Google
- Aplikacjia Miro – wirtualny whiteboard do równoległej pracy z innymi
- Canva – narzędzie do tworzenia infografik itp.
- Odcinek 9 – Między młotem a kowadłem, czyli jak dogadać biznes z IT
Transkrypcja odcinka
[00:00:59.000] – Paweł
Cześć, witajcie w Nerd Management z tej strony Paweł Rekowski…
[00:01:02.150] – Krzysztof
…i Krzysztof Rakowski.
[00:01:03.530] – Paweł
Witamy Was w trzecim sezonie. To już trzeci sezon. Ponad 80 odcinków nagraliśmy. Mamy nadzieję, że tak jak u nas – u was również wakacje minęły super. Odpoczęliście, nabraliście sił, ponieważ w tym sezonie mamy bardzo dużo wywiadów, wszelkiego typu materiałów własnych, dużo dodatkowych rzeczy i też może kilka rzeczy jeszcze się pojawi, które zostawimy sobie na przyszłość.
[00:01:26.970] – Paweł
A dzisiaj chcielibyśmy porozmawiać. O czym?
[00:01:30.260] – Krzysztof
Dzisiaj porozmawiamy o konkretnym temacie, o tym, jak Paweł w swoim zespole podszedł do pewnego istotnego problemu związanego z tworzeniem strategii technologicznej w zespole. To bazuje na problemach, które Paweł miał i w jaki sposób doszedł do ich rozwiązania. Bardzo ciekawy odcinek, fajny początek trzeciego sezonu.
[00:01:53.450] – Krzysztof
Paweł, zacznijmy od tego, jaki w ogóle problem chciałeś rozwiązać?
[00:01:57.440] – Paweł
Problem był taki, że my mamy aplikację, na której pracuje około 16 zespołów. To jest 150-160 osób. I teraz jest problem tego typu, że te zespoły mają różne obszary tej aplikacji. To jest stara aplikacja legacy, jest wielka, jak to w większości bywa, w każdej organizacji jest tak, że taki czy inny duży kawał systemu jednak się ma. Bo to wynika z tego, że historycznie tak się robiło, tak to działało i to nadal przynosi to prawdopodobnie bardzo dużo pieniędzy.
[00:02:29.120] – Paweł
Dlatego my mieliśmy ten problem, że każdy z zespołów robił w niezależnej strukturze. Czyli mamy tę jedną aplikację, ale każdy miał jakiś swój pomysł na to. Jeden chciał iść w lewo, drugi zespół chciał iść prawo. Jeden zespół o jakość dbał, drugi jakość miał gdzieś, bo musiał szybko coś naprawić.
[00:02:49.160] – Paweł
I stąd wyszła właśnie taka potrzeba, że my mamy tę aplikację, musimy z nią żyć, bo to jest core całego właściwie naszego systemu. No i przydałaby się jakaś taka wizja, gdzie my idziemy, żebyśmy szli w jednym kierunku jako firma, jako aplikacja. I tu było konieczne zdefiniowanie tego, gdzie my chcemy być, gdzie my chcemy iść. Bo zobacz, że jest taka rzecz, że kiedy są projekty, gdzie coś nie idzie i chce się podejść do tego projektowo… Czyli na zasadzie: zróbmy projekt – refaktoring. To widziałeś kiedyś taki, który się udał? Bo ja nie.
[00:03:25.500] – Krzysztof
Dobrze, ale jak to było? Przyszedł do ciebie szef i powiedział: słuchaj, Paweł, widzimy wszyscy ten problem i wszyscy się zgadzają, wszystkie zespoły to widzą. Musimy się za to zabrać.
[00:03:36.210] – Paweł
No nie. Bo to był problem, który widzieliśmy u mnie w zespole. To był problem, który różne osoby gdzieś podnosiły przy różnych okazjach, ale nie było chętnego, żeby się za to wziąć i to zrobić. I to jest myślę, że jeden z takich pierwszych punktów na dzisiaj, zwłaszcza po wakacjach. Macie dużo siły, macie dużo pomysłów. Zacznijcie działać i weźcie sprawy w swoje ręce.
[00:03:56.730] – Paweł
Bo jeżeli tak jak było u mnie: było kilka osób, które to widziało, że trzeba coś z tym zrobić. Proces zaczynał kuleć, bo my robiliśmy coś w jednym segmencie, a drugi zespół gdzieś musiał zrobić coś na styku naszych obszarów, no i ten kod się kupy nie trzymał. I w tym momencie mamy zespół zdenerwowany, bo to jest nie tak, nie tak my chcemy robić, nie po to my robimy dobrze, żeby tutaj teraz się męczyć z kimś, kto przyjdzie i naklepie coś tam. I wtedy jako liderzy macie przerąbane. Więc to jest w waszym interesie, żeby wziąć się za to i wziąć odpowiedzialność i taki proces przeprowadzić.
[00:04:35.910] – Krzysztof
To co zrobiłeś?
[00:04:36.780] – Paweł
To się robi w taki sposób, że przede wszystkim nie podchodzimy do takiego zadania projektowo w rozumieniu refaktoringu globalnego. Czyli, że dobra, to ustalmy teraz projekt, może napiszmy sobie business case, pod to, przepiszmy całą aplikację. To nie działa. To nie ma w ogóle racji bytu, jeżeli to jest duża aplikacja legacy. Nie ma opcji, żeby to zadziałało. Bo nikt wam za to nie zapłaci.
[00:05:02.160] – Paweł
Więc trzeba zmienić zupełnie podejście. Trzeba podejść nie od tego, że musimy znaleźć projekt, który pozwoli nam zmienić tę aplikację. Tylko trzeba zmienić w ogóle nastawienie. Trzeba zmienić kierunek myślenia wszystkich ludzi, którzy są zaangażowani. Trzeba zbudować wizję tego, gdzie wy chcecie być z tym systemem za pięć lat, za dziesięć lat. A nie tego, że zróbmy projekt „na hurra” I to będzie jeden projekt, w trzy miesiące, kwartał, pół roku, rok. I to może się uda, to się nie uda.
[00:05:33.000] – Paweł
Ale kiedy będziecie patrzeć na to tak, że ustalmy wizję, gdzie my chcemy być. I teraz wszystkie decyzje projektowe, które będą podejmowane w przyszłości, będą miały tę wizję z tyłu głowy. Wtedy macie szansę dużo szybciej dojść do celu, do którego chcecie dojść, ale zupełnie inną drogą.
[00:05:51.100] – Krzysztof
Czyli te zmiany będą się działy w trakcie realizacji kolejnych projektów, bo będziemy mieli jakąś roadmapę, będziemy wiedzieli, gdzie chcemy dojść.
[00:05:59.250] – Paweł
Nawet coś ważniejszego niż roadmapa. Bo zobacz, roadmapa to jest lista projektów, lista zadań. Mamy listę zadań, epiców. Jeżeli na przykład pracujemy w scrumi, pracujemy z jirą, to widzimy, że możemy sobie podzielić dane zadania na etapy, epiki. To będą kolejne etapy i to nam się rozkłada na rok. I to jest roadmapa.
[00:06:18.870] – Paweł
A my chcemy, aby ludzie mieli z tyłu głowy kierunek, nie roadmapę, nie konkretne zadania, nie ilość konkretnych zadań, ale coś, co będzie składać się na absolutnie każde zadanie. I ta wizja jest takim fundamentem do każdej decyzji, nawet najmniejszej. Mam projekt do zrobienia, nawet jest mały, mam dodać jakiś jeden przycisk, albo jeden tekst, albo coś małego. Najmniejsza zmiana. I teraz ty będziesz miał tę wizję z tyłu głowy i będziesz miał X rozwiązań na każdą najmniejszą rzecz. Każdy task, który ci wpada do backlogu, będziesz miał X rozwiązań. I teraz, mając tę wizję z tyłu głowy, będziesz mógł wybrać: to rozwiązanie jest fajne i szybkie, ale mnie od tej wizji oddala. A to rozwiązanie jest też fajne i szybkie i mnie do tej wizji przybliża. A jest jeszcze jakieś trzecie, które w ogóle jest super szybkie, ale w ogóle rozwala cały system.
[00:07:16.450] – Paweł
I teraz to jest kwestia podjęcia takiej świadomej decyzji przez deweloperów, właściwie cały zespół, łącznie z product ownerem, z tobą jako liderem czy managerem do tego, czy idziemy w tą stronę, czy nie. Bo czasem pójście w drugą stronę od tej wizji też jest OK. Ale wtedy wiemy, że idziemy tam po coś. Idziemy po to, że na przykład jest jakiś problem, pożar. Albo jest jakaś okazja biznesowa, która jest bardzo szybka, na przykład real time marketing. Albo coś wybuchło i trzeba na szybko coś wrzucić. I nie możesz się zastanawiać, czy to zrobić pięknie, czy nie, bo to jest tu i teraz, albo zrobisz to tu i teraz, byle by było, albo ta szansa przeleci.
[00:07:57.460] – Paweł
Kiedy podchodzi się do tego świadomie i ma się tę wizję z tyłu głowy, to można podejść tak: tutaj podejmuję świadomą decyzję, że idę w drugą stronę, bo to mi daje X benefitów. A później z drugiej strony masz kolejne rzeczy, na które nie masz takiego parcia, nie masz ciśnienia, nie musisz tego zrobić już teraz, natychmiast. I wtedy możesz wybrać tę drogę, która będzie OK i będzie wspierać tą wizję tak, żeby małymi kroczkami, krok po kroku dojść do tego, gdzie chcesz być za te 5-10 lat.
[00:08:28.470] – Krzysztof
Jak do tego podszedłeś: miałeś tę wizję i wziąłeś papier, kredki, spisałeś ją i podzieliłeś się nią z zespołem?
[00:08:35.510] – Paweł
Nie, to nie działa w ten sposób.
[00:08:37.560] – Krzysztof
Wiem, dlatego cię pytam, jak to zrobiłeś?
[00:08:39.410] – Paweł
To nie działa w ten sposób bo to nie może być wasza wizja. Nawet jeżeli jest, to nie może być wasza wizja. Dlaczego? Dlatego, że siłą rzeczy pracują przy danym projekcie ludzie. I to ludzie muszą czuć tę wizję. To musi być ich wizja, a najlepiej wasza wspólna.
[00:08:56.120] – Paweł
Więc przede wszystkim trzeba zacząć od tego, żeby znaleźć sobie dobre umocowanie w organizacji. Jeżeli ludzie wiedzą, że jest taki problem, że zespół A idzie tu, zespół B idzie tu, to prawdopodobnie twój szef będzie chciał ci bardzo pomóc. Jeżeli ty przyjdziesz do niego z tym pomysłem, słuchaj: zróbmy z tym porządek raz na zawsze. Nie chcę projektu, nie refaktoringu. Chcę po prostu, żeby ludzie wiedzieli, gdzie idziemy. Bo mamy X zespołów, mamy aplikację i chcemy coś z nią zrobić, ale rozsądnie, a nie na pałę.
[00:09:28.280] – Paweł
Więc jeżeli masz umocowanie u szefa, a najlepiej u szefa swojego szefa, jeżeli to jest duża aplikacja, tak jak ja na przykład miałem tutaj umocowanie u dyrektora, managerów IT, teamliderów, i również ludzi. Wszyscy wiedzieli, że to trzeba, to trzeba zrobić, to trzeba spisać.
[00:09:45.050] – Krzysztof
W jaki sposób ich przekonałeś? Jak to sprzedałeś?
[00:09:47.910] – Paweł
Ja sprzedawałem to na zasadzie podejścia: refaktor a tak zwany kaizen, czyli takie małe kroki w strategii długofalowej. Świetna książka – „Kaizen” – polecam. I oni stwierdzili, że tak, że to jest dobre, że to jest dobry pomysł, spotkajmy się, pogadajmy. I jak takie spotkania wyglądały? Ja zaprosiłem wszystkich ludzi, którzy są zainteresowani, zaangażowani, czyli od dyrektora, przez IT managerów, team liderów, architektów, developerów i testerów. Dla chętnych, to było dla chętnych. To nie było na zasadzie zwołania całego działu, bo takie spotkanie byłoby po pierwsze nieefektywne, a po drugie trwałoby długo i nie miałoby za dużo sensu. Ale z drugiej strony zaraz zobaczycie, jak to można zrobić sprytnie.
[00:10:34.300] – Paweł
Czyli zebrałem najpierw chętnych: kto chce się zaangażować? No bo wiadomo, jedni będą robić swoje i czuć się z tym OK albo robić swoje i marudzić. Ale jak mają coś zrobić więcej, to już niekoniecznie. Tych tam nie chcecie. Z tymi wszystkimi ludźmi zrobiłem tablicę na Miro, spotkaliśmy się zdalnie, więc tutaj nasze doświadczenia z pracy, z zdalnej, hybrydowej, takimi narzędziami jak Miro, ułatwiają życie. Mamy tablicę zdalną, wszyscy mogą skorzystać w swoim czasie.
[00:11:07.600] – Paweł
I zrobiłem to w taki sposób, że zrobiłem listę, takie trzy placeholdery. Na rzeczy: jaka jest nasza wizja? Czyli gdzie my chcemy być z tą aplikacją za 10 lat i te 10 lat? No to kurcze, przesadzone. To ile średnio w branży ludzie pracują? Rok, dwa max. A tutaj my chcemy aplikację na 10 lat i teraz może się to wydawać głupie, ale z perspektywy czasu i tak tam dojdziecie. I tak tam – jeżeli ta firma jest dobra, ma solidne fundamenty, to za te 10 lat będziecie funkcjonować, i za 20, i za 50 tak samo.
[00:11:42.160] – Paweł
Więc dobrze mieć ten horyzont daleki po to, żeby też nie ustawiać swojego myślenia na projekt. Czyli to ja chcę wiedzieć, jak to wygląda za 3 miesiące, bo w trzy miesiące nic nie zrobicie, zwłaszcza z taką dużą aplikacją legacy.
[00:11:57.250] – Krzysztof
To jest to, o czym mówiliśmy przy okazji książki Software Development at Google, że to wyróżnia software engineering od programowania. Czyli tutaj nie myślimy na etapie programowania: naklepię jakiś skrypcik, który coś zrobi, tylko myślimy w kontekście inżynierii oprogramowania, budowania czegoś, co zakładamy, że nasza firma będzie istniała jeszcze dekady. W związku z tym oprogramowanie też musi istnieć dekady, nawet jeżeli będzie ewoluować, nawet jeżeli się będzie zmieniać, to jakieś oprogramowanie tam będzie i jesteśmy na etapie inżynierii tego rozwiązania za te dziesięć lat.
[00:12:33.370] – Paweł
Dokładnie tak. I teraz są takie trzy rzeczy. Czyli z jednej strony to jest wizja. Czyli co my chcemy, takie fundamentalne rzeczy, które jak wejdziemy do wehikułu czasu, przeniesiemy się te 10 lat do przodu, to co będzie takim fundamentem? Chcecie system, który będzie rozproszony, to będzie jakieś DAO, czy to będą mikro serwisy? Cokolwiek? Napiszcie to. To jest dokładnie to, co czujecie, że tam to powinno być.
[00:12:59.830] – Paweł
Druga rzecz to są problemy, czyli jakie problemy aktualnie mamy, jakie problemy chcemy rozwiązać. To jest bardzo ważne, ponieważ patrząc na te problemy, które mamy, nie wpadamy w taką bańkę nieskończoności. To jest pomysł taki, wiesz, greenfield totalny, bo tak się nie uda. Mamy te problemy, które mamy. Mamy ekosystem, który mamy, środowisko, które mamy, biznes, jaki mamy i w tym będziemy się poruszać. Więc chcemy mieć te problemy, chcemy je widzieć, żeby można było się do nich odnieść i sprawdzić, czy nasza wizja do tych problemów jakkolwiek pasuje. Czyli może się okazać, że w sumie problemy, które mamy, one są jakby na tyle… nie chcę powiedzieć specyficzne, bo wszystkie problemy są specyficzne, ale są, powiedzmy na tyle proste, że takie grube kosmiczne rozwiązania wcale nie są najlepsze do tego. I to też jest dobrze, żeby sobie uświadomić.
[00:13:55.780] – Paweł
Czyli mamy wizję, mamy problemy i mamy pomysły, miejsce na pomysły wszelkiego rodzaju, jakieś takie rzeczy, które fajnie by było widzieć, żeby mieć przestrzeń dla ludzi, żeby kreatywnie się mogli wyżyć.
[00:14:13.120] – Paweł
Powiedziałeś, że zaprosiłeś na spotkanie dyrektorów, biznes, developerów to ich pomysły i problemy były zupełnie z innych bajek. W jaki sposób to pogodziłeś? Czy godziłeś to, czy odstawiałeś to na jakieś podgrupy?
[00:14:26.710] – Paweł
Tych problemów było dużo i z wielu segmentów. I podobnie jak przy Event Stormingu, podlinkujemy do odcinka, zastosowałem bardzo podobną metodę. Czyli na początku zebrałem wszystkie pomysły, czyli każdy wrzucił na to Miro, co ma. I zaczęliśmy rozmawiać, żeby ruszyć tę dyskusję. Ruszyć temat, gdzie my chcemy zobaczyć jakikolwiek, jaki kontekst mamy. Zobaczyć też, co ewidentnie odrzucamy. Zobaczyć, że my nie chcemy iść w środowisko mikroserwisowe, bo to się wiąże z takimi konsekwencjami, które są nam do niczego niepotrzebne. I to była bardzo ważna decyzja. Więc takie rzeczy można sobie wyciągnąć na takim spotkaniu.
[00:15:10.810] – Paweł
I co ważne, takie spotkanie zrobiliśmy jedno na początku po to, żeby wytłumaczyć: jak my będziemy pracować, że mamy to Miro, musimy to ustalić, zlokalizować te problemy, nakreślić tę wizję. I później przeszliśmy w tryb asynchroniczny, czyli na tym Miro dorzucaliśmy rzeczy. Był czas na to, żeby przemyśleć, czy to już jest OK i czy to nie jest OK.
[00:15:33.610] – Paweł
Poczym wróciliśmy do spotkań, po dwóch czy trzech tygodniach, na które zaprosiliśmy też ludzi, którzy pracują z tą aplikacją, którzy wcześniej nie chcieli wziąć udziału w tym pierwszym spotkaniu. Później im pokazaliśmy: to wygląda tak, zrobiliśmy takie spotkanie i to jest ważne, bo oni też mogą mieć coś fajnego do powiedzenia, żeby ich zaangażować. Oni wtedy wrzucali jakieś karteczki. Do tego pojawiało się tego coraz więcej.
[00:15:59.260] – Paweł
No i po jakimś czasie, kiedy już przestały się pojawiać nowe karteczki, wtedy się spotkaliśmy ponownie po to, żeby zacząć przechodzić przez to co my tam mamy? Co tam jest? Żeby zacząć to porządkować. I takich spotkań, na których zaczęliśmy porządkować problemy i szukać rozwiązań, bo do każdego problemu, który mieliśmy wyszczególniony, musieliśmy się odnieść i dorzucić rozwiązanie, które nam będzie budować, część tej wizji. Zrobić taki klocek do tego, żeby to było spójne.
[00:16:29.800] – Paweł
I po takich pięciu spotkaniach udało nam się przelecieć przez te wszystkie rzeczy i to nam zbudowało 11-12 obszarów. Czyli sama wizja została podzielona na takie obszary. Była część główna, czyli główna wizja, taka North Star, gwiazda północna, która świeci tam, wiemy, że tam chcemy iść. I ona miała taką główną część. A poza tym były konkretne rzeczy, które ustaliliśmy, odnoszące się do każdego aspektu aplikacji, czyli do architektury, do infrastruktury, do bazy danych, do tego, co ma być w kodzie, do tego, jakie procesy chcemy mieć, do tego, jak ma wyglądać zarządzanie tą aplikacją. I to są rzeczy takie wysokopoziomowe. Czyli, że na przykład chcemy mieć proste zarządzanie tą aplikacją i być w stanie releasować niezależnie na środowisko produkcyjne, kiedy nam przyjdzie ochota. I do rozwiązania tego jest wiele sposobów, ale my to chcemy mieć. I to jest właśnie taki punkt w tej strategii, dla tej aplikacji, który jest długofalowy.
[00:17:39.700] – Paweł
I teraz podchodząc pod jakikolwiek task, jakąkolwiek pracę, kiedy biznes przyjdzie z jakimkolwiek zadaniem, mamy tę listę tych wszystkich rzeczy i podejmując decyzję, czy robiąc jakąś analizę, czy powinniśmy zrobić tak, czy zrobić inaczej, no to mamy to z tyłu głowy i wiemy, że OK, dobra, my chcemy iść tam. Więc jeżeli mamy podjąć decyzję, podejmiemy taką decyzję, która wspiera ten kierunek.
[00:18:04.630] – Krzysztof
Gdy mieliście… może konflikt to za duże słowo, ale jakieś różnice zdań, jeżeli chodzi o formułowanie tej wizji, w takim tłumie osób, które są zaangażowane, w jaki sposób podejmowaliście tę decyzję?
[00:18:14.740] – Paweł
To wyglądało w taki sposób, że w większości przypadków, to każdy był świadomy tych problemów. Bo to właśnie dobrze wyjść od tych problemów, bo one bolą praktycznie wszystkich, którzy pracują z daną aplikacją. I to często są rzeczy ogólne, że nie da się czegoś rozwijać, albo są konteksty pomieszane, albo to jest za duże, albo już nie da się sensownie wdrażać nowych funkcji, bo jest to powiązane w taki sposób, że budując funkcję A, rozwalimy funkcję B. A do tego oczywiście nie wszystko jest otestowane, więc dział testów w taką wizję też wchodził, jak te testy mają wyglądać. Więc też przez to jak te testy mają wyglądać, no to wiedzieliśmy, co trzeba robić. Więc tych konfliktów było tak naprawdę mało, bo każdy miał jakiś swój cel, żeby usprawnić pracę nad aplikacją.
[00:19:06.040] – Paweł
A już same konflikty, jeżeli się pojawiają, to to jest też bardzo proste, jest to system demokratyczny. Więc mając Miro, możecie wykorzystać głosowanie. Możecie dokleić karteczki innego koloru na zasadzie: mamy temat i głosujemy, czy my to chcemy, czy nie.
[00:19:24.250] – Paweł
A właśnie jedną rzecz przypomniałeś, bo my zrobiliśmy jeszcze jeden taki krok. Kiedy mieliśmy te wszystkie rzeczy zebrane, to zebrało się to gremium zainteresowanych, czyli wszyscy najważniejsi decyzyjni ludzie, którzy mieli chęć, ale również deweloperzy, którzy chcieli coś z tym zrobić i realnie pracują z tą aplikacją. To nie było, że to była wizja szefa IT i tyle. To wtedy nie zadziała, jeżeli zespoły chcą robić coś innego. I przeszliśmy przez te wszystkie punkty i było na zasadzie takiej: jeżeli wszyscy się zgadzaliśmy, to zostawiamy. Jeżeli się nie zgadzaliśmy, gdy mieliśmy ułożone te wszystkie punkty, podzieloną tę wizję, czyli taki ostatnie sprawdzenie, jeżeli były jakiekolwiek wątpliwości, to go usuwaliśmy. Bo chodzi o to, żeby ta wizja była w miarę możliwie dokładna, ale też żeby nie powodowała konfliktów. To nie jest przestrzeń do tego, żeby się teraz kłócić, czy chcecie mieć kontrolery takie czy takie, czy chcecie mieć jakieś szczegóły implementacyjne jakieś konkretne, bo to może was później blokować, a to jest bez sensu, więc lepiej to wyrzucić i mieć tę wizję bardziej ogólną i mieć ten kierunek, że to jest tam, tam chcemy iść, niż żeby mieć wyszczególnione, jak macie iść, jak macie tam dojść, bo to nie o to chodzi.
[00:20:54.730] – Krzysztof
Fajnie, przygotowaliście tę wizję i no teraz trzeba było to sprzedać, zaprezentować. Bo wiadomo, że nie wszyscy byli zaangażowani przez wszystkie etapy, a jednak wszyscy muszą postępować zgodnie z tą wizją, te 16 zespołów, o których wspomniałeś. Jak do tego przystąpiłeś?
[00:21:10.030] – Paweł
Tak, i to jest wyzwanie. To jest największe wyzwanie. Zrobienie wizji to jest nic przy tym, żeby ją dobrze sprzedać, żeby to wszystko miało sens. Więc wykorzystałem praktycznie wszystkie możliwe kanały dotarcia do wszystkich ludzi. I jako wszystkie możliwe mam na myśli tak: prezentację, która jak agregowała całą wizję, czyli 11-12 slajdów na każdy aspekt tej wizji. I poleciało to w formie prezentacji. Tę prezentację razem z kumplem zespołu żeśmy nagrali w formie wideo, pokazując tę prezentację, omawiając ją dla tych, którzy chcieliby sobie posłuchać, o co tam chodzi, żeby zobaczyli dokładnie omówienie tej prezentacji. To jest ważne. Nie można wysłać PDFa czy PowerPointa i stwierdzić, że gotowe. Bo to nie działa. Trzeba wysłać też omówienie w formie wideo.
[00:22:05.410] – Paweł
Z tego można wyciągnąć też audio, jeżeli się da puścić osobnym kanałem, zrobić do tego jakieś infografiki albo poprosić dział, który się zajmuje grafikami, jeżeli taki macie, jeżeli nie, to tutaj też podlinkujemy coś, co się nazywa canva.com, czyli coś, czego zresztą używamy od dawna, nawet w Nerd Management, do robienia grafik. To jest prosta aplikacja online, w której możecie sobie wyklikać takie infografiki, posty, czy wszelkiego typu grafiki używane w internecie. I to jest na tyle sprytne i dobre, że sami jesteście w stanie to zrobić, nawet jak nie macie, podobnie jak ja, żadnego smaku graficznego.
[00:22:42.100] – Paweł
Chodzi o to, żeby to mieć coś, jak to przekazać. Więc grafika wideo, audio, prezentacja, PDF, maile, komunikatory. I wysyłajcie to wszystkim, komu się da. Bo wysyłacie to mailem do wszystkich, wysyłacie to na wszelkiego typu grupy, jeżeli macie jakieś kanały komunikacyjne dla deweloperów czy ludzi w ramach danego projektu, to to jest miejsce, gdzie coś takiego musi się znaleźć. Mało tego, jeżeli robicie podsumowania np. miesięczne, kwartalne, to jest też miejsce, gdzie trzeba o tym przypominać, trzeba o tym przypominać regularnie. My robimy prezentacje kwartalne, gdzie podsumujemy sobie kwartał, sprawdzamy sobie, jak wyglądały KPI, co było dobre, co było złe, co się działo w zespołach i na każdej takiej prezentacji od ponad ponad roku, bo tę wizję zrobiliśmy chyba półtora roku temu. Na każdym evencie, każdym wydarzeniu, każdym spotkaniu, całego działu lub dużej grupy ludzi, gdzie była tylko okazja, trzeba o tym przypominać, że to jest, że to działa, bo też są nowi ludzie, niektórzy zapominają, niektórzy w takiej codziennej, bieżącej pracy zapominają, więc też trzeba im pokazać na co żeśmy się wszyscy zgodzili, dlaczego robisz inaczej?
[00:24:12.520] – Paweł
I tak samo właśnie przy takich sytuacjach, kiedy masz zespół, to też zespół musi być świadomy tego, co tam jest. Pracować w zgodzie z tym. Jeżeli widzisz jakieś pull requesty, które są niezgodne z tym, co założyliście, to dopytywać. Też dobrą rzeczą, to, co też mówiliśmy nie raz odnośnie mentoringu i dzielenia się wiedzą, to najlepsze, co można zrobić, to dzielić się tą waszą wizją z innymi zespołami, zwłaszcza takimi zespołami wewnętrznymi. Wyobraź sobie, do mnie jeden przyszedł człowiek, mówi: tutaj zrobiliście taką wizję super ładną, piękną. A teraz na przykład chcesz coś, co się z tym kłóci. To już robicie sami bat na siebie.
[00:24:52.750] – Paweł
Także możecie zobaczyć, jeżeli dobrze to sprzedacie, jak to fajnie zadziała, że kiedy nawet będzie trzeba zrobić coś odwrotnie, to wtedy ktoś inny wam powie: w tej wizji mieliście inaczej.
[00:25:08.140] – Krzysztof
No właśnie, to przechodzisz do wątku, który mnie interesuje, czyli z perspektywy tego półtora roku: jak to działa? Czy postępujecie zgodnie z tą wizją?
[00:25:17.620] – Paweł
Kierunek jest ustalony, idziemy w tę stronę, bo całym sensem jest wydzielenie obszarów i to się dzieje. To jest projekt na jakieś 5-7 lat, dlatego ważne, żeby ta wizja była długoterminowa i dlatego my też przyjęliśmy tę perspektywę 10 letnią. I to się dzieje. Są zaangażowane w to praktycznie te wszystkie zespoły. Dzięki temu też te konteksty nam się lepiej rozdzielają. Dzięki temu dochodzimy do tego. To nie był cel sam w sobie, ale to była nasza wizja, żebyśmy byli bardziej niezależni, bardziej elastyczni. I to jest konsekwencja, a nie projekt. I to idzie. Trwa to bardzo, bardzo, bardzo powoli. I nie przesadzam, bo to jest coś, co trwa bardzo długo. Dojście do takiego stanu, zwłaszcza jeżeli macie aplikację, która ma 7, 8, 10 lat, to to nie będzie tak od razu. To idzie bardzo pomału. I to jest narzędzie takie bardzo wspierające.
[00:26:21.800] – Paweł
Wiemy, że ta wizja tam jest i czasem się nawet o tym zapomni, bo czasem przyjdzie biznes, trzeba zrobić coś na szybko. Ale się do tego wraca. Przez to też, że mamy podsumowania kwartalne, to w najgorszym wypadku to jest taki wake up call dla wszystkich, przypomnienie, że to jest, to nie umarło, to żyje, działa.
[00:26:46.490] – Krzysztof
Bardzo dużo ciekawych informacji przedstawiałeś, wartościowych. Jeżeli ktoś z naszych słuchaczy by stwierdził, że też chciałby ugryźć ten temat, podejść do tego, jaka jest pierwsza rzecz, za którą trzeba się zabrać? Pierwszy krok, jaki trzeba zrobić?
[00:27:01.090] – Paweł
Myślę, że pierwszy krok to jest to, czego zaczęliśmy, czyli wziąć odpowiedzialność. Musicie podjąć rękawice i to zrobić. I żeby tutaj nie zostawiać wątpliwości – to nie był mój pomysł, żeby coś takiego zrobić. To był pomysł jednego z moich ludzi, że przydałoby się w końcu coś takiego zrobić. Zróbmy takie spotkanie, ustalmy, gdzie my chcemy iść. Tylko problem polegał na tym, że on to powiedział. Ja mówię: super, to zrób. I już nie poszły za tym konkrety. Ja to wziąłem, bo z jednej strony szlag mnie trafił, a z drugiej strony to było coś, co ma sens, bo my żeśmy się rozbijali już o projekty na zasadzie refaktoringu. Robisz projekt, robisz refactor jakiejś dużej aplikacji czy nawet małej aplikacji. On trwa miesiącami i ogólnie nic nie daje, albo kończysz tym, że jest gorzej niż było na początku. A kiedy masz jasny kierunek i wiesz, gdzie chcesz dojść, to ty tam dojdziesz, wcześniej czy później i prawdopodobnie wcześniej niż później.
[00:27:59.920] – Paweł
I zamiast się zastanawiać którędy, to wiesz gdzie idziesz. To jest dużo prostsze, kiedy tę wizję masz, kiedy to idzie. Ale pamiętam byliśmy na takim warsztacie jeszcze przed wakacjami, na IT Manager of Tomorrow u Elizy Stasińskiej, która powiedziała, że w tej branży to nie ma nic trudniejszego i bardziej skomplikowanego, niż zdefiniowanie tej wizji. Więc weźmy pod uwagę, że może to być trudne, ale weźcie tę odpowiedzialność i zróbcie to.
[00:28:31.630] – Krzysztof
A jeżeli będziecie jeszcze jakieś pytania do Pawła w tej sprawie, to piszcie na kontakt@nerd.management. I oczywiście jesteśmy bardzo chętni i bardzo otwarci do tego, żeby odpowiadać na wszelkie pytania. Też możecie komentować pod tymi filmikami, czy to na YouTube, czy Linkedin, na Facebooku. Jesteśmy chętni do kontaktu.
[00:28:51.220] – Paweł
Dajcie łapkę w górę, niech to się niesie. Udostępnijcie je też swoim znajomym, którzy się męczą, albo robią jakiś refactoring, albo próbują przekonać biznes do tego, żeby właśnie jakiś refactoring zrobić, bo to nie tędy droga. Warto najpierw ustalić ten kierunek i później refactoring będzie się dział automatycznie, przy praktycznie każdym, każdym tickecie, zadaniu, każdym mniejszym lub większym projekcie.
[00:29:15.610] – Krzysztof
Dziękujemy, że obejrzeliście i wysłuchaliście pierwszy odcinek trzeciego sezonu Nerd Management. Zapraszamy Was do zapisania się do newslettera, subskrypcji na YouTubie, na Linkedin, na Facebooku. I tym odcinkiem zaczynamy kolejny sezon. Będziemy Wami przez całą jesień, zimę, wiosnę i lato.
[00:29:35.440] – Paweł
Tak jest i widzimy się już w następny wtorek, 8:00.