Innan du anlitar en partner för mjukvaruutveckling: ta reda på exakt vem som ska skriva koden, vilka liknande system partnern har levererat, hur omfattning och godkännande definieras och vem som äger koden från första dagen. Vaga svar på någon av de frågorna är ett tydligare varningstecken än ett högt pris.
Ta reda på vem som faktiskt ska skriva koden
De som sitter med på säljmötet är ofta inte de som bygger ditt system. Be om namn, roller och erfarenhet för de utvecklare som ska arbeta i projektet, och be att få prata med den tekniska ansvariga innan du skriver på.
Fråga om något av arbetet läggs ut på underleverantörer eller görs av frilansare. Båda kan fungera bra, men du ska veta om det, och partnern ska gå i god för alla som den tar in. Fråga också vad som händer om en nyckelperson slutar mitt i projektet, och vem som betalar för den tid en ersättare behöver för att komma in i arbetet.
- Vem är tekniskt ansvarig, och hur stor del av sin tid lägger personen på det här projektet?
- Vilka utvecklare är anställda, och vilka är underleverantörer eller frilansare?
- Hur väljer och kontrollerar ni de specialister ni tar in?
- Hur går ni till väga om någon slutar eller inte passar?
Be om meriter som motsvarar ditt problem
En lång kundlista bevisar inte mycket om inget av det liknar ditt projekt. Be om exempel med liknande förutsättningar: samma typ av system, jämförbar trafik eller lika känsliga data, och ett liknande regelverk. Fråga sedan vad just det här teamet gjorde i varje fall, inte vad hela kundens program uppnådde.
Var noga med vems erfarenhet du köper. Vissa företag lyfter fram sina utvecklares individuella meriter, vilket är legitimt om det sägs öppet. Fråga när företaget grundades, vilket arbete som gjordes under dess egna avtal och om du kan prata med en tidigare kund.
Få omfattning, delmål och godkännande skriftligt
Många tvister beror på en omfattning som aldrig skrevs ner exakt. Ett bra förslag namnger leveranserna, delar upp arbetet i delmål och definierar hur varje delmål godkänns, till exempel tester som går igenom, en demo i en testmiljö eller levererad dokumentation.
Fråga hur ändringsönskemål hanteras och prissätts, och vilken affärsmodell som gäller. Fast pris passar för väldefinierat arbete, medan löpande räkning passar för förstudier och krav som utvecklas. Oavsett vilket ska du få se antagandena bakom uppskattningen.
Reda ut äganderätten till koden och överlämningen innan arbetet börjar
Avtalet ska ange att du äger koden och tillhörande immateriella rättigheter, och när äganderätten övergår. Be om att kodförråd, molnkonton och domäner skapas i din organisation från första dagen, med partnern inbjuden som medarbetare, så att du aldrig är beroende av partnern för åtkomst.
Planera överlämningen i början, inte i slutet. Fråga vad du kommer att få: dokumentation, dokumenterade arkitekturbeslut, driftrutiner (runbooks) och arbetssessioner med ditt eget team. Kontrollera vilka licenser för tredjepartskomponenter och öppen källkod projektet kommer att använda, eftersom de medför skyldigheter.
Kom överens om hur du ska se framstegen
Du ska aldrig behöva fråga om projektet går enligt plan. Kom överens om en fast rytm, till exempel en demo varje vecka av fungerande mjukvara och en kort skriftlig lägesrapport som tar upp framsteg, risker och beslut som behövs från dig.
Be om direkt åtkomst till ärendehanteringen och kodförrådet, och om en namngiven kontaktperson som ansvarar för leveransen. Klargör hur problem eskaleras och hur snabbt du kan räkna med svar.
Pröva deras säkerhetsrutiner, inte deras märken
Fråga hur utvecklarna får åtkomst till dina system och data, hur hemligheter lagras, hur koden granskas innan den levereras och hur beroenden kontrolleras mot kända sårbarheter. Konkreta svar betyder mer än en bild med logotyper.
Om partnern ska behandla personuppgifter för din räkning behövs ett personuppgiftsbiträdesavtal som uppfyller kraven i GDPR. Om en leverantör hävdar att den har en certifiering: be om certifikatet och dess omfattning, och kontrollera att det täcker teamet och tjänsterna du köper.
Varningstecken som borde avsluta samtalet
Ett enskilt varningstecken kan ha en förklaring. Flera tillsammans betyder oftast att projektet blir svårare än det behöver vara.
- De kan inte namnge utvecklarna som ska göra jobbet.
- Kundcasen visar resultat men inte vad just det här teamet faktiskt gjorde.
- Uppskattningen kommer innan någon har ställt detaljerade frågor om ditt system.
- Kodförråd och molnkonton stannar under partnerns kontroll.
- Delmålen saknar skriftliga kriterier för godkännande.
- Säkerhetsfrågor besvaras med allmänna försäkringar i stället för konkreta rutiner.
Det viktigaste
- Träffa den tekniskt ansvariga och ta reda på vem som ska skriva koden innan du skriver på.
- Bedöm meriter efter hur väl de motsvarar dina förutsättningar och efter vad teamet självt gjorde.
- Skriftliga delmål med tydliga kriterier för godkännande förebygger många tvister om omfattningen.
- Håll kodförråd och molnkonton i din egen organisation från första dagen.
- Be om konkreta säkerhetsrutiner och bevis för varje certifiering en leverantör hävdar att den har.
Vanliga frågor
Hur många partner ska jag prata med innan jag väljer?
Tillräckligt många för att kunna jämföra verkliga skillnader i arbetssätt, vilket för de flesta projekt betyder några stycken. Ge var och en samma underlag och samma frågor, så att svaren går att jämföra.
Ska jag välja ett avtal med fast pris eller på löpande räkning?
Fast pris passar för arbete som du kan specificera i detalj innan det börjar. Löpande räkning passar för förstudier, krav som utvecklas och löpande utveckling, förutsatt att du får öppen rapportering och regelbundna demos.
Vad ska ett första samtal med en möjlig partner ta upp?
Ditt mål, dina begränsningar, din tidsplan och dina befintliga system, och deras frågor tillbaka till dig. En partner som ställer detaljerade frågor om ditt system redan i första samtalet är oftast en som kommer att uppskatta det ärligt. Hos SDK Enterprises är det första samtalet ett 30 minuter långt samtal på franska eller engelska.