Jak przygotować się do rozmowy o nowym systemie

Do pierwszej rozmowy o nowym systemie nie potrzebujesz specyfikacji. Wystarczy, że opiszesz problem, który system ma rozwiązać, i powiesz, kto będzie z niego korzystał. Przyda się też informacja, na jakich danych system będzie pracował i z jakimi programami ma się łączyć. Do tego zbierz ograniczenia: termin, przybliżony budżet i to, kto będzie utrzymywał aplikację po wdrożeniu.

Z takim materiałem rozmowa kończy się konkretnymi pytaniami, a po niej przygotowujemy wycenę. Poniżej lista, z którą możesz przyjść do nas albo do każdego innego wykonawcy. Dotyczy tylko pierwszego kroku. Cały proces opisaliśmy we wpisie jak powstaje oprogramowanie na zamówienie.

Pierwsza rozmowa decyduje o wycenie

Wycena oprogramowania to w praktyce wycena założeń. Jeśli założenia są niejasne, wykonawca ma dwa wyjścia: doliczyć zapas na niewiadome albo wycenić najprostszy wariant i dopisać resztę później. W obu przypadkach tracisz. Przepłacasz albo dostajesz projekt, którego koszt rośnie w trakcie.

Twój problem analizuje u nas zespół projektowy razem z programistami. Analizujemy problem biznesowy, doradzamy rozwiązanie i dopiero na tej podstawie wyceniamy. Konsultacja i analiza wymagań przed wyceną są bezpłatne. Wycenę przygotowujemy w ciągu do 5 dni roboczych, zwykle w 2 dni. Tak zaczynamy pracę nad aplikacją webową na zamówienie.

Conetso to także administratorzy systemów i sieci, dlatego już na tym etapie pytamy o infrastrukturę: gdzie aplikacja ma działać i kto ją będzie utrzymywał. Od czego dokładnie zależy kwota, opisaliśmy we wpisie ile kosztuje aplikacja webowa na zamówienie.

Jak opisać problem zamiast gotowego rozwiązania?

Zacznij od opisu tego, co dziś nie działa. Najczęstszy błąd to przyjście z listą ekranów („potrzebujemy panelu z tabelą i przyciskiem eksportu”). Pomogą odpowiedzi na trzy pytania:

• Co robicie dziś i ile czasu Wam to zajmuje? Na przykład: „zlecenia przychodzą mailem, ktoś przepisuje je do arkusza, a potem dzwoni do pracowników”.
• Gdzie powstają błędy? Zgubione zlecenia, podwójne rezerwacje, rozjazd między arkuszem a fakturami.
• Co ma się zmienić po wdrożeniu? Jedno, dwa zdania o efekcie, np. „klient sam zgłasza zlecenie, a menedżer widzi, kto jest wolny”.

Na starej stronie Conetso Software pokazywaliśmy taki przykład. Firma usługowa przyszła z wymaganiami systemu do obsługi zleceń i zarządzania pracownikami. Nasz zespół zaproponował dodanie płatności online i automatycznego fakturowania. Taka propozycja jest możliwa tylko wtedy, gdy rozumiemy cały proces. Podobny system opisaliśmy w realizacji Service Quotes.

Lista kontrolna przed rozmową

Nie musisz mieć odpowiedzi na wszystko. Zaznacz, czego nie wiesz. To też jest informacja.

Obszar	Co przygotować	Po co nam to
Problem	3–5 zdań o tym, co dziś nie działa i co ma się zmienić	Ustalamy cel projektu i to, co będzie miarą sukcesu
Użytkownicy i role	Kto będzie korzystał z systemu: pracownicy, klienci, partnerzy, administrator. Kto co może widzieć i zmieniać	Liczba ról i uprawnień to jeden z głównych czynników ceny
Proces	Kolejne kroki od zgłoszenia do zamknięcia sprawy, z wyjątkami („a co, jeśli klient odwoła?”)	Obsługa wyjątków często zajmuje więcej pracy niż ścieżka podstawowa
Dane	Przykładowe arkusze, formularze, dokumenty (z usuniętymi danymi osobowymi)	Widzimy, jakie dane system ma przechowywać i czy trzeba je przenieść
Integracje	Z czym system ma się łączyć: księgowość, CRM, płatności, poczta, SMS, system branżowy	Każda integracja to osobna praca i zależność od dokumentacji drugiej strony
Materiały wizualne	Zrzuty ekranów programów, które lubicie albo których nie znosicie, gotowe makiety, jeśli są	Szybciej ustalamy oczekiwania co do interfejsu
Ograniczenia	Termin, przybliżony budżet, wymagania prawne (np. dane pacjentów), gdzie aplikacja ma działać	Bez tego nie da się zaproponować sensownego zakresu pierwszej wersji
Decyzje	Kto po Waszej stronie zatwierdza zakres i odbiera kolejne etapy	Projekt bez osoby decyzyjnej stoi

Podział na „musi być” i „byłoby miło”

Podziel funkcje na dwie listy jeszcze przed rozmową. „Musi być” to wszystko, bez czego system nie zastąpi obecnego sposobu pracy. „Byłoby miło” to usprawnienia, które mogą poczekać na kolejny etap.

Dzięki temu podziałowi proponujemy pierwszą wersję, która zaczyna działać szybciej. Resztę wyceniamy jako rozwój. Jeśli zastanawiasz się, czy w ogóle budować własny system, czy kupić gotowy program, zacznij od wpisu oprogramowanie dedykowane czy gotowe. Opisujemy tam, kiedy własny system ma sens.

O co zapytamy na pierwszym spotkaniu?

Z naszej strony zwykle padają te pytania:

1. Ile osób będzie korzystać z systemu i czy będą to także osoby spoza Twojej firmy (klienci, partnerzy)?
2. Czy system ma przechowywać dane osobowe? Jeśli tak, jakie (np. dane o zdrowiu)?
3. Z jakich urządzeń użytkownicy będą korzystać: komputer w biurze, telefon w terenie, tablet?
4. Czy system ma przyjmować płatności albo wystawiać dokumenty sprzedaży?
5. Gdzie aplikacja ma działać: w chmurze, na Waszym serwerze, a może nie macie zdania?
6. Kto będzie utrzymywał system po wdrożeniu i czy potrzebujecie wsparcia technicznego?
7. Czy jest termin, którego nie da się przesunąć (sezon, otwarcie nowego oddziału, koniec umowy na stary program)?

Pytania 5 i 6 często zaskakują. Po wdrożeniu instalujemy aplikację na docelowym serwerze, podłączamy domenę i konfigurujemy szyfrowane połączenie. Potem możemy przeszkolić zespół, zapewnić wsparcie techniczne i procedury kopii zapasowych bazy danych. Dlatego wolimy znać te potrzeby od początku, zanim dojdziemy do odbioru.

Jakie materiały wysłać przed spotkaniem?

Przed rozmową możesz wysłać:

• krótki opis problemu (może być w treści maila),
• przykładowe pliki, na których dziś pracujecie, bez danych osobowych; wystarczy kilka wierszy z wymyślonymi nazwiskami,
• zrzuty ekranów obecnego programu albo linki do aplikacji, które Wam się podobają,
• listę systemów, z którymi trzeba się połączyć, z nazwą producenta i informacją, czy macie do nich dostęp przez API (interfejs do wymiany danych między programami).

Nie przygotowuj długiej specyfikacji na siłę. Dokument pisany bez rozmowy z wykonawcą często opisuje rozwiązanie zamiast potrzeby. Potem trzeba go przepisywać.

Czego nie musisz wiedzieć przed rozmową

Nie musisz wybierać technologii, bazy danych ani dostawcy chmury. Nie musisz też wiedzieć, ile ekranów będzie miała aplikacja. To nasza praca: na podstawie Twojego opisu proponujemy architekturę i zakres. Pracujemy m.in. w Next.js, React, TypeScript, .NET Core i PostgreSQL, ale technologię dobieramy do projektu.

Nie musisz też znać ostatecznego budżetu. Pomaga jednak, jeśli powiesz, jaki rząd wielkości jest dla Ciebie realny. Wtedy od razu proponujemy wariant, który się w nim mieści. Nie tracimy czasu na wycenę wersji, której i tak nie zamówisz.

Jeśli masz pomysł na system albo problem do rozwiązania, opisz go w formularzu wyceny. Przeanalizujemy wymagania i odezwiemy się z pytaniami oraz wyceną.