Wsparcie decyzyjne przed wdrożeniem
Najtańsza godzina w projekcie to ta przed jego rozpoczęciem. Sprawdzamy założenia, porównujemy oferty na tych samych zasadach i tniemy zakres do tego, co naprawdę musi powstać najpierw.
Decyzje zapadające przed pierwszą linijką kodu
Zanim projekt wystartuje, większość jego kosztu jest już przesądzona. Zakres uzgodniony, dostawca wybrany, platforma założona z góry, termin ustawiony pod datę, którą ktoś rzucił na spotkaniu. To, co następuje potem, jest w dużej mierze wykonaniem wyborów podjętych szybko i rzadko gdziekolwiek zapisanych.
Ta praca dzieje się wcześniej. Jest krótka, jej efektem jest dokument, a nie oprogramowanie, i cała jej wartość polega na zadaniu pytań wtedy, gdy odpowiedzi da się jeszcze tanio wykorzystać.
Porównywanie ofert, które nigdy nie były porównywalne
Trzy wyceny tego samego projektu potrafią różnić się kilkukrotnie i powodem prawie nigdy nie jest to, że jeden dostawca pracuje aż tyle sprawniej.
Różnią się, bo obejmują co innego. Jedna zakłada, że projekty graficzne dostarczasz Ty. Druga zawiera rok utrzymania. Trzecia wycenia integrację, a inna wpisuje ją jako zależność po Twojej stronie. Jedna przenosi na Ciebie prawa do kodu, inna udziela licencji. Gdy zestawi się je obok siebie bez sprowadzenia do wspólnego mianownika, wygrywa najniższa liczba, a różnicę poznajesz później, zwykle w momencie, w którym masz najmniejsze pole manewru.
Układamy je w tej samej strukturze i zadajemy pytania, które dokumenty zostawiają otwarte: co się dzieje przy zmianie zakresu, kto jest właścicielem repozytorium, co dokładnie obejmuje przekazanie i czego wymagałoby przejście do innego dostawcy za dwa lata. Wtedy porównanie dotyczy pracy, a nie formatowania.
Sprawdzanie założeń, na których stoi plan
Prawie każdy plan opiera się na kilku założeniach, których nikt nie zweryfikował. Wzorzec jest powtarzalny.
Integracja istnieje. Zwykle tak, ale nie zawsze w formie, jakiej wymaga plan. API bywa tylko do odczytu tam, gdzie potrzebny jest zapis, albo stronicowane w sposób, przez który synchronizacja trwa godzinami.
Limity zapytań wystarczą. Udokumentowane limity często leżą wyraźnie poniżej tego, co wynika z zakładanego obciążenia, a odkrycie tego po wdrożeniu oznacza przeprojektowanie synchronizacji.
Dane da się zmigrować. Stary system eksportuje, ale w eksporcie brakuje pola, od którego zależy nowy proces, albo dane historyczne są niespójne w sposób, którego nikt nie zauważył, dopóki czytał je człowiek, po jednym rekordzie.
Termin jest sztywny. Czasem faktycznie jest, bo wynika z umowy albo z sezonu. Częściej to preferencja, którą z czasem zaczęto traktować jak twardy warunek, a rozróżnienie tych dwóch przypadków zmienia cały kształt planu.
Sprawdzenie tego oznacza sięgnięcie do samej dokumentacji, a tam, gdzie to nie rozstrzyga, krótki test na dowód. To niewielki koszt wobec odkrycia problemu w połowie budowy.
Cięcie zakresu bez wypatroszenia projektu
Większość pierwszych wersji jest za duża i powód jest zrozumiały: za każdą funkcją stoi ktoś, kto jej chce, i nie ma oczywistego argumentu przeciw.
Wyjściem jest ustalenie, co pierwsza wersja ma udowodnić, a potem konfrontowanie z tym każdej pozycji. Czy bez tego wydanie przestaje odpowiadać na swoje pytanie? Dla większości pozycji odpowiedź brzmi „nie”. To, co wypada, nie jest złe. Jest przedwczesne.
Kluczowe jest spisanie, co usunięto i dlaczego. Nieudokumentowane cięcia wracają jako kryzys tuż przed premierą, rozstrzygany z pamięci. Udokumentowane wracają jako decyzja, do której wracasz z danymi z wydania, które faktycznie trafiło do ludzi.
Kiedy rekomendacja brzmi „nie rób tego”
Zauważalna część takich analiz kończy się radą, żeby nie realizować projektu w zaplanowanej formie. Istniejące narzędzie pokrywa już większość potrzeby. Problem leży w procesie, który przetrwa automatyzację w niezmienionej formie. Coś, od czego projekt zależy, nie jest gotowe, a budowanie obok kosztuje więcej niż poczekanie.
To nie jest nieudana współpraca. Decyzja o nierozpoczynaniu jest w tym momencie najtańszą dostępną decyzją i przestaje być dostępna bardzo szybko, gdy umowy są podpisane, a zespół zebrany.
Częściej jednak wniosek brzmi łagodniej: rób, ale nie to i nie w tej kolejności. Zamiast pełnego systemu wystarczy jeden proces obsłużony porządnie, żeby sprawdzić, czy założenia o pracy użytkowników się bronią. Zamiast integracji z pięcioma systemami naraz, integracja z jednym: tym, przez który przechodzi najwięcej danych. Takie przesunięcie zwykle nie zmienia celu, tylko rozkłada ryzyko na etapy, które da się ocenić po kolei.
Co dostajesz
Oferty porównane na tych samych zasadach
Wyceny od różnych dostawców rzadko są porównywalne w formie, w jakiej przychodzą. Sprowadzamy je do wspólnego mianownika: co wchodzi w zakres, co jest rozliczane osobno, kto ma prawa do kodu, ile kosztuje utrzymanie po starcie i co oznaczałoby wyjście.
Zakres MVP z jawną listą cięć
Nie tylko to, co obejmuje pierwsza wersja, ale też co z niej wypadło i ile każde takie cięcie kosztuje Cię w międzyczasie. Cięcie, którego nikt nie zapisał, wraca jako niespodzianka trzy tygodnie przed premierą.
Weryfikacja założeń technicznych
Sprawdzamy w samej dokumentacji założenia, na których opiera się plan: możliwości API, limity zapytań, formaty eksportu danych, warunki licencji. Plany nagminnie zakładają istnienie integracji, której nie ma.
Rejestr ryzyk z działaniami ograniczającymi
Konkretne rzeczy, które mogą wykoleić ten projekt, uszeregowane, każda z informacją, co zmniejszy jej prawdopodobieństwo albo skutki. Ogólne listy ryzyk są ozdobą; użyteczne nazywają system i rodzaj awarii.
Przedziały kosztów i pracochłonności
Niezależny szacunek podany jako przedział z nazwanymi czynnikami, żeby było widać, które fragmenty zakresu niosą niepewność, zamiast spierać się o jedną liczbę.
Pisemna rekomendacja
Jasne stanowisko, co robić, razem z argumentami przeciw. Jeśli rekomendujemy budowę własnego rozwiązania, piszemy też, co przechyliłoby szalę na rzecz gotowego, i odwrotnie.
Jak pracujemy
- 01
Ustalamy, co właściwie jest przedmiotem decyzji
Zadane pytanie często nie jest tym prawdziwym. „Który dostawca” bywa w istocie pytaniem „czy to w ogóle ma być system, czy zmiana w procesie”. Rozdzielamy decyzje odwracalne od tych, których nie da się cofnąć.
- 02
Zbieramy ograniczenia
Kształt budżetu, terminy realne kontra preferowane, obowiązujące umowy, kto będzie to później utrzymywał i ile Twój zespół jest w stanie unieść obok bieżącej pracy.
- 03
Sprawdzamy założenia u źródła
Czytamy dokumentację API, warunki licencji i formaty danych, zamiast ufać streszczeniu. Tam, gdzie coś jest naprawdę niepewne, krótki test jest tańszy niż odkrycie tego w trakcie budowy.
- 04
Porównujemy warianty
Każda realna ścieżka wyceniona i opisana w tej samej strukturze, łącznie z wariantem „na razie nic nie robimy”. Gdy stan obecny jest jawną opcją, porównanie pozostaje uczciwe.
- 05
Rekomendujemy i przekazujemy
Dostajesz pisemną rekomendację z uzasadnieniem i listę pytań, które warto zadać wybranym dostawcom. Chodzi o to, żeby resztę procesu dało się poprowadzić bez nas.
Narzędzia i technologie
Tam, gdzie istnieje dobre narzędzie open source, wybieramy je zamiast zamkniętego. Bez uzależnienia od jednego dostawcy i z kosztami, które da się przewidzieć.
- n8n
- Supabase
- PostgreSQL
- Next.js
- Medusa
- Directus
- Keycloak
- Figma
- Linear
- Notion
- Stripe
- Shopify
Najczęściej zadawane pytania
Pozostałe usługi w tej kategorii
Strategia technologiczna
Strategia technologiczna to kilka decyzji, które podejmuje się raz i tanio, a zmienia bardzo drogo. Pomagamy podjąć je świadomie, ze spisanymi kompromisami.
Audyt obecnych rozwiązań
Audyt zamienia niejasne przeczucie, że coś jest nie tak, w listę uporządkowaną według wagi: co jest realnym ryzykiem, co tylko bałaganem, a co pęknie najszybciej przy wzroście.
Modernizacja i skalowanie systemów
Systemy rzadko przestają działać z dnia na dzień. Zmienia się je coraz wolniej, utrzymuje coraz drożej, a każde wdrożenie jest coraz bardziej ryzykowne. Lekarstwem jest zaplanowana seria małych wymian, nie przepisanie całości.
Przeczytaj opinie firm, które nam zaufały
Dostarczone znacznie wcześniej niż termin.
Indywidualne podejście ZanReal jest imponujące.
Wiedza i intuicja biznesowa czynią ich wartościowym partnerem.
Szybkie rozwiązania, które obniżyły koszty o 99%.
+20% dostarczalności dla naszych kampanii e-mail.
Masz na stole oferty albo zakres do zatwierdzenia?
Napisz do nasPrześlij zakres lub wyceny, które porównujesz, a powiemy Ci, które założenia sprawdzilibyśmy najpierw i jak wyglądałaby taka weryfikacja przed podpisem.
Nie nadążasz za zmianami w świecie AI?
Pozwól, że weźmiemy to na siebie. Co tydzień destylujemy najważniejsze wydarzenia ze świata AI w skupiony, 5-minutowy przegląd — żebyś był na bieżąco bez szumu.
Dowiedz się więcej