Cześć, dzień dobry, z tej strony Grzegorz Tabor, a to jest podcast IT i Biznes, gdzie jako dyrektor technologiczny pomagam przedsiębiorcom i menadżerom realizować projekty IT, które wspierają cele biznesowe skutecznie i w terminie. Jeśli napotykasz na swojej drodze wyzwania i potrzeby wsparcia twojego biznesu świadomie z użyciem technologii, ten podcast jest dla ciebie. Odcinek 62.

Co może pójść nie tak w realizacji projektu IT? 

Każdy z nas chciałby wierzyć, że dobra analiza i szczegółowa specyfikacja na starcie prac wystarczą, aby projekt przebiegł idealnie. Ale pytanie, czy da się zaplanować wszystko w 100%? Uważam, że w 100% się nie da. I w tym odcinku opowiadam o tym, dlaczego nawet najlepiej przygotowany projekt może się wysypać i co zrobić, żeby zminimalizować ryzyko kosztownych zmian na późniejszych etapach.

A na koniec mam dla ciebie praktyczną wskazówkę, która może uratować twój projekt przed niepotrzebnymi przeróbkami. Także jeśli nie chcesz dowiadywać się o problemach, gdy projekt jest już w połowie drogi, to ten odcinek jest z pewnością dla ciebie. I tym samym serdecznie zapraszam do części głównej.

Cześć, dzień dobry. Prowadząc projekty od lat ciągle analizujemy nasze podejście i modyfikujemy je tak, aby na każdym etapie minimalizować ryzyko. Powiedzmy ryzyko, że coś pójdzie nie tak, że pojawią się niedopowiedzenia, że w specyfikacji zabraknie istotnych elementów, albo że klient zmieni wymagania chwilę po ich wcześniejszej akceptacji i rozpoczęciu prac nad jakimś projektem.

I tu rodzi się pytanie, czy da się takie ryzyko zminimalizować do zera? 

Czy da się wszystko zaplanować?

Czy można zaplanować projekt tak, żeby absolutnie nic się w nim nie zmieniło i żeby przebiegał jeden do jednego zgodnie z tym, co zostało zaprojektowane na papierze? Moim zdaniem nie da się. Zawsze pojawią się nowe rzeczy, nowe przemyślenia, bo im więcej widzimy namacalnych efektów, coś, co można przeklikać, coś, co można sprawdzić, i przede wszystkim im więcej światła rzucamy na te różne nowe wątki i zaczynamy wchodzić w nie bardziej szczegółowo na etapie realizacji projektu, tym więcej zauważamy braków, nowych możliwości, rzeczy do poprawy, czy też funkcji, o których wcześniej zwyczajnie nie myśleliśmy. I nie mówię tutaj o zwykłych detalach takich designerskich, typu przestawiania jakiegoś przycisku, wdrażania jakiejś drobnej rzeczy wizualnej, natomiast bardziej o takich rzeczach, które są ewidentnie czymś, co powinno działać zupełnie inaczej, czy jest jakimś elementem brakującym, albo o czymś, co zupełnie nie spełni oczekiwań użytkowników końcowych, chociaż wcześniej wydawało się na etapie planowania całego projektu, na etapie rozpisywania specyfikacji czymś super.

Super, po prostu. I teraz, jak zminimalizować takie ryzyko i sprawić, żeby tych niespodzianek było jak najmniej, albo w idealnym świecie, żeby ich nie było w ogóle. 

Jak zminimalizować ryzyko już na starcie?

Dzisiaj opowiem Wam o takim case, który stał się dla nas inspiracją do wprowadzania dodatkowego kroku w naszym procesie projektowym i takiego kroku, który pozwala nam i też klientowi na wcześniejszym znacznie etapie, niż dopiero weryfikacji wykonania danego etapu projektu, pozwala nam doprecyzować wymagania i potwierdzić, co można zrobić lepiej.

Zanim przejdę do konkretów, to chciałbym tylko jeszcze powiedzieć, że jeśli słuchasz podcastu IT i biznes i jeszcze nie subskrybujesz, to właśnie teraz jest dobry moment, żeby to zrobić. I dzięki temu nie przegapisz kolejnych odcinków, gdzie będziemy dalej dzielić praktycznymi wskazówkami dla biznesu i technologii. I wracając do odcinka.

To teraz chciałbym Wam przybliżyć właśnie sytuację, która dała nam mocno do myślenia i sprawiła, że wprowadziliśmy pewną ważną zmianę w naszym procesie projektowym. I pojawił się u nas klient, przesłał nam założenia, przesłał specyfikacje, był gotowy do rozpoczęcia współpracy i poprosił o wycenę. Kiedy zaczęliśmy drążyć, bo bardzo często tak robimy, że nie od razu wyceniamy projekt, tylko bardziej staramy się zrozumieć, co klient chce rozwiązać poprzez tą właśnie realizację projektu.

Okazało się, że klient ma już jakąś aplikację, ale ona jest niedokończona, chociaż częściowo działa. Obok niej są jeszcze inne aplikacje, które jeszcze nie działają w firmie. Ale co najważniejsze, klient ma też trudności w zdobyciu kodu źródłowego.

Pojawiły się problemy z prawami autorskimi. Pojawiły się różnego rodzaju inne trudności. I skracając, klient zdecydował się zbudować aplikację od podstaw.

I teraz na podstawie tych poprzednich doświadczeń przygotował też specyfikację. 

Wizja lokalna zmienia wszystko

I my mimo tego, że otrzymaliśmy taką specyfikację, wybraliśmy się do klienta na wizję lokalną. Czyli właśnie na taki nasz stały proces współpracy, gdzie staramy się jeszcze lepiej zapoznać z organizacją, zapoznać z biznesem klienta, po to, żeby móc jeszcze lepiej doradzić na początku i w ogóle właśnie jak najlepiej zaplanować projekt.

Specyfikacja to nie wszystko

I teraz okazało się, że kiedy pojawiliśmy się u klienta i spojrzeliśmy na świeżo na te jego procesy, na te jego potrzeby, na to, na co tak realnie narzeka, na to, co tak realnie nie zagrało w tych poprzednich aplikacjach, okazało się, że ta specyfikacja to był tak 1 do 1 spis funkcjonalności, które były w tej starej aplikacji, który nie do końca uwzględniał wszystkie wnioski, te takie realne bóle, które klient miał, doświadczał na etapie ich budowy tych poprzednich aplikacji. Więc dzięki temu spojrzeniu na świeżo, dzięki temu, że na żywo poświęciliśmy sobie wzajemnie czas, udało nam się wiele rzeczy rozplanować, rozpisać i już tutaj się zgodzić. I teraz to był etap planowania projektu.

Gdybyśmy w ogóle na etapie planowania samego projektu działali schematycznie, to wystarczyłoby nam wziąć te specyfikacje od klienta, pewnie odpowiedzieć na kilka dodatkowych pytań typu, czy mamy doświadczenie z jakąś konkretną technologią, dopytać być może z jakimi systemami, jeszcze musimy się zintegrować i tak naprawdę moglibyśmy ruszać z developmentem, co często w branży właśnie tak wygląda. Ale mając za sobą kilkadziesiąt projektów i masę doświadczeń z nich wynikających, wiemy na pewno, że to co klient przynosi w zapytaniu, bardzo często nie w 100% rozwiązuje jego taki realny problem, który próbuje rozwiązać właśnie daną aplikacją czy rozwiązaniem. A nawet jeśli rozwiązuje, to bardzo często tylko jakąś nikłą część tego problemu.

Bo często jest tak, że klientowi bardzo trudno jest samemu wejść w szczegóły tego, co tak naprawdę potrzebuje, jeszcze to spisać i dobrze przedstawić, tak żeby druga strona zrozumiała to, patrząc z tej samej perspektywy co klient. 

Kluczowe pytanie: po co Ci ten system?

I dlatego u nas standardem jest to, że zawsze pytamy, po co ci ten system? Co chcesz osiągnąć poprzez jego wdrożenie? Bardzo mocno pogłębiamy ten temat. Rozmawiamy nie tylko z osobą, która się do nas zgłasza, ale też staramy się porozmawiać z zarządem, z użytkownikami końcowymi, bo to oni na co dzień będą z tym systemem danym pracować.

I teraz to jest mega ważne, że to wizja lokalna się odbywa. To jest jeden z etapów tej minimalizacji ryzyka, czyli tego, żeby się nie okazało, że potem będziemy z klientem się przerzucać odpowiedzialnością na temat tego, czy problem był na etapie specyfikacji, którą klient przesłał, czy na etapie tego, że my jej być może zbyt dobrze nie przeanalizowaliśmy. Bo to do tego najczęściej dochodzi w przypadku współpracy danego klienta, biznesu kontra też software house'u, dosłownie kontra, a nie ze software house'em.

I teraz, kiedy już zobaczymy na żywo, jak to wszystko wygląda, poznamy lepiej się w ogóle sam model działania firmy, poznamy się lepiej z zespołem klienta, z którym być może będziemy mieli okazję też współpracować, to często jest tak, że na etapie realizacji projektu jeszcze nadal pogłębiamy różne rzeczy. 

Gdzie powstają błędy i jak ich unikamy?

I czasem to jest tak, że klient ma poczucie, że to momentami mógłby być przerost formy nad treścią, ale jednak, kiedy pojawi się taka sytuacja, że zauważymy jakąś taką nawet drobną rzecz, to często może się okazać, że brak tej jakiejś jednej drobnej, konkretnej rzeczy, która wyniknęła niestety dopiero na etapie realizacji projektu, bardzo często wpływa na całą lub znaczną część, na przykład architektury systemu. I czasem to są takie niby drobnostki, ale w IT często drobnostki potrafią zmienić bardzo duży obszar prac, który trzeba potem tak zwanie refaktoryzować, czy w tym wypadku nawet zmieniać.

I generalnie jest tak, że pominięcie tego typu rzeczy na etapie analizy jest no niestety kwestią, która może się zdarzyć każdemu, może wynikać z przeróżnych rzeczy. Natomiast ta wizja lokalna to jest jeden z procesów, który mamy u siebie na etapie startu projektu, żeby tutaj jak najwięcej rzeczy właśnie tego typu wyłapać. I teraz idąc dalej, jeżeli te projekty są mocno przemyślane, powinno nie być już żadnych niespodzianek problemu, bo przecież bardzo dużo czasu i uwagi poświęcamy na poznanie firmy, poznanie, dobór rozwiązań też i w ogóle przejście przez wszystkie procesy.

Więc co może pójść nie tak w realizacji projektu IT? I teraz jedna kwestia wizja lokalna, to mamy omówione. Druga kwestia to jest tak, że z klientem może być tak samo jak z nami, to znaczy to my możemy mu wysłać po wizji lokalnej piękną specyfikację, rozpisane funkcjonalności, opowiedzieć też na spotkaniu, co i jak będzie wyglądało. I na tym etapie wysokopoziomowym klient potwierdza, kiwa głową, bardzo często nam mówi, że to rozumie, że jak najbardziej się z tym zgadza, że tak będzie okej.

Papier przyjmie wszystko. A prototyp?

Natomiast dopiero kiedy oddajemy jakąś część projektu, coś namacalnego, coś, co już można zobaczyć, przeklikać, to wtedy nagle pojawiają się nowe refleksje, że jeszcze wypadałoby zrobić to, a jeszcze nie pomyśleliśmy o tym, a może jeszcze uwzględnimy taki i taki proces działający w naszej organizacji. Albo nagle okazują się rzeczy, z których klient sam sobie nawet nie zdawał sprawy. I teraz papier jest w pewnym sensie najlepszą specyfikacją, ale koniec końców on nie daje klientowi tego samego obrazu co pewien prototyp, makieta, działający element systemu.

Więc akceptacja zakresów prac na sucho bardzo często może się okazać, że to będzie za mało versus jakieś trudne procesy, które są oprogramowywane. Więc my zalecamy to, żeby realizować też wszelkiego rodzaju wizualizacje, klikalne elementy, coś co jak najbardziej pozwoli klientowi poczuć system zanim on powstanie, ale zanim właśnie on powstanie, to znaczy zrobić taki tzw. proof of concept w pewnym sensie systemu, natomiast jak najniższym kosztem po to, żeby klient mógł ocenić, czy to o to tutaj chodzi.

I teraz tutaj nie możemy pomijać perspektywy klienta na to, co on chce finalnie otrzymać, bo gdybyśmy tak zrobili, no to kompletnie byłoby to bez sensu i kłóciłoby się z tym, dlaczego realizuje się projekt IT, bo tak tutaj uważamy. No i tak samo, kiedy my prosimy klienta o pewną wizualizację, o rozrysowanie czegoś czy pokazanie, i to bardzo często robimy na wizji lokalnej, wspólnie z klientem pewne rzeczy mapujemy właśnie po to, żeby poczuć ten biznes i jak najbardziej móc się jak najlepiej wcielić w te role i w te odpowiedzialności naszego klienta. I teraz zastanawialiśmy się nad tym, jak to zrobić, żeby z jednej strony unikać rozjazdów między tym, co planujemy wysokopoziomowo, a tym, co potem wychodzi na etapie realizacji pojedynczych, drobnych etapów, tak żeby tutaj tych rozbieżności było jak najmniej, albo w idealnym świecie, żeby ich w ogóle nie było.

Jak wygląda nasz proces planowania i weryfikacji?

I wprowadziliśmy jeszcze dwie dodatkowe rzeczy, które są tutaj super istotne. Po pierwsze, jeżeli to są rzeczy, które są super ważne, jeżeli chodzi o wygląd, to staramy się je też warsztatować pod kątem tzw. UX i UI, czyli po prostu zmapować sobie taki proces, ale już wizualnie pokazać to klientowi, jak to będzie wyglądać i wynikiem takich warsztatów jest prototyp właśnie takiego rozwiązania klikalne dostępne np.

w Figmie, czyli jednym z takich dość popularnych rozwiązań, co powoduje, że jeżeli przekażemy klientowi taki prototyp działający, czyli klikalny, to to już pozwala klientowi poczuć, jak ten system będzie działał. Oczywiście on jeszcze nie ma żadnych konkretnych danych, on jeszcze nie działa na zasadzie, nie wiem, połączenia z jakąś bazą danych itd., natomiast jest bardzo szybki do wytworzenia i od ręki pokazuje, jak to wizualnie będzie działać. Natomiast często jest tak, że jak robimy ten warsztat, to okazuje się, że ten nawet proces, którym rozmawialiśmy z klientem, jednak wygląda trochę inaczej, bo jak go zaczynamy rozbierać na czynniki pierwsze i wchodzić jeszcze głębiej niż podczas takiej analizy wysokopoziomowej, no to okazuje się, że tam jeszcze są rzeczy istotne, o których klient podczas jednego czy dwóch warsztatów nie był w stanie nam też opowiedzieć, a my też nie dopytaliśmy, bo po prostu nawet nie mieliśmy tego świadomości.

I teraz to, co jest ważne, to druga rzecz, którą wdrożyliśmy, to są takie minisesje analityczne, które pozwalają nam jeszcze głębiej wejść, ale w konkretny obszar. I realizujemy to najczęściej w takich miejscach, które są super krytyczne, to znaczy wiemy, że tam na pewno może wyniknąć jeszcze coś więcej niż to, co wyglądało wysokopoziomowo, wiemy, że to jest jakiś bardziej skomplikowany proces, który zbiera dane z różnych miejsc, przy którym trzeba jeszcze więcej rzeczy przewidzieć i tym samym dużo trudniej jest to przewidzieć, widząc tylko opis specyfikacji. Więc mając taki większy temat, na przykład nowy moduł czy jakąś skomplikowaną integrację, staramy się go nie zostawiać tylko na poziomie specyfikacji, ale robimy sobie jeszcze właśnie takie spotkanie warsztatowe, ale nie UX-owo, UI-owe, tylko takie bardziej analityczne, na podstawie którego rozrysowujemy cały proces na Miro od startu, od etapu początkowego aż po efekt końcowy i co najważniejsze, podejmujemy wspólnie z klientem decyzję na bazie tej wizualizacji, a nie wyobrażeń.

I teraz średnio taki warsztat trwa około 2 godziny per proces obszar, ale to nam daje gigantyczną oszczędność na etapie developmentu, bo i my i klient jesteśmy jeszcze bardziej pewni tego, co powinniśmy zrobić, bo jeśli coś miałoby się wysypać, to bardzo często wysypie się na etapie właśnie tej koncepcji, czy na etapie tego rozrysowywania na Miro, a nie dopiero wtedy, gdy mamy już gotowy system w jakimś już na przykład momencie wdrożenia czy odbiorów po stronie klienta i dopiero wtedy pojawia się jakiś błąd. 

Czy da się zrobić projekt bez zmian?

I teraz przechodząc już bliżej podsumowania, czy da się zaplanować projekt tak, żeby wszystko było idealnie, nic się nie zmieniło? Uważam, że niestety nie, ale na pewno da się te zmiany ograniczyć i sprawić, żeby projekty były bardziej przewidywalne, mniej kosztowne i szybsze w realizacji poprzez taką właśnie kilkuetapową weryfikację, że na pewno dobrze się rozumiemy. Kluczem jest nie tylko ta nasza analiza, ale też oddanie klientowi realnej wizji rozwiązania, zanim zaczniemy programować.

Prototyp i sesje analityczne jako gamechanger?

Czyli te sesje analityczne, wizualizacja procesów na Miro i warsztaty UX-owo, UI-owe, to jest nasz sposób na to, żeby minimalizować ryzyka i wspólnie podejmować decyzję na czymś, co realnie jesteśmy w stanie zobaczyć i co zbliża nas do tej wspólnej perspektywy patrzenia na dany problem biznesowy. I wiecie co? Uważam, że to naprawdę działa, bo to daje spokój obu stronom, a projekty dzięki temu są po prostu lepsze i mniej kosztowne zarazem, bo poprawianie błędów na etapie developmentu, kiedy tam został popełniony jakiś błąd architektoniczny, jest zwyczajnie drogie. Jeśli chcesz, żeby Twój projekt był poprowadzony w taki sposób, żebyś miał bądź miała realny wpływ na kształt rozwiązania już na etapie planowania, ale też na etapie realizacji, aby projekt był dostosowany do Twoich realiów biznesowych, to zapraszam Cię na bezpłatną konsultację.

Porozmawiamy wtedy o Twoim wyzwaniu IT i pokażemy Ci, jak taki proces od A do Z wyglądałby u nas w praktyce. Jeżeli chodzi o dzisiejszy odcinek, bardzo dziękuję za jego przesłuchanie. 

Na zakończenie: planuj mądrze i etapowo

Pamiętajcie, że mimo tego, że nie da się wszystkiego zaplanować, to oczywiście trzeba planować, żeby jednak jak najwięcej ryzyk przewidzieć.

Dzięki raz jeszcze i do usłyszenia za tydzień. Cześć.