O tym czemu zasada „nie wolno wdrażać w piątki” jest… chałowa.
Wiele firm w roku 2021 przez co najmniej 59 dni roboczych nie będzie dostarczało nowych funkcji, zmian do swoich klientów. Dlaczego? „Bo w piątki (i przed świętami) nie wdrażamy”.
Jeszcze inne firmy przez kolejne 20 dni lub więcej opóźnią wydanie nowej wersji swojego produktu. Przykładowa platforma e-commerce wstrzymuje wdrożenia co roku:
- przed każdym Black Friday (+ 4 dni),
- Świętami i Sylwestrem w grudniu (+8 dni),
Dla niej oznaczać to będzie łącznie co najmniej 71 dni bez wdrożeń. To łącznie ponad 2 miesiące! Z reguły nie myślimy o tym w ten sposób, nie dodajemy tych dni do siebie. Może być i więcej, w zależności od podejścia i „okazji” – Walentynki…
Sporo. Wg mnie wystarczająco dużo, aby przyjrzeć się procesowi i sprawdzić czy przypadkiem nie warto go zmienić.
Dlaczego wstrzymujemy się z wdrożeniami (w piątki itp.)?
Intencje mamy dobre. Obawiamy się, że nasze nowe funkcje popsują coś w działaniu produktów:
- nie chcemy, aby przestały one działać w okresach wrażliwych (np. Black Friday), bo to straty nie tylko dla nas, ale także dla naszych klientów
- nie chcemy, aby czas naprawy się wydłużył (wg założenia, że w weekend czy święta trudniej znaleźć kogoś kto naprawi dany błąd)
- chcemy uniknąć stresu – awaria w piątek o 15 oznaczać może opóźnienie startu weekendu dla niektórych, naprawianie pod presją itp.
Wszystko to bardzo ważne powody. Natomiast rozwiązanie tych problemów jest… nadal chałowe.
Konsekwencje zamrożeń
Wyobraź sobie, że Twój backlog to 10 nowych funkcji, wydawanych jedna po drugiej. Jeśli opóźnisz o 1 dzień wybrane z nich (np. #2, #4, #7) to ostatnia z nich wjedzie na produkcję opóźniona już o 3 dni.
Jeśli mamy szałowy pomysł na nowy feature, ale dostarczymy go z opóźnieniem, to z opóźnieniem dowiemy się czy rzeczywiście był trafiony. Może konkurencja przed nami wyda podobny?
Takie zamrożenia bywają pokłosiem jakichś wpadek – zespół Alpha chciał dobrze, fajny pomysł na nowy feature, zrobili release w piątek po 12:00 i… podarowali klientom buga. Klienci źli, Biuro Obsługi Klienta obrywa. Co robią menedżerowie? Wprowadzają „zakaz”.
Tworzymy w ten sposób kulturę ograniczania zamiast odpowiedzialności. Pracownicy firmy uczą się stosowania „zakazów, limitów i ograniczeń”, bo to oficjalna praktyka, pochodząca od liderów. Nie wspieramy odwagi i eksperymentów.
Piątki bez wdrożeń to „dodatkowy dzień”, w którym zbieramy do paczki kolejne zmiany. Konsekwencją jest większy rozmiar takiej paczki. Skoro nie możemy wdrożyć, to dokładamy do najbliższego wydania. Większa paczka oznacza większą szansę na niechciany błąd, nie przetestowanie czegoś do końca, większe koszty szukania błędu, cofania zmian itd.

Skoro mogliśmy ominąć piątek, to czy rzeczywiście musimy wdrażać w poniedziałek? Jest pokusa, że rzecz się jeszcze przesunie. W poniedziałek mamy pełno spotkań i pilnych spraw, to może przerzucimy to na wtorek?
Przed dłuższymi zamrożeniami, np. świąteczno-noworoczny okres, będzie wręcz odwrotnie – potrafimy dopychać na szybko ostatnie zmiany. „Bo jutro już nie będzie można wdrożyć, dopiero w styczniu”. Pośpiech nie jest dobrym doradcą, nie pomaga jakości. W efekcie sprzyjamy powstawaniu błędów, których tak chcemy uniknąć.
Co z tym zrobić?
Wierzę w to, że to zespoły najlepiej wiedzą kiedy mogą zmianę wdrożyć, kiedy jest to ryzykowne itd. Liderzy zamiast kontrolowania i zakazów, mogą skupić się na tym, aby pomóc zespołom zbudować warunki do łatwego wdrażania, wycofywania zmian i odpowiedniej atmosfery. Może to oznaczać:
- budowa odpowiednich struktur, które pomagają w zrozumieniu i praktykowaniu CI/CD, dbaniu o jakość (np. wsparcie chapterów, gildii; budowa zespołów prawdziwie interdyscyplinarnych;)
- priorytety dla ról i zespołów wspierających (czasem będą to architekci, DevOpsi itd.), aby zespoły miały poczucie, że trudno coś zepsuć, narzędzia do wykrywania i naprawy tego co popsute. Oczywiście z reguły lepiej, gdy takie funkcje są integralną częścią interdyscyplinarnego zespołu, ale praktyka firm bywa różna, a od każdej reguły są wyjątki 😉 To na inny artykuł 😊
- odpowiednie narzędzia i wyszkolenie (czy każdy umie i może wdrażać, a zmiany łatwo cofnąć?; co ze zrozumieniem i praktyką CI/CD? itd.)
- wsparcie inicjatyw dot. stabilnych środowisk (nieraz słyszę jak zespoły narzekają, że “staging jest do dupy, bo…”, “X się nie chce zbudować” itd.), ale na uporanie się z tym nie ma czasu, pieniędzy, ludzi itd.
- wspieranie tych, którym coś nie wyszło, a nie ich rozliczanie; ot luźny przykład jak tego nie robić – czasem bywa, że liderzy, nawet z dobrymi intencjami (tzw. knowledge sharing), zmuszają do pisania publicznych “Lessons Learned” podczas gdy akurat Ci deweloperzy tego nie czują – przed następnym ruchem dwa razy się zastanowią czy nie lepiej zaczekać, zostawić to komuś innemu, bo potem może się okazać, że jeszcze publicznie będą musieli wyjaśniać co popsuli; tzw. “Lessons Learned” są super, ale pod warunkiem, że Ci co je piszą robią to z własnej woli, rozumieją po co itd.
Tyle o liderach. A zespoły? Dość chętnie kisimy zmiany, gromadzimy je, tworzymy dużą paczkę, bo wydaje się, że tak wygodniej. Podczas, gdy to małe zmiany, często wrzucane na produkcję, dadzą nam większe poczucie bezpieczeństwa.
Nie do przecenienia jest tu rola Product Ownera (PMa itp.) – jeśli pomysły na zmiany są duże, to też deweloperzy będą mieli trudności w zbudowaniu mniejszych paczek wdrożeniowych.
Jeśli dana firma wstrzymuje się przez te 2 miesiące w roku, to ile $ straci (nie otrzyma)? Czy ten koszt możemy porównać z kosztem naprawy błędów po wdrożeniach? Ciężko o taki eksperyment, ale podskórnie czuję, że w niejednej firmie z zakazami restrykcyjna polityka jest nieopłacalna finansowo.
Dodatkowe komentarze na koniec
Jest tu jeszcze sporo miejsca na pisanie o Quality Assurance i kilku innych tematach, które mogłyby pomóc z problemem, ale sądzę że po tylu przeczytanych literach wiesz już o co mi chodzi. Uważam, że zbyt często stosujemy zakazy, zmniejszamy autonomię zespołów. To jest droga na skróty, budowanie kultury ograniczeń. Przecież błędy zdarzają się też od poniedziałku do czwartku.
Nie twierdzę też, że “YOLO” to najlepsze podejście do wytwarzania produktów cyfrowych. Twierdzę natomiast, że to na zespołach powinna spoczywać decyzja i odpowiedzialność (całych zespołach, razem z produktowcami). Liderzy mają bardzo ważną rolę do odegrania w tym scenariuszu – zadbać o środowisko, atmosferę, narzędzia, szkolenia itd.