Jak sprawdzić stan projektu IT? 15 pytań audytowych

Siedzisz na spotkaniu statusowym z zewnętrznym dostawcą, który rozwija dla Ciebie oprogramowanie. Dashboard świeci na zielono, dostawca zapewnia, że wszystko idzie zgodnie z planem. A Ty masz dziwne przeczucie, że coś jest nie tak. Nie potrafisz tego udowodnić, ale czujesz, że projekt zaczyna się wymykać spod kontroli.

Nie jesteś paranoikiem. około 66% projektów IT kończy się porażką, w całości albo częściowo. To, że na dashboardzie wszystko wygląda dobrze, nie znaczy, że tak jest naprawdę. Ten rozdźwięk ma nawet swoją nazwę: “efekt arbuza”. Zielony na zewnątrz, czerwony w środku.

Jeśli czujesz, że coś jest nie tak, prawdopodobnie masz rację. W tym artykule znajdziesz 15 pytań, które pomogą Ci to sprawdzić. Koniec z ogólnikami. Czas sprawdzić, co naprawdę dzieje się w kodzie, procesach i zespole.

Przestań ufać raportom, zacznij sprawdzać

Gdy przestajesz wierzyć raportom, czas zajrzeć pod maskę. Zamiast pytać managera, sprawdź, co mówią dane. Raport pokazuje to, co ktoś chciał Ci za jego pomocą pokazać, niekoniecznie stan rzeczywisty. A słaba komunikacja jest jedną z głównych przyczyn porażek projektów. Prawdę powiedzą Ci logi, historia commitów i stan backlogu. O ile masz do nich dostęp.

A jak powiedzieć „sprawdzam”? Proś o konkrety i je weryfikuj. Poniższe pytania Ci w tym pomogą.

Pytania o proces i postępy, które ujawnią prawdziwy stan projektu

Chodzi o sprawdzenie, czy raporty zgadzają się z rzeczywistością. Czy «zrobione» naprawdę znaczy, że funkcjonalność działa? Czy «wszystko OK» naprawdę oznacza zdrowy projekt? Dzięki tym pytaniom dostaniesz dowody, nie deklaracje.

1. “Pokażcie mi pipeline dla funkcjonalności oznaczonej jako ‘gotowa’. Możemy ją od razu wdrożyć na produkcję?”

„Zrobione” często znaczy „skończyłem kodować”, gdy powinno oznaczać „można wdrożyć na produkcję”. Czy funkcjonalność jest zintegrowana i przetestowana na stagingu? Czy można ją jednym kliknięciem wrzucić na prod? Poproś o pokazanie pipeline’u na żywo. Jeśli nie da się jej od razu wdrożyć, to nie jest gotowa.

2. “Chcę wprowadzić tę drobną zmianę. Za ile będzie na produkcji?”

Chodzi o czas od zgłoszenia do wdrożenia (tzw. lead time). Najlepsze zespoły wdrażają na żądanie, nawet kilka razy dziennie. Jeśli drobna zmiana ciągnie się tygodniami, to sygnał: dług techniczny, zła architektura albo zepsuty proces. A jeśli nie potrafią powiedzieć, za ile zmiana będzie na produkcji, to znaczy, że każde wdrożenie jest loterią.

3. “Pokażcie mi, co blokuje pracę i jak długo.”

W każdym projekcie coś od czasu do czasu spowalnia lub wręcz blokuje postęp prac: zależności, czekanie na decyzje, problemy techniczne. Poproś, żeby pokazali Ci aktualną listę takich blokerów. Gdzie ją trzymają, to nieważne. Ważne, czy potrafią pokazać, co stoi, od kiedy i dlaczego. Jeśli odpowiedź brzmi „nic”, drąż głębiej. „Nic nas nie blokuje” zwykle znaczy, że ktoś nie jest z Tobą transparentny.

4. “Co Was martwi w tym projekcie?”

Każdy się czymś martwi. Długiem technicznym, wymaganiami, architekturą. To pytanie nie brzmi jak oskarżenie, więc łatwiej o szczerość. Jeśli usłyszysz „nic nas nie martwi”, może akurat mają spokojny okres, ale częściej boją się powiedzieć prawdę. Słuchaj, czy mówią o prawdziwych obawach, czy zbywają Cię ogólnikami typu „no wiadomo, terminy”.

5. “Otwórzmy tablicę z ticketami.”

Chodzi o to, żeby zobaczyć te same dane co oni, w surowej formie. Jeśli się zawahają albo zaproponują wysłanie raportu później, zapytaj dlaczego. To może być uzasadniona prośba albo znak, że chcą coś ocenzurować. Pewny siebie zespół udostępni ekran bez wahania.

Pytania ujawniające ukryty dług techniczny i problemy z jakością kodu

Dług techniczny narasta i nawarstwia się stopniowo, aż w końcu staje się poważnym problemem. Dla osoby nietechnicznej jest praktycznie niewidoczny, dopóki nie zacznie spowalniać całego projektu, a koszty operacyjne wymkną się spod kontroli. Te pytania pomogą Ci określić stan techniczny projektu.

6. “Jak u Was wygląda poprawa jakości kodu? Pokażcie mi przykład.”

W zdrowym projekcie dba się o jakość: porządkuje kod, poprawia pokrycie testami, upraszcza skomplikowaną logikę. Jedni wydzielają osobny czas na refaktoryzację, inni robią to przy okazji pracy nad funkcjonalnościami. Oba podejścia działają. Ważne, żeby to się działo. Poproś o konkretny przykład z ostatniego czasu: commit, PR albo wzorzec, którego się trzymają. Jeśli nie wskażą niczego konkretnego, warto dopytać, jak radzą sobie z narastającym długiem technicznym. Programiści spędzają średnio 33% czasu na sprzątaniu po kompromisach technicznych. Kod sam się nie zoptymalizuje.

7. “Jakie macie pokrycie testami automatycznymi? Pokażcie mi.”

Testy automatyczne wyłapują błędy zanim te trafią na produkcję. Niskie pokrycie oznacza, że funkcjonalności mogą się zepsuć bez ostrzeżenia. Odpowiedni poziom pokrycia testami zależy od złożoności projektu i tolerancji na ryzyko, ale orientacyjnie: 80% i więcej to solidny wynik; poniżej 50% robi się niepokojąco. Jeśli nie pokażą Ci konkretnej liczby, to znaczy, że tego nie śledzą. A skoro nie śledzą, to pokrycie pewnie pozostawia wiele do życzenia i polegają głównie na testach manualnych. A te nie skalują się przy większym projekcie.

8. “Pokażcie mi najstarsze nienaprawione błędy.”

Błąd nienaprawiony od sześciu miesięcy jest nienaprawiony z jakiegoś powodu. Zapytaj, z jakiego. Albo błędu nie da się łatwo naprawić (zależność, złożoność, architektura), albo zespół nie ma na to czasu. Obie odpowiedzi mówią Ci coś ważnego. Zapytaj, ile innych błędów czeka w tej samej kolejce.

Pytania o kulturę zespołu i praktyki deweloperskie

Agile na pokaz, kultura obwiniania, brak zgrania w zespole, wysoka rotacja. To problemy, które nie pojawią się w raportach statusowych statusowym. A potrafią zatopić projekt równie skutecznie jak problemy techniczne. Te pytania pomogą Ci ocenić kulturę pracy w zespole.

9. “Opowiedzcie o sytuacji, gdy po retrospektywie naprawdę coś zmieniliście. Co to było i czy zmiana się utrzymała?”

Agile opiera się na ciągłym doskonaleniu procesów. Retrospektywy istnieją po to, żeby identyfikować problemy i wprowadzać zmiany. Brak konkretnego przykładu albo błaha „zmiana” to znak, że te spotkania są tylko formalnością. A jeśli zmiana się nie utrzymała? Zapytaj dlaczego. Może brakować czasu, priorytetów albo nikt nie pilnuje, żeby ustalenia trwale weszły w życie.

10. “Opowiedzcie o ostatniej poważnej wpadce. Jak zespół sobie z nią poradził?”

Słuchaj uważnie, jak opowiedzą. Będą mówić o naprawianiu procesu czy o szukaniu winnego? Badania DORA pokazują, że otwartość w mówieniu o wpadkach to cecha najlepszych zespołów. Zdrowe zespoły analizują problemy bez wskazywania palcem i skupiają się na tym, jak uniknąć powtórki. Jeśli w odpowiedzi pojawi się obwinianie kogoś, to zły znak. Karanie za błędy doprowadzi do jednego: zespół zacznie je zamiatać pod dywan.

11. “Pytanie do programistów: jaki problem biznesowy rozwiązuje ta funkcjonalność?”

Nie polegaj na zapewnieniach managera. Porozmawiaj bezpośrednio z programistami. Jeśli będą potrafili wyjaśnić problem biznesowy, który dana funkcjonalność rozwiązuje, to partnerzy: rozumieją cel i zakwestionują specyfikację, gdy nie służy temu celowi. Jeśli potrafią tylko opisać technikalia, to wykonawcy poleceń: zbudują dokładnie to, co zamówiłeś, nawet jeśli to niewłaściwa rzecz.

12. “Jaka była rotacja w zespole w ciągu ostatnich 6 miesięcy? Powiedzmy, że dołączam do projektu. Jak byście mnie wdrożyli?”

Każda osoba, która odchodzi, zabiera ze sobą część wiedzy o projekcie. Nie wierz na słowo, że „wszystko jest udokumentowane”. Poproś, żeby przeprowadzili Cię przez onboarding, jakbyś dołączał do projektu jutro. Oceń, czy proces, który Ci przedstawią, ma sens. Porozmawiaj też z najnowszą osobą w zespole o jej doświadczeniach z wdrożeniem. Jeśli potrzebowała miesięcy, żeby zacząć normalnie pracować, proces nie działa.

Pytania sprawdzające, czy dostawca dostarcza realną wartość

Aktywność to nie to samo co postęp. Zespół może pracować pełną parą i wciąż nie dowozić wartości. Te pytania pomogą Ci sprawdzić, czy wymagania są jasno zdefiniowane, czy zespół rozumie priorytety biznesowe i czy praca przekłada się na realne rezultaty.

13. “Pokażcie mi kilka user stories z backlogu. Jak wygląda u was proces ich tworzenia?”

Storki w stylu „zaimplementuj logowanie” to za mało. Programiści potrzebują jasnych wytycznych, żeby móc dostarczyć to, czego oczekuje biznes. Sprawdź, czy zadania są jasno rozpisane, czy mają kontekst, uzasadnienie biznesowe i konkretne warunki ukończenia. Jeśli tego brakuje, nikt nie pilnuje jakości backlogu. To problem z procesem, nie z dokumentacją.

14. “Otwórzmy aplikację. Wybiorę kilka rzeczy oznaczonych jako ‘zrobione’ i pokażecie mi, jak działają.”

Losowa weryfikacja szybko ujawni, jak jest naprawdę. Jeśli się zawahają albo będą próbowali wybrać, co pokazać, zapytaj dlaczego. Niektóre elementy mogą nie działać, bo zależą od innych części systemu, i to jest OK. Ale powtarzające się wahanie to zły znak. Funkcjonalności oznaczone jako „gotowe” powinny być ukończone. Jeśli nie działają, raporty statusowe nie są wiarygodne.

15. “Co byście wycięli z backlogu? I dlaczego jeszcze tego nie wycięto?”

Jeśli wskażą rzeczy o niskiej wartości, zapytaj, dlaczego wciąż są w planie. Jeśli wszystko okaże się „niezbędne”, to znaczy, że nie priorytetyzują. Zespół, który traktuje wszystkie funkcjonalności jako równie ważne, nie rozumie biznesu na tyle, żeby podejmować trudne decyzje. W rezultacie Twój budżet idzie na rzeczy, które nikomu nie są potrzebne.

Co robić, gdy odpowiedzi Cię niepokoją

Gdy reakcją na Twoje pytania są:

• puste obietnice typu “wrócę z odpowiedzią”,
• defensywność lub uniki przy prośbie o konkrety,
• sprzeczne wersje tego, co się dzieje, od managerów i programistów,
• metryki, które zawsze wyglądają dobrze albo są z jakiegoś powodu niedostępne,

to znak, że dostawca nie widzi problemu albo nie chce go widzieć. Kolejne spotkania nic tu nie zmienią. Czas przestać pytać i zacząć działać. Co możesz zrobić?

• Musisz pójść z tym do zarządu? Ten artykuł pomoże Ci przygotować się do rozmowy z zarządem o problemach w projekcie. Znajdziesz tam schemat rozmowy i wskazówki, jak nie stracić wiarygodności.
• Myślisz o zmianie dostawcy? Najpierw sprawdź, jak bardzo jesteś od niego uzależniony. Nasz przewodnik po vendor lock-in pomoże Ci to ocenić i podjąć świadomą decyzję.
• Chcesz policzyć straty? Jeśli przed podjęciem dalszych kroków potrzebujesz twardych liczb, sprawdź nasz przewodnik o tym, jak obliczyć rzeczywisty koszt długu technicznego.
• Potrzebujesz kogoś z zewnątrz? Wiesz już, że w projekcie się pali, ale nie wiesz, jak go ugasić? Niezależny audyt projektu da Ci konkretne opcje z szacunkami kosztów.

Podsumowanie

Nie musisz zadać wszystkich 15 pytań na raz. Wybierz kilka i zobacz, co się stanie. Sam fakt, że prosisz o konkret zamiast akceptować ogólniki, wpłynie na dynamikę rozmowy.

Po co to robisz? Nie żeby kogoś przyłapać na kłamstwie, tylko żeby zorientować się, co naprawdę się dzieje, zanim będzie za późno na naprawę. Dostawca, który odpowiada otwarcie i bez problemu pokazuje dane, to partner. Dostawca, który kręci, unika i tłumaczy się, że „musi przygotować raport”, sam sobie wystawia ocenę.

Na następnym spotkaniu statusowym zadaj jedno pytanie z każdej kategorii i zapisz odpowiedzi. Jeśli zobaczysz uniki albo niespójności, będziesz wiedział, że czas działać. Twoje przeczucie Cię tu przyprowadziło. Teraz masz narzędzia, żeby sprawdzić, czy miało rację.

Nie wiesz, od czego zacząć? Odezwij się do nas, pomożemy Ci ocenić sytuację.