Pamiętasz ten mem z psem siedzącym w płonącym pokoju?W projektach technologicznych to nie jest żart. To bardzo częsty stan. Gunshow Comic Od ponad 12 lat zajmujemy się ratowaniem projektów, które miały „małe problemy”.Dziś prawie połowa naszych przychodów w Pragmatic Coders pochodzi właśnie z takich sytuacji - gdy ktoś orientuje się, że projekt nie tyle ma trudności, co… już się pali. Największy problem? Zazwyczaj wszyscy widzieli sygnały wcześniej.Tylko nikt nie chciał ich nazwać po imieniu. Dlaczego wczesne sygnały są tak ważne? Bo problemy w projekcie działają jak dług procentujący składanie. * Na początku są tanie do naprawy. * Z czasem zaczynają generować kolejne problemy. * W końcu gasisz już nie przyczynę, tylko skutki. * A potem skutki skutków. Im później reagujesz, tym: * trudniej znaleźć prawdziwą przyczynę, * więcej kosztuje naprawa, * więcej energii idzie w gaszenie pożarów zamiast budowanie wartości. 1. Projekt „arbuz” - na zewnątrz zielony, w środku czerwony To jeden z najbardziej niebezpiecznych stanów. Wszystko wygląda dobrze: * taski w Jirze są „done”, * sprinty „zamknięte”, * statusy zielone, * prezentacje ładne, * screenshoty działają. Ale: * nikt nie daje produktu do realnego użycia, * demo jest kontrolowane i prowadzone „utartą ścieżką”, * nie ma możliwości swobodnego kliknięcia, * interesariusze nigdy nie użyli systemu samodzielnie. Widziałem projekt w banku z UK, gdzie przez prawie 2 lata wszystko było „na zielono”.Po zajrzeniu w kod znaleźliśmy setki pustych metod z komentarzem „do zaimplementowania później”. Taski były odhaczane.Produkt nie istniał. To jest właśnie arbuz. 2. Nikt nie potrafi powiedzieć, po co budujemy ten produkt Zadaj w zespole jedno pytanie: „Jaki jest cel tego produktu?” Jeśli: * każda osoba odpowiada inaczej, * odpowiedzi są ogólnikowe, * albo nikt nie potrafi odpowiedzieć, to projekt już zaczyna się palić. Dodatkowe sygnały: * brak roadmapy albo roadmapa jako lista życzeń, * feature factory - ciągle coś dodajemy, * brak mierników sukcesu, * metryki mierzą output, nie outcome. Możesz dowozić sprinty i jednocześnie nie budować żadnej wartości biznesowej. To nie jest postęp. To ruch w miejscu. 3. Delivery zaczyna się rozjeżdżać Popatrz na: * rosnący lead time, * coraz więcej rzeczy „in progress”, * coraz mniej rzeczy realnie kończonych, * duży rework, * ciągłe zmiany priorytetów, * wąskie gardła w postaci jednej kluczowej osoby. Jeśli: * rozpoczynacie dużo, * kończycie mało, * a wszystko trwa coraz dłużej, to system jest przeciążony. Często winne są: * brak jasnych celów sprintu, * brak limitów WIP, * wieloetapowe akceptacje, * jeden ekspert domenowy, który wszystko blokuje. To są sygnały, które widać dużo wcześniej, niż wybuchnie pożar. 4. Dług techniczny zaczyna sterować biznesem Techniczny pożar rzadko zaczyna się spektakularnie. Zaczyna się tak: * mała zmiana psuje coś w innym miejscu, * release to wielkie wydarzenie o 3:00 nad ranem, * testy są „na czerwono, ale i tak jedziemy na produkcję”, * o błędach dowiadujecie się od użytkowników. Jeśli developerzy regularnie mówią: „Tak się już nie da pracować” to warto ich posłuchać. W większości przypadków mają rację. Jeśli tego nie zrobisz, scenariusz bywa jeden z dwóch: * kosztowny refactoring pod presją, * rekomendacja: „wyrzućmy to i napiszmy od nowa”. Dziś, przy AI i przyspieszonym developmentcie, taka rekomendacja pada częściej niż 3–4 lata temu. Ale jeśli kultura i procesy się nie zmienią, nowy system skończy tak samo. 5. Sygnały ludzkie - najbardziej niedoceniane To często najwcześniejsze i najbardziej wyraźne objawy. Zwróć uwagę na: * wysoką rotację, * odchodzenie kluczowych osób, * cynizm i sarkazm w zespole, * postawę „robimy minimum, to i tak nie ma sensu”, * konflikty business vs delivery, * nadgodziny jako norma, * „superbohaterów”, którzy jako jedyni potrafią naprawić produkcję. Superbohater w projekcie to często ukryty symptom choroby systemowej. Jeśli wszystko zależy od jednej osoby, masz poważny problem. Dlaczego te sygnały są ignorowane? Najczęstsze powody: 1. Mierzymy złe rzeczy Skupiamy się na: * budżecie, * terminach, * velocity. Ignorujemy: * jakość, * błędy, * zadowolenie użytkowników, * realny outcome. 2. Kultura „nie przynosimy złych wiadomości” W wielu organizacjach: * nikt nie chce być tym, który mówi „mamy problem”, * używa się słów „wyzwanie” zamiast „pożar”, * problemy zamiata się pod dywan. Z czasem patologia się normalizuje. „U nas tak zawsze było”. To jedno z najbardziej niebezpiecznych zdań w biznesie. Co robić, zanim będzie za późno? * Zacząć mierzyć właściwe rzeczy - outcome, nie tylko output. * Zapewnić realną transparentność. * Stosować procesy zgodnie z zasadami (Scrum, Kanban - naprawdę, nie „po swojemu”). * Słuchać developerów. * Reagować na pierwsze sygnały, nie na kryzys. Bo kiedy projekt już płonie naprawdę, opcje są drogie: * wymiana zespołu, * wymiana liderów, * wymiana technologii, * albo wszystko naraz. Najważniejsze pytanie Nie brzmi: „Czy mamy problemy?” Bo każdy projekt je ma. Brzmi: „Czy reagujemy na pierwsze sygnały, czy czekamy, aż zapłonie sufit?” Jeśli czytając to rozpoznałeś kilka sygnałów u siebie - to dobra wiadomość. Bo najgorsze projekty to te, które płoną… i nikt jeszcze nie czuje dymu. 🎥 Obejrzyj pełny materiał wideo W tym odcinku omawiam wszystkie sygnały bardziej szczegółowo i opisuje konkretne przykłady z projektów, które ratowaliśmy. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit pragmatycznieo.substack.com
