Missförstånd mellan mig och kodare
 

Hej!

Det har uppstått ett "missförstånd" mellan mig och en kodare. Jag tycker att jag har förklarat vad jag vill ha genom bilder och text men har säkert missat någon småbit, det är omöjligt att tänka på allt innan och jag har besvarat de frågor som han ställt till mig under tiden. Bland annat så hade jag inte speciferat exakt hur jag ville att datan skulle vara sparad men angett att det var något vi skulle diskutera senare så att det blev som jag ville ha det. Men nu är det som så att han säger att han tänker avsluta projektet på sitt eget sätt medan jag inte är nöjd med lösningen.

Han påstår bland annat att jag genom att ha accepterat hans lösning med att inte ha några sidotabeller även innebar att han inte behövde normalisera tabellen etc, vilket inte jag tycker. Han säger att hans bud från början gällde det han trodde att jag vill ha och säger att han inte har tid eller lust att fixa till vårt missförstånd. Innan vi kom fram till ett gemensamt beslut så la vi även ned stor möda på att försöka förstå varandra så bra som möjligt vilket vi tydligen ändå misslyckats med.

Så jag undrar helt enkelt vems fel är det? Är det jag måste stå för kostnaden att betala en annan kodare att slutföra hans jobb eller hans fel som inte uppfattat mig korrekt? Att vi tolkar saker olika är rätt självklart men att inte vilja åtgärda att vi tolkat saker olika tycker jag är dåligt. All kontakt har enbart skett via mail.

Vad står i avtalet och kravspecifikationen? Det är det som gäller!

Jag skulle inte säga att det är helt enkelt. Om jag fick kod levererad till mig som var total skit, icke normaliserad databasstruktur och dåligt skriven efter vår överenskommelse så skulle jag helt enkelt inte betala för den. Samtidigt vet jag att jag är hyfsat noggrann i uppdragsbeskrivningar.

Jag har varit med i vissa projekt där beställaren inte är så noga, ändrar sig efter vägen och inte riktigt vet hur de ska ha det. Dessutom vill de inte betala rimlig summa för arbetet och kommunicerar sisådär. I dessa fall anser jag att det är beställarens fel. Till detta har beställaren ofta inte kollat upp programmeraren alls. Kan personen i fråga inte normalisera data borde han/hon kanske inte anlitas.

Sen är det synd att vissa programmerare inte kan sitt jobb, de bör heller inte anlitas.

Det är rätt ofta man får "rita och förklara med enkla ord" för en kund att "en snygg hemsida som skall ha funktionen XYZ, ungefär som de har på www.någon-skum-sida.nu" inte räcker som kravspec. När kunden då anser att jag som utvecklare borde veta hur man bygger "funktion XYZ" , som jag ofta inte har en susning om hur den förväntas fungera, brukar man få förklara lagom pedagogiskt att "ja jag kan bygga nånting som ser ut som det du länkade till, men jag garanterar inte att det kommer fungera som DU hoppas eftersom jag inte har en aning om vad det är du vill ha.

Det är ju lite som om jag skulle gå in på en restaurang, bara beställa med "Jag var på en annan restaurang veckan och såg en kille som åt något som såg gott ut, det vill jag ha, fast inte lika mycket sallad..."

Jag kan inte helt säga att jag kan svära mig fri från allt ansvar. Kodaren kan normalisera och grundlig koll gjordes innan rent kunskapsmässigt. Det verkar mer som en ovilja från hans sida att rätta till problem som uppstått under projektets gång som han helt enkelt har struntat i att förklara mig när han upptäckt.

Exempelvis om jag får in en viss typ av data så blir det fel. Sättet det blir fel på är ett sätt som jag som köpare inte tänkte att det kunde bli fel på innan jag fick se det med egna ögon i slutproduktet. Hur kan skriva ned att problem som jag inte är medveten om i början av projektet ska lösas är frågan?

Så där tycker jag helt enkelt att det är dåligt av kodaren att påstå att det inte är hans skyldighet att rätta till sånna fel.

Hur själva projektet ska vara utformat har han förstått väl genom de bilder och beskrivningar han har fått. Problemen är helt enkelt problem som uppstår när man matar in data på speciella sätt. Han har varit väl medveten om att data kan matas in på dessa sätt då jag fått loggar från användare av det tidigare systemet som jag skickat till honom och klart och tydligt angett att den ska kunna ta emot data på dessa olika sätt. Den klarar som sagt av att ta emot datan på dessa olika sätt men den sparar bara ned den vilket gör det omöjligt att filtrera datan som den är nu.

Exempelvis att datum fås in på 4 olika sätt. Problemet jag själv kan känna mig skyldig till här är att jag bara lite kort nämnt syftet med hur datan senare ska användas, nämligen filtreras. Jag har koncenterat mig på att du ska lösa det här. Men borde man inte som kodare åtminstone reagera på att datum skrivs på olika sätt och fråga om det är rätt?

Kihlbom: i mitt fall har jag vetat hur jag vetat ha det från början och försökt föra över det till kodaren. Sen så har vi ändrat vissa delar genom överenskommelse. Vi har haft daglig kontakt via mail och jag har besvarat de han har frågat efter så det känns som att vi har haft en bra kontakt. Problemen har uppstått när jag har fått testa hans lösning och inte är helt nöjd med hur han löst. Han har löst problemet som han ska men jag är inte nöjd med hur han löst det eftersom att jag nu inte kan använda datan från projektet som jag vill även om datan finns där. Han har gjort som han ska men utan att tänka, hade jag programmerat detta själv så hade jag reagerat på detta. Jag anser att man som kodare måste kunna analysera att här kan det gå fel och berätta det för mig kunden och inte bara göra upp och ned vad som är föreslaget utan att tänka. Jag får tyvärr lite den dåliga bilden av en kodare, nämligen att han har suttit ensam i ett mörkt rum och inte har vetskap om vad som kan hända i världen utanför.

Vi har även lyckats tolka vissa av våra överenskommelser på olika sätt vilket känns oerhört konstigt då det har i stunden vi kommit fram till dem känts som att vi har varit helt överens. Men när jag har fått se slutresultatet upptäcker jag att han har löst det på ett annat sätt som jag inte har tolkat överenskommelsen. Han har i vissa fall löst det på det sätt som jag först specifierat men som han påpekat var en mindre bra lösning och föreslagit en annan lösning som jag hållt med om att är bättre och accepterat. Då undrar man varför han frågade i första fallet när han ändå inte gör som vi kom överens om senare i projektet. Var det mer tidskrävande att lösa det på hans sätt och bara struntat i det eller vad (han har undvikt att svara på detta)? Det känns som en väldigt komplex sits.

Jag är dock ganska ny på att anlita externa kodare så när det blir såhär känner man sig ju mindre road att göra det i fortsättning. Jag undrar helt enkelt om det finns någon mall eller liknande som man kan följa för att jag som köpare åtminstone ska ha fått ned risken att det ska bli såhär i kommande situationer. Hur skriver ni en uppdragsbeskrivning mellan dig som köpare och en kodare om vad han ska göra?

De fel du beskriver är typiska fel som uppstår vid felaktiga krav. Dvs beställaren har inte angett exakt vad denne vill ha ut av projektet.

Det finns bara ett vettigt sätt att få det rätt och det är att göra en kravspecifikation enligt konstens alla regler och specificera ALLT som du vill få ut.

Som beställare måste man även ha olika testfall med testdata som systemet ska klara av.

Det framgår inte om det är ett fastprisprojekt eller om det är på löpande räkning. Fastprisprojekt måste alltid vara väl dokumenterade i form av krav om de ska vara möjliga att genomföra framgångsrikt.

Både krav och testfall måste vara skrivana på ett sånt sätt att en oerfaren utvecklare kan förstå vad som ska göras. Det ska även vara så utförligt specificerat att en oberoende extern part kan bedöma i efterhand om kraven är uppfyllda eller inte.

Om man är ovan som beställare ska man i första hand anlita en oberoende men erfaren konsult för att bedöma kraven, om de är tillräckliga för att gå vidare och anlita en utvecklare.

Jag har skrivit mycket om detta i andra trådar här på WN, bristfälliga krav är den enskilt största anledningen till havererade projekt.

Det är aldrig utvecklarens jobb att veta vad beställaren vill ha, det kan bara beställaren veta. Då förstår man också varför beställaren och ingen annan ska dokumentera alla sina krav på systemet.

Utvecklarens jobb är bara att översätta kraven till ett system, utvecklaren har normalt inte kunskaper om beställarens verksamhet, därför måste beställaren vara tydlig i sina krav.

Det exempel du nämner, att du som beställare upptäcker att datat kan matas in på andra sätt än beställaren tänk från början, detta är INTE utvecklarens ansvar, det är beställarens ansvar och man kan inte ställa ktav på att utvecklaren ska åtgärda detta gratis. Felet ligger ju helt och hållet på bristfälliga krav, och kraven är som sagt beställarens ansvar.

Man kan inte förvänta sig att utvecklaren ska göra mer än vad som uttryckligen står i kravdokumentationen vid ett fastprisprojekt. Vid löpande uppdrag så ska alltid beställaren betala för utfört och redovisat arbete.

Vad som är viktigt är vad som står i avtalet och vad som står i kravspecifikationen, det är det man har kommit överens om inget annat. Tillkommande atrbetsuppgifter ska alltid bekostas av beställaren.

Det är ju som Conny säger, men en bra utvecklare måste ju också kunna tänka lite själv i de fall som kraven är lite bristfällande och då rådgöra med beställaren.
Exemplet med att samma data sparas i olika format i databasen är ju ett typiskt exempel på något där utvecklaren bör tänka efter om det rimligt att göra det så och kontrollera med beställaren om det inte uttryckligen står i kraven att beställaren vill ha det så.

Man kan ju inte kräva att kraven ska täcka varenda detalj och en bra utvecklare tar ju inte var enda genväg denne kan hitta så länge kraven uppfylls om man inte fått instruktioner att göra det.

Kör man fastpris som utvecklare får man ju räkna med att det blir problem och lägga på 10-30%(beroende på erfarenhet och komplexitet i systemet) på den uppskattade tiden.

Det handlar väl mycket om att välja rätt utvecklare antar jag, men det är ju såklart inte så lätt.

Det är viktigt att parterna är noga med att specificera allt som kravställaren vill ha och se till att man har ett bra avtal annars skiter det sig ganska säkert.

I det här fallet är det två problem, en helt oerfaren kravställare och en hyfsat oerfaren (dvs billig) utvecklare, det är ingen bra kombination. Min farhåga är desutom att de varken har avtal eller kravspecifikation i skriftlig form, då är det som upplagt för problem.

Men det är viktigt att kravställaren ska ställa krav utifrån hur det ska fungera i sin verksamhet, inte tekniska krav, för det har beställaren/kravställaren oftast inte tillräckliga kunskper för. Till detta hör att specificera lämpliga testfall så utvecklaren kan testa att dessa testfall fungerar innan denne överlämnar sin leverans.

Allt som kravställaren "kommer på" i efterhand ska beställaren betala utöver fastpriset, det är inte utvecklarens ansvar att stå för den kostnaden.

Börja alltid med att specificera systemets ansvarsområde så du begränsar omfånget, det är lätta tt ställa krav så systemet blir gigantiskt och därmed dyrare än nödvändigt, bättre är att bygga små system som snabbare kommer i produktion.

Definiera vilka olika roller som ska använda systemet, det är helt avgörande för hur man bygger upp strukturen i systemet, exempelvis ska varje externt system som kommunicerar med systemet ha egna roller definierade. Givetvis ska vanliga användare och administratörer ha olika roller m.m.

Kravspecen ska vara specificerad så att kravet är fullständigt beskrivet med text och förväntat resultat gärna i punktform eller med s.k användningsfall (som oftast är helt otekniska beskrivningar av hur rutinen ska fungera i verksamheten). På samma sätt ska testfall beskrivas medinmatningsvärden och förväntat resultat.

Det går alltså INTE att skriva som krav att: "Systemet ska fungera som systemet XYZ", då har man inte specificrat hur det ska fungera utan givit en extern referens till ett system som utvecklaren inte vet hur det fungerar. Det är ett mycket dåligt sätt att beskriva ett krav på.

Kravspecen måste också innehålla en konceptuell informationsmodell/datamodell, vilka begrepp som används i verksamheten och hur de relaterra till varandra.

Ett första steg är att skriva upp alla krav kravställaren har på systemet, sen kan man lämpligen göra en WBS (Work Breakdown Structure) för att bryta ner kraven till de minsta beståndsdelar där utvecklaren "vet" vad som behöver göras. En sån WBS brukar vara mycket matnyttig för att upptäcka saker man missat att ta hänsyn till i sitt projekt. Men detta ska göras INNAN man börjar med projektet, det är en del av förstudien/kravarbetet. När man har en komplett WBS brukar det vara mycket enklare att tids-/resursestimera projektet.

Skilj även på Funktionella krav (Verksamhetskrav) och Icke Funktionella krav (Tekniska krav och allt annat som inte är rena verksamhetskrav).

Sammanfattningsvis kan man anvönda följande mall för att komma igång med sina kravdefinitioner:


PRIMITIV MALL FÖR KRAVSPECIFIKATION:

Icke funktionella krav:
- Ekonomiska ramar
- Tidsmässiga Ramar
- Juridiska krav (Lagar som PUL, Avtal m.m.)
- Tekniska krav (Utvecklingsmiljö, operativsystem, programspråk, ramverk, protokoll m.m.)
- Effektmål i verksamheten (vad har du för mål med systemet i din verksamhet, (hör egentligen till förstudien)

Funktionella krav (Verksamhetskrav):

Användningsfall/Userstories:

Krav 1: ...
Krav 2: ...
.
.
.


Testfall:

Testfall 1: ...
- Input:
- Förväntad output:

Testfall 2: ...
- Input:
- Förväntad output:

Testfall 3: ...
- Input:
- Förväntad output:

Testfall 4: ...
- Input:
- Förväntad output:

Testfall 5: ...
- Input:
- Förväntad output:

Riktigt bra inlägg Conny! Tack!

Då har jag äntligen hittat ett riktigt bra användningsområde för användarfall som jag lärt mig i skolan.. :)

I en idealisk värld skulle alla mina kunder skriva en kravspec som inte lämnar någon risk för missförstånd.
I den värld jag verkar som ensam frilansare är det dock tyvärr en ovanlighet med kunder som klarar att skriva en kravspec alls.

Det gör att jag tycker det blir en bedömningsfråga från fall till fall hur noga man skall vara med specifikationen. Jag var van vid grundliga specifikationer efter att ha jobbat för webbyråer på större projekt, och efter att ha flyttat tillbaka till Sverige och börjat jobba hemifrån försökte jag till en början göra allt jag kunde för att se till att specifikationer var så noggranna som möjligt, men insåg snabbt att det inte var värt det extra arbete det medförde på många projekt.

Dels är det många som är motvilliga till att betala för att få en kravspec skriven, och specifikationen behövs ju innan man tar fram en offert. Många verkar ha svårt att förstå att en ordentlig specifikation är något de har nytta av även om de inte accepterar min offert, utan de ser det som att de betalar för framtagning av offerten.
Man får göra sitt bästa för att förklara för dem, men skulle jag haft det som krav att de betalar för att ta fram specifikationen skulle jag missat många kunder som annars är bra och resonliga.

Sedan är det för mindre projekt ofta så att det tar oproportionerligt mycket tid att ta fram en grundlig specifikation. Då kan det löna sig att helt enkelt göra lite arbete som inte var specificerat snarare än att spendera tid på specifikationen. Självfallet tar man med det i beräkningen då man tar fram en offert och lägger på lite extra tid för oförutsedda tillägg eller ändringar.

Säg att det är ett jobb som skall ta fem dagar att genomföra. Skriva specifikationen kan ta en dag. Begär jag av kunden att han först skall betala för en dag för specifikationen för att komma fram till att det går åt fem dagar för arbetet tas inte alltid det emot så väl, och de kanske hellre väljer den som vill ha betalt för sju dagar men inte kräver att man först tar fram en grundlig specifikation.
Säger jag istället sex dagar till att börja med och ställer upp på att göra lite saker som inte var specificerade så blir kunden nöjd eftersom den känner jag har gjort lite extra.
Visar det sig att det blir mer än lite extra är kunden ofta förstående till att betala mer om man redan visat att man är tillmötesgående genom att göra en del mindre jobb som inte var inkluderat i specifikationen.

Självfallet finns det en viss risk med att inte ha en grundlig specifikation, men mindre projekt tycker jag ofta fördelarna kan överväga nackdelarna och hittills har det fungerat bra för mig. Jag har inte haft några projekt där kunderna vägrat acceptera leverans eller där de protesterat om jag har krävt extra betalt.
Och skulle det någon gång hända att jag inte kan komma överens med en kund då det gäller ett mindre projekt är jag övertygad om att jag fortfarande har tjänat på ett inte alltid kräva en perfekt specifikation.

Vi är nog rörande överens om att det finns ett problem med att ha bristfälliga kravspecifikationer.

Vi har däremot olika uppfattning hur problemet ska hanteras på bästa sätt.

Jag ser dock att i TS fall så skulle det ha varit till hjälp för båda parter att ha tagit fram en kravspec eftersom beställaren och leverantören har helt olika uppfattning om vad jobbet innebar.

Beställarna måste höja sin kompetens vad gäller just beställarfunktionen och vara beredda på att ta fram ordentliga kravspecar, leverantören behöver vara hårdare och inte acceptera jobb utan tillräckliga specifikationer, då undviker man många tvister.

Jag sammanfattar det som jag brukar; En överenskommelse/avtal/specifikation som inte tål att dokumenteras på papper är inte värd pappret den är skriven på!

Då beställaren inte är en organisation som har anställda med den kunskap som krävs för att ta fram en grundlig specifikation är det dock svårt att begära det av dem.

Jag tycker det förefaller som TS problem verkar ha att göra med en utvecklare som inte har kommunicerat väl och inte gjort ett bra jobb. Även om det är mindre sannolikt så är det inte säkert att en grundlig specifikation helt hade undvikit situationen. Som beställare skall du inte behöva presentera en databasstruktur, utan det skall utvecklaren klara. En utvecklare som inte klarar det kommer förmodligen heller inte klara att skriva en specifikation som håller en hög standard.

Vill man som företagare utan tillräcklig kunskap för att skriva grundliga specifikationer minimera riskerna för problem med en utvecklare är det bästa förfarandet att först beställa en specifikation. Då kan man om inte annat få en bättre uppfattning om utvecklarens kompetens. Det kan vara en hel del jobb och kan höja kostnaden på projektet, och i vissa fall kan det faktiskt vara värt risken att nöja sig med en mindre omfattande specifikation, men det kräver självfallet att du kan lita på att utvecklaren har en bra förståelse för projektet och bryr sig om att hitta optimala lösningar.

Mitt svar var från en utvecklares perspektiv, och även om en beställare kan tjäna på att strunta i att ta fram en grundlig specifikation är det sällan ett tillvägagångssätt jag skulle rekommendera, framförallt inte med en utvecklare man inte har tidigare erfarenhet av att jobba med. Men om man som utvecklare vet med sig att man brukar göra ett jobb som kunderna blir nöjda med utan att ha dokumenterat allt i minsta detalj, kan det vara ok att gå med på att göra mindre jobb utan en grundlig specifikation om kunden inte vill betala för att du skall skriva specifikation innan du ger en offert.

Det tar emot för mig att acceptera sådana förhållanden, men det är verkligheten som jag har erfarit den, och även om det kan verka slarvigt och riskabelt har det inte resulterat i några problem för mig under de ca 8 år jag jobbat som enskild frilansare.

Tycker det låter helt bakvänt att leverantören skall skriva kravspecen som du verkar vara inne på!?

Som utvecklare förväntas man få en kravspec från beställaren. Sedan kan givetvis en beställare lägga ut specifikationsjobbet på någon som kan verksamheten bra, men detta har normalt inget med själva utvecklingsjobbet att göra. Enligt min erfarenhet är det mycket olyckligt om en kravspec skrivs av den som skall göra utvecklingen.

Jag måste hålla med blixtsystems här.

Det är orimligt att som utvecklare kräva att beställaren ska ha kompetensen att själv till ta fram kravspecifikationer som beskriver exakt hur slutresultatet ska bli om man inte jobbar emot stora företag eller organisationer. Anledningen till att man anlitar någon konsult utifrån är ju att man saknar kompetensen själv och utan att veta hur utvecklingen går till är det svårt att göra en bra kravspec. Det är också ofta svårt för kunden att veta precis vad de vill ha. De har ett problem som de vill lösa och då måste utvecklaren i många fall hjälpa till med att hitta lösningen och skriva en kravspec.

Jag tycker nog att det är utvecklarens ansvar att se till att det upprättas en kravspec som han är nöjd med så att det inte råder några tvivel om vad som ska göras och hur.

Som utvecklare måste man ju också kunna vara flexibel nog att kunna ändra specifikationerna något på vägen till en extra kostnad som motsvarar det extra arbetet det innebär.
Som sagt, normalfallet är att kunden inte vet exakt vad de vill ha. Det har ett problem som de behöver en lösning till och eftersom de inte har kompetensen själva att lösa det tar de in en konsult. Hur ska man då kunna kräva att kunden har kompetensen till att upprätta en kravspec?

Tycker vi pratar om 2 olika saker här:
1. Kunden har inte kompetens att specificera vad som skall göras. Då tar man in en konsult som måste kunna branschen/verksamheten mycket väl.
2. Ett rent utvecklingsjobb. Då skall inte utvecklaren skriva kravspec:en. Då pratar jag om en utvecklare som inte är mycket väl insatt i kundens verksamhet.

Sedan kan det finnas fall där det kan kombineras, främst vid små nischade uppdrag.

I mindre organisationer finns det sällan någon som både kan verksamheten bra och som kan skriva en specifikation så bra att utvecklaren vet exakt vad som ska göras.
Ska man då ta in en konsult till som först ska lära sig hela verksamheten och sedan skriva en kravspecifiktaion?

Helt okej för ett stort företag, men det känns inte riktigt hållbart eller rimligt när det gäller små företag eller organisationer med en begränsad budget.

Kunden och utvecklaren gör ju såklart kravspecen tillsammans då. Kunden har kunskap om verksamheten och utvecklaren har kunskapen som krävs för att skapa en lösning enligt de önskemål som kunden har.

Jag säger inte att det är ett idealisk scenario eller hur det ska vara, utan pratar om mina erfarenheter med att jobba med mindre kunder utan en organisation med befintlig kompetens.
Vem skall de vända sig till om de inte har kunskapen att skriva en specifikation själva?
Jag känner inte till många företag som är specialister på att skriva specifikationer, utan det faller enligt vad jag erfar alltid på antingen beställaren, webbyrån eller utvecklare.

Har man inte kunskapen om hur man skriver en specifikation måste man anlita någon som får sätta sig in i verksamheten. Har man budget för det lär man få bäst resultat med en webbyrå som har folk som kan skriva specifikationer såväl som utvecklare, men man kommer inte ifrån att man måste hitta någon som kan sätta sig in i verksamheten.

Har man jobbat med utveckling en längre tid har man ju en hel del insikt i vad som krävs av en specifikation och vad som resulterar i en lyckad webbsida eller applikation.
Min erfarenhet är den motsatta av din. Då företagare som själva inte kan mycket om utveckling försöker göra en grundlig specifikation blir ofta resultatet inte speciellt lyckat, även om de råkar vara metodiska och faktiskt skulle lyckas göra ett bra jobb med att dokumentera vad de vill ha. Det är ett måste att vara en duktig arkitekt och kunna användarvänlighet för att ta fram en specifikation från grunden, och oavsett vad många beställare må tro om sina kunskaper på det området så är de ofta bristfälliga. Att utveckla en specifikation i samråd med utvecklaren kommer oftast ge ett bättre resultat.
Utvecklaren kan dessutom göra prototyper, UML-diagram och förslag till databasstruktur för att se till att allt är ordentligt genomtänkt innan utvecklingsarbetet påbörjas.

Självfallet är det skillnad på utvecklare och utvecklare, och det finns de som är mycket duktiga på algoritmer eller kan massa språk extremt väl men som är usla arkitekter. Och de finns ypperliga arkitekter som inte är speciellt duktiga på att programmera.
Då det gäller TS situation låter det som det inte har varit frågan om ett projekt med hundratusentals kronor i budget, och då går det ju bort med det idealiska scenariot där man anlitar en webbyrå som har en kundkontakt som man kan diskutera sina önskemål med, arkitekter, designers samt duktiga utvecklare.
Anlitar man då en utvecklare som inte är en duglig arkitekt, inte är kapabel att sätta sig in i verksamheten eller inte är bra på att kommunicera med kunden är det självfallet något som lätt leder till katastrof. Det är inte att rekommendera även om man anser att man har kunskapen för att skriva specifikationen själv. Har man inte många års erfarenhet med att utveckla applikationer är man helt enkelt inte kompetent att ensam agera arkitekt, så även om utvecklaren gör precis som du tänkt dig kommer förmodligen resultatet bli långt ifrån optimalt.

Precis, kombinationen av de rollerna är det jag pratar om, och huvudsakligen den typ av uppdrag jag jobbar med. Jag tror inte det är speciellt ovanligt med sådana scenarion, utan det är med regel än undantag då det gäller små företag och små webbyråer eller enskilda utvecklare.

Det känns som att ni alla talar om vitt skilda verksamheter i den här tråden vilket gör diskussionen helt meningslös. Handlar det om mindre företag som inte har särskilt mycket erfarenhet av internet så är det självklart så att man inte kan få en ordentlig kravspec. Har man valt att rikta in sig mot den typen av kunder måste man hantera den delen av arbetet själv i många fall men då ska man givetvis också ta betalt även för detta och förklara vikten av det för kunden. Detta gör man lämpligtvis i nära samarbete med kunden. Handlar det om större projekt så kan man ju dock ifrågasätta om det verkligen är en bra idé att diskutera alla detaljer. Jag hade själv aldrig gjort det men det beror nog mest på att jag tycker den typen av jobb är extremt tråkiga och inte sysslar med det längre :) Arbetar man däremot som mig mestadels med företag som har internet som primärt verksamhetsområde så har de normalt sett inga svårigheter att lämna en utförlig kravspec och de har även god kunskap om de flesta tekniska lösningar. Sedan finns det givetvis mellanting. Det är inte alltid en kravspec är nödvändig, jag har själv många gånger arbetat utan att en sådan funnits på förhand och det har aldrig varit några större problem.

Det är omöjligt att ge något rätt svar på frågeställningen utan att känna till alla detaljer men rent generellt får man nog skylla sig själv ifall det inte finns någon konkret överenskommelse om vad som ska levereras. Det är mycket svårt att kräva något i efterhand oavsett om jobbet gjorts bra eller dåligt.

Det verkar vara en förvirring av begrepp här, låt mig klargöra hur jag ser på begreppen:

Verksamhet: Om kunden är ett Dagis så är verksamheten dagisets verksamhet.

Krav: Användningsfall eller UserStories, ofta punktlistor med önskemål om vad systemet ska göra för verksamheten, men ett verksamhetskrav/funktionellt krav är aldrig en teknisk beskrivning.

Kravspec: Det är den verksamhetsmässiga bekrivningen av vad verksamheten vill åstadkomma, inet en beskrivning av hur man bygger ett IT-system. En kravspec innehåller inga tekniska beskrivningar. Om man inte har en kravspec att utgå ifrån så är det nästan en garanti att projektet kommer att hamna i kris (med mycket få undantag). En Kravspec är den kompletta sammanställningen av alla krav som ett projekt ska leverera till verksamheten. Ofta kompletteras det med konkreta "Testfall". En kravspec kan vara från en A4 till miljoner A4 beroende på projektstorlek och finansiering. Men även en kravspec på en A4 kan ta någon vecka att utföra och leverera.

Systemspec: Detta är en en teknisk beskrivning hur IT-sidan har tänkt bygga systemet, innehåller mycket tekniska beskrivningar. Har man en befintlig arkitektur och en bra kravspec så minskar kravet att ha en utförlig systemspec. Systemspecen brukar även inkludera en arkitekturspec, ibland har man en separat arkitekturspec. Vid riktigt små webbprojekt kan man ibland klara sig med en bra kravspec, utan systemspec.

Acceptanstest: Ett test som utförs av kunden/beställaren/verksamheten (ej ev leverantören) för att verkligen testa att det levererade IT-systemet, inklusive rutiner och dokumentation fungerar som man specifierat i den verksamhetsmässiga kravspecen. När acceptanstesten är klar så tar kunden över ansvaret för systemet (kan i sig outsourcas till en driftleverantör om den tekniska kunskapen inte finns i verksamheten).

Systemtest: Utförs av tekniskt kunnig personal, kan vara både inom verksamheten och hos leverantören (i större företag utförs det flera tester på olika nivåer hos leverantören, Siemens hade senast jag hörde det 17 olika nivåer, men de tillverkar ju Pacemakers och liknande så det är väl lite extremt exempel kanske).

ROLLER (OBS!!!! En fysisk person kan ha flera roller, i små projekt är det snarare regel än undantag att en person har flera roller, viktigt att prata om "ROLLER" i diskussionen, inte "befatttningar" / "Jobbtitlar").

Beställare: Den som har de befogenheter som behövs för att fatta bestllarbeslut, skriver avtal med Leverantören. Har oftast hjälp av en kravhanterare för att först ta fram ordentliga krav innan beställning görs hos IT-leverantör. Beställare har sällan personlig teknisk kompetens.

Kravhanterare: Verksamhtsperson som kan vara inhyrd konsult som är specialist på att beskriva verksamhetens krav, en helt oteknisk roll. Bakgrunden för en kravhanterare är sällan från den tekniska sidan utan dessa personer kommer oftast från mångårigt arbete inom verksamheten.

Acceptanstestare: Person hos beställaren som har kunskap om hur systemet förväntas fungera i verksamheten och den som fysiskt utför tester av det levererade systemet.

Systemdesigner: Gör mest arbete med design och en hel del kravanalys (analys av kravspec). Ibland programmering men i större företag ingen programmering då är detta mer en arkitektroll, men det finns en hel uppsjö av egna arkitektroller som jag inte tänktte dra här.

Systemutvecklare: En Systemutvecklare gör en del systemdesign som modellering och justering av systemspecifikationer. Ibland en del programmering. Roller är ganska flytande och en systemutvecklare har oftast många års erfarenhet.

Programmerare: En programmerare gör ALDRIG specifikationsarbete eller systemdesign. Enbart programmering och programtester. En programmerare har ofta betydligt kortare erfarenhet än en systemutvecklare och brukar därför inte ha lika stort eller brett ansvarsområde.

Givetvis finns det många fler roller, men det här är ett kort axplock av de viktigaste som vi resonerat om i denna tråd.

Då kan vi vara överens om att ifall man som utvecklare även skall ta fram kravspec krävs det att man sätter sig in i (eller redan kan) verksamheten bra och att man jobbar mycket nära kunden!? Annars kan det bli hur illa som helst (som det verkar vara här)

Begreppen är lika relevanta oavsett hur stor organisation man är verksam i, du måste skilja på "roller" och "jobbtitlar" som jag skrev.

"Jobbtitlar" kan skilja sig mycket mellan stora respektive små organisationer men "rollerna" är per defintion närmast identiska.


i De minsta utvecklingsprojekten behövs:

Beställare (en person):
Kompetens: Beställare, Kravhanterare (ev annan inhyrd konsult om beställaren ej har denna kompetens)
Dokument/Leverabler: Kravspec (Gärna med verksamhetsbeskrivning)
Jobb: Kravhantering, Avtal, Acceptanstest (godkännande/eller ej av leverans)


Leverantör (en person):
Kompetens: Kundansvarig, Avtal, Systemutvecklare
Jobb: Avtal, Systemutveckling(Vid behov systemspec), Programtest/enhetstest, Systemtest, Installation, Utbildning av beställare
Dokument/Leverabler: Databas, Program, (ev källkod om kunden vill ha det), installation, övrig dokumentation


Avtal
Parterna förhandlar och kommer överens om en kravspec som ska ingå i ett avtal mellan parterna, Parterna kommer överens om en projektplan (Vad vardera parten lovar att bidra med och när saker ska finnas klara, samt pris).

I många fall finns det även drift och supportavtal som gör att leverantören har ett långtgående åtagande efter driftsättningen.

Har leverantören redan kunskap om verksamheten (kanske jobbat många år med detta som anställd eller haft uppfdrag mot samma kund förut) så blir startsträckan med att sätta sig in i beställarens verksamhet givetvis kortare. Det är många konsulter som lever just på att de har verksamhetskompetns i kombination med sin tekniska kompetens.

Förväxla inte det jag beskriver som utvecklingsprojekt med supportuppdrag, eller underhållsuppdrag.

I sak håller jag med dig, Conny, men i många mindre företag (mindre = få anställda = i princip alla svenska webbrelaterade företag) finns inte särskilt många jobbtitlar och inte sällan så är de mest för formalitetens skull :) De viktiga grunderna är givetvis att man måste veta vad man beställer, utvecklaren måste sköta sitt jobb och ett avtal bör finnas. Avtal är dock inte alltid så livsviktigt som du alltid framställer det :) Personligen har jag aldrig under hela min verksamma tid tvistat om ett avtal. Det handlar mer om vilka man arbetar tillsammans med.

@ConnyWesth
De beskrivningar av roller som du beskriver är generella och ingen absolut sanning.
Jag har tidigare jobbat med musikproduktion, och där har du även vissa roller som normalt existerar: producent, tekniker och musiker. Nuförtiden är det dock väldigt vanligt att rollerna övergår i varandra.

Som exempel kan jag nämna en kund som har en pokerträningssida och vill ha en handuppspelare med diverse träningsverktyg. Han skickar mig ett dokument som beskriver i mycket grova drag vad han vill ha för funktionalitet, men det är långt ifrån en acceptabel kravspec och omöjlig att göra en offert ifrån eftersom den är alldeles för odetaljerad och lämnar massor med frågetecken om vad som faktiskt skall göras.
Jag tar då och jobbar fram en specifikation tillsammans med en prototyp som visar exakt hur allt skall implementeras. Eftersom jag har erfarenhet av att utveckla sådana applikationer, kan UX-design och förstår verksamheten väl kan jag göra ett betydlig bättre jobb än beställaren med att ta fram specifika krav. Han går över mitt förslag till specifikation och vi gör ett par revisioner baserat på hans kommentarer.
Så i detta fall är jag leverantör, men gör kravhantering i samråd med beställaren. Det finns inget som säger att en kravhanterare inte också kan vara leverantör utan måste vara antingen beställaren själv eller en separat konsult.

I extrema fall vet faktiskt inte beställaren mycket mer att han exempelvis vill ha en hemsida och vad den har för mål, men saknar helt kunskap om vad för funktionalitet som är mest lämplig för att uppnå målet. Då kontaktar man vanligen en webbyrå eller en utvecklare och låter dem komma med förslag. Större webbyråer kommer involvera ett antal olika personer för att hitta det optimala sättet att uppnå målet, men med mindre webbyråer eller enskilda utvecklare faller det på utvecklarna själva.