Kierowniczka programu w firmie ubezpieczeniowej dostała zadanie, które w prezentacji dla zarządu zmieściło się na jednym slajdzie: „nowy portal obsługi agentów, start za dziewięć miesięcy”. Budżet zatwierdzono, dział zakupów pyta, kiedy wyśle zapytanie ofertowe, a ona ma trzy rzeczy: notatki z dwóch warsztatów z działem sprzedaży, arkusz z wymaganiami spisany przez IT i listę życzeń od działu likwidacji szkód. Te trzy dokumenty się nie zgadzają. Nikt nie wie, ile systemów portal ma integrować, kto odpowiada za dane agentów i które wymagania wynikają z przepisów, a które z przyzwyczajeń.
Wysłanie takiego materiału do pięciu software house’ów skończy się pięcioma ofertami, których nie da się porównać. Każdy dostawca inaczej zinterpretuje luki, jeden wyceni minimum, drugi wszystko z zapasem, trzeci wpisze „do doprecyzowania w fazie analizy” i zostawi sobie furtkę na aneksy. Kierowniczka programu wie, że potrzebuje czegoś pomiędzy notatkami a umową. To coś to analiza przedwdrożeniowa.
Ten artykuł jest dla osoby, która ma ją zamówić albo przekonać zarząd, że warto. Opisujemy, co konkretnie powinno powstać, jak przebiega praca, ile trwa, od czego zależy koszt, kto powinien ją wykonać i co zapisać w umowie, żeby wyniki należały do Ciebie, a nie do dostawcy. Szczegółowe różnice między analizą biznesową a systemową oraz budowę specyfikacji wymagań omawialiśmy osobno, więc tutaj skupiamy się na stronie zakupowej: co kupujesz i za ile.
Czym jest analiza przedwdrożeniowa i czym różni się od warsztatów discovery?
Analiza przedwdrożeniowa to zamknięty etap przed budową albo wdrożeniem systemu, w którym zespół analityków zamienia cele biznesowe i rozproszone oczekiwania w opis, na podstawie którego da się system rzetelnie wycenić, zaprojektować i zbudować. Łączy dwie perspektywy. Analiza biznesowa odpowiada na pytanie, po co system powstaje, jakie procesy ma wspierać i jak zmierzyć sukces. Analiza systemowa odpowiada na pytanie, co dokładnie system ma robić, z jakimi systemami się łączyć, jakie dane przetwarzać i jakie ma mieć cechy jakościowe. Szerzej o tym podziale piszemy w artykule analiza biznesowa a analiza systemowa.
Warsztaty discovery to co innego, choć pojęcia się mieszają. Warsztaty to zwykle kilka intensywnych sesji, które ustalają cel produktu, użytkowników, zakres pierwszej wersji i priorytety. Są świetnym początkiem, ale ich wynik to najczęściej uzgodniona wizja, mapa historyjek i lista ryzyk, a nie dokumentacja, na której oprzesz zapytanie ofertowe. Jak dobrze przeprowadzić takie warsztaty, opisaliśmy w artykule o warsztatach odkrywczych IT. W praktyce warsztaty są często pierwszym tygodniem analizy przedwdrożeniowej, a nie jej zamiennikiem.
Trzecie pojęcie to analiza wdrożeniowa w projektach systemów gotowych, na przykład ERP czy CRM. Tam analiza porównuje procesy firmy z możliwościami systemu i opisuje luki, które trzeba wypełnić konfiguracją albo rozwojem. Logika zakupu jest podobna, ale wynik inny: zamiast specyfikacji budowy dostajesz analizę dopasowania. W tym artykule skupiamy się na systemach budowanych na zamówienie, a różnice dla systemów gotowych zaznaczamy tam, gdzie mają znaczenie.
Dlaczego warto zapłacić za analizę przed wyborem wykonawcy?
Bo błędy w wymaganiach są najdroższe wtedy, gdy wychodzą późno, a bez analizy wychodzą zawsze późno. Najczęściej cytowane dane w tej sprawie pochodzą z raportu PMI „Pulse of the Profession: Requirements Management” z 2014 roku, opartego na ankiecie wśród ponad dwóch tysięcy praktyków zarządzania projektami i analityków. Według niego 47% projektów, które nie osiągnęły celów, nie osiągnęło ich z powodu niedokładnego zarządzania wymaganiami, a 5,1% każdej złotówki wydanej na projekty i programy marnuje się przez słabe zarządzanie wymaganiami (PMI, 2014). To ankieta, a nie eksperyment, i ma już kilka lat, ale kierunek jest zgodny z doświadczeniem każdego, kto prowadził projekt z niejasnym zakresem.
Dla kupującego argument jest jeszcze bardziej praktyczny. Bez analizy nie da się porównać ofert. Każdy dostawca wypełnia luki w wymaganiach własnymi założeniami, więc różnica w cenie między ofertami częściej wynika z różnych założeń niż z różnej efektywności. Wybierasz wtedy nie najlepszego dostawcę, tylko tego, który założył najmniej.
Bez analizy nie da się też dobrze napisać umowy. Umowa o stałej cenie bez opisu zakresu kończy się sporami o to, co było w zakresie, a umowa time and materials bez opisu zakresu kończy się budżetem, który rośnie bez kontroli. Analiza nie usuwa niepewności, ale ją nazywa: wiadomo, co jest pewne, co jest założeniem, a co wymaga decyzji.
Wreszcie analiza ujawnia problemy, których nikt nie chciał widzieć. Dwa działy mają sprzeczne wymagania wobec tego samego procesu. System źródłowy, z którym trzeba się zintegrować, nie ma API. Dane klientów są w trzech miejscach i w każdym inne. Lepiej dowiedzieć się o tym za kilkadziesiąt tysięcy złotych na etapie analizy niż za kilkaset tysięcy w połowie budowy.
Co powinieneś dostać na koniec analizy przedwdrożeniowej?
To najważniejsza część zamówienia. Analiza bez jasno zdefiniowanych produktów zamienia się w serię spotkań, po których zostaje poczucie, że „dużo omówiliśmy”. Zanim podpiszesz zlecenie, upewnij się, że oferta wymienia konkretne dokumenty. Typowy zestaw obejmuje osiem elementów.
Kontekst i cele biznesowe. Krótki dokument, który odpowiada na pytanie, po co system powstaje, kto go używa, jak zmierzyć sukces i co jest poza zakresem. Wygląda na oczywistość, ale to on rozstrzyga spory w trakcie projektu.
Model procesów. Procesy, które system ma wspierać, w stanie obecnym i docelowym, zwykle w notacji BPMN albo w prostszej formie, jeśli procesy są nieskomplikowane. Tu wychodzą sprzeczności między działami.
Wymagania funkcjonalne. Co system ma robić, opisane jako przypadki użycia, historyjki użytkownika z kryteriami akceptacji albo jedno i drugie. Kluczowe jest to, żeby każde wymaganie było testowalne. Więcej o technice znajdziesz w haśle słownikowym o analizie wymagań.
Wymagania niefunkcjonalne. Wydajność, dostępność, bezpieczeństwo, zgodność z przepisami, dostępność cyfrowa, wymagania co do hostingu i utrzymania. Często pomijane, a to one decydują o architekturze i o dużej części kosztu. Zobacz też wymagania niefunkcjonalne w naszym słowniku.
Mapa integracji i danych. Z jakimi systemami nowy system się łączy, w którą stronę płyną dane, jakie są interfejsy i kto po drugiej stronie za nie odpowiada. Plus model danych na poziomie pojęciowym i decyzja, który system jest źródłem prawdy dla których danych.
Wstępna architektura. Nie projekt techniczny do ostatniej klasy, tylko główne decyzje: komponenty, technologie lub ich ograniczenia, sposób wdrożenia, kluczowe ryzyka techniczne. Bez tego dostawcy zaproponują pięć różnych architektur i porównasz jabłka z gruszkami.
Backlog z priorytetami. Lista funkcji ułożona według wartości i zależności, z wyraźnie oznaczonym zakresem pierwszej wersji, czyli często MVP.
Oszacowanie i rejestr ryzyk. Szacunek pracochłonności w przedziale, a nie jedna liczba, z założeniami i listą ryzyk, które mogą go przesunąć.
Jeśli analiza ma być podstawą przetargu albo zapytania ofertowego, te dokumenty składają się zwykle w specyfikację wymagań. Jak ją zbudować, żeby była użyteczna dla dostawców i dla testerów, opisaliśmy w przewodniku po specyfikacji wymagań oprogramowania (SRS). Punktem odniesienia dla jej struktury jest norma ISO/IEC/IEEE 29148:2018 opisująca procesy inżynierii wymagań i zawartość dokumentów wymagań.
Jak sprawdzić jakość dokumentów przy odbiorze?
Odbiór analizy to moment, w którym najłatwiej przepuścić słabą pracę, bo dokumenty są obszerne, a terminy gonią. Zamiast czytać wszystko od deski do deski, przeprowadź pięć prostych testów.
Test testera. Wybierz losowo dziesięć wymagań funkcjonalnych i zapytaj osobę z QA, czy potrafi do każdego napisać przypadek testowy. Wymaganie typu „system powinien być intuicyjny” albo „raport ma pokazywać istotne dane” nie przejdzie tego testu i wróci jako spór przy odbiorze budowy.
Test nowego dostawcy. Daj dokumenty komuś, kto nie uczestniczył w warsztatach, na przykład architektowi z innego zespołu, i poproś o listę pytań po godzinie lektury. Jeśli pytań jest kilkadziesiąt i dotyczą podstaw, dokumenty opisują rozmowy, a nie system.
Test sprzeczności. Sprawdź, czy lista sprzeczności zgłoszonych w trakcie analizy ma przy każdej pozycji decyzję i jej autora. Sprzeczność „zamknięta” bez decyzji sponsora wróci w trakcie budowy.
Test integracji. Dla każdej integracji powinien być wskazany właściciel systemu po drugiej stronie, kierunek przepływu danych i informacja, czy interfejs istnieje, czy trzeba go zbudować. Brak którejś z tych trzech informacji to luka w wycenie.
Test założeń. Oszacowanie powinno mieć listę założeń. Zapytaj, co się stanie z przedziałem, jeśli dwa najważniejsze założenia okażą się fałszywe. Jeśli analityk nie umie odpowiedzieć, szacunek jest liczbą, a nie analizą.
Żaden z tych testów nie wymaga wiedzy technicznej od kierownika programu, a razem zajmują jedno popołudnie. Warto je wpisać do procedury odbioru w umowie.
Jak przebiega analiza tydzień po tygodniu?
Przebieg zależy od wielkości systemu, ale dobra analiza średniej wielkości ma rozpoznawalny rytm. Poniżej przykład dla czterotygodniowej analizy systemu obsługującego kilka działów.
Tydzień 1: cele, interesariusze, materiały. Spotkanie otwierające z zarządem albo sponsorem, ustalenie celu i granic zakresu. Przegląd istniejących dokumentów: notatek, procedur, opisów obecnych systemów, umów z dostawcami. Mapa interesariuszy i harmonogram warsztatów. Jeśli przewidziano warsztaty discovery, odbywają się w tym tygodniu.
Tydzień 2: procesy i wymagania. Warsztaty z działami, zwykle po dwie lub trzy sesje z każdym kluczowym obszarem. Model procesów, pierwsza wersja wymagań funkcjonalnych, lista sprzeczności do rozstrzygnięcia przez sponsora. Równolegle architekt rozmawia z IT o istniejących systemach i ograniczeniach.
Tydzień 3: integracje, dane, wymagania niefunkcjonalne. Rozmowy z właścicielami systemów, z którymi trzeba się zintegrować. Mapa integracji, model danych, wymagania niefunkcjonalne. Wstępna architektura i lista ryzyk technicznych. Druga wersja wymagań funkcjonalnych po rozstrzygnięciu sprzeczności.
Tydzień 4: priorytety, szacunek, odbiór. Backlog z priorytetami i zakresem pierwszej wersji, oszacowanie w przedziale z założeniami, rejestr ryzyk. Przegląd dokumentów z interesariuszami, poprawki, prezentacja wyników dla sponsora i formalny odbiór.
Zauważ, że w tym planie analitycy nie piszą w samotności. Większość pracy to rozmowy, a kluczowym zasobem jest czas ludzi po Twojej stronie. Jeśli dział sprzedaży ma czas na warsztaty dopiero za trzy tygodnie, analiza potrwa trzy tygodnie dłużej, niezależnie od tego, ilu analityków zatrudnisz.
Ile trwa analiza przedwdrożeniowa?
Nie ma jednej odpowiedzi, ale są czynniki, które da się nazwać i ocenić przed startem. Orientacyjnie: prosty system z jednym głównym procesem, jednym działem i kilkoma integracjami to zwykle około dwóch tygodni. System obsługujący kilka działów z kilkoma integracjami to raczej cztery do sześciu tygodni. Duże programy, które zastępują kilka systemów, mają wymagania regulacyjne albo obejmują wiele krajów, potrzebują od dwóch do trzech miesięcy, często dzielonych na etapy. To szacunki oparte na typowej strukturze pracy, a nie dane rynkowe.
Dla porównania, w projektach tworzenia oprogramowania na zamówienie ARDURA Consulting zaczynamy od fazy discovery trwającej od tygodnia do dwóch, która ma zdefiniować zakres i architekturę. To krótsza forma, wystarczająca, gdy budujemy system sami i ustalenia od razu zamieniamy w pracę zespołu. Pełna analiza pod zapytanie ofertowe do wielu dostawców wymaga więcej dokumentacji, bo jej odbiorcą jest ktoś, kto nie uczestniczył w rozmowach.
Czas najbardziej wydłużają cztery rzeczy. Po pierwsze, dostępność interesariuszy: kalendarze dyrektorów i ekspertów dziedzinowych są zwykle wąskim gardłem. Po drugie, nierozstrzygnięte sprzeczności: jeśli dwa działy chcą czegoś innego, a sponsor nie decyduje, analiza stoi. Po trzecie, systemy bez dokumentacji: integracja z systemem, którego nikt nie opisał, wymaga odtwarzania wiedzy z kodu albo z rozmów z dostawcą tego systemu. Po czwarte, zmiana celu w trakcie: jeśli w trzecim tygodniu zarząd zmienia zakres, część pracy trzeba powtórzyć.
Czas skracają: jeden sponsor z prawem decyzji, zarezerwowane z góry terminy warsztatów, materiały przekazane przed startem i zgoda na to, że część szczegółów zostanie doprecyzowana w trakcie budowy, a analiza wskaże tylko, które to szczegóły.
Ile kosztuje analiza przedwdrożeniowa i od czego zależy cena?
Koszt analizy to liczba osobodni razy stawki ról, które w niej uczestniczą. Nie ma publicznego, wiarygodnego cennika rynkowego analiz, który dałoby się uczciwie zacytować, dlatego pokazujemy arytmetykę na jawnych założeniach.
Typowy skład zespołu to analityk biznesowo-systemowy przez cały czas trwania analizy, architekt w części czasu, przy większych systemach drugi analityk albo projektant UX, a czasem kierownik projektu. Dla ilustracji przyjmijmy stawki dzienne 1 500–2 800 PLN netto. To przedział zbliżony do stawek seniora i architekta w cenniku ARDURA Consulting, gdzie na przykład senior Project Manager to 1 520–2 080 PLN, a architekt lub lead backendu 2 080–2 800 PLN za dzień. Rola analityka nie ma w cenniku osobnego wiersza i jest wyceniana indywidualnie.
- Prosty system, ok. 2 tygodnie: analityk 10 dni i architekt 3 dni, razem ok. 13 osobodni, czyli szacunkowo 20–36 tys. PLN netto.
- Średni system, ok. 4 tygodnie: analityk 20 dni, architekt 8 dni, projektant UX 8 dni, razem ok. 36 osobodni, czyli szacunkowo 54–100 tys. PLN netto.
- Duży program, 6–10 tygodni: dwóch analityków, architekt, UX i kierownik, razem ok. 80–120 osobodni, czyli szacunkowo 120–340 tys. PLN netto.
Sprawdź też, czego w ofercie nie ma. Klikalny prototyp interfejsu, badania z użytkownikami, opinia prawna co do przepisów branżowych czy dowód wykonalności technicznej (proof of concept) dla ryzykownej integracji to zwykle osobne pozycje. Każda z nich może być warta swojej ceny, ale powinna być wyceniona osobno, żeby nie rozmywała zakresu analizy i żebyś mógł świadomie zdecydować, czy jej potrzebujesz.
Rozpiętość jest duża, bo zależy od kilku czynników jednocześnie. Zestawiamy je w tabeli poniżej. Jeśli chcesz najpierw zobaczyć, w jakim rzędzie wielkości może być sama budowa, nasz kalkulator kosztów MVP daje orientacyjne widełki dla typowych produktów. Rozsądna analiza kosztuje ułamek budowy, a jeśli oferta na analizę zbliża się do kosztu budowy pierwszej wersji, coś jest nie tak z zakresem jednego albo drugiego.
| Czynnik | Jak wpływa na czas i koszt | Co możesz zrobić po swojej stronie |
|---|---|---|
| Liczba działów i interesariuszy | Każdy kolejny dział to warsztaty, sprzeczności i uzgodnienia; koszt rośnie szybciej niż liniowo | Wyznacz jednego sponsora z prawem decyzji i zarezerwuj terminy przed startem |
| Liczba integracji | Każda integracja wymaga rozmów z właścicielem systemu i opisu interfejsu | Przygotuj listę systemów, ich właścicieli i dostępną dokumentację API |
| Wymagania regulacyjne (RODO, przepisy branżowe, dostępność cyfrowa) | Dochodzi analiza przepisów i często konsultacja z prawnikiem lub inspektorem ochrony danych | Wskaż osobę po stronie compliance, która odpowie na pytania w ciągu kilku dni |
| Jakość istniejącej dokumentacji | Brak opisu obecnych procesów i systemów oznacza odtwarzanie wiedzy z rozmów | Zbierz procedury, notatki, zgłoszenia i opisy systemów, jakie by nie były |
| Docelowy odbiorca dokumentów | Analiza pod przetarg lub zapytanie do wielu dostawców wymaga pełniejszej dokumentacji niż analiza pod własny zespół | Ustal na starcie, do czego posłużą wyniki |
| Poziom szczegółowości | Opis każdego ekranu i reguły kosztuje wielokrotnie więcej niż opis funkcji i kryteriów akceptacji | Zdecyduj, co doprecyzujecie w trakcie budowy, i zapisz to w analizie |
| Stabilność celu | Zmiana zakresu w trakcie analizy oznacza powtarzanie pracy | Zatwierdź cel i granice zakresu w pierwszym tygodniu |
Kto powinien wykonać analizę: Twój zespół, przyszły wykonawca czy niezależna firma?
Każda z trzech opcji ma sensowne zastosowanie i każda ma koszt, który nie zawsze widać od razu.
Własny zespół analityków. Zna firmę, procesy i ludzi, nie wymaga przetargu i zostaje po projekcie. Działa, jeśli taki zespół istnieje, ma czas i ma doświadczenie w systemach tej klasy. Ryzyko polega na tym, że wewnętrzni analitycy są częścią układu sił w firmie i trudniej im rozstrzygać spory między działami, a ich czas zjadają bieżące obowiązki.
Przyszły wykonawca. Wiele software house’ów oferuje analizę lub fazę discovery jako pierwszy etap projektu. Zaletą jest ciągłość: ludzie, którzy analizowali, potem budują i nie trzeba im niczego tłumaczyć drugi raz. Wadą jest konflikt interesów: dostawca, który pisze specyfikację, pisze ją pod siebie, swoją technologię i swój sposób pracy, a Ty tracisz pozycję negocjacyjną, bo zmiana dostawcy po analizie wydaje się marnowaniem pieniędzy. Da się to zrównoważyć umową, o czym w następnej sekcji.
Niezależna firma lub analitycy z zewnątrz. Daje największą swobodę wyboru wykonawcy, bo analiza nie jest pisana pod nikogo. Wymaga za to dobrego przekazania wiedzy wykonawcy i zwykle kilku dni, w których wykonawca weryfikuje analizę przed złożeniem oferty. To najlepsza opcja, gdy planujesz konkurencyjne zapytanie ofertowe albo przetarg.
Jest też opcja mieszana: analityk z zewnątrz w modelu body leasingu, który pracuje w Twoim zespole, pod Twoim kierownictwem, a wyniki od początku należą do Ciebie. W naszym serwisie dostępnych ekspertów znajdziesz między innymi profil seniora analityka biznesowo-systemowego z doświadczeniem w ubezpieczeniach, bankowości i finansach, biegłego w UML, BPMN i inżynierii wymagań. Taki model łączy niezależność wyników z elastycznością zasobu.
Jak rozliczać analizę i co zapisać w umowie?
Analiza to jedno z niewielu zleceń IT, które dobrze pasują do stałej ceny: ma zamknięty zakres, określone produkty i ograniczony czas. Jeśli dostawca nie umie wycenić analizy ryczałtowo, zapytaj, dlaczego. Zwykle znaczy to, że nie rozumie zakresu albo że analiza ma płynnie przejść w budowę bez momentu decyzji. Model time and materials ma sens przy bardzo niepewnym zakresie, ale wtedy z limitem osobodni i z cotygodniowym raportem postępu.
Niezależnie od modelu, umowa powinna zawierać sześć zapisów.
Lista produktów z kryteriami odbioru. Dokumenty wymienione z nazwy, z opisem minimalnej zawartości i procedurą odbioru. Nie „dokumentacja analityczna”, tylko „model procesów w notacji BPMN dla procesów X, Y, Z”.
Prawa do wyników. Przeniesienie autorskich praw majątkowych do wszystkich dokumentów, z wymienionymi polami eksploatacji, w tym prawem do udostępnienia ich innym dostawcom i modyfikowania. Bez tego zapisu nie możesz legalnie użyć analizy w zapytaniu ofertowym do konkurencji wykonawcy.
Format przekazania. Edytowalne pliki źródłowe, a nie wyłącznie PDF: modele procesów w formacie narzędzia, backlog w eksporcie z narzędzia do zarządzania zadaniami, diagramy w formacie, który da się dalej edytować.
Brak zobowiązania do dalszej współpracy. Jasny zapis, że analiza jest osobnym zleceniem i nie daje wykonawcy pierwszeństwa ani wyłączności przy budowie. Jeśli to wykonawca ma budować, warto nawet wpisać, że jego oferta na budowę zostanie złożona na tych samych zasadach co oferty innych.
Obowiązki zamawiającego. Dostępność interesariuszy, czas na odpowiedzi, przekazanie materiałów. To chroni obie strony: jeśli analiza się opóźni przez brak dostępu do ludzi, wiadomo dlaczego.
Procedura zmiany zakresu. Co się dzieje, jeśli w trakcie analizy okaże się, że zakres jest większy, niż zakładano. Kto decyduje, jak wycenia się dodatkową pracę i jak zmienia się termin.
Czego potrzebuje zespół analityczny po Twojej stronie?
Analiza jest wspólną pracą, a jej jakość zależy od zamawiającego co najmniej tak samo jak od analityków. Przygotuj cztery rzeczy przed startem.
Sponsora z prawem decyzji. Jedna osoba, która rozstrzyga sprzeczności między działami i zatwierdza zakres. Komitet sterujący jest dobry do informowania, ale zły do podejmowania decyzji w ciągu dwóch dni.
Zarezerwowany czas ekspertów dziedzinowych. Każdy kluczowy dział powinien wskazać osobę, która zna proces od środka i ma w kalendarzu zarezerwowane terminy warsztatów. Typowo dwie do czterech sesji po dwie godziny na dział w ciągu całej analizy, plus krótkie odpowiedzi na pytania w trakcie.
Materiały. Procedury, instrukcje, zrzuty ekranów obecnych systemów, raporty, z których korzystają ludzie, umowy z dostawcami systemów, które trzeba zintegrować, dokumentacja API. Nawet nieaktualne materiały oszczędzają godziny rozmów.
Osobę od IT i bezpieczeństwa. Ktoś, kto powie, jakie są standardy technologiczne firmy, gdzie system może być hostowany, jakie są wymagania bezpieczeństwa i kto odpowiada za systemy, z którymi trzeba się połączyć.
Jeśli którejś z tych rzeczy nie masz, powiedz o tym dostawcy przed startem. Rzetelny dostawca wydłuży harmonogram albo zmieni zakres. Nierzetelny przyjmie zlecenie i wyjaśni opóźnienie później.
Jakie są czerwone flagi w ofertach na analizę?
Kilka sygnałów w ofercie powinno skłonić do dodatkowych pytań.
Brak listy produktów. Oferta opisuje spotkania i warsztaty, ale nie wymienia dokumentów, które powstaną. Płacisz wtedy za czas, nie za wynik.
Analiza „w cenie” budowy. Dostawca oferuje analizę za darmo albo symbolicznie, pod warunkiem że potem zbuduje system. To nie jest prezent: koszt analizy jest ukryty w budowie, a Ty tracisz możliwość porównania ofert, bo analiza jest pisana pod jednego wykonawcę.
Gotowa architektura przed analizą. Oferta już na starcie przesądza technologię i architekturę. Analiza powinna te decyzje uzasadnić, a nie potwierdzić.
Brak wymagań niefunkcjonalnych w zakresie. Oferta mówi o procesach i funkcjach, a milczy o wydajności, bezpieczeństwie i utrzymaniu. To właśnie te wymagania najczęściej podnoszą koszt budowy, więc ich brak w analizie przenosi problem na później.
Jedna liczba zamiast przedziału w oszacowaniu. Rzetelny szacunek na etapie analizy ma przedział i założenia. Jedna liczba bez założeń to albo nadmierna pewność, albo liczba dobrana pod budżet.
Brak zapisu o prawach do dokumentów. Jeśli oferta lub wzór umowy milczy o prawach autorskich, dopytaj przed podpisem, nie po nim.
Jak wykorzystać wyniki analizy w zapytaniu ofertowym i umowie?
Dobra analiza zmienia sposób, w jaki kupujesz budowę. Zamiast prosić dostawców o „wycenę portalu dla agentów”, prosisz o wycenę konkretnego backlogu pierwszej wersji, przy konkretnych wymaganiach niefunkcjonalnych, integracjach i architekturze. Oferty stają się porównywalne, bo dostawcy wyceniają to samo.
W zapytaniu ofertowym dołącz dokumenty z analizy i poproś dostawców o trzy rzeczy: listę założeń, które przyjęli ponad analizę, listę pytań i ryzyk, które widzą, oraz wycenę w podziale na elementy backlogu albo moduły. Różnice w założeniach pokażą, kto rozumie projekt, a kto wycenił minimum.
W umowie analiza staje się załącznikiem opisującym zakres. W modelu stałej ceny jest podstawą rozstrzygania, co jest zmianą, a co było w zakresie. W modelu time and materials jest punktem odniesienia do mierzenia postępu i budżetu. W obu przypadkach backlog z priorytetami pozwala ustalić, co zostanie dostarczone, jeśli budżet się wyczerpie.
Dla zamawiających publicznych analiza przedwdrożeniowa łączy się z narzędziem przewidzianym w ustawie Prawo zamówień publicznych: wstępnymi konsultacjami rynkowymi z art. 84, które pozwalają przed wszczęciem postępowania zasięgnąć opinii wykonawców przy przygotowaniu opisu przedmiotu zamówienia. Konsultacje nie zastępują analizy, ale pomagają sprawdzić, czy wymagania są realne i czy rynek jest w stanie je wycenić. Informację o przeprowadzonych konsultacjach trzeba zamieścić w ogłoszeniu o zamówieniu.
Kiedy analiza przedwdrożeniowa nie jest potrzebna albo może być krótsza?
Analiza nie zawsze się opłaca w pełnej formie. Są trzy sytuacje, w których wystarczy krótsza wersja albo można ją pominąć.
Mały produkt, który i tak będzie się zmieniał. Jeśli budujesz pierwszą wersję produktu, którego rynek dopiero sprawdzasz, szczegółowa specyfikacja zestarzeje się szybciej, niż powstanie. Lepiej wystarczy krótka faza discovery, zakres MVP i praca w krótkich iteracjach z zespołem, któremu ufasz.
Ten sam zespół analizuje i buduje, w modelu time and materials. Jeśli nie planujesz porównywać ofert, a zespół, który będzie budował, i tak jest wybrany, pełna dokumentacja dla zewnętrznego odbiorcy jest zbędna. Wystarczy krótka faza discovery, a reszta szczegółów powstaje w trakcie, sprint po sprincie. Tak wygląda faza discovery w naszych projektach tworzenia oprogramowania na zamówienie.
Wymiana systemu na gotowy produkt bez większych zmian procesów. Jeśli wdrażasz standardowy system i dostosowujesz procesy do niego, a nie odwrotnie, wystarczy analiza dopasowania i lista luk, a nie pełna specyfikacja.
W każdym innym przypadku, a zwłaszcza gdy planujesz konkurencyjny wybór wykonawcy, umowę o stałej cenie, projekt obejmujący kilka działów albo integracje z systemami, których nie kontrolujesz, analiza przedwdrożeniowa jest najtańszym sposobem, żeby nie przepłacić za budowę.
Podsumowanie: jak zamówić analizę, która się zwróci?
Analiza przedwdrożeniowa zamienia rozproszone oczekiwania w opis, na podstawie którego da się porównać oferty, napisać umowę i zbudować system bez ciągłych sporów o zakres. Jej wartość nie leży w liczbie stron, tylko w tym, że nazywa niepewność: co jest ustalone, co jest założeniem i co wymaga decyzji.
Zapamiętaj pięć rzeczy. Po pierwsze, zamawiaj produkty, nie spotkania: lista dokumentów z kryteriami odbioru to podstawa oferty. Po drugie, licz koszt jako osobodni razy stawki i porównuj go z kosztem budowy; analiza kosztująca tyle co pierwsza wersja ma zły zakres. Po trzecie, czas trwania zależy głównie od dostępności ludzi po Twojej stronie, więc rezerwuj ich kalendarze przed startem. Po czwarte, zapisz w umowie prawa do dokumentów, edytowalny format i brak zobowiązania do dalszej współpracy, niezależnie od tego, kto robi analizę. Po piąte, użyj analizy w zapytaniu ofertowym tak, żeby dostawcy wyceniali to samo, i poproś ich o listę założeń ponad analizę.
Jeśli przygotowujesz projekt i chcesz zacząć od fazy discovery albo potrzebujesz doświadczonego analityka biznesowo-systemowego w swoim zespole, zobacz, jak pracujemy przy tworzeniu oprogramowania na zamówienie albo umów rozmowę o zakresie. Powiemy, jak długa analiza ma sens w Twoim przypadku i czy w ogóle jej potrzebujesz.