Råd till blivande kalsongkonsulter

Som blivande IT-ingenjör på KTH lever du en ganska okomplicerad tillvaro. Kurserna kommer och går, festerna likaså, du prickar av lagom många av varje sort och så håller du på så i 5-10 år tills du har din examen. Fast det är klart, bor du inte hos sina föräldrar blir det ganska knapert med pengar emellanåt. Du känner att med dina otroliga skillz i både C++ och Java borde du ju kunna skrapa ihop bättre än de tre lax i månaden du lyckats lura till dig från CSN. Då får du syn på den lilla lappen som försöker göra sig sedd i myllret på skolans anslagstavla:

Hej! Jag och en polare har en lysande affärsidé med enorm potentiell marknad som bygger på webben och på iPhone och Android-apps. Tyvärr kan vi inget om programmering men vi tror att du som är student med grymma kunskaper inom databaser, integration mot externa källor, webbutveckling och mobil utveckling kan fixa den tekniska biten om du är villig att lägga några timmar i veckan. Möjlighet till delägarskap i företaget finns om vi ser potential i dig. Vill du tjäna en hacka, jobba med spännande teknik, vara med och skapa något nytt, kontakta mig så berättar jag mer! trettiopoangforetagsekonomi@hotmail.com

Trots bristen på detaljer, projektets uppenbart skakiga underbyggnad och det faktum att “en hacka” förmodligen betyder “del av vinsten ifall vi någonsin får någon, och efter att vi som kom på idén har fått våra 98%” så visst känns det lockande? För din inre syn ser du ett ekonomiskt oberoende innan du ens fyllt 25 jordsnurr, eller åtminstone befrielse från CSN-eländet. Om den första lappen inte är tillräckligt övertygande så hittar du snart fler. Idésprutor och entreprenörer med Handels-examen färsk i fickan skriker efter unga och hungriga (läs: billiga) utvecklare som kan förverkliga deras drömmar.

Been there, done that, som klyschan säger. Det är absolut ett bra sätt att tjäna pengar under tiden man pluggar – i vissa fall dessutom en god stund därefter. Jag kan lugnt säga att alla små konsultuppdrag (för det är ju vad det är) jag åtagit mig under åren på KTH bidragit rejält till att bekosta såväl bilar som andra nöjen. Men fallgroparna är många och man är naturligtvis extra sårbar när man är ung och saknar branscherfarenhet. Ofta lider dessutom beställaren av en svårdiagnosticerad sjukdomsprofil där hybris avseende den egna affärsidén kombineras med en svårartad okunskap om vad som är en realistisk tidsåtgång (och kostnad) för ett stycke mjukvaruutveckling utifrån en spec som är luddigare än vad min katt har mellan bakbenen.

Här kommer därför några råd – eller checkboxar om man så vill – på saker som är bra att hålla koll på innan man ger sig ut på sitt första uppdrag som kalsongkonsult:

  1. Vems är upphovsrätten på det du levererar? Din eller beställarens? Om den är din, hur ser licensavtalet ut för beställarens användande av programvaran efter leverans?
  2. Vem äger specifikationen? Är den huggen i granit från projektstarten eller är den mer flytande? Vet beställaren vad han vill ha? (Nej.)
  3. När ska leveransen vara klar? Vem bestämmer om leveransen är klar? Vad händer om det tar längre tid på grund av oväntade problem? Vad händer om det tar längre tid på grund av att beställaren ändrar sig?
  4. När får du betalt? Hur mycket? Vitt eller svart? Är det beroende av svaret på frågorna ovan? Får du betalt per timme eller förväntar sig beställaren “flat rate”? Vad händer med det överenskomna priset om tidsåtgången eller kraven ändras?
  5. Vem ansvarar för underhåll och support av mjukvaran efter leverans? Kommer beställaren att förvänta sig kontinuerlig tillgång till dig framöver? Får du betalt för det? Vad händer om du vill hoppa av?
  6. Förväntar sig beställaren att få programkoden eller räcker det med binärer?
  7. Ska koden vara dokumenterad? Förväntar sig beställaren att du producerar en användarhandbok eller motsvarande?
  8. Vem bär ansvaret om din kod, g#d förbjude, orsakar någon ekonomisk skada eller används på ett sätt som strider mot lagen?

Givet dessa åtta punkter inser man förstås att man helst vill friskriva sig från precis allt ansvar efter att mjukvaran är levererad, ta betalt per timme (både under projektets gång och för support därefter) men gå med på att beställaren ändrar sina krav under resans gång. Det finns bara ett problem; väldigt få beställare går med på detta. Man vill ha ett fast pris, bestämt på förhand, baserat på en specifikation som är så otydlig att tidsåtgången bara kan uppskattas till “veckor” eller “månader”. I värsta fall erbjuds ingen fast ersättning alls utan bara “del i vinsten”. Mitt råd är att tacka nej till sådana uppdrag. Det minsta man kan begära är betalning vid leverans.

Kravet på ett fast pris är lättare att hantera. Du kan köra Dilbert-varianten och multiplicera din tidsuppskattning med en faktor 20 så att du nästan säkert tjänar på det, även om beställaren ändrar sig i elfte timmen. Du kan kräva att få kraven specade ner till minsta detalj och kräva mer kosing för varje liten ändring. Du kan bita ihop, ta betalt för en ärlig uppskattning och hoppas att det ändå löser sig på något vis. Av dessa alternativ är egentligen inget särskilt bra. Det är upp till dig att avgöra vilket som är minst dåligt.

Sist men inte minst, många beställare vill gärna betala svart. Inte en jättebra idé. Det är förvisso rätt mycket jobb att dra igång en enskild firma, momsregistrera sig och betala F-skatt bara för ett enstaka uppdrag. Men om man tänker göra en hobby av att kalsongkonsulta är det definitivt värt det. Man vet aldrig när ett organisationsnummer kommer till nytta.

Uppdatering (2011-01-05): Fortsättning följde.