Poradnik
Jak wybrać wykonawcę pierwszej wersji produktu: pytania, które warto zadać
Wybór wykonawcy pierwszej wersji ma większe skutki niż wybór technologii. Od niego zależy, czy po trzech miesiącach masz produkt, który da się sprzedać i przejąć, czy makiety i kod, do którego nie masz hasła. Poniżej to, o co pytać, i to, co powinno niepokoić.
Kto może zbudować pierwszą wersję
Agencja albo firma programistyczna. Zespół z kierownikiem projektu, projektantem i kilkoma programistami. Dobrze, gdy masz duży budżet i chcesz jednego partnera na lata. Ryzyko: pierwsza wersja bywa dla nich za mała, więc zakres rośnie, a osoba, która rozmawia z Tobą, często nie jest tą, która pisze kod.
Freelancer. Jedna osoba, niższy koszt, bezpośredni kontakt. Dobrze, gdy produkt jest mały i wykonawca ma za sobą podobne. Ryzyko: gdy jest zajęty albo znika, praca staje, a kod bez dokumentacji trudno przekazać dalej.
Jedna osoba z rolą architekta i zespół dobierany do zadań. Tak pracuję. Rozmawiasz z osobą, która projektuje produkt i pisze jego rdzeń. Przy większym zakresie dołączają sprawdzeni ludzie do konkretnych zadań, a odpowiedzialność za całość zostaje u mnie. Ryzyko: jak przy każdej małej firmie, warto zapytać, co się dzieje, gdy jestem niedostępny. Odpowiedź: dokumentacja i stan kodu, który przejmie ktoś inny. Zakres takiej pracy opisuję w usłudze strony internetowe i aplikacje.
Własny zespół. Zatrudniasz programistów na etat. Dobrze, gdy produkt jest sercem firmy i będzie rozwijany latami. Ryzyko na start: rekrutacja trwa miesiące, a pierwszej wersji potrzebujesz teraz. Częsty scenariusz to zbudowanie pierwszej wersji z zewnątrz i przekazanie jej własnemu zespołowi, gdy produkt zarabia. Pierwszą wersję dostajesz razem z kodem i dostępami, więc własny zespół może ją przejąć bez mojego udziału.
Pytania, które warto zadać każdemu
- Kto będzie pisał kod? Chcesz znać osobę, nie logo firmy. Jeśli odpowiedź brzmi „przydzielimy zespół po podpisaniu umowy”, nie wiesz, kogo wybierasz.
- Kiedy kod i dostępy stają się Twoje? Właściwa odpowiedź: z każdym opłaconym etapem, nie dopiero na końcu. Serwery i domena na Twoją umowę. Nie „przekażemy po zakończeniu projektu”.
- Czy da się przejąć produkt bez Was? Poproś o przykład dokumentacji z poprzedniego projektu. Produkt, którego nie przejmie inny programista, jest wart tyle, ile dostępność autora.
- Jak wygląda rozliczenie i co, gdy zabraknie pieniędzy? Płatność za etap po odbiorze oznacza, że zostaje Ci działający fragment. Płatność z góry za całość oznacza, że zostajesz z tym, co akurat było w budowie.
- Co dostanę po pierwszym miesiącu? Odpowiedź „makiety i dokument z wymaganiami” to za mało. Zwykle po miesiącu powinno być coś, co da się kliknąć i pokazać.
- Jak wygląda opieka po starcie? Kto odbiera telefon, gdy płatności przestaną działać w sobotę, i ile to kosztuje. Lepiej wiedzieć przed startem.
- Czy podpiszecie umowę o poufności? Przed rozmową o szczegółach, jeśli tego chcesz. Odmowa albo zwlekanie to sygnał.
Sygnały ostrzegawcze
Wycena bez rozmowy o produkcie. Kwota podana po jednym mailu oznacza, że wykonawca wycenił coś, co sobie wyobraził. Prawdziwa wycena wymaga spisania zakresu i pytań, które z tego wynikają.
Płatność z góry za całość. Wtedy całe ryzyko jest po Twojej stronie. Zaliczka na start bywa uzasadniona, ale większość pieniędzy powinna iść za odebraną pracą.
„Zbudujemy wszystko na raz”. Wykonawca, który nie próbuje zmniejszyć zakresu pierwszej wersji, buduje dla siebie, nie dla Twojej sprzedaży. Dobry wykonawca odejmuje funkcje na pierwszej rozmowie.
Brak dostępu do kodu w trakcie. Jeśli kod zobaczysz „na koniec”, nie wiesz, co powstaje, i nie możesz odejść w połowie z tym, za co zapłaciłeś.
Technologia zamiast produktu. Rozmowa, w której słyszysz nazwy narzędzi, a nie pytania o klienta i za co płaci, zwykle kończy się produktem dobrym technicznie i nie do sprzedania.
Brak przykładów podobnych produktów. Budowanie od zera różni się od dokładania funkcji do istniejącego systemu. Poproś o produkt, który wykonawca zbudował od pierwszej linii kodu do startu sprzedaży, i o możliwość kliknięcia w niego.
Jak porównać oferty
Porównuj dopiero wtedy, gdy każdy wykonawca dostał ten sam spisany zakres pierwszej wersji. Bez tego jedna oferta obejmuje płatności i panel, druga nie, a kwoty wyglądają, jakby dotyczyły tego samego. Jak przygotować taki opis, zanim poprosisz o wycenę, opisuję w poradniku o przygotowaniu do wyceny.
Co powinno znaleźć się w zakresie, jest na stronie co musi mieć pierwsza wersja, a od czego zależy cena na stronie ile kosztuje pierwsza wersja. Cały proces budowy opisuję na stronie głównej poradnika.
Opisz w formularzu poniżej, co ma robić Twój produkt. Odezwę się do Ciebie i odpowiem na piśmie na każde z powyższych pytań.
Pytania i odpowiedzi
Czy jedna osoba da radę zbudować cały produkt?
Pierwszą wersję tak. Ważniejsze od liczby osób jest to, kto odpowiada za efekt.
Czy tańszy wykonawca oznacza gorszy produkt?
Nie zawsze, ale niska cena bez rozmowy o produkcie zwykle oznacza, że wykonawca nie wie jeszcze, co buduje. Porównuj oferty dopiero wtedy, gdy każda opisuje ten sam, spisany zakres. Bez tego porównujesz liczby, które dotyczą różnych rzeczy.
Czy podpiszesz umowę o poufności przed rozmową?
Tak, jeśli chcesz, przed rozmową o szczegółach produktu. Kilka moich realizacji jest objętych takimi umowami i dlatego opisuję je bez nazw.
Kontakt
Opisz swój produkt, a odpowiem na każde z tych pytań na piśmie
Nie potrzebujesz specyfikacji. Wystarczy, że opiszesz, jak dziś wygląda praca i co ma się zmienić. Zakres spiszemy razem.