Przed zatrudnieniem firmy programistycznej trzeba dokładnie ustalić, kto będzie pisał kod, jakie podobne systemy już dostarczyła, jak zdefiniowano zakres i odbiór oraz do kogo należy kod od pierwszego dnia. Wymijające odpowiedzi na którekolwiek z tych pytań są poważniejszym sygnałem ostrzegawczym niż wysoka cena.
Kto naprawdę będzie pisał kod
Osoby obecne na spotkaniu handlowym często nie są tymi, które zbudują system. Warto poprosić o nazwiska, role i doświadczenie inżynierów, którzy będą pracować nad projektem, oraz o rozmowę z liderem technicznym przed podpisaniem umowy.
Trzeba też zapytać, czy część prac jest zlecana podwykonawcom lub freelancerom. Oba rozwiązania mogą dobrze działać, ale należy o tym wiedzieć, a partner powinien ręczyć za każdą osobę, którą wprowadza do projektu. Warto również zapytać, co się stanie, jeśli kluczowy inżynier odejdzie w trakcie projektu, i kto zapłaci za czas potrzebny zastępcy na wdrożenie się.
- Kto jest liderem technicznym i jaką część swojego czasu poświęca temu projektowi?
- Którzy inżynierowie są pracownikami, a którzy podwykonawcami lub freelancerami?
- Jak firma wybiera i sprawdza specjalistów, których angażuje?
- Jak wygląda proces, gdy ktoś odchodzi albo nie pasuje do zespołu?
Doświadczenie, które odpowiada Państwa problemowi
Długa lista klientów niewiele dowodzi, jeśli żaden projekt nie przypomina Państwa projektu. Warto poprosić o przykłady z podobnymi ograniczeniami: ten sam rodzaj systemu, porównywalny ruch lub wrażliwość danych, podobny kontekst regulacyjny. Następnie zapytać, co w każdym przypadku zrobił ten konkretny zespół, a nie co osiągnął cały program klienta.
Trzeba jasno ustalić, czyje doświadczenie się kupuje. Niektóre firmy przedstawiają indywidualny dorobek swoich inżynierów, co jest w porządku, jeśli mówią o tym uczciwie. Warto zapytać, kiedy firma została założona, które prace wykonała w ramach własnych umów i czy można porozmawiać z jej byłym klientem.
Zakres, kamienie milowe i odbiór na piśmie
Wiele sporów bierze się z zakresu, którego nigdy nie spisano precyzyjnie. Dobra oferta wymienia rezultaty, dzieli prace na kamienie milowe i określa, jak odbywa się odbiór każdego z nich, na przykład przez testy, które przechodzą, demo w środowisku testowym (staging) lub przekazaną dokumentację.
Warto zapytać, jak obsługiwane i wyceniane są zmiany zakresu oraz jaki jest model rozliczeń. Stała cena pasuje do dobrze zdefiniowanych prac, a rozliczenie czasu i materiałów do fazy rozpoznania i zmieniających się wymagań. W obu przypadkach należy zobaczyć założenia, na których opiera się wycena.
Prawa do kodu i przekazanie projektu ustalone przed startem
Umowa powinna stwierdzać, że kod i związana z nim własność intelektualna należą do Państwa, oraz określać, kiedy następuje przeniesienie praw. Repozytoria, konta chmurowe i domeny najlepiej zakładać w Państwa organizacji od pierwszego dnia, a partnera zapraszać jako współpracownika, aby nigdy nie zależeć od niego w kwestii dostępu.
Przekazanie projektu planuje się na początku, a nie na końcu. Warto zapytać, co zostanie przekazane: dokumentacja, zapisy decyzji architektonicznych, instrukcje operacyjne (runbooki) i sesje robocze z Państwa zespołem. Trzeba też sprawdzić, jakich licencji zewnętrznych i open source projekt będzie używał, bo wiążą się z nimi obowiązki.
Uzgodniony sposób śledzenia postępów
Nigdy nie powinno być potrzeby dopytywania, czy projekt idzie zgodnie z planem. Warto uzgodnić stały rytm, na przykład cotygodniowe demo działającego oprogramowania i krótki pisemny raport o postępach, ryzykach i decyzjach, których potrzeba z Państwa strony.
Należy poprosić o bezpośredni dostęp do systemu zgłoszeń i repozytorium oraz o jedną wskazaną osobę kontaktową, która odpowiada za realizację. Trzeba też ustalić, jak eskalowane są problemy i jak szybko można spodziewać się odpowiedzi.
Praktyki bezpieczeństwa zamiast odznak
Warto zapytać, jak inżynierowie uzyskują dostęp do Państwa systemów i danych, jak przechowywane są sekrety, jak kod jest przeglądany przed wdrożeniem i jak zależności są sprawdzane pod kątem znanych podatności. Konkretne odpowiedzi znaczą więcej niż slajd z logotypami.
Jeśli partner będzie przetwarzał dane osobowe w Państwa imieniu, potrzebna jest umowa powierzenia przetwarzania danych spełniająca wymogi RODO. Jeśli dostawca powołuje się na certyfikat, warto poprosić o jego kopię wraz z zakresem i upewnić się, że obejmuje zespół i usługi, które Państwo kupują.
Sygnały ostrzegawcze, przy których warto przerwać rozmowę
Pojedynczy sygnał ostrzegawczy może mieć wyjaśnienie. Kilka naraz zwykle oznacza, że projekt będzie trudniejszy, niż musiałby być.
- Firma nie potrafi wskazać inżynierów, którzy wykonają pracę.
- Studia przypadków pokazują wyniki, ale nie to, co faktycznie zrobił ten zespół.
- Wycena przychodzi, zanim ktokolwiek zadał szczegółowe pytania o Państwa system.
- Repozytoria i konta chmurowe pozostają pod kontrolą partnera.
- Kamienie milowe nie mają spisanych kryteriów odbioru.
- Na pytania o bezpieczeństwo pada ogólne zapewnienie zamiast konkretnych praktyk.
Najważniejsze wnioski
- Przed podpisaniem umowy warto poznać lidera technicznego i dowiedzieć się, kto będzie pisał kod.
- Doświadczenie ocenia się po tym, jak bardzo odpowiada Państwa ograniczeniom, i po tym, co zrobił sam zespół.
- Spisane kamienie milowe z jasnymi kryteriami odbioru zapobiegają wielu sporom o zakres.
- Repozytoria i konta chmurowe powinny od pierwszego dnia należeć do Państwa organizacji.
- Warto pytać o konkretne praktyki bezpieczeństwa i o dowód każdego certyfikatu, na który powołuje się dostawca.
FAQ
Z iloma firmami porozmawiać przed wyborem?
Z tyloma, by móc porównać realne różnice w podejściu, co w przypadku większości projektów oznacza kilka. Każda powinna dostać ten sam opis projektu i te same pytania, aby odpowiedzi dało się porównać.
Stała cena czy rozliczenie czasu i materiałów?
Stała cena pasuje do prac, które można szczegółowo opisać przed ich rozpoczęciem. Rozliczenie czasu i materiałów (time and materials) pasuje do fazy rozpoznania, zmieniających się wymagań i ciągłego rozwoju, pod warunkiem przejrzystego raportowania i regularnych demo.
Co powinna obejmować pierwsza rozmowa z potencjalnym partnerem?
Państwa cel, ograniczenia, harmonogram i istniejące systemy, a także pytania partnera do Państwa. Partner, który już podczas pierwszej rozmowy zadaje szczegółowe pytania o system, zwykle wyceni go uczciwie. W SDK Enterprises taka pierwsza rozmowa trwa 30 minut i odbywa się po francusku lub po angielsku.