Før du hyrer en udviklingspartner, skal du finde ud af, præcis hvem der skal skrive koden, hvilke lignende systemer de har leveret, hvordan omfang og accept defineres, og hvem der ejer koden fra første dag. Uklare svar på et af de spørgsmål er et stærkere advarselstegn end en høj pris.
Find ud af, hvem der rent faktisk skal skrive koden
De personer, der sidder med til salgsmødet, er ofte ikke dem, der bygger dit system. Bed om navne, roller og erfaring på de udviklere, der skal arbejde på projektet, og bed om at tale med den tekniske leder, før du skriver under.
Spørg, om noget af arbejdet lægges ud til underleverandører eller freelancere. Begge dele kan fungere fint, men du bør vide det, og partneren bør stå inde for alle, den tager med ind. Spørg også, hvad der sker, hvis en nøgleudvikler stopper midt i projektet, og hvem der betaler for den tid, en afløser skal bruge på at komme ind i opgaven.
- Hvem er den tekniske leder, og hvor stor en del af sin tid bruger vedkommende på dette projekt?
- Hvilke udviklere er ansatte, og hvilke er underleverandører eller freelancere?
- Hvordan udvælger og kontrollerer I de specialister, I tager med ind?
- Hvad er processen, hvis nogen stopper eller ikke passer ind?
Bed om erfaring, der matcher dit problem
En lang kundeliste beviser ikke meget, hvis intet på den ligner dit projekt. Bed om eksempler med lignende begrænsninger: den samme type system, sammenlignelig trafik eller lige så følsomme data og en lignende regulatorisk sammenhæng. Spørg så, hvad netop dette team gjorde i hvert tilfælde, ikke hvad kundens samlede program opnåede.
Vær præcis med, hvis erfaring du køber. Nogle firmaer præsenterer deres udvikleres individuelle erfaring, hvilket er legitimt, hvis det siges ærligt. Spørg, hvornår virksomheden blev grundlagt, hvilket arbejde der er udført under dens egne kontrakter, og om du kan tale med en tidligere kunde.
Få omfang, milepæle og accept på skrift
Mange tvister skyldes et omfang, der aldrig blev skrevet præcist ned. Et godt tilbud navngiver leverancerne, deler arbejdet op i milepæle og definerer, hvordan hver milepæl godkendes, for eksempel tests, der består, en demo i et stagingmiljø eller leveret dokumentation.
Spørg, hvordan ændringsønsker håndteres og prissættes, og hvad den kommercielle model er. Fastpris passer til veldefineret arbejde, mens afregning efter medgået tid passer til afklaring og krav, der udvikler sig. Uanset hvad bør du kunne se de antagelser, estimatet bygger på.
Afklar ejerskabet til koden og overdragelsen, før I starter
Kontrakten bør fastslå, at du ejer koden og de tilhørende immaterielle rettigheder, og hvornår ejerskabet overgår. Bed om, at repositories, cloudkonti og domæner oprettes i din organisation fra første dag, med partneren inviteret som samarbejdspartner, så du aldrig er afhængig af dem for at få adgang.
Planlæg overdragelsen fra starten, ikke til sidst. Spørg, hvad du får: dokumentation, nedskrevne arkitekturbeslutninger, runbooks til driften og arbejdssessioner med dit eget team. Tjek, hvilke tredjeparts- og open source-licenser projektet vil bruge, for de følges af forpligtelser.
Aftal, hvordan du kan følge fremdriften
Du bør aldrig skulle spørge, om projektet er på rette spor. Aftal en fast rytme, for eksempel en ugentlig demo af software, der virker, og en kort skriftlig status, der dækker fremdrift, risici og de beslutninger, der kræves af dig.
Bed om direkte adgang til issue trackeren og repositoryet og om én navngiven kontaktperson, der står til ansvar for leverancen. Afklar, hvordan problemer eskaleres, og hvor hurtigt du kan forvente svar.
Test deres sikkerhedspraksis, ikke deres badges
Spørg, hvordan udviklerne får adgang til dine systemer og data, hvordan hemmeligheder opbevares, hvordan koden gennemgås, før den sendes ud, og hvordan afhængigheder tjekkes for kendte sårbarheder. Konkrete svar betyder mere end en slide med logoer.
Hvis partneren skal behandle persondata på dine vegne, skal du have en databehandleraftale, der opfylder kravene i GDPR. Hvis en leverandør hævder at have en certificering, så bed om certifikatet og dets omfang, og bekræft, at det dækker det team og de ydelser, du køber.
Faresignaler, der bør stoppe samtalen
Ét advarselstegn kan have en forklaring. Flere på én gang betyder som regel, at projektet bliver sværere, end det behøver at være.
- De kan ikke navngive de udviklere, der skal udføre arbejdet.
- Kundecasene viser resultater, men ikke hvad netop dette team gjorde.
- Estimatet kommer, før nogen har stillet detaljerede spørgsmål om dit system.
- Repositories og cloudkonti forbliver under partnerens kontrol.
- Milepælene har ingen skriftlige acceptkriterier.
- Spørgsmål om sikkerhed besvares med generelle forsikringer i stedet for konkret praksis.
Det vigtigste
- Mød den tekniske leder, og find ud af, hvem der skal skrive koden, før du skriver under.
- Bedøm erfaring ud fra, hvor godt den matcher dine begrænsninger, og ud fra, hvad teamet selv gjorde.
- Skriftlige milepæle med klare acceptkriterier forebygger mange tvister om omfanget.
- Hold repositories og cloudkonti i din egen organisation fra første dag.
- Bed om konkret sikkerhedspraksis og dokumentation for enhver certificering, en leverandør hævder at have.
FAQ
Hvor mange partnere bør jeg tale med, før jeg vælger én?
Nok til at sammenligne reelle forskelle i tilgang, hvilket for de fleste projekter betyder nogle få. Giv dem alle den samme projektbeskrivelse og de samme spørgsmål, så svarene kan sammenlignes.
Skal jeg vælge fastpris eller afregning efter medgået tid?
Fastpris passer til arbejde, du kan specificere i detaljer, før det starter. Medgået tid passer til afklaring, krav, der udvikler sig, og løbende udvikling, forudsat at du får gennemsigtig rapportering og regelmæssige demoer.
Hvad bør et første opkald med en mulig partner dække?
Dit mål, dine begrænsninger, din tidsplan og dine eksisterende systemer og deres spørgsmål tilbage til dig. En partner, der stiller detaljerede spørgsmål om dit system i det første opkald, er som regel en, der vil estimere det ærligt. Hos SDK Enterprises er det første opkald en samtale på 30 minutter på fransk eller engelsk.