Pragmatycznie o… tym, czy Twój projekt już płonie?

Cześć! W dzisiejszym odcinku porozmawiamy „Pragmatycznie o…” tym, czy Twój projekt być może już płonie, tylko Ty jeszcze tego nie widzisz.

Będzie między innymi o tym, jak rozpoznać pierwsze sygnały tego, że w projekcie dzieje się coś nie tak. Będzie też o tym, co z tym zrobić, oraz porozmawiamy o tym, dlaczego jest to tak istotne i dlaczego warto zwracać uwagę na pewne rzeczy, które być może dzisiaj wydają Ci się nieistotne, ale tak naprawdę mają bardzo duży wpływ na to, czy to, co robisz, to, co robi Twoja firma, to, co robi Twój zespół, w przyszłości będzie problematyczne, albo odniesie duży sukces.

Zapraszam do dzisiejszego odcinka.

Skąd wziął się ten temat?

Na początku tego odcinka chciałbym powiedzieć Wam, skąd w ogóle wziął się ten temat. Prawda jest taka, że od ponad 15 lat osobiście zajmuję się pomaganiem firmom w ratowaniu ich projektów, a czasami nawet całych firm przed tym, żeby te firmy po prostu nie upadły albo żeby te projekty nie stały się całkowitą porażką. Kiedyś byłem konsultantem, robiłem to jako konsultant: doradzałem firmom, szkoliłem ludzi, pomagałem im wyjść z opresji, a od ponad 11 lat razem z całą ekipą Pragmatic Coders, którą wspólnie zbudowaliśmy z kolegami, zajmujemy się wyciąganiem takich projektów z tarapatów. I wydaje mi się, że robimy to całkiem nieźle, gdyż dzisiaj prawie połowa naszych przychodów to są właśnie przychody od klientów, którym po prostu pomagamy, czy którym już pomogliśmy, a teraz dalej rozwijamy produkty – projekty, które w jakiś sposób były zagrożone. Czy to z powodu tego, że ich poprzedni dostawcy nie dostarczyli wystarczającej wartości bądź też jakości, bądź też nie poradzili sobie z dostarczeniem tego w określonym czasie, który był bardzo istotny, lub w sytuacjach, kiedy to wewnętrzne działy IT, wewnętrzne zespoły również z jakiegoś powodu nie poradziły sobie z na przykład dużą presją czy rosnącą skalą biznesu, czy w ogóle z tym, że biznes bardzo szybko rósł i potrzebował troszeczkę innych środków, innych metod wytwarzania produktów, które byłyby adekwatne do ówczesnej skali tego biznesu. Mało tego, pierwszy nasz klient Pragmatic Coders, pierwszy projekt, którym się zajmowaliśmy, to właśnie był projekt, w którym mieliśmy za zadanie ten projekt i część organizacji klienta uratować przed porażką. Projekt, który w zasadzie był już praktycznie skazany na porażkę, a nam udało się w około półtora roku ten projekt wyprowadzić na prostą, sprawić, że zaczął generować znaczące, znaczące zyski dla naszego klienta. A żeby tego było mało, to nasz drugi klient w historii Pragmatic Coders również był klientem, który poprosił nas o to, żebyśmy uratowali jego aplikację. Wielokrotnie klienci do nas zwracali się z właśnie takim problemem, takim wyzwaniem i wielokrotnie z tym wyzwaniem sobie razem z tymi klientami wspólnie w jakiś sposób radiliśmy. W zasadzie dzisiaj można powiedzieć, że mamy już dosyć sprawdzone metody na większość przypadków, które mogą wystąpić w organizacjach takich jak Wasza, jeśli chodzi o to, co może pójść nie tak w projekcie.

Dlaczego wczesne wykrywanie problemów jest kluczowe?

Zanim przejdziemy do omówienia pierwszych sygnałów dotyczących tego, że w Twoim projekcie jest coś nie tak, że być może tam się pali, tylko Ty jeszcze tego nie widzisz i nie czujesz dymu, warto, żebyśmy porozmawiali o tym, dlaczego tak istotne jest zauważenie tych problemów wcześnie, albo w zasadzie jak najwcześniej. Myślę, że odpowiedź jest prosta, ale nieoczywista. Jeżeli są jakieś problemy w projekcie i one dopiero są na wczesnym etapie i uda nam się je wykryć, to mamy bardzo dużo możliwości, żeby coś z nimi zrobić. Natomiast jeżeli nic z tymi problemami nie zrobimy albo je przeoczymy, to te problemy bardzo szybko rosną i one wręcz rosną geometrycznie. Powodują kolejne problemy. Z czasem tak naprawdę dużo trudniej jest cokolwiek z nimi zrobić. Mało tego, te problemy rosną, rosną kaskadowo, jedne problemy generują kolejne i nawet za jakiś czas, jeżeli będziemy chcieli coś poprawić, będziemy chcieli polepszyć sytuację, w której będziemy, to trudno będzie znaleźć prawdziwą przyczynę tego, co jest problemem, realnym problemem. Być może już będziemy pracować na jakichś pochodnych problemach, na rzeczach, których nawet rozwiązanie wcale nie poprawi sytuacji, a poprawi ją tylko trochę. A tak naprawdę z czasem okaże się, że te poprawy w ogóle przestaną działać albo pojawią się jeszcze nowe problemy, które spowodują jeszcze gorsze rezultaty. Im wcześniej znajdziemy problem, zdiagnozujemy problem i go rozwiążemy, tym łatwiej jest nam w długim okresie czasu zarządzać organizacją. No i też tak naprawdę koszty wytwarzania produktu czy realizacji danego projektu w ten sposób stają się dużo niższe niż w sytuacji, kiedy dużo naszego czasu, dużej naszej energii poświęcamy na gaszenie pożarów, zamiast na rozwijanie produktu, dostarczanie wartości i zastanawianie się nad tym, jak tę wartość realnie maksymalizować.

Sygnał 1: Projekt „Arbuz”

Pierwszą grupę sygnałów, którą chciałbym Wam przedstawić, sygnałów, że coś się dzieje nie tak w projekcie, nazwałem sobie roboczo „Arbuz”. Dlaczego arbuz? Dlatego, że jest to projekt, w którym na zewnątrz wszystko jest piękne, zielone, a w środku jest czerwono. Wszystko się gotuje, tam jest pożar, płonie i tak dalej. No ale patrząc z zewnątrz, jest zielono. Czyli wszystkie statusy są na zielono, wszyscy ludzie są zadowoleni, uśmiechnięci i tak dalej. Natomiast w środku jest czerwono i są tam same problemy, których jeszcze nikt nie widzi. Po czym poznać, że mamy do czynienia z takim arbuzem? No, przede wszystkim to jest taka sytuacja, w której na przykład idziecie sobie na review zespołu i tam wszystko jest pięknie na zielono, wszystkie testy działają, wszystkie historyjki zostały ukończone w sprincie, cele nawet może są gdzieś tam jakoś osiągane, tylko te cele to tak jakoś nie brzmią jak prawdziwe cele, ale są na zielono. Wszystko jest fajnie. Ludzie przedstawiają na przykład slajdy, pokazują, jakie to piękne rzeczy dowieźli, pokazują screenshoty z aplikacji, ale na przykład bardzo rzadko pokazują działającą aplikację. Albo nawet jeśli ją pokazują, no to oni prezentują to, co zrobili. Natomiast no już nie dają do przeklikania się przez tę aplikację nikomu z osób obecnych na takim review, na takim spotkaniu. To jest takie trochę właśnie malowanie trawy na zielono. Ci ludzie być może wiedzą, jak się przeklikać przez tę aplikację, żeby pokazać, pochwalić się tym, co zrobili. Natomiast jeśliby kliknęli gdzieś poza tą utartą ścieżką, no to mogłoby się okazać, że ta aplikacja już nie do końca będzie działała w taki sposób, jak powinna. Mieliśmy wiele takich historii, kiedy klienci do nas przychodzili. Zazwyczaj właśnie zdecydowanie za późno. W takich sytuacjach, kiedy już się orientowali, kiedy ktoś naprawdę po czasami wielu miesiącach albo nawet wielu latach mówił „sprawdzam”. Kiedy ktoś z interesariuszy, ktoś ze sponsorów takiego projektu faktycznie próbował użyć takiego produktu, to okazywało się, że tam tak naprawdę nic nie działa, nic nie ma, a wszystko to, co było pokazywane, to tylko zasłona dymna. Mam taką historię. Parę lat temu zwrócił się do nas bank z Wielkiej Brytanii, który zatrudnił sobie do jednego z projektów, który mieli zrealizować, zatrudnili sobie firmy z tak zwanej Wielkiej Czwórki czy Wielkiej Piątki, wielką korporację konsultingową. Wiadomo, bank, korporacja konsultingowa – to wszystko ma sens. Ta firma konsultingowa budowała dla nich rozwiązanie przez około półtora roku, chyba nawet dwa lata. W którymś momencie właśnie ktoś z interesariuszy powiedział: „sprawdzam”. Tam oczywiście wszystko w Jirze wyglądało pięknie. Taski były pokończone. Część rzeczy oczywiście tam jeszcze wymagała jakichś małych przeróbek i tak dalej, ale wszystko było ukończone. Niby wszystko miało działać i tak dalej. No ale okazywało się, że tak naprawdę nie ma co pokazać. Jak ktoś zapytał, jak ktoś chciał tego użyć, no to nie było nic, co można byłoby użyć. Ten klient zwrócił się do nas, żebyśmy spojrzeli, co tak naprawdę zostało zrobione, żebyśmy zajrzeli w kodzik i zobaczyli, co tam w tym kodzie jest. Wiadomo, kod prawdy ci powie. No i my to zrobiliśmy. Zajrzeliśmy do tego kodu i to, co tam zobaczyliśmy, było, myślę, że niesamowite, ponieważ znaleźliśmy tam na przykład bardzo dużo pustych metod. Były funkcje, które nie miały żadnego ciała funkcji, czyli nie było żadnego kodu, który mógłby się wykonać. Te metody były wywoływane w innych miejscach, natomiast one nic nie zwracały, nic nie robiły. Po prostu było na przykład `return true`, a dopisany był komentarz: „No i w tej metodzie trzeba będzie zaimplementować jeszcze to, to, to i to”. I takich metod odkryliśmy wręcz setki. Co się okazało? Ludzie, którzy pracowali nad tym projektem po stronie tego konsultanta, czy też tak naprawdę prawdopodobnie to byli jacyś kontraktorzy, było to gdzieś dalej zlecone komuś innemu. Ci ludzie po prostu mieli płacone za odhaczanie tasków w Jirze. Nie mieli żadnej definition of done. Definicji ukończenia, jak gdyby nikt nie sprawdzał po nich pracy. Bardzo szybko się zorientowali, że wystarczy, że muszą jak gdyby realizować to, co jest przez jakiegoś architekta zlecone, czyli na przykład mają dodać jakieś metody. Te metody mają się jakoś wywoływać i tak dalej. Ktoś w ten sposób nimi zarządzał, pewnie jakiś wysoko postawiony konsultant. No i oni robili dokładnie to, co było im powiedziane, i nic więcej. Myślę, że to mniej więcej tak musiało wyglądać. Nie spodziewam się, żeby tam było jeszcze to jakoś inaczej zrealizowane. No niemniej jednak na koniec dnia ci ludzie, ta firma przez wiele, wiele miesięcy za naprawdę grube miliony nie dostarczyła nic. Dobrym końcem tej historii jest to, że naszemu klientowi po kilku rozprawach sądowych udało się odzyskać prawie wszystkie środki, które przepalili na ten projekt, z tą firmą konsultingową. Niemniej jednak stracili prawie dwa lata, przez które mogli realnie dostarczyć ten produkt. I notabene ten produkt nasz zespół, nieduży zespół, chyba około dziesięcioosobowy, zrealizował w kolejnych kilku miesiącach, bodajże osiem, dziewięć miesięcy, praktycznie zaczynając od zera, bo tam nie było nic, co można byłoby realnie wykorzystać w prawdziwym produkcie.

Sygnał 2: Problemy produktowo-biznesowe

Druga grupa problemów czy też takich sygnałów, że coś jest nie tak, dotyczy tak naprawdę takich sygnałów stricte produktowo-biznesowych. Natomiast zanim do tego przejdziemy, myślę, że to jest dobry moment, żeby wspomnieć, że ponad połowa z osób, które oglądają nasze odcinki, nie jest subskrybentami naszego kanału. Także to jest dobry moment. Jeśli temat Was interesuje, kliknijcie subskrybuj, dajcie kciuka w górę. To jest coś, co nas jako twórców bardzo motywuje do tego, żeby dalej dzielić się wiedzą. I tak naprawdę robimy to dla Was. A teraz wracamy do materiału, który przygotowałem.

Jeśli w danym zespole albo w danej firmie, w dziale IT czy w zespole, który realizuje jakieś przedsięwzięcie, zapytamy dowolną osobę o to, po co tak naprawdę robi to, co robi, jaki jest cel tego produktu, który buduje, to taka osoba na przykład nie jest w stanie udzielić takiej odpowiedzi bądź udziela odpowiedzi, która jest totalnie błędna. Albo w ogóle zapytamy kilka osób i każda z tych osób mówi coś zupełnie innego. To jest jeden z takich sygnałów, który pokazuje nam, że jest duże prawdopodobieństwo, że nie wiedząc, po co coś robimy, nie wiedząc, jaki jest cel, na koniec dnia zostanie zbudowane coś, co niekoniecznie będzie wnosiło wartość biznesową, niekoniecznie będzie ten prawdziwy cel realizował. W takich przypadkach bardzo często widać, że na przykład różne działy w firmie albo właśnie różne zespoły mają różne pojęcie na temat tego, jaka jest wizja produktu. Często też widać, że na przykład jest jakaś roadmapa produktu. To już w ogóle brak roadmapy też jest jednym z sygnałów, że coś się dzieje nie tak. Ale załóżmy, że jest jakaś roadmapa i tak naprawdę ta roadmapa nie jest taką prawdziwą produktową roadmapą, tylko jest po prostu jakąś taką losową listą życzeń, gdzie przeplatają się bardzo różne rzeczy, które nie są ze sobą jakoś strasznie powiązane, które tak naprawdę nie realizują jednej konkretnej wizji, jednego konkretnego celu, no tylko po prostu ktoś przyszedł, powiedział, że chce coś, no to dodajmy to do roadmapy, dodajmy do backlogu. Ktoś inny przyszedł, powiedział, że chce coś innego, zostało to dodane. I tak sobie ten produkt jest dalej rozwijany.

W efekcie bardzo często w takich sytuacjach dochodzi do czegoś takiego, że nawet jeśli zespół, jeśli dostawca regularnie dostarcza nowe wersje oprogramowania – tutaj zakładam, że to oprogramowanie już nawet może być na produkcji, może mieć użytkowników – to te nowe wersje oprogramowania tak naprawdę nie przynoszą żadnej wartości. Nie jest tak, że każda nowa funkcjonalność na przykład zwiększa nam, nie wiem, zainteresowanie czy zaangażowanie klientów, czy zwiększa nam przychody, czy zyski i tak dalej. Taka fabryka feature’ów. Dodajemy cały czas nowe rzeczy. Te rzeczy faktycznie nawet być może działają, działają całkiem nieźle, natomiast okazuje się, że nikt ich nie używa. Ponieważ tak naprawdę te feature’y to jest jakaś taka lista życzeń pojedynczych osób, o których wspomniałem przed chwilą. W takich sytuacjach coś, na co warto zwrócić uwagę, to to, czy w ogóle istnieją jakieś mierniki sukcesu, czy są w ogóle jakieś metryki, które są śledzone w takim projekcie. Jeśli takich metryk nie ma, no to to jest kolejny sygnał, który mówi nam, że prawdopodobnie za chwilę w takim projekcie coś może wybuchnąć. No i druga rzecz. Nawet jeżeli takie metryki są, to trzeba się pochylić nad tym, czy te metryki dotyczą outcome’ów, czy dotyczą outputów. Tutaj zachęcam Was do jednego z naszych już odcinków sprzed wielu, wielu miesięcy, gdzie opisaliśmy, czym jest output, outcome i impact. Jeśli nie znacie tych pojęć, to gorąco zachęcam, sięgnijcie do tego odcinka. Natomiast jeśli metryki, które w projekcie są – szczęśliwie, to już jest w ogóle sukces, jeśli są – nie dotyczą outcome’u, tylko dotyczą właśnie outputów, to jest też duża szansa, że taki projekt nie skończy się najlepiej. Prawdopodobnie za chwilę trzeba będzie gasić w nim pożar.

Kolejnym takim sygnałem w tego typu projektach często jest to, że jest bardzo duży chaos, jeśli chodzi o priorytety. Te priorytety zmieniają się ciągle. Zmieniają się osoby decyzyjne albo w ogóle jest wiele osób decyzyjnych, które wywierają naciski na zespół, na dostawcę odnośnie do tego, co tak naprawdę powinno być najważniejsze, co w danym momencie powinno być robione. Tak naprawdę kończy się to zazwyczaj tym, że ludzie przerzucają się zadaniami. W sensie rozpoczynają pracę nad czymś, ktoś przychodzi i wywraca priorytety do góry nogami. Oni rzucają to, co robili, i zaczynają robić coś innego. Później przychodzi ktoś jeszcze inny, prosi o coś innego. Znowu rzucają wszystko i zaczynają robić kolejną rzecz. No i na koniec dnia nic nie jest skończone. Jeśli chcą do czegoś wrócić, to praktycznie muszą zaczynać od nowa. No i wszyscy kręcą się w kółko. Nic nie jest dostarczane. Na koniec dnia wszyscy są niezadowoleni. Wartości jak nie było, tak nie ma. Taki projekt, jeśli jeszcze się nie pali, jeśli jeszcze nie płonie, to za chwilę już tam będzie porządny pożar i trzeba będzie ten pożar gasić. Trzeba będzie ingerować w to, jak wygląda zarządzanie takim projektem.

W takich projektach często się też zdarza taka sytuacja, że koszty utrzymania takiego projektu się nie spinają. I nie mówię tutaj o kosztach rozwoju, o developmencie, tylko na przykład o tym, że większość czasu deweloperów jest przeznaczana tak naprawdę na przykład na support, na obsługiwanie zgłoszeń klientów. Albo większość tego czasu jest przeznaczana na łatanie jakichś błędów, rozwiązywanie problemów zamiast na rozwijanie wartości. O tym za chwilę też powiemy w kontekście takich sygnałów stricte technicznych, technologicznych. Niemniej jednak już na poziomie biznesowym bardzo często to widać. Po prostu jeśli ktoś zaczyna mierzyć koszty, zaczyna po prostu liczyć pieniądze, to okazuje się, że w takim projekcie często wydaje się bardzo dużo pieniędzy na rzeczy, które no realnie nie wnoszą tak naprawdę dużej wartości. No może poza wartością związaną z tym, że jeżeli mamy duży problem, mamy błędy, które powodują jakieś koszty albo straty wizerunkowe, no to ratujemy tak naprawdę te straty. To już jest ratowanie projektu w momencie, kiedy on jest zbugowany, a nie tak naprawdę jego stabilne rozwijanie.

I tutaj, żeby wam podać przykład, to mieliśmy takiego klienta. Klient z Bliskiego Wschodu, duża firma odzieżowa, która zwróciła się do nas właśnie z takim problemem, że z jakiegoś powodu ich programiści, ich zespół od dłuższego czasu niczego nie dowiózł. No może nie tak, że niczego, bo tam jakieś rzeczy cały czas są dowożone, cały czas były jakieś release’y nowych funkcjonalności. Niemniej jednak tak naprawdę zyski tej firmy, przychody tej firmy, w zasadzie wszystkie istotne biznesowe metryki po prostu stały w miejscu. Po może nie krótkiej diagnozie, bo to wymagało od nas troszeczkę wniknięcia w strukturę organizacji – naprawdę, zanim dostaliśmy dostępy do pewnych rzeczy i tak dalej, to też trochę minęło – odkryliśmy, że te problemy, o których wcześniej powiedziałem, czyli problemy z decyzyjnością, z chaosem, jeśli chodzi o to, kto tak naprawdę podejmuje decyzje, brakiem wizji, zmianą priorytetów i tak dalej – wszystkie te rzeczy w tej organizacji występowały. No i tak naprawdę musieliśmy zacząć nawet nie tyle od ratowania samego projektu, od kodowania, gdzie kod też nie był najwyższej jakości, umówmy się. Było tam też dużo różnych problemów związanych z infrastrukturą, z administrowaniem tą infrastrukturą i tak dalej. Niemniej jednak, zanim siedliśmy do tych rzeczy technicznych, tak naprawdę najpierw musieliśmy rozwiązać te problemy stricte zarządcze. Kwestie związane z tym, jak ten projekt był prowadzony, żebyśmy w ogóle mieli szansę tam cokolwiek realnie zrobić i temu klientowi realnie pomóc.

Sygnał 3: Sygnały z procesu dostarczania (delivery)

Kolejna grupa sygnałów, na której chciałbym się skupić, to takie sygnały stricte z delivery. To takie sygnały procesowe. Jednym z nich na przykład jest to, że jak sobie spojrzycie na, no na przykład na cumulative flow diagram w Jirze – jest taki report dostępny dla tych, którzy nie wiedzą. Jeśli używacie innego narzędzia, to pewnie w nich też coś podobnego jest. Ewentualnie możecie te dane wyeksportować i sobie to wszystko spróbować jakoś uwidocznić w na przykład Excelu. Natomiast patrząc na taki cumulative flow diagram, takim sygnałem, że coś jest nie tak, jest to, że rzeczy, które są oznaczone jako „In progress”, jest bardzo dużo. Zwłaszcza jeżeli tych rzeczy in progress cały czas przybywa, no to po prostu mamy problem. Mamy problem z tym, że jest prawdopodobnie jakiś bardzo duży multitasking, właśnie zmiany priorytetów, o których mówiłem w poprzedniej grupie sygnałów. Być może po prostu ludzie kręcą się w kółko i robią w kółko te same rzeczy. Być może jest tak, że dostarczają rzeczy niskiej jakości i te rzeczy wracają z powrotem od developmentu. I tutaj pojawia się taki problem, że tak naprawdę mamy problem z kończeniem rzeczy, a cały czas rozpoczynamy nowe.

Może to jest też kwestia związana z tym, że na przykład mamy proces, w którym wszystko wymaga jakiejś wieloetapowej akceptacji i tak naprawdę wszyscy czekają na tę akceptację. Ta akceptacja jest wąskim gardłem w naszym procesie. Robimy sztukę dla sztuki, dewelopując nowe rzeczy, które czekają tygodniami albo dniami na akceptację, a później tak naprawdę i tak wracają do developmentu. Jest bardzo dużo reworku, bardzo mało tak naprawdę efektów takiej pracy. Tutaj jeszcze jedna mała uwaga. To, że coś jest oznaczane jako „done”, wcale nie musi znaczyć, że to jest skończone. Tutaj, w takiej sytuacji warto też się przyjrzeć temu, jak wygląda definition of done danego zespołu. Co to znaczy, że zespół myśli, że coś jest dostarczone? Bo może się okazać tak, że faktycznie przybywa nam tych rzeczy, które są skończone, natomiast po jakimś czasie okazuje się, że no tam są na przykład błędy, ponieważ w definition of done nie było mowy o tym, żeby coś przetestować. Albo te rzeczy – może w samych tych nowych rzeczach, które robimy, błędów nie ma, ale powodują one błędy w regresji. Psują po prostu inne rzeczy, które teoretycznie nie powinny być podczas tych zmian poruszone, ale jednak mamy jakiś impact na tamte rzeczy, ponieważ na przykład w definition of done nie było testów regresyjnych. Także warto się przyglądać takiej definicji ukończonego, definition of done. No i warto też sprawdzić, czy nawet jeśli to definition of done jest pięknie spisane, wydrukowane, na ścianie przyklejone, zespół codziennie na nie patrzy, to czy oni faktycznie się do tego stosują? Czy o tym rozmawiają? Czy każde zadanie, które robią, każda historyjka, którą wyznaczają, jest sprawdzana pod kątem właśnie tego definition of done.

Kolejnym takim sygnałem, że coś jest nie tak na poziomie naszego procesu, jest kwestia tego, że lead time nam rośnie z czasem. Lead time, czyli średni czas, w jakim jesteśmy w stanie od pomysłu do wejścia na produkcję najlepiej dostarczyć jakąś nową funkcjonalność. I jeśli widzimy, że z czasem jest nam coraz trudniej, zajmuje nam coraz więcej czasu albo coraz więcej nas kosztuje, bo na przykład w międzyczasie, nie wiem, koszty rosną, zespół rośnie i tak dalej, rośnie nam ten koszt czy czas dostarczenia czegoś na produkcję, to wiedz, że coś się dzieje. Wiedz, że w tym projekcie prawdopodobnie jest jakiś problem. On może być stricte procesowy, może też być stricte techniczny, może tam być po prostu bardzo duży dług techniczny, ale o tym za chwilę porozmawiamy. Natomiast to może być kwestia procesowa. Warto się też pochylić nad tym, sprawdzić te rzeczy, o których mówiłem przed chwilą.

W takich sytuacjach, tak jak wspomniałem wcześniej, warto poszukać tego, czy nie ma jakichś blockerów, które są zaimplementowane w naszym procesie. Właśnie, jakieś akceptacje, ale to niekoniecznie musi być akceptacja. To może być na przykład kwestia tego, że mamy tylko jedną osobę, która jest ekspertem domenowym i tylko ta osoba może realnie odpowiadać na pytania zespołu. Może pomagać temu zespołowi w wykonywaniu swoich zadań. Być może to jest jedyny senior w zespole, jedyny architekt, jedyny analityk albo w ogóle jeszcze inna osoba, która jest po prostu tym wąskim gardłem w naszym procesie. Jeśli jest taka situacja, no to to, co powinniśmy zrobić, to przede wszystkim wiedzę tej osoby, tej osoby rozdysponować, tak naprawdę udokumentować, a później rozdysponować na jak najwięcej osób, tak żeby to nie tylko ta osoba podejmowała wszystkie decyzje i była tym naszym wąskim gardłem w procesie.

Tutaj myślę, że warto nawiązać do historii jednego z naszych pierwszych klientów, gdzie dokładnie te problemy zidentyfikowaliśmy na samym początku. W zasadzie tych problemów było kilka. Pierwszy z nich wynikał z tego, że projekt ten był realizowany, był dużym legacy, przejętym gdzieś tam jeszcze od kogoś innego. Miał bardzo, bardzo dużo błędów, bardzo dużo problemów, bardzo dużo technicznych jakichś naleciałości z wcześniejszych implementacji tego samego przedsięwzięcia. Tak naprawdę praca deweloperów w tym projekcie polegała na tym, że oni cały czas gasili pożary, cały czas łatali bugi, obsługiwali jakieś zgłoszenia z supportu. Z produktu korzystały w zasadzie chyba dziesiątki tysięcy użytkowników w tamtym czasie. Także skala tego produktu troszeczkę przerosła jego techniczne możliwości. Ludzie, no, biegali w kółko, rozwiązywali problemy. Problemem była też kwestia wiedzy. Nie było wystarczającej liczby osób, które faktycznie by rozumiały, jak działa ten system, jak wygląda jego architektura i tak dalej. No i tam też klient poprosił nas o wsparcie. Mieliśmy okazję zbudować nasz własny zespół. Ten zespół wkroczył do akcji. Na początku był dosyć duży. Naszym celem tak naprawdę było wdrożenie – na pierwszym, pierwszym kroku było wdrożenie narzędzi pozwalających monitorować wszystkie błędy, które się pojawiają w aplikacji, a później sukcesywnie te błędy, błąd po błędzie rozwiązywaliśmy aż do momentu, kiedy z sytuacji, kiedy tych błędów były tysiące dziennie w logach, zaczęło tych błędów być dosłownie kilka. W zasadzie pojawiały się raz na kilka dni. No i z zespołu, który miał na początku chyba szesnaście osób pracujących dla tego klienta po to właśnie, żeby troszeczkę masą wygenerować przestrzeń na refactoring, na naprawianie tych problemów technicznych, tak naprawdę ten zespół w ciągu dwóch lat skurczył się do zaledwie trzech osób, które ten produkt były w stanie nie tylko utrzymywać, ale też sukcesywnie rozwijać na produkcji, zaspokajać zmieniające się potrzeby rynku, potrzeby użytkowników. To już było prawie dziesięć lat temu. Nadal przynosi bardzo duże przychody dla naszego klienta. Da się to zrobić. Tam oczywiście po drodze też było wiele różnych innych problemów. Poza tymi bottleneckami w postaci osób, które znały architekturę, były też problemy procesowe i tak dalej. To wszystko też musieliśmy zaadresować, zanim realnie udało nam się efektywnie nad tym projektem pracować i temu klientowi pomóc.

Sygnał 4: Sygnały techniczne

Czwarta grupa sygnałów to sygnały stricte techniczne. Już o tym wspominałem trochę, ale dług techniczny często jest też objawem tego, że nasz projekt już płonie, tylko jeszcze tego nie widać. Czasami jest to maskowane przez to, że deweloperzy dwoją się i troją, żeby faktycznie coś dostarczać, ale cały czas, za każdym razem, z każdą nową funkcjonalnością staje się to coraz bardziej trudniejsze. Nasz kod, nasza aplikacja jest trudna w rozwoju, jest bardzo złożona. Wszystkie rzeczy albo wiele rzeczy jest ze sobą powiązanych. Zmiana w jednym miejscu powoduje problemy gdzieś indziej. To najczęściej widać właśnie przez to, że dodajemy jakąś zmianę w jednym miejscu i za chwilę od naszych użytkowników najczęściej, niestety, dowiadujemy się, że zepsuliśmy przez przypadek coś innego. To jest taka sytuacja, którą myślę, że większość z osób, które kiedykolwiek budowały jakikolwiek produkt software’owy, doskonale zna. Niemniej jednak warto już na wczesnym etapie wykrywać tego typu sytuacje, ponieważ prawda jest taka, że takim pierwszym sygnałem, jeśli dzieje się coś takiego, jest to, że to deweloperzy sami podnoszą tutaj alarm. Tylko niestety z jakiegoś powodu mało kto tych deweloperów słucha. To, co ja zawsze radzę deweloperom, jeśli to oglądacie, to posłuchajcie. To nie jest do końca tak, że jak wy już podniesiecie alarm czy powiecie, że coś jest nie tak, to obowiązkiem tych ludzi naokoło jest to, żeby teraz wam wygenerować nie wiadomo ile przestrzeni na jakiś wielki refactoring. Tak naprawdę to waszym zadaniem jest robienie tego refactoringu w sposób ciągły, tak żeby do takich sytuacji nie dopuszczać. Albo jeśli już tak jest, to żeby samodzielnie wygenerować przestrzeń na stopniowe, systematyczne poprawianie jakości tego, nad czym pracujecie, tego, co robicie. Ja wiem, że to nie jest proste. Wiem, że zawsze jest duże ciśnienie i zawsze w sytuacji, kiedy ta złożoność najpierw rośnie przez jakiś czas, to ciśnienie się tak naprawdę zwiększa, no bo rośnie złożoność, wydłuża się lead time, więc ciśnienie rośnie jeszcze bardziej. Jest to takie trochę błędne koło. Deweloperzy, też musicie o to przede wszystkim wy zadbać. Ale z drugiej strony dla wszystkich osób, które deweloperami nie są, pracują w takich projektach czy to zarządzają takimi projektami, narzekanie waszych deweloperów w większości, przeważającej większości przypadków jest uzasadnione. Nie bez powodu płacicie tym ludziom tyle pieniędzy, żeby tak naprawdę ignorować sygnały, które oni wam dają, że coś jest nie tak i coś warto z tym zrobić.

Myślę, że w takich sytuacjach warto usiąść do stołu od razu, jak tylko takie sygnały się pojawiają i od razu próbować wspólnie adresować te problemy, które są, i wspólnie znajdywać rozwiązania. Bo jeśli się tak nie stanie, to prawdopodobnie prędzej czy później traficie do firmy takiej jak nasza, która powie wam dokładnie to samo. To żeby wyjść z takiej sytuacji, no to okej, fajnie, że mamy jakieś tutaj biznesowe cele i inne rzeczy. Też się na nich skupimy, ale musimy też usiąść i poważnie zastanowić się nad tym, jak podnieść jakość. Więc na koniec dnia Wasza możliwa prędkość developmentu, dostarczania, bez względu na to, ile osób zatrudnicie, będzie mniejsza niż prawdopodobnie byście tego chcieli. Lub w którymś momencie może dojść do takiej sytuacji, że ktoś taki jak my, albo w ogóle jakiś konsultant z zewnątrz, albo ktoś inny po prostu Wam rekomenduje, żeby to wszystko wyrzucić do kosza i zacząć tworzyć od nowa. Jeszcze myślę, że trzy, cztery lata temu mało kto tego typu rady dawał. Natomiast dzisiaj z możliwością wykorzystania AI, z powodu tego, że ogólnie software development przyspieszył, taka rekomendacja jest coraz częstsza. No oczywiście wiąże to się z niemałymi kosztami. No i też jest niezerowa szansa, że robiąc rzeczy od nowa, doprowadzicie do tych samych problemów, które mieliście wcześniej. Więc tutaj ryzyko też jest dosyć wysokie. Warto to przemyśleć. Warto przemyśleć przede wszystkim, czy jeżeli decydujecie się na robienie czegoś od nowa, tego samego od nowa, czy warto to robić z tymi ludźmi, którzy już raz doprowadzili do sytuacji, w której nie chcielibyśmy się znaleźć ponownie?

Po czym poznać, że jest źle, poza narzekaniami deweloperów? No przede wszystkim to, o czym mówiłem, czyli mała zmiana powoduje lawinę problemów. Kolejna taka oznaka to kwestia tego, że na przykład chcecie wejść na produkcję z nową wersją i to jest wielkie wydarzenie. Cała produkcja musi zostać zatrzymana albo w ogóle ludzie robią wdrożenie na produkcję o trzeciej nad ranem, bo wtedy nie ma użytkowników. Jak coś się stanie, to będą w stanie to szybko jakoś jeszcze załatać i coś z tym zrobić. Także tego typu sytuacje, poza jakimiś skrajnymi przypadkami systemów naprawdę wysokiego ryzyka, bardzo złożonych, bardzo skomplikowanych, tego typu sytuacje są pewną oznaką tego, że w Waszym projekcie nie jest najlepiej. Tam coś się dzieje nie tak i warto się temu przyjrzeć i poświęcić trochę uwagi na to, jak wygląda ten aspekt techniczny Waszego produktu.

Tutaj w takich sytuacjach najczęściej po prostu brakuje kontroli jakości. Nie ma na przykład testów automatycznych, nie ma continuous integration, continuous delivery, która by w automatyczny sposób odpalała testy i dawała znać, że coś się popsuło i tak dalej. To są takie najczęstsze rzeczy, które można łatwo zauważyć. Nawet jak nie jesteście osobą techniczną, po prostu zapytać deweloperów, czy mają CI/CD, czy odpalają testy. Jakie jest pokrycie tymi testami? Czy faktycznie – czasami widziałem takie sytuacje naprawdę, że ludzie odpalali testy, no tam testy na czerwono, no ale co z tego? My wiemy, że one zawsze są na czerwono. No to jedziemy na produkcję. Użytkownicy nam powiedzą, jeżeli coś będzie nie tak. No i oczywiście właśnie w takich sytuacjach jednym z objawów problemów jest to, że o problemie dowiadujemy się od użytkowników, a nie wychwytujemy tego typu rzeczy sami. Oczywiście, takie rzeczy się zdarzają. Błędy zawsze będą, zawsze będziemy popełniać błędy i od czasu do czasu błąd na produkcji po prostu statystycznie się musi wydarzyć. Jeżeli taka sytuacja jest codziennością, no to mamy problem z jakością naszego projektu.

Sygnał 5: Sygnały ludzkie

Piąta i ostatnia grupa sygnałów to sygnały ludzkie. Sygnały, które możemy obserwować, po prostu patrząc, czy w zasadzie słuchając ludzi, których mamy w organizacji. To, co oni mówią, ale przede wszystkim to, co robią. To, co oni mówią, a przede wszystkim to, co robią, może być dla nas informacją na temat tego, czy w naszym projekcie jest dobrze, czy tak naprawdę już tam się tli jakiś pożar, który za chwilę wybuchnie. Takim jednym najbardziej widocznym sygnałem, ludzkim sygnałem, że coś się dzieje nie tak, jest wysoka rotacja. Kiedy nasz zespół rotuje, kiedy odchodzą zwłaszcza kluczowe osoby, to coś na pewno jest nie tak z danym projektem. Tam może być kwestia związana z motywacją, a raczej demotywacją wynikającą właśnie na przykład z wysokiego długu technicznego albo z frustracji, która wynika właśnie z dużej presji, która jest wywierana na ludzi, a oni z tą presją nie potrafią sobie poradzić, ponieważ nie mają możliwości, bo sytuacja jest, jaka jest, złożoność jest, jaka jest i ciężko jest w takiej złożoności pracować w efektywny sposób. Duża rotacja w zespole jest jednym z sygnałów tego, że prawdopodobnie coś jest nie tak w projekcie. Prawdopodobnie mamy ten pożar. Mało tego, taka rotacja to jest też utrata wiedzy na temat tego przedsięwzięcia, na temat tego projektu, co tak naprawdę generuje kolejne problemy i jest dokładaniem kolejnego drewna czy węgla – w Polsce węgla – do ognia i za chwilę ten ogień jeszcze bardziej wybuchnie.

W takich sytuacjach często też widać na przykład wypalenie zawodowe wśród ludzi, którzy pracują nad takim projektem. Tutaj takie pierwsze oznaki to na przykład cynizm albo wysoki poziom sarkazmu, który jest używany przez deweloperów, przez członków zespołu. Może się to, poza cynizmem, sarkazmem, objawiać też na przykład taką postawą, że robimy absolutne minimum, bo to się i tak nie uda. Byliśmy już wielokrotnie w tej sytuacji, już wielu nam tutaj chciało pomóc, a to i tak będzie jak zawsze. To są takie częste cytaty, które czy to w organizacjach, w których kiedyś pomagałem jako konsultant, czy w niektórych organizacjach naszych klientów po prostu się pojawiają, które są objawem tego, że w projekcie dzieje się źle. Często tak naprawdę one wynikają z tego, że jest już tak źle albo jest już tak długo tak źle, że ludzie są realnie zmęczeni tą sytuacją. A to wynika z tego, że po prostu te pierwsze sygnały, które się pojawiały, zostały zignorowane, albo może nawet nie zostały zignorowane, ale po prostu niewystarczająco zostały zaadresowane i ktoś doprowadził do takiej sytuacji, która jest obecnie.

W takich sytuacjach bardzo często też dochodzi do konfliktów i te konflikty są widoczne na linii business – delivery czy dostawca – osoby, które miały zarządzać tą pracą tego dostawcy u klienta. Czy w ogóle jakieś pojedyncze działy w firmie zaczynają skakać sobie do gardeł, szukając winnych niepowodzenia, nawet jeszcze zanim ktokolwiek określił, że sytuacja, w której jesteśmy, jest jakiegoś rodzaju niepowodzeniem. To wszystko mówi Wam o tym, że prawdopodobnie Wasz projekt płonie. A w zasadzie na pewno Wasz projekt płonie i albo za chwilę zapłonie widocznie, a dzisiaj być może płonie, tylko Wy jeszcze tego nie dostrzegacie.

Jeszcze jeden aspekt, który się często zdarza, to kwestia tego, że nadgodziny stają się normą. Mało tego, nie tylko nadgodziny, ale pojawiają się superbohaterowie. Pojawiają się osoby, które swoją ciężką pracą, wielkim efortem, niesamowitymi umiejętnościami i niesamowitą znajomością systemu od podszewki są w stanie jako jedyni rozwiązywać problemy w środku nocy. Oni są często nawet wręcz nagradzani w takich organizacjach, a z czasem stają się po prostu wąskimi gardłami, osobami, od których wszystko w takiej firmie zależy i które nieważne co zrobią, są nietykalne, nieusuwalne. Więc jeśli dostrzegacie wokół siebie takie osoby albo macie w firmie takie osoby, to tak naprawdę macie bardzo duży problem, ponieważ jeśli tym osobom coś się stanie albo przyjdzie im do głowy, żeby zmienić pracę, no to może być problem taki, że nie będzie kto miał przejąć tego heroizmu od nich. A Wy nie macie żadnych procesów, które by te problemy adresowały.

Mogę Wam podać przykład takiego klienta, który przyszedł do nas po tym, jak odszedł mu CTO, a w zasadzie CTO złożył rezygnację. Oni tam jeszcze myśleli, że przez długi czas negocjowali. Ten CTO miał oczywiście trzymiesięczny okres wypowiedzenia. No wiadomo, trochę się zabezpieczyli, ale dwa tygodnie przed końcem tego okresu wypowiedzenia ten CTO powiedział definitywnie: „nie, nie zgadzam się, nie zamierzam kontynuować tej pracy. Mam lepsze oferty”. Oni nie byli w stanie tego skontrować, a w zasadzie tam już chyba dochodziło do jakichś konfliktów czy innych problemów. Albo tak naprawdę ten CTO wiedział, że to, co do tej pory zrobił, no jest pożarem, który się tli, albo pożarem, który jest bardzo dobrze ukryty. No i ten klient przyszedł do nas, czy moglibyśmy coś zrobić? Czy moglibyśmy mu pomóc? Czy moglibyśmy na przykład postawić jakiegoś interim CTO? My tam postawiliśmy na początku dwie osoby: naszego jednego ze świetnych deweloperów, który taką rolę interim CTO pełnił. Natomiast od razu po pierwszej takiej diagnozie wiedzieliśmy, że tam nie są tylko kwestie techniczne problemem, ale są też kwestie właśnie procesowe czy ogólnie zarządzania produktem problemem. Umówiliśmy się z tym klientem, że oprócz tego CTO obok będzie stał chief product officer, czyli jeden z naszych product managerów i oni we dwójkę skupią się na tym, żeby jednocześnie poprawić procesy i skupić się na poprawie aspektów technologicznych, technicznych, spłaceniu długu technicznego. No i dopiero taki setup plus tam później jeszcze kilka osób od nas, które ich wspierały, pozwolił na to, żeby wyjść z problemów, które ta firma miała. Bo tam te wszystkie objawy, o których mówiłem: że bardzo duży lead time, bardzo dużo błędów, problemy z tym, że było robione wszystko naraz, a tak naprawdę żadne metryki biznesowe się nie zmieniały. No myślę, że tutaj moglibyśmy jeszcze godzinę nad tym dyskutować, jak ten projekt wyglądał. To wszystko tam było. Udało się z tego całkiem fajnie wybrnąć. Udało się całkiem fajnie doprowadzić ten projekt do sytuacji, w której realnie się rozwija, zarabia pieniądze, podnosi się jakość. Dzisiaj dalej z tym klientem współpracujemy i w zasadzie nawet w tym momencie pracujemy nad już stricte podnoszeniem jakości, przygotowywaniem tego produktu do dalszego skalowania, ponieważ pojawiły się nowe okazje biznesowe do tego, żeby produkt znacznie urósł.

Dlaczego ignorujemy sygnały ostrzegawcze?

No dobrze, jak gdyby niektóre z tych sygnałów, o których Wam powiedziałem, myślę, że są dosyć oczywiste i widzieliście to wielokrotnie i wielokrotnie podnosiliście alarm. Być może nawet coś z tym robiliście. Być może nawet Wam się czasami udawało coś z tym zrobić, ale w wielu przypadkach, nawet pomimo tego, że wszyscy widzieli te sygnały, z jakiegoś powodu były one ignorowane. Z jakiegoś powodu ludzie odwracali głowę i mówili: „no jakoś to będzie”. Pomyślimy o tym później, będziemy się martwić, jak to będzie faktycznie realny problem, jak skala będzie na tyle duża, że to będzie dla nas problem. Dlaczego się tak dzieje? Z czego to wynika? Dlaczego tak naprawdę po pierwsze słabo rozpoznajemy te sygnały na wczesnym etapie, a po drugie, nawet jeżeli je widzimy, to nic z nimi nie robimy albo po prostu je ignorujemy?

Myślę, że jednym z takich powodów, dlaczego sponsorzy i interesariusze nie dostrzegają tego typu problemów albo dostrzegają to zbyt późno, jest kwestia tego, że mierzone w projektach są niewłaściwe rzeczy. Zbyt często skupiamy się na mierzeniu kosztu, budżetu, czasu i tak dalej. A nie skupiamy się na takich metrykach jak na przykład wartość, którą dostarczamy, na outcome’ach, które dostarczamy. Nie skupiamy się na tym, jak wygląda jakość naszego produktu, ile mamy błędów, ile mamy awarii na produkcji, jak nasz produkt odbierają nasi użytkownicy. To są metryki, które zbyt często są pomijane albo marginalizowane i nie bierzemy ich pod uwagę, podejmując kluczowe decyzje na przykład odnośnie do właśnie budżetu. Pchamy do przodu, chcemy jak najwięcej, jak najszybciej dostarczyć, jak najtaniej dostarczyć. A z czasem okazuje się, że nasza jakość spada. No i tak naprawdę wartość, którą jesteśmy w stanie dostarczyć, generowana wartość też spada.

Innym, myślę, że problemem związanym z tym, dlaczego ludzie ignorują tego typu rzeczy, jest po prostu kwestia kulturowa. W wielu, wielu firmach, zwłaszcza dużych organizacjach, nikt nie chce przychodzić ze złymi wiadomościami. Ludzie zamiatają pewne rzeczy pod dywan, jak gdyby wszyscy budują swoje kariery na sukcesach, a nie na porażkach. Nikt nie chce być tą osobą, która przyjdzie i powie, że ma problem, jak gdyby wszyscy muszą te problemy raczej rozwiązywać, albo jak nie potrafią rozwiązać, to lepiej po prostu je zignorować i o nich nie mówić, albo wręcz używać słów typu wyzwania, opportunity i tak dalej. Zamiast po prostu powiedzieć, że mamy problem, mamy pożar, jest ciężko. Potrzebujemy wsparcia. Potrzebujemy się zatrzymać, skupić się na rozwiązaniu problemu, a nie brnąć dalej, bo z czasem on stanie się jeszcze większy, nawet jeśli krótkoterminowo dostarczymy coś, co jest od nas oczekiwane.

Oczywiście z czasem, jeżeli w organizacji wygląda to w ten sposób, to taka patologia się normalizuje. Także jeśli w organizacji, do której niedawno przyszliście, zauważyliście jakiś problem, mówicie o tym, że: „ej, tutaj jest coś nie tak”, a słyszycie, że: „no tak, wiemy, wiemy, ale u nas to tak zawsze było”. No to to jest właśnie normalizacja patologii. To jest taka situacja, w której wiele firm się niestety bardzo często odnajduje. Co można zrobić w takiej sytuacji? No po prostu trzeba to przerwać, trzeba zmienić tę kulturę, trzeba zmienić to nastawienie do tego typu patologii. Trzeba przede wszystkim zacząć nazywać takie rzeczy patologiami, zacząć mówić o problemach, pokazywać je, mierzyć, mierzyć ich impact i na tej podstawie zacząć podejmować decyzje o tym, żeby coś z tymi problemami robić, a nie zamiatać je pod dywan.

To wszystko najczęściej wynika z braku kontroli i bardzo niskiej transparentności. To są dwie rzeczy, które tak naprawdę można osiągnąć w prosty, dosyć stosunkowo prosty sposób, stosując odpowiednie procesy, na przykład prawidłowo stosując metodę Scrum zgodnie z zasadami, zgodnie z tym, jak jest opisana, a nie jakoś połamana, dostosowana do naszej specjalnej organizacji, w której zawsze się robiło tego scruma inaczej. Scrum, Kanban, to może być też inna metoda, ale stosowana tak, jak powinna być stosowana metoda, która zapewnia wysoką transparencję. Metoda, która daje nam jakąś kontrolę czy monitoring tego, co się dzieje i ostrzega nas tak naprawdę bardzo szybko o tego typu problemach. Bo jeśli na przykład mamy sensowne cele sprintów, zespoły mają pracować na celach sprintów, a nie na zakresie w danym sprincie, i widzimy, że czwarty sprint z rzędu nasze zespoły nie dostarczyły swoich celów, no to mamy problem i musimy zajrzeć głębiej i zobaczyć, co tam się dzieje i nad tym problemem pracować. Jeśli mierzymy nasze velocity w Scrumie albo używamy Kanbana i mierzymy throughput, mierzymy lead time czy time to market, czy cycle time i widzimy, że te metryki nam spadają sukcesywnie ze sprintu na sprint, z miesiąca na miesiąc, no to widzimy, że mamy problem. No ale żeby to zrobić, to najpierw musimy stosować te metody zgodnie z założeniami, zgodnie z tym, jak one zostały stworzone i opisane, a nie jakoś, albo jak nam się wydaje. To niestety wymaga pracy. Wymaga zdobycia tej wiedzy. Wymaga zaimplementowania tej wiedzy w praktyce.

No i myślę, że to, że u nas my naprawdę używamy Scruma zgodnie z książką, mało tego, my w ogóle sprawdzamy nasze zespoły, czy one używają Scruma, to nam daje bardzo dużą przewagę i dzięki temu na przykład jesteśmy w stanie wejść do dowolnej organizacji, która ma problem, i z naszymi metodami, z naszym podejściem, z naszym zarządzaniem produktem bardzo szybko albo relatywnie szybko – bo to „bardzo szybko” może być różne w różnych przypadkach – relatywnie szybko wyprostować taki projekt, po prostu przeciągnąć go na właściwe tory i realnie pracować, rozwiązywać problemy nawet w bardzo chaotycznym środowisku, gdzie jest duża presja i dzieją się bardzo różne nieciekawe czasami rzeczy.

No i tutaj mam jeszcze taką jedną myśl, dlaczego tak naprawdę wielu klientów z Polski zwraca się do nas z takimi problemami? Dużo rzadziej mamy klientów na przykład ze Stanów Zjednoczonych czy z Wielkiej Brytanii, którzy by przychodzili z tego typu problemami, chociaż to też się zdarza. Natomiast z Polski mamy relatywnie wielu klientów, którzy zwracają się do nas właśnie w sytuacjach, kiedy ktoś im czegoś nie dostarczył i to wygenerowało duże problemy. Ich zespół niekoniecznie sobie radzi albo nie poradził sobie, już tego zespołu nie ma, z dostarczeniem wartości, która była oczekiwana, albo dostarczył coś, co jest niskiej jakości. I tutaj oczywiście mógłbym mnożyć te historie. Dlaczego takie rzeczy dzieją się właśnie w Polsce? Tak sobie myślę, że może to ma związek z tym trochę, jak wygląda rynek w Polsce, gdzie tak naprawdę w Polsce większość firm IT to są podwykonawcy albo firmy, które są po prostu jakąś częścią delivery większych zagranicznych firm, gdzie tak naprawdę w tych firmach decyzyjność odbywa się gdzieś indziej. Decyzje nawet o tym, że coś jest problemem, czy diagnoza tego, czy coś jest problemem, czy nie jest problemem, również odbywają się gdzieś indziej. Nie tutaj, w Polsce. Nie jest to diagnozowane przez polską kadrę czy naszą lokalną kadrę menedżerską, tylko przez ludzi zza oceanu czy skądś indziej. Więc ci nasi ludzie niekoniecznie mieli od kogo się uczyć, jak rozpoznawać tego typu rzeczy na wczesnym etapie. Myślę, że w tych firmach, dużych firmach, kwestia kultury w tym nie pomaga. No i też tak naprawdę w dużej firmie, żeby coś było naprawdę poważnym pożarem, to to musi być potężny pożar. To nie są małe pożary, tam są potężne budżety. Można przepalać bardzo dużo pieniędzy i nic złego się nie dzieje. Dzieje się. Marnujemy bardzo dużo pieniędzy, ale dla tej organizacji jest to wręcz niezauważalna. Więc mamy bardzo dużą tolerancję na to, żeby po prostu robić rzeczy nieefektywnie przez bardzo długi czas, ignorować problemy, które mamy, po to tylko, żeby robić, żeby rozwijać tak naprawdę naszą karierę, a niekoniecznie myśleć stricte produktowo, podejmować decyzje, które są najlepsze dla produktu. Po prostu podejmujemy decyzje zgodne z polityką firmy, a niekoniecznie decyzje dobre dla produktu. Nie wiem, czy problemem jest kwestia właśnie tego, że nasi polscy menedżerowie uczyli się najczęściej w pracy dla korporacji z zachodu, nie mając dostępu do osób, które naprawdę są blisko produktu. Być może tak jest, być może nie. To też się oczywiście zmienia. Mamy coraz więcej naszych polskich firm, gdzie dostęp do tych osób decyzyjnych jest dużo lepszy. Mamy mnóstwo ludzi, którzy wyjechali za granicę. Wracają, przywożą tę wiedzę i się nią dzielą. Także myślę, że to się wkrótce zmieni i myślę, że warto obserwować ten trend.

Jak monitorować stan projektu?

Czy jest jakiś prosty sposób, żeby zauważyć, że w naszym projekcie jest coś nie tak? Tutaj wymieniłem Wam wiele różnych sygnałów, które mówią o tym, że coś się dzieje nie tak. Natomiast myślę, że Wy sami, na podstawie Waszych doświadczeń, na podstawie tego, co widzieliście w wielu projektach, w których uczestniczyliście, czy nawet widzicie w obecnej pracy, jesteście w stanie stworzyć swoje własne mechanizmy monitoringu. Swoje własne metryki, które pokazują Wam, czy będą Wam pokazywać, czy wszystko jest okej, czy być może dzieje się coraz gorzej, a może po prostu dzieje się tak, jak się zawsze działo i nawet jeśli mamy jakieś istotne problemy, to wcale nie jest tak źle. Nic się nie pogarsza, po prostu idziemy tym samym tempem do przodu. Do tego Was gorąco zachęcam. My w Pragmatic Coders mamy wiele różnych, na przykład checklist czy metryk, które pokazują nam, jak jest naprawdę, jak jest w naszych projektach, projektach, które realizujemy dla klientów i które pozwalają nam wykrywać problemy na wczesnym etapie, no i dzięki temu, widząc to, mamy możliwość, żeby zareagować. Oczywiście nie zawsze mamy możliwość, nie zawsze mamy moce przerobowe, żeby na każdy problem od razu reagować. Czasami pewne opóźnienia się zdarzają w tej naszej reakcji i też wtedy konsekwencje tego są poważniejsze. Natomiast zazwyczaj udaje nam się ugasić pożary, zanim one powstaną, właśnie dzięki metrykom i checklistom, o których tak naprawdę opowiadałem Wam w odcinku o tym, jak mierzyć pracę programistów, do którego Was odsyłam i tam możecie zobaczyć, jak to wszystko wygląda.

A jeśli chcielibyście dostać od nas takie checklisty, to myślę, że możemy sobie zrobić taki mały challenge. Jeśli skomentujecie ten odcinek pięćdziesiąt razy, w sensie pięćdziesiąt osób skomentuje ten odcinek z chęcią otrzymania takiej na przykład technicznej checklisty sprawdzającej, czy wszystko jest dobrze w projekcie, to taką checklistę pod tym odcinkiem dodamy, opublikujemy. Także zachęcam Was do zabawy. No i oczywiście do subskrypcji naszego kanału, zostawienia kciuka w górę. A na dzisiaj to już wszystko. Dajcie znać, co myślicie o tym materiale, który dla Was przygotowaliśmy.