Å la noen utenfor selskapet ditt endre koden din er en større beslutning enn det ser ut som i et tilbud. Prisen og tidsplanen får oppmerksomheten. Spørsmålene som avgjør om du blir glad for valget senere, er stillere: hvem som eier det som blir skrevet, hva partneren kan komme til, hvem som sier ja før en endring går i drift, og hvordan du kommer deg ut.
Still dem før den første endringen, mens hvert svar fortsatt er billig. Still dem til alle du vurderer: et byrå, en frilanser, en ny leverandør, eller oss.
Eierskap: hvem eier arbeidet?
Svaret du vil ha, er kort. Koden som skrives for deg, er din, uten betingelser. Alt som er lengre, fortjener en nøye gjennomlesning.
- Hvem eier koden når den er skrevet? Ikke «når sluttfakturaen er betalt», og ikke «når prosjektet er ferdig». Eierskap som kommer sent, er et pressmiddel som holdes over deg i mellomtiden.
- Hvor ligger arbeidet mens det pågår? Hvis det ligger hos partneren fram til en overlevering, eier du et løfte i stedet for kode. Arbeid som ligger i ditt eget kodelager fra første dag, trenger ingen overføring i det hele tatt.
- Hva får du ikke? Noen partnere holder deler tilbake, for eksempel et rammeverk de lisensierer til deg eller en komponent de gjenbruker andre steder. Det kan være greit, men du bør vite nøyaktig hvor grensen går før du blir avhengig av det som ligger på den andre siden av den.
- Kunne et annet team tatt over i morgen? Eierskap du ikke kan bruke, er eierskap bare av navn. Kode som en dyktig fremmed kan lese, bygge og endre, er kode du faktisk har.
Tilgang: hva kan de komme til?
Gi det arbeidet trenger og ikke noe mer, og sørg for at du kan se tilgangen og trekke den tilbake.
- Hva nøyaktig vil de trenge tilgang til? En tydelig, kort liste er et godt tegn. «Admin på alt, for sikkerhets skyld» er det ikke.
- Vil de røre produksjonsdata? Mange endringer kan lages og prøves uten. Hvis en partner trenger ekte kundedata, spør hvorfor, og spør hva som skjer med dataene etterpå.
- Hvem på deres side kan bruke tilgangen? Du ga den til et selskap. Finn ut hvordan de hindrer at den sprer seg innad i det selskapet.
- Kan du ta den tilbake på en ettermiddag? Tilgang du ikke kan trekke tilbake raskt, er tilgang du ikke kontrollerer. Behold nøklene i dine egne kontoer og lån dem ut, i stedet for å låne dem tilbake fra noen andre.
Samtaler om sikkerhet glir ofte over i merker og sertifikater. De har sin plass, men de fire spørsmålene over er dem du kan sjekke selv, på dine egne systemer, denne uken.
Godkjenning: hvem sier ja?
Ingenting bør nå brukerne dine uten at noen på din side har sagt ja til det.
- Hvor vil du se en endring før den går i drift? Ikke i en statusrapport, men i selve endringen, med nok forklaring til at du kan følge hva den gjør og hvorfor.
- Hvem på din side godkjenner, og kan de si nei? Et nei som er dyrt eller ubehagelig, er ikke et ekte nei. Sørg for at det å avslå en endring er en vanlig hendelse og ikke en eskalering.
- Hvordan vil du bedømme kvaliteten? Spør hva som følger med hver endring for å vise at den virker: tester du kan kjøre, en side du kan åpne, et før og et etter. Kvalitet du må ta på tro, er bare et håp.
- Hva skjer når noe slipper gjennom? Før eller siden gjør det det, med enhver partner. Spør hvor raskt brukerne dine får et produkt som virker tilbake, og hvem som sier fra til deg.
Det er også her kontrollen ligger. En partner som bestemmer hva som leveres, har tatt over retningen for produktet ditt, uansett hvor høflig. En partner som legger hver endring fram for deg til avgjørelse, har latt retningen bli der den hører hjemme.
Utgang: hvordan kommer du ut?
Spør om slutten i begynnelsen, når ingen blir støtt av spørsmålet.
- Hva har du den siste dagen? Svaret bør være alt du hadde dagen før. Hvis det å gå krever en eksport, en migrering eller en forhandling, er det innlåsing, uansett hvordan det er formulert.
- Hva er oppsigelsestiden, og hva fortsetter i løpet av den? Lange haler er vanlige i kontrakter og sjeldne i tilbud.
- Kan ditt eget team, eller en annen partner, fortsette uten dem? Testen er om arbeidet gir mening uten menneskene som skrev det: en lesbar historikk, beslutninger som er skrevet ned, ingenting som bare kjører på deres maskiner.
- Kan du starte i det små? En partner som har tro på arbeidet, lar deg prøve én del før du forplikter deg til resten. Det er den billigste utgangen som finnes: aldri å gå lenger inn enn du selv velger.
Slik bruker du listen
Du trenger ikke sende alle seksten spørsmålene i én e-post. Velg de to eller tre som bekymrer deg mest, og ta dem opp i den første samtalen.
Lytt mindre til ordene enn til formen på svaret. Korte, enkle svar betyr som regel at partneren har fått spørsmålet før og ikke har noe å skjule. Lange svar med forbehold viser deg hvor du bør lese kontrakten nøye.
Skriv så ned svarene der teamet ditt kan finne dem. Avklart på forhånd slutter disse spørsmålene å være en bekymring du tar med deg inn i hvert møte. Det gjør deg fri til å løfte blikket fra kodebasen til produktet den tjener.
Våre egne svar
Siden vi foreslår å stille disse spørsmålene til alle, er her våre. Arbeidet leveres i ditt eget kodelager. Koden vi bygger for deg, tilhører deg. Vi arbeider innenfor tilgangen du gir, og ikke mer. Du bestemmer hva som leveres. Ingenting når brukerne dine uten din godkjenning. Koden din og produktet ditt er dine å ta med deg hvor som helst.
Det starter med en samtale, helt uforpliktende. Ta med listen.
