[mojitoo]

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.

[Conny Westh]

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

[Kihlbom]

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.

[rhdf]

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..."

[mojitoo]

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?

[Conny Westh]

Ursprungligen postat av mojitoo

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.

[pelmered]

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.

[Conny Westh]

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:

[pelmered]

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..

[blixtsystems]

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.