Dlaczego specyfikacje z ChatGPT nie pomagają w wycenie

Masz pomysł na system albo aplikację. Zastanawiasz się, czy da się ją zrobić. Czy będzie to trudne? Ile to może kosztować? I ile to może zająć czasu? Do tych rozważań możesz oczywiście wykorzystać czata GPT i na wstępnym etapie pewnie tak zrobisz.

Natomiast nadejdzie taki moment, że zaczniesz szukać firmy, która wyceni projekt, podpowie jak go zrobić, podpowie jakiej technologii użyć, a docelowo także ten projekt wykona. Pierwsze pytanie, jakie usłyszysz, kiedy zadzwonisz do takiej firmy, czyli zadzwonisz do Software House'u, to czy ma Pan już specyfikację tego projektu? I usłyszysz tak jeden, drugi, trzeci, piąty raz.

No i wówczas będziesz miał poczucie, że to pewnie standard tej branży, więc jako osoba nietechniczna próbujesz ten standard nadgonić, żeby uzyskać wycenę.

W jaki sposób? Najszybciej będzie oczywiście z użyciem czata GPT. Podajesz kilka istotnych informacji i na koniec powstaje Ci specyfikacja na 50 stron, którą z Software House nie uwierzysz, podsumujesz z wykorzystaniem sztucznej inteligencji, aby w miarę sprawnie przebrnąć przez etap najważniejszych założeń i móc podać wstępną wycenę.

Najczęstszy błąd: opsujemy system zamiast problemu

Zacznijmy od tego, że stworzenie specyfikacji na początku projektu jest po prostu trudne. Największy problem polega na tym, że na tym etapie jeszcze nie wiemy dokładnie tak naprawdę czego chcemy. Mamy wizje, mamy potrzeby. Czasem mamy już nawet listę funkcjonalności w głowie, ale brakuje nam pełnego obrazu systemu jako całości.

Z drugiej strony Software House, żeby w ogóle wycenić projekt i zrobić to dobrze, potrzebuje opisu funkcjonalności i to z dużą dokładnością. Ogólna zasada mówi, że im mniej szczegółów zostanie podane na tym etapie, tym bardziej ogólna wycena będzie i tym bardziej odbiegająca od finalnych, rzeczywistych kosztów.

Idąc z duchem czasu, korzystając z dostępnych narzędzi, próbujemy spełnić ten wymóg. Chcemy poznać realny koszt, więc generujemy specyfikację z pomocą AI na bazie naszych przeróżnych myśli i oczekiwań, co prowadzi do tego, że wychodzi nam dokument na 50 stron, który w praktyce powstaje na podstawie kilku ogólnych zdań.

Efekt jest taki, że mamy masę tekstu, a nadal nie ma jasności, co właściwie chcemy zbudować i przede wszystkim dlaczego.

Czyli nie ma szczegółów o naszym problemie i oczekiwaniach, tylko bardzo szybko przechodzimy do etapu funkcjonalności, no bo o to właśnie nasz software house'y pytają, czyli co my chcemy zrobić w tej aplikacji i tego, jak system miałby działać.

Najważniejsza zasada budowania specyfikacji

Jeśli miałbym dać jedną najważniejszą zasadę, to brzmi ona tak. Na początku nie opisujemy szczegółowych ekranów, przycisków, ani zachowań systemu. Opisujemy natomiast, co ma się zmienić w firmie po wdrożeniu, czyli:

• generowałaś / generowałeś specyfikację projektu w ChatGPT,
• jaki problem ma rozwiązać system,
• gdzie dziś nas najbardziej boli w naszej organizacji,
• jaki ma być efekt końcowy,
• jaka jest wizja końca, którą uznamy za sukces.

I to jest już pierwszy punkt, gdzie mijamy się w komunikacji, która w projektach IT jest ogromnie istotna. Jeżeli software house nie spojrzy na nasz problem w pewnym sensie naszymi oczami, to naprawdę może zbudować coś, co kompletnie nie będzie pasowało do naszej firmy, a takie rozwiązania są najdroższymi i najgorszymi zarazem. Czyli na początek warto skupić się na tym, żeby jak najlepiej opisać swoją sytuację i swój problem, jednak dopiero do tego zbudować specyfikację, przy czym ja gorąco zachęcam do tego, aby zbudować ją we współpracy z software housem, czyli niekoniecznie w 100% tak samemu i za chwilę powiem o tym dlaczego.

Jak myśleć o ChatGPT w projektach IT (role i perspektywy)

Wracając na chwilę do czata GPT. Warto traktować go tak samo, czy w pewnym sensie tak samo jak specjalistów, z którymi będziesz docelowo współpracował. W realnych projektach IT rzadko jest tak, że jedna osoba zajmuje się wszystkim naraz.

Zazwyczaj mamy:

• kogoś kto patrzy na temat od strony biznesowej, czyli analityka biznesowego,
• kogoś kto myśli o rozwiązaniu od strony technicznej i jakich rozwiązań użyć,
• kogoś kto dba o to, żeby system był wygodny w użyciu, czyli dba o tzw. user experience

Każda z tych osób zadaje inne pytania i skupia się na zupełnie innych aspektach problemu, jaki mamy rozwiązać daną aplikacją. I dokładnie tak samo działa czat GPT.

Jeśli próbujesz, żeby jednocześnie analizował problemy biznesowe, projektował rozwiązania techniczne i zastanawiał się nad użytecznością, to bardzo łatwo jest mu się pogubić i przejść do tzw. halucynacji. Dlatego zamiast próbować robić wszystko naraz, warto rozdzielić te sposoby myślenia.

Krok 1: mapowanie procesów i realnych potrzeb firmy

Krok pierwszy to mapowanie potrzeb, czyli w ogóle zanim zaczniemy mówić o systemie, o tych funkcjonalnościach, możemy wykorzystać ChataGPT do wsparcia na w pogłębieniu i wydobycia naszego dlaczego, w jaki sposób czat może nam zadawać pytania i też później pytania pomocnicze.

Z takich głównych pytań, jakie czat może nam zadać, to:

• jak działa firma
• jak działają procesy,
• gdzie są problemy,
• gdzie są ręczne działania,
• gdzie bazujemy na Excelach,
• gdzie giną kluczowe informacje,
• co spowalnia ludzi, dlaczego chcemy takie rozwiązanie, a nie inne,
• jakich innych rozwiązań już próbowaliśmy.

Generalnie pytań, które warto sobie zadać, żeby złapać taką samoświadomość i to odpowiedź na to główne pytanie dlaczego, jest mnóstwo. Jeśli użyjemy dobrego prompta, to czat GPT działa świetnie, bo pomaga dobyć z nas rzeczy, których normalnie byś nie opisał. Czyli pomoże ci przejść etap rozbrajania bólu na czynniki pierwsze.

Krok 2: struktura systemu, moduły i priorytety

Dopiero kiedy masz podsumowane potrzeby, przechodzisz do nowej sesji z kolejnym promptem. Wrzucasz mu podsumowanie z kroku pierwszego i prosisz, żeby pomógł zbudować strukturę systemu, jakiego poszukujesz i żeby działał w oparciu o ten problem, jaki chcesz rozwiązać.

I co ważne, mówisz wprost, że jeszcze nie wiesz, jakie będą wszystkie funkcjonalności. Czat GPT ma wtedy pomóc podzielić system na logiczne elementy, na przykład:

• moduł klientów
• moduł ofert,
• moduł do raportowania,
• moduł zadań,
• integracje,

czy jakiekolwiek inne moduły, które będą potrzebne do tego, żeby twój cel biznesowy zrealizować. Na tym etapie czat może też doradzić, co zrobić w MVP, co jest krytyczne, a co można zrobić później.

Krok 2: struktura systemu, moduły i priorytety

Trzeci etap to finalny dokument. Krótki i konkretny w formacie do wycenny. I tutaj ponownie korzystasz z nowej sesji z odpowiednim promptem.

Najprostszy i najbezpieczniejszy format, jaki możesz dostarczyć dla Software House'u, wygląda tak, że opisujesz:

• nazwę danego modułu - w dwóch, trzech zdaniach opis, co ten moduł powinien robić,
• Kryteria odbiory - czyli po czym poznasz, że wdrożenie rozwiązało problem w określinym module

Przykłady takich modułów?

• Moduł ofertowania, który ma przyspieszyć pracę handlowca.
• Moduł, który ma ułatwić wpisywanie danych do CRM-a w sposób głosowy.
• Moduł, który ma przyspieszyć planowanie logistyki.
• Moduł, który ma połączyć planowanie produkcji z planowaniem logistyki.
• Moduł, który ma połączyć sprzedaż z planowaniem produkcji.
• Moduł, który ma cyfrowo odtworzyć proces X, dziejący się obecnie w zeszycie.
• Moduł planowania zasobów, który ma zastąpić trzy eksele, w których obecnie planujemy naszą pracę.

I tak dalej, i tak dalej. I dopiero taki materiał wysyłamy do Software House'u. I teraz z rzeczy organizacyjnych.

Dlaczego mówiłem o tym otwieraniu kolejnych sesji w czacie? Dlatego, że każda sesja to inny kontekst myślenia, czyli dzięki temu AI nie miesza tych wcześniejszych założeń z nowymi celami. Nowa sesja pozwala spojrzeć na problem świeżo, bez skażenia, w pewnym sensie wcześniejszymi odpowiedziami i skrótami myślowymi, a także bez halucynacji. I dzięki temu łatwiej oddzielisz analizę biznesową, projektowanie rozwiązania i opis techniczny, zamiast próbować zrobić wszystko naraz. W praktyce nowe sesje działają jak różni specjaliści w zespole.

Każdy patrzy na problem z innej perspektywy i zadaje zupełnie inne pytania. I zbliżając się do końca. Uważam, że dużo ważniejsze jest na tym etapie, żeby software house zrozumiał sens, zrozumiał co chcesz rozwiązać, co chcesz osiągnąć i dobrze oszacował wielkość projektu, a nie tylko czytał długą listę funkcjonalności.

Z pewnością nie chcesz na tym etapie, aby ktoś myślał task oriented, tylko żeby nadal myślał biznes oriented, bo tylko wtedy projekt faktycznie przyniesie realną korzyść biznesową.

Czego to podejście nie zastąpi i co realnie daje?

Absolutnie nie i trzeba powiedzieć to wprost. Nie zastąpi profesjonalnej analizy, spotkań, nie zastąpi człowieka, który pracuje jednak w znacznie szerszym kontekście niż AI, przynajmniej póki co.

Natomiast na pewno bardzo dobrze zastępuje pierwszy chaos, czyli moment w którym software house próbuje zrozumieć co w ogóle klient chce zrobić i co klient chciałby osiągnąć. Pamiętajcie, że technologia jest dla nas, a nie my dla technologii, więc korzystajmy z niej mądrze i wspierajmy swoje działania jak najbardziej, jednak pamiętajmy, że po drugiej stronie pracę wykonują ludzie i to z nimi musimy się przede wszystkim dogadać. Na koniec obiecana niespodzianka.

Budowa specyfikacji to bardzo dobry trening na zmapowanie swoich potrzeb i przemyślenie tematu we własnym gronie z własnym zespołem i chciałbym Wam w tym pomóc, dlatego przygotowałem zestaw promptów, z których możecie łatwo skorzystać, czy to w czacie GPT czy Gemini czy jakimkolwiek innym AI-u.