Før du engasjerer en partner for programvareutvikling, bør du finne ut nøyaktig hvem som skal skrive koden, hvilke lignende systemer de har levert, hvordan omfang og godkjenning defineres, og hvem som eier koden fra første dag. Vage svar på noen av disse spørsmålene er et sterkere varseltegn enn en høy pris.
Finn ut hvem som faktisk skal skrive koden
Personene i salgsmøtet er ofte ikke de som bygger systemet ditt. Be om navn, roller og erfaring for utviklerne som skal jobbe på prosjektet, og be om å få snakke med den tekniske lederen før du signerer.
Spør om noe av arbeidet settes ut til underleverandører eller gjøres av frilansere. Begge deler kan fungere godt, men du bør vite det, og partneren bør gå god for alle den tar inn. Spør også hva som skjer hvis en nøkkelutvikler slutter midt i prosjektet, og hvem som betaler for tiden en erstatter trenger for å komme inn i arbeidet.
- Hvem er teknisk leder, og hvor mye av tiden sin bruker vedkommende på dette prosjektet?
- Hvilke utviklere er ansatte, og hvilke er underleverandører eller frilansere?
- Hvordan velger og kontrollerer dere spesialistene dere tar inn?
- Hva er prosessen hvis noen slutter eller ikke passer inn?
Be om erfaring som passer til problemet ditt
En lang kundeliste beviser lite hvis ingenting på den ligner prosjektet ditt. Be om eksempler med lignende rammer: samme type system, sammenlignbar trafikk eller like sensitive data, og en lignende regulatorisk kontekst. Spør deretter hva dette teamet gjorde i hvert tilfelle, ikke hva hele kundens program oppnådde.
Vær presis på hvem sin erfaring du kjøper. Noen selskaper presenterer den individuelle erfaringen til utviklerne sine, noe som er legitimt hvis det sies ærlig. Spør når selskapet ble grunnlagt, hvilket arbeid som ble gjort under egne kontrakter, og om du kan snakke med en tidligere kunde.
Få omfang, milepæler og godkjenning skriftlig
Mange tvister kommer av et omfang som aldri ble skrevet presist ned. Et godt tilbud navngir leveransene, deler arbeidet inn i milepæler og definerer hvordan hver milepæl godkjennes, for eksempel tester som består, en demo i et staging-miljø eller levert dokumentasjon.
Spør hvordan endringsønsker håndteres og prises, og hvilken kommersiell modell som gjelder. Fastpris passer til godt definert arbeid, mens medgått tid passer til utforskning og krav som utvikler seg. Uansett bør du få se forutsetningene bak estimatet.
Avklar eierskap til koden og overleveringen før dere starter
Kontrakten bør slå fast at du eier koden og de tilhørende immaterielle rettighetene, og når eierskapet overføres. Be om at repositorier, skykontoer og domener opprettes i din organisasjon fra første dag, med partneren invitert som bidragsyter, slik at du aldri er avhengig av dem for å få tilgang.
Planlegg overleveringen ved starten, ikke ved slutten. Spør hva du vil få: dokumentasjon, beslutningslogger for arkitekturen, driftsinstrukser og arbeidsøkter med ditt eget team. Sjekk hvilke tredjeparts- og åpen kildekode-lisenser prosjektet skal bruke, fordi de medfører forpliktelser.
Bli enige om hvordan du skal se fremdriften
Du skal aldri måtte spørre om prosjektet er i rute. Bli enige om en fast rytme, for eksempel en ukentlig demo av programvare som fungerer, og en kort skriftlig status som dekker fremdrift, risikoer og beslutninger du må ta.
Be om direkte tilgang til saksverktøyet og repositoriet, og om én navngitt kontaktperson som står ansvarlig for leveransen. Avklar hvordan problemer eskaleres, og hvor raskt du kan forvente svar.
Test sikkerhetspraksisen deres, ikke sertifiseringsmerkene
Spør hvordan utviklerne får tilgang til systemene og dataene dine, hvordan hemmeligheter lagres, hvordan kode gjennomgås før den lanseres, og hvordan avhengigheter sjekkes for kjente sårbarheter. Konkrete svar betyr mer enn et lysbilde med logoer.
Hvis partneren skal behandle personopplysninger på dine vegne, trenger du en databehandleravtale som oppfyller kravene i GDPR. Hvis en leverandør hevder å ha en sertifisering, be om sertifikatet og omfanget, og bekreft at det dekker teamet og tjenestene du kjøper.
Røde flagg som bør stoppe samtalen
Ett varseltegn kan ha en forklaring. Flere sammen betyr som regel at prosjektet blir vanskeligere enn det trenger å være.
- De kan ikke navngi utviklerne som skal gjøre jobben.
- Kundehistoriene viser resultater, men ikke hva dette teamet faktisk gjorde.
- Estimatet kommer før noen har stilt detaljerte spørsmål om systemet ditt.
- Repositorier og skykontoer forblir under partnerens kontroll.
- Milepælene har ingen skriftlige godkjenningskriterier.
- Sikkerhetsspørsmål blir møtt med generelle forsikringer i stedet for konkret praksis.
Det viktigste
- Møt den tekniske lederen og finn ut hvem som skal skrive koden, før du signerer.
- Vurder erfaring etter hvor godt den passer til rammene dine, og etter hva teamet selv gjorde.
- Skriftlige milepæler med tydelige godkjenningskriterier forhindrer mange tvister om omfang.
- Behold repositorier og skykontoer i din egen organisasjon fra første dag.
- Be om konkret sikkerhetspraksis og dokumentasjon for enhver sertifisering en leverandør hevder å ha.
Spørsmål og svar
Hvor mange partnere bør jeg snakke med før jeg velger?
Nok til å sammenligne reelle forskjeller i tilnærming, noe som for de fleste prosjekter betyr noen få. Gi alle den samme beskrivelsen og de samme spørsmålene, slik at svarene kan sammenlignes.
Bør jeg velge en kontrakt med fastpris eller etter medgått tid?
Fastpris passer til arbeid du kan spesifisere i detalj før det starter. Medgått tid passer til utforskning, krav som utvikler seg, og løpende utvikling, forutsatt at du får åpen rapportering og jevnlige demoer.
Hva bør en første samtale med en mulig partner dekke?
Målet ditt, rammene, tidsplanen og eksisterende systemer, og spørsmålene deres tilbake til deg. En partner som stiller detaljerte spørsmål om systemet ditt i den første samtalen, er som regel en som vil estimere det ærlig. Hos SDK Enterprises er denne første samtalen en prat på 30 minutter på fransk eller engelsk.