Czy pracowaliście kiedyś z rozpadającą się aplikacją?

Może kojarzycie taką sytuację - pojawił się błąd w aplikacji nad którą pracujecie. Coś się źle wyświetla.

Tydzień badania problemu dało Wam odpowiedź - zmiana wymagała poprawy jednej linijki. Patrzycie na tę aplikację i myślicie sobie, że chyba tak nie powinno to wyglądać.

Mieliście może podobną sytuację?

A dodatkowo, może po naprawieniu tego wyjątkowo irytującego problemu Wasz przełożony powiedział coś w stylu “co tak długo”?

Dla Was to oczywiste - dużą aplikację się trudno rozwija. Coraz trudniej znaleźć to, czego w danym momencie szukacie.

Do tego biznes coraz bardziej naciska na zwiększenie prędkości dostarczania nowych rzeczy a programiści gubią się pod ciężarem istniejącego kodu.

Na potwierdzenie tego, wszystkie liczby mówiące o wydajności zespołu pokazują konsekwentne spowolnienie pracy.

Programiści są nieszczęśliwi. Biznes jest nieszczęśliwy.

Pytanie czy każdy projekt jest skazany na taką mroczną wizję. Czy da się inaczej?

Jak mogłoby być?

Załóżmy, że rok temu ktoś z Was powiedział biznesowi “słuchajcie, praca z tym kodem robi się za trudna; musimy przebudować i oczyścić ten program”. Może nawet ktoś zrobił analizę kosztów i korzyści pod kątem biznesu.

Najpewniej biznes odrzucił taką propozycję. Najpewniej biznesowi się by to opłacało w perspektywie długoterminowej, ale nie widzieli tej korzyści.

A co, gdyby biznes powiedział “dobrze, zróbmy to”?

Co, gdyby biznes faktycznie powiedział “akceptujemy spowolnienie pracy” i zmniejszył presję lub powiedział “dobrze, przebudujmy ten program by działał szybciej”? Nie byłoby lepiej?

Z dobrych wieści - przekonanie biznesu do podjęcia takiej decyzji jest możliwe. Wpierw jednak musimy zrozumieć problem okiem programisty i okiem biznesu.

Skąd bierze się nasz problem?

Dwa główne powody rozpadania się kodu to “za dużo tego wszystkiego” oraz “budujemy katedrę na fundamentach bunkra”.

Za dużo tego wszystkiego

We wczesnych etapach życia aplikacji miała ona około 5 tysięcy linijek kodu rozrzuconych na 100 plików. W późniejszych etapach, najpewniej ma bliżej 100 tysięcy linijek rozrzuconych na kilka projektów, każdy po 1000 plików.

Do tego nasza aplikacja pozbierała różnego rodzaju bibliotek, frameworków i innych takich. Są fragmenty aplikacji których nikt nie rozumie, bo programiści nad nimi pracujący już odeszli z firmy.

To trochę jak ze zdjęciami - jeśli mamy 100 zdjęć na biurku, łatwo znaleźć to, którego szukamy.

Jeśli mamy 100 nieuporządkowanych albumów ze zdjęciami, dokumenty do pracy oraz słoik ogórków kiszonych który leży tam z niewiadomych powodów, to bardzo trudno jest znaleźć poszukiwane zdjęcie. Zajmie to dużo więcej czasu, nie?

Budujemy katedrę na fundamentach bunkra

Czemu powiedziałem o słoiku ogórków kiszonych i nieuporządkowanych albumach? Ano, najpewniej Wasza aplikacja kiedyś robiła coś innego.

Żeby to wzmocnić - nigdy nie pracowałem nad aplikacją, która nie uległa poważnym zmianom na poziomie wizji pomiędzy rozpoczęciem pracy a zakończeniem pracy. Sama zmienność otoczenia biznesowego wymusiła te zmiany.

To trochę takie uczucie jakbyśmy rozpoczęli budowanie bunkra. Gdzieś po drodze ktoś powiedział, że w sumie potrzebny nam tunel do dostarczania zapasów, więc zaczęliśmy pracę nad tunelem.

Gdy byliśmy w 33% gotowi, okazało się, że budujemy katedrę - więc niech ten tunel służy jako piwnica. Nieco długa i dziwna, ale piwnica.

Budujemy więc katedrę na fundamentach bunkra, gdzie dawny tunel służy jako piwnica. Nie jest łatwo się połapać, bo to co jest w kodzie często nie ma sensu i nijak nie przekłada się na język biznesu i to, czego się od nas oczekuje. Ale - przynajmniej działa.

Problem pojawia się, gdy trzeba coś w tych dziwnych obszarach kodu zmienić.

Znacie ten problem, prawda? Większość skutecznych, dużych aplikacji ma podobny problem.

A co jest problemem dla biznesu?

Zacznijmy od tego, że ludzie w biznesie nie są ani głupi ani nieracjonalni. To ciężko pracujący ludzie, nie mniej niż programiści - po prostu pracują na innej materii.

Z perspektywy biznesu kod może nawet nie istnieć - oni potrzebują sprawnej aplikacji, którą da się sprzedać klientom. Ich trapi przede wszystkim niezadowolenie klientów i to, że jeśli nie biegnie się szybko do przodu, to można zostać z tyłu, za konkurencją.

Stąd wieczny nacisk na dodawanie nowych rzeczy, jak najszybciej.

Czasami biznes działa w fazie prototypowania. Nie wie jeszcze, czy budujemy bunkier, katedrę czy kuźnię. Czasami otoczenie biznesowe wymusza na biznesie całkowitą zmianę planów - budowali katedrę, muszą budować kuźnię.

Najprostszy przykład działania sił rynkowych - pierwszy iPhone został wydany w roku 2007. Ten ruch wymusił zmianę działania wszystkich firm zajmujących się produkcją telefonów. Wyobrażacie sobie tamtą skalę zmian w łańcuchach dostaw i liniach produkcyjnych?

Tak więc biznes też nie wie, dokąd zmierzamy. Ale biznes musi to sprzedać, jak najszybciej.

Biznes nie rozumie naszych problemów. Nie ma na to czasu, bo ma własne.

Z tego wynika jeden prosty wniosek - musimy pokazać biznesowi problem w języku biznesu. Pokazać, że to jest problem biznesu, nie tylko programistów.

Kanarek w kopalni

Jeżeli biznesowi zależy na ilości błędów (jak najmniejszej) i prędkości pracy (jak największej), musimy pokazać im rozwiązanie właśnie na tym poziomie.

Na tej podstawie powstała technika “kanarek w kodzie”, która sprawdziła się już kilkukrotnie w różnych formach.

O co chodzi z “kanarkiem”?

Ano, w XVIII i XIX wieku górnicy tyrolscy wykorzystywali to, że kanarki są szczególnie podatne na gazy toksyczne. Zabierali kanarki ze sobą do podziemi i je obserwowali.

Gdy kanarek czuł się gorzej lub tracił przytomność, górnicy się ewakuowali z miejsca zagrożonego wybuchem (źródło na dole artykułu).

“Kanarek w kodzie” jest przeniesieniem tego pomysłu na programowanie i na komunikację z biznesem.

Kanarek w kodzie

Technika jest stosunkowo prosta:

Znajdźcie zadanie referencyjne. Niech to będzie zadanie, którego typ powtarza się stosunkowo często i które zajmuje mniej więcej do godziny pracy “przeciętnego członka zespołu”. To zadanie jest naszym punktem odniesienia.

Ustalcie z biznesem, że spotkacie się by podjąć decyzję co robić dalej gdy zadanie referencyjne przekroczy ustalony czas (np. 5 godzin).

Gdy zadanie referencyjne przekroczy ustalony czas, spotykacie się z biznesem. Wasz kanarek właśnie stracił przytomność. Teraz biznes musi podjąć decyzję:

  • musimy przebudować kod, by zadanie referencyjne spadło np. do 2 godzin i musimy ustalić nowy próg “kanarka” - np. 6 godzin.
  • tymczasowo akceptujemy nowy próg czasu zadania referencyjnego. Pracujemy w pośpiechu; wrócimy do tematu w określonej dacie. Do tej pory monitorujemy “kanarka”, ale nie robimy z nim niczego więcej.
  • na stałe akceptujemy nowy poziom zadania referencyjnego. Nowego kanarka ustawiamy np. na 10 godzin.

Zadziała to szczególnie dobrze, jeśli pokażecie biznesowi wykresy z danymi pokazujące, że zadania tego typu są wykonywane coraz wolniej i że trend jest nieubłagany.

Oczywiście, możecie wykorzystać inną miarę - zamiast czasu wykonywania zadania możecie użyć np. ilości wykrytych na produkcji błędów.

A jeśli biznes się zgodzi na wyleczenie kanarka?

Załóżmy teraz, że biznes się zgodzi na rozwiązanie problemu kanarka. Co dalej?

Skupcie się tylko na przyspieszeniu wydajności pracy programistów.

Waszym zadaniem jest zidentyfikowanie gdzie najwięcej czasu jest marnowane (np. testy odpalają się cztery godziny, nie wolno niczego wrzucić bez odpalenia testów) i rozwiązanie tego problemu.

Bardzo często rozwiązaniem tego problemu będzie refaktoryzacja. Nie mniej często - zmiana czegoś w procesach, wprowadzenie Continuous Integration czy inne takie.

Ważne jest to, że jeśli nie dostarczycie wartości biznesowi, nie będziecie poważnym partnerem do dyskusji. Jeśli coś obiecujecie, musicie obietnicy dotrzymać.

Prowadziłem swego czasu warsztaty z ludźmi z biznesu z różnych firm. Sami mnie pytali, jak można przekonać programistów do usprawnienia kodu celem przyspieszenia pracy. Innymi słowy, biznes często widzi taką potrzebę.

Bardzo często jednak refaktoryzacja na którą biznes się zgadza kończy się tym, że “coś się zmieniło w kodzie” i biznes nie ma z tego korzyści.

To Wy musicie biznesowi udowodnić, że refaktoryzacja przyniosła im wartość. Dlatego tak silnie skupiłem się na mierzalności kanarka i zadaniu referencyjnym.

A jeśli biznes się nie zgodzi? Jeśli kanarek umrze?

Są całkowicie racjonalne powody, czemu biznes może podjąć taką decyzję:

  • biznes jest w trybie prototypowania - ważniejsze jest znalezienie “czegoś” niż “zrobienie tego dobrze”
  • biznes ma ogromną presję by dostarczyć coś przed określonym terminem - np. produkt musi mieć nową wersję przed świętami
  • nowa prędkość jest akceptowalna w porównaniu z kosztami przyspieszenia pracy (np. złamanie ISO czy innych procesów wymaganych prawem)

Ważne jest to, że jeśli biznes zaczyna pytać “czemu tak długo”, Wy macie możliwość wyciągnięcia decyzji podjętej przez biznes.

Prosta linia działania to: “ostrzegaliśmy o takiej sytuacji - czy ważniejsza staje się prędkość pracy czy nadal ważniejsze jest dostarczenie nowych rzeczy?”

To nie jest szantaż. Biznes ma pełne prawo podjąć decyzję o pogorszeniu stanu kodu, ale Wy macie pełne prawo do tego, by chronić się przed decyzjami dla Was niekorzystnymi.

Jeśli dla biznesu prędkość pracy jest ważniejsza, podejmą inną decyzję. Ale wtedy - Wy musicie być dość dobrzy by usprawnić sytuację pod kątem prędkości dostarczania nowych własności. Oni są ekspertami biznesowymi, Wy - technicznymi.

Jeśli coś obiecujecie - musicie tego dotrzymać. I na odwrót.

Bez tego wzajemnego zaufania i ścisłej współpracy by dostarczyć jak najlepszą aplikację to wszystko nie zadziała.

Dlaczego ta technika działa?

Pokonaliśmy hipotezę zero

Wyjdźmy od hipotezy zero, czyli “co się stanie, jeśli nie zrobimy niczego, jeśli nic się nie zmieni”.

Pamiętacie, jak mówiłem o trendach i o monitorowaniu czasu wykonania zadania referencyjnego? Dzięki temu, że to robiliście mamy wyraźny trend - z biegiem czasu coraz wolniej wykonywane jest zadanie referencyjne.

Uzbrojeni w tą wiedzę możecie łatwo pokazać biznesowi, że na przestrzeni czasu mamy praktycznie gwarancję, że to zadanie będzie bardzo powoli realizowane.

Teraz - domyślne działanie zajętych ludzi to jest nie robić niczego, nie podejmować decyzji. Jest to racjonalne działanie - większość problemów sama pojawia się i znika.

Tyle, że pokazując trend na bazie faktycznych pomiarów jednocześnie pokazaliśmy, że hipoteza zero jest dla biznesu skrajnie niekorzystna. Pokonaliśmy hipotezę zero. Nie podjęcie decyzji staje się decyzją - i to decyzją skrajnie niekorzystną.

Zmusiliśmy biznes do działania. Do podjęcia najkorzystniejszej dla siebie decyzji.

Zostawiliśmy decyzję w rękach biznesu

Zwróćcie uwagę - decyzja o poprawieniu stanu kodu i przyspieszeniu pracy programistów w rzeczywistości nie jest decyzją techniczną. Jest to decyzja priorytetów na poziomie biznesu.

Pozostawiając biznesowi kontrolę i jedynie prezentując dane pokazujące wpływ tej decyzji na przyszłość wychodzimy z pozycji inżyniera. Partnera, który pilnuje obszarów technicznych i także patrzy na potrzeby biznesu.

Akceptujemy fakt, że biznes jest decydentem - ale zapewniając wszystkie potrzebne informacje nie wychodzimy z pozycji petenta a partnera.

Czemu to ważne?

Nad petentem ma się władzę. Z partnerem się współpracuje. Petentowi wydaje się polecenia, z partnerem wspólnie rozwiązuje się problem.

A przecież czy nie o to nam chodziło od samego początku?

Podsumujmy to wszystko

Rola biznesu, rola techniczna

Większość problemów zespołów technicznych nie wynika ze złej woli biznesu - i na odwrót. Różne role wymuszają różne punkty widzenia i w ferworze walki często nie zauważamy problemów innych ról, na które wpływamy.

Rozwiązaniem tego jest bliższa współpraca i komunikowanie się w języku biznesu. Problemy zespołu technicznego są pochodnymi problemów biznesowych, dlatego pomagając biznesowi, programiści pomagają też sobie.

Aplikacje będą się rozpadać

Jeżeli prace nad aplikacją się toczą, jednocześnie rośnie złożoność tej aplikacji. Im większa złożoność, tym trudniej się w aplikacji połapać. Dodatkowo, na wymagania działa otoczenie biznesowe - zagrożenia i okazje, na które musi biznes odpowiedzieć.

To powoduje, że większość aplikacji prędzej czy później stanie się trudna do utrzymania. Nawet firmy takie jak Google, Microsoft czy Apple mają tego typu problemy - nie jest to coś, czego można się całkowicie pozbyć.

Kanarek monitoruje stan aplikacji

Możemy jednak ustawić zadanie referencyjne - owego “kanarka” - który pomoże nam określić trendy zgodnie z istotnymi dla nas miarami (ilość błędów lub czas dodania nowej funkcjonalności).

Ważne, by to zadanie referencyjne było mierzone na poziomie rzeczy ważnych dla biznesu. Dzięki temu mamy możliwość spotkania się z biznesem i wspólnie przedyskutowania co robić z tym dalej.

Wspólnie rozwiążemy ten problem skuteczniej

Jako, że hipoteza zero wskazuje na bardzo niekorzystne trendy, trzeba podjąć jakąś decyzję. We współpracy z biznesem osoby techniczne są w stanie pomóc usprawnić istotnych dla biznesu parametrów.

Ani biznes ani osoby techniczne nie są w stanie samodzielnie rozwiązać tego problemu. Jedynie współpracując możemy znaleźć taki czas, który jest najkorzystniejszy z perspektywy biznesowej i takie rozwiązanie, które najbardziej pomoże zespołowi technicznemu.

Źródła