„Ile to będzie kosztować?”, „jak długo potrwa realizacja?”, „w jakiej technologii to zrobicie?” – tak zaczyna się większość rozmów o projektach IT. I choć te pytania są naturalne z perspektywy biznesowej, często padają zbyt wcześnie. To pokazuje jak często jest pomijany kluczowy etap, który decyduje o tym jak zacząć projekt IT, aby miał szansę powodzenia.

Każda inwestycja wymaga kontroli budżetu, czasu oraz zasobów. To oczywiste, że na początku chcemy znać liczby, harmonogram i sposób działania. Problem leży w tym, że w projektach IT te kwestie często pojawiają się zanim zostanie jasno zrozumiane, co właściwie ma być rozwiązane. Wiele organizacji nie wie, jak zacząć projekt IT w sposób uporządkowany i świadomy. 

Z perspektywy zespołu GOTOMA GENERAL, będącego generalnym wykonawcą IT wyraźnie widać, że źródłem trudności rzadko są kompetencje technologiczne. Problemy zaczynają się znacznie wcześniej, już na etapie definiowania problemu. Ten z kolei często inicjują niewłaściwie postawione pytania. 

Ten artykuł nie jest krytyką. To zaproszenie do spojrzenia na projekty IT z innej perspektywy. Nie od strony technologii, kosztów i czasu, lecz problemu, który ma być rozwiązany. Bo między „chcemy aplikację”, a „wiemy jaki problem ma ona rozwiązać” istnieje zasadnicza różnica. 

Jak zacząć projekt IT i osiągnąć sukces?

To, jak zacząć projekt IT, ma bezpośredni wpływ na jego koszt, czas realizacji i końcowy efekt. Większość projektów ma podobny schemat. Klient zgłasza się z pomysłem lub potrzebą – często w bardzo ogólnej formie: 

• „chcemy mieć nową aplikację”, 

• „potrzebujemy systemu do zarządzania procesami”, 

• „chcemy zautomatyzować dział X”, 

• „interesuje nas rozwiązanie podobne, jak u konkurencji”. 

Te wstępne deklaracje często sugerują, że klient czegoś potrzebuje, ale dokładnie nie wie, jaki problem chce rozwiązać. 

Pierwsza rozmowa odbywa się zazwyczaj na szczeblu biznesowym z CEO lub inną osobą decyzyjną. Analizowane są możliwości, ograniczenia budżetowe i oczekiwania. Następnie projekt trafia do analizy technicznej, gdzie CPO lub zespół architektów weryfikuje możliwości i sposoby realizacji. Jeśli wszystko jest jasne – powstaje wycena. Zazwyczaj jednak dochodzi do iteracji spotkań, warsztatów i dodatkowych pytań, które doprecyzowują zakres potrzeb i prac. Od niedawna na tym etapie dochodzą jeszcze warsztaty UI/UX, które pomagają doprecyzować funkcjonalność, użytkowość i wygląd realizowanego projektu.  

W takim procesie przewagę daje współpraca z generalnym wykonawcą. Zamiast zlecać outsourcing zadań między agencję marketingową, software house i zewnętrznych wykonawców jeden partner jest odpowiedzialny za cały proces. GOTOMA GENERAL spina analizę, architekturę, development i integrację w jeden spójny system. Dzięki temu unikamy chaosu komunikacyjnego.  

Na tym etapie wszystko rozbija się o specyfikację – czy klient wie czego chce? Czy ma to spisane? Jeśli tak – pomaga to „ugryźć” lub omówić temat szerzej, zarówno od strony biznesowej jak i technicznej.  

Na tym etapie kluczowe jest jedno pytanie: Czy klient potrafi opisać EFEKT, który chce osiągnąć? Czy wie, czego naprawdę potrzebuje – a nie tylko, CO chciałby mieć?  

Jasna odpowiedź na takie pytanie pomaga zweryfikować, czy obie strony rozumieją projekt w ten sam sposób. Dopiero wtedy wycena i harmonogram mają realny sens. 

Pytania, które mogą spowolnić projekt i zwiększyć koszty 

Niezależnie od branży, pierwsze pytania są zwykle bardzo podobne: 

• „Ile to będzie kosztować?” 

• „Jak szybko to zrobicie?” 

• „Jakich technologii użyjecie?” 

• „Czy można to zrobić dokładnie tak, jak X?” 

Same w sobie nie są złe. Pojawiają się dlatego, że większość firm nie wie jak zacząć projekt IT. Problem pojawia się wtedy, gdy padają one zanim zdefiniujemy problem do rozwiązania. Zamiast rozumieć cel, od razu skupiamy się na technologii lub funkcjonalnościach. 

Kilka lat temu rynek przeżywał boom na aplikacje z użyciem technologii frontend takie jak Angular, React, czy Vue.js. Padały pytania: „Dlaczego React jest lepszy?”, albo: „Czemu Angular?”. Głównym tematem stawała się sama technologia – nie jej funkcjonalność i to, czy w ogóle rozwiązuje problem. 

Dziś podobny efekt obserwujemy przy AI. Firmy pytają: „Jak zacząć projekt IT wykorzystując sztuczną inteligencję?” zamiast „Jaki problem chcemy dzięki niej rozwiązać?”. 

Tymczasem technologia jest wtórna. Nowoczesne rozwiązania potrafią dziś zrealizować bardzo podobny zakres funkcjonalny. Najważniejsze jest to, czy rozwiązanie spełnia swój cel i jest uzasadnione biznesowo. 

„Czerwona lampka” zapala się w sytuacji, kiedy klient oczekuje wyłącznie wyceny lub gotowych rozwiązań, ale nie rozumie procesu.  

W wielu branżach zamawia się usługę i otrzymuje jej efekt. W IT nie działa to w tak prosty sposób. Klient biznesowy nastawiony na wyniki oczekuje efektu końcowego. Partner IT jest w jego oczach specjalistą i ma dobrać technologię, która podoła jego oczekiwaniom. Klienci bardziej techniczni analizują nie tylko formę realizacji i jej efekt, ale też użyte technologie i architekturę. Myślą nie tylko „tu i teraz” ale zwracają uwagę na skalowalność i długofalowe konsekwencje wyborów technologicznych. 

Inni klienci idą w drugą skrajność: zamiast analizować oczekują realizacji „na już, teraz lub wczoraj”. Zadowoli ich prototyp – nawet niedopracowany – ale taki, który tylko zweryfikuje ich tezę. „Jeśli się uda – poprawimy później” – tak brzmi typowa argumentacja. W praktyce rzadko się ona sprawdza.  

Stąd popularność „vibe codingu” z użyciem AI – szybkie kodowanie dające efekt „na już”. Przykład: klient przynosi na spotkanie listę „must-have” funkcji, ale nie potrafi określić, jakie problemy biznesowe mają one rozwiązać. Projekt prawdopodobnie będzie rozwijał się w chaosie. 

Dopiero podczas wstępnych rozmów lub warsztatów wychodzą na wierzch wymagania, których lista „must-have” nie spełnia. Kluczowe w tej sytuacji jest przeiterowanie wewnętrznie i powrót z sugestiami i doprecyzowaniem.  

Uparte trwanie przy swoich danych i uważanie ich za swoje „guru”, zmierza do forsowania realizacji gdzie indziej. Końcem końców winą za niedostarczenie tego, co „było w głowie, ale nie na papierze” obarczany jest software house. Rezultat? Zakres pracy rośnie, terminy się rozjeżdżają, a projekt traci wartość długoterminową. 

Pytania, które mogą być niebezpieczne dla projektu 

• „Ile kosztuje projekt?” – bez poznania zakresu prac. 

• „Dlaczego tak drogo, da się taniej?” – po poznaniu zakresu, ale bez jego rozumienia. 

• „Czy możemy użyć TEJ technologii?” – bez zdefiniowania problemu. 

• „Ile to potrwa? Dlaczego tak długo?” – bez znajomości wymagań. 

• „Czy w trakcie realizacji możemy zmieniać funkcje?” – sygnał, że nie wiemy, czego chcemy. 

• „Dlaczego wycena tyle trwa, nie możecie od razu powiedzieć, ile i na kiedy?” – często preludium do nacisku na rabaty, skrócenie terminów czy późniejszego doszukiwania się niejasności. 

Ponownie – to nie są pytania złe same w sobie. Kluczem jest kolejność i kontekst. Jeśli są pierwszym krokiem – mogą wprowadzić projekt w pułapkę presji kosztu lub terminu, co prowadzi do kompromisów w jakości i funkcjonalności. 

Świadomy klient docenia czas i koszty, jakie zespół IT poświęca na analizę i wycenę, aby uniknąć pułapek. Ten mniej doświadczony lub rozczarowany złą obsługą w innym miejscu, podważa każdy jej punkt.  

Często takie pytania są zagrywką marketingowo-sprzedażową, mające „wymusić” rabaty, niższe koszty, szybszą realizację, kosztem jakości. Takie projekty w większości są oceniane po cenie i prędkości, nie po jakości czy doborze technologii. 

Co sugerują partnerowi IT takie „niebezpieczne” pytania stawiane na starcie? Przede wszystkim perspektywę klienta: czy szuka rozwiązania problemu, czy gotowego produktu? Mogą też sugerować brak doświadczenia w projektach IT, presję budżetową lub po prostu złe wspomnienia z poprzednich projektów. 

Choć na pierwszy rzut oka taka sytuacja wydaje się problematyczna, dla partnera IT może to być nawet wręcz okazja, aby wykazać się odpowiednim podejściem do klienta. Sygnały z takich pytań pozwolą dostosować rozmowę z klientem – od „złych pytań” do tych, które prowadzą projekt do sukcesu.  

Skąd biorą się projekty, które kosztują więcej i trwają dłużej niż zakładano? 

Nie wynikają one ze złej woli. Najczęściej są efektem: 

• Braku doświadczenia w projektach IT, 

• Skupienia się na efekcie, a nie na problemie, 

• Presji budżetowej, 

• Wpływu wcześniejszych doświadczeń, np. outsorcing w branżach, gdzie gotowe rozwiązania są dostarczane błyskawicznie. 

To, że większość projektów zaczyna się od powierzchownych pytań, to nic szczególnego – to wręcz powszechna praktyka. Z reguły klient nie wie, że IT to nie usługa „na gotowo”, a wieloetapowy proces. 

Projekty IT kierują się w głównej mierze jedną doktryną: zrozumienie tematu > realizacja. Bez zrozumienia sedna problemu, cała realizacja będzie źle przebiegać. Przy ogólnych założeniach, technicznie projekt może zostać „dowieziony”. Kod działa, funkcje są dostępne, a interfejs wygląda przejrzyście i nowocześnie. Problem tkwi w tym, że bez głębokiego zrozumienia kontekstu biznesowego, nawet poprawnie zrealizowany system może nie rozwiązywać realnego problemu firmy. 

W wielu branżach usługa oznacza szybkie dostarczenie gotowego rozwiązania. W IT jednak rezultat projektu jest efektem analizy, warsztatów, iteracji i wielu decyzji strategicznych.  

Jak złe pytania zjadają budżet i zaufanie do partnera IT? 

Źle postawione pytania na starcie generują realne konsekwencje w całym projekcie. CEO i managerowie mogą je rozpoznać po kilku sygnałach ostrzegawczych, które wprost sugerują, że projekt idzie w złą stronę. Najczęstsze symptomy to: 

• Rosnąca liczba change requestów – funkcje są ciągle zmieniane lub dodawane, bo ich pierwotny zakres nie był jasno zdefiniowany. 

• Ciągłe doprecyzowanie zakresu – coraz więcej czasu zajmuje ustalanie „co klient miał na myśli” zamiast sama realizacja. 

• Spory między działami – różne sekcje mają różne oczekiwania, wobec tego samego projektu, co spowalnia wdrożenie. 

• Przesuwanie wdrożeń i terminów – ciągłe poprawki i niedopracowania generują kolejne opóźnienia. 

Rozpoznanie tych symptomów na wczesnym etapie pozwala szybko wdrożyć mechanizmy kontrolne i zapobiec eskalacji kosztów i frustracji zespołu. 

Niezrozumienie problemu prowadzi do błędnych założeń projektowych. W trakcie realizacji pojawiają się nowe wymagania, które nie zostały uwzględnione na etapie analizy. To z kolei przenosi się na harmonogram – pojawiają się opóźnienia i przesunięcia w czasie. 

Wszystkie takie nieporozumienia i niedopowiedzenia oraz ich konsekwencje prowadzą do napięcia w relacji między partnerem IT a klientem – po obu stronach pojawia się frustracja i konflikt interesów. 

Często problem wynika z bariery komunikacyjnej między światem biznesu a technologią lub po prostu brakiem znajomości branży. Osoba kontaktowa ze strony klienta nie zawsze jest techniczna.  

Wyobraźmy sobie sytuację: klient dostarcza plik do implementacji i akceptuje wycenę. Projekt zakłada kilka godzin pracy. Po wdrożeniu ze strony klienta dołącza do projektu nowa osoba – zaznajomiona technicznie. Analizuje wdrożenie i jak się okazuje, dostarczony pierwotnie plik to tylko przykład, a nie gotowe rozwiązanie! Oczekiwania klienta obejmowały znacznie szerszy zakres funkcji. Po doprecyzowaniu z kilku godzin pracy robi się kilkadziesiąt, a projekt zawiesza się w czasie nawet na kilka miesięcy. 

To typowa sytuacja, w której nikt nie miał złych intencji. Po prostu osoba kontaktowa nie była techniczna – nie znała żargonu, nie zadała właściwych pytań na starcie. To właśnie takie bariery komunikacyjne generują większość napięć w projektach IT. 

W GOTOMA managerowie wywodzą się ze środowiska programistów. Dzięki temu potrafią tłumaczyć język technologii na język biznesu – i odwrotnie. W ten sposób można niwelować chaos komunikacyjny, zabezpieczać budżet oraz harmonogram, a przede wszystkim budować partnerskie relacje B2B. 

Jak zacząć projekt IT – jakie pytania zadać na początku?

Jak zacząć projekt IT od dobrych pytań? Zamiast zaczynać od ceny, czy nawet technologii, kluczowe jest, aby jako pierwsze omówić biznesowe zastosowanie realizacji projektu. Dlatego najpierw należy postawić na diagnozę: 

• Jaki problem biznesowy chcemy rozwiązać? 

• Jakie cele chcemy osiągnąć w perspektywie 6-12 miesięcy? 

• Kto będzie korzystał z systemu i jakie są ich potrzeby? 

To ostatnie pytanie jest szczególnie ważne. Praktyka pokazuje, że różne działy mają zupełnie inne priorytety i kompletnie inaczej rozumieją ten sam projekt. Marketing patrzy przez pryzmat KPI sprzedaży, IT przez stabilność i bezpieczeństwo, a BOK przez funkcjonalność i wygodę w codziennej obsłudze klienta.  

Zdarza się też, że sprzedawcy, marketing czy kadra zarządzająca zupełnie inaczej rozumie funkcjonalności albo nie bierze pod uwagę wielu parametrów, które są ważne dla innych działów.  

Jeśli tych perspektyw nie zderzymy ze sobą na początku, zderzą się one w trakcie realizacji – z różnym skutkiem. W tej sytuacji nieoceniona jest rola generalnego wykonawcy. Potrafi on wyciągnąć wnioski z różnych potrzeb poszczególnych ludzi i spiąć je jednym rozwiązaniem. Pozwala to na znaczną redukcję ryzyka „rozjechania się” oczekiwań między działami. 

Warto na uwadze mieć też to, że obecnie technologia jest wtórna, a wiele rozwiązań da się dziś zbudować podobnym kosztem. Kluczowe jest biznesowe zrozumienie zakresu, zastosowania i efektu. Bez tego plan działania i wycena będą nietrafione, a realizacja chaotyczna. 

Fundamentalne pytanie na tym etapie brzmi: „Co się stanie, jeśli nic nie zmienimy?”. Jeśli odpowiedź brzmi „nic istotnego” – projekt prawdopodobnie jest zbędny. Jeśli jednak brak zmiany oznacza utratę klientów, wzrost kosztów lub spadek efektywności – mamy realny, biznesowy powód do działania. Jeżeli projekt jest przemyślany – bez zająknięcia można odpowiedzieć, dlaczego i po co jest potrzebny oraz jaką konkretną wartość przyniesie.  

Niewygodne pytania, które ratują projekt przed kosztownymi błędami 

Partner IT musi mieć świadomość, że nie każdy klient patrzy na projekt i problem technologiczny tak, jak zespół techniczny. My mamy doświadczenie, specjalistyczną wiedzę i sprzęt – klient niekoniecznie. 

Dlatego kluczowe jest, aby na wielu etapach pracy nad projektem nie przyjmować roli sędziego, ale prowadzić klienta jak przewodnik i wspierać w wyborach jako ekspert. Odpowiedzialny partner IT powinien potrafić powiedzieć: „Zatrzymajmy się. Czy na pewno rozwiązujemy właściwy problem?”. 

Tu pojawia się moment, w którym partner IT przejmuje inicjatywę. Jako ekspert w branży wie, jak zacząć projekt IT dobrze i kiedy oraz jakie pytanie postawić. Może okazać się jednak, że nasze pytanie będzie dla klienta niewygodne.  

„Właściwe” pytania potrafią ujawniać luki w procesach, trudne i nieprzemyślane decyzje strategiczne, obejścia systemowe, pewne pójścia na skróty, wewnętrzne konflikty i brak spójnej strategii. O wielu z tych kwestii osoby zarządzające mogą nie być świadome.  

Dlatego należy do „niewygodnych pytań” podchodzić z pewnym wyczuciem. Dla niektórych zadanie takowych na forum może być niekomfortowe. Mija się to także z naszym celem – odpowiedź będzie wymijająca albo nieprawdziwa. Nic się nie dowiemy i źle podejdziemy przez to do projektu. Z naszego doświadczenia – klient niejednokrotnie docenia pytania, które pomagają znaleźć głębsze źródło problemu. 

Co zmienia się, gdy wiesz jak zacząć projekt IT? 

Z perspektywy partnera IT nie ma nic lepszego od dobrze napisanej specyfikacji, jasnych założeń i wspólnego zrozumienia projektu. Proces staje się wtedy przewidywalny, zakres klarowny, a oczekiwania realistyczne. Projekty wymagają mniej korekt i są lepiej dopasowane do rzeczywistych potrzeb. Fundamentem sukcesu zawsze jest dobrze napisana specyfikacja i wspólne zrozumienie celu. 

To właśnie solidna faza diagnozy gwarantuje przewidywalność budżetu. Gdy pytania są zadane poprawnie i w odpowiednim momencie, unikamy ukrytych kosztów, które często wypływają w trakcie projektu. Właściwą fazę diagnozy zapewnia generalny wykonawca – który na każdy etap procesu patrzy holistycznie i czuwa nad każdym krokiem. 

Nie ma jednak uniwersalnego podejścia czy przepisu na idealny projekt. Każdy klient jest inny i nawet po kilkunastu latach działania na rynku trudno znaleźć dwa identyczne przypadki. Często trzeba zatem lawirować. Domyślać się, co klient ma w głowie.  

Wiele projektów zaczyna się od podejścia: „mam pomysł, czy się da i za ile?”. Potem dochodzi cała otoczka: warsztaty, dopytywanie, konsens i nadzieja na to, że efekt końcowy się sprawdzi. W wielu przypadkach udaje się trafić, czasami jednak klient w końcu mówi „Nie o to mi chodziło, ale teraz już wiem, czego chcę”. To też pozytywny efekt – pomogliśmy klientowi zrozumieć problem. 

Choć pytania o koszt, termin czy technologię są naturalne, nabierają sensu dopiero wtedy, gdy wiemy, jaki problem rozwiązujemy. 

Jak zacząć projekt IT dobrze? Zrozumieć cel. Doświadczenie uczy zatem jednego i pozostanie to niezmienne: im więcej czasu poświęcimy na zrozumienie problemu, tym mniej czasu stracimy na jego naprawianie, a szansa na sukces rośnie.

Jeśli stoisz przed strategiczną decyzją o wdrożeniu systemu IT lub cyfryzacji kluczowego procesu, zacznijmy od 60-90 minut warsztatu „złych pytań”, po którym dostaniesz: 

• Szczerą weryfikację biznesową – dowiesz się, czy Twój pomysł rozwiązuje realny problem (oddzielisz „chcę” od „potrzebuję”). 

• Mapę zagrożeń – zidentyfikujesz ryzyka i ukryte koszty. 

• Jasny plan startu – zarys specyfikacji, który pozwoli Ci uzyskać porównanie cenowe. 

Zaryzykujesz budżetem całego projektu, czy godziną merytorycznej rozmowy? Skontaktuj się z nami, aby umówić termin.