Pierwsza rozmowa z software house'em: jak się przygotować

Na pierwszą rozmowę z software house’em nie trzeba przynosić specyfikacji. Wystarczy, że wiesz, jaki problem chcesz rozwiązać, kto będzie z aplikacji korzystał i do kiedy ma ona działać. Resztę da się ustalić wspólnie, ale tylko wtedy, gdy te trzy rzeczy są jasne. Poniżej piszemy, o co na pierwszej rozmowie pytamy my, i o co warto zapytać wykonawcę, niezależnie od tego, czy będziemy nim my, czy ktoś inny.

Opisz problem, a nie gotowe rozwiązanie

Łatwo przyjść z listą ekranów albo z nazwą technologii, którą ktoś polecił. Bardziej przydaje się jednak opis tego, co dzieje się dziś: kto wykonuje daną pracę, w jakim narzędziu, gdzie traci czas i co ma się zmienić, kiedy aplikacja zacznie działać. Z takiego opisu inżynier wyczyta więcej niż z makiety, bo zobaczy, które kroki trzeba zautomatyzować, a które wystarczy uporządkować. Jeśli masz makietę albo arkusz, w którym dziś pracujecie, pokaż go. To dobry materiał, o ile nie zastępuje opisu problemu.

Sprawdź, gdzie są dane

Jeśli aplikacja ma korzystać z danych, które już macie, warto wiedzieć, gdzie one dziś są: w arkuszu, w systemie ERP, w CRM albo w sklepie internetowym. Nie musisz znać szczegółów technicznych. Wystarczy nazwa systemu i osoba, która odpowie na pytania o dostęp i o to, czy system ma API. Pytamy o to na samym początku, bo od dostępu do danych zależy, jak zaplanujemy integracje i w jakiej kolejności będziemy budować.

Termin, budżet i to, kto decyduje

Powiedz, do kiedy aplikacja ma działać i z czego wynika ten termin, na przykład z sezonu, z targów albo z końca umowy z obecnym dostawcą. Termin, który ma przyczynę, łatwiej zaplanować, bo wiadomo, co musi być gotowe na ten dzień, a co może poczekać. Z budżetem jest podobnie: nawet orientacyjny przedział pomaga dobrać zakres pierwszej wersji, zamiast wyceniać coś, czego nikt nie zamierza kupić. Dobrze też od razu ustalić, kto po Twojej stronie podejmuje decyzje i kto będzie odpowiadał na pytania w trakcie projektu.

O co zapytać wykonawcę

Te pytania warto zadać każdemu wykonawcy, z którym rozmawiasz:

Kto będzie budował projekt i czy ta osoba bierze udział w rozmowie.
Jak będziesz widzieć postęp: czy dostaniesz prototyp, wersje testowe albo dostęp do repozytorium.
Kto będzie właścicielem kodu i kiedy go dostaniesz.
Co dzieje się po wdrożeniu: kto poprawia błędy i aktualizuje zależności.
Jak powstaje wycena i co się dzieje, gdy w trakcie projektu zmieni się zakres.

Prawa do kodu ustalcie na piśmie

Program komputerowy jest w polskim prawie chroniony jak utwór literacki (art. 74 ust. 1 ustawy o prawie autorskim i prawach pokrewnych). Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53), a obejmuje tylko te pola eksploatacji, które są w niej wyraźnie wymienione (art. 41 ust. 2). Dlatego warto, żeby umowa wprost opisywała przeniesienie praw do kodu i wymieniała sposoby, w jakie zamierzasz z niego korzystać. Konkretne zapisy najlepiej skonsultować z prawnikiem. U nas zasada jest prosta: po wdrożeniu przekazujemy kod i dokumentację.

Dane osobowe to osobny temat

Jeśli wykonawca będzie przetwarzał dane osobowe w Twoim imieniu, na przykład podczas migracji danych klientów albo przy utrzymaniu aplikacji, art. 28 RODO wymaga, żeby to przetwarzanie regulowała umowa albo inny instrument prawny wiążący wykonawcę. Warto o tym wspomnieć już na pierwszej rozmowie, żeby umowa powierzenia była gotowa, zanim ktokolwiek zobaczy prawdziwe dane.

Co dalej

U nas po pierwszej rozmowie przychodzi warsztat zakresu. Spisujemy funkcje, ograniczenia i kolejność prac, a na tej podstawie przygotowujemy wycenę. Jeśli chcesz zacząć, opisz projekt w kilku zdaniach. Tyle wystarczy, żeby umówić pierwszą rozmowę.