Jag har köpt en del kodningsjobb, och det är ju alltid lite problem att kommunicera exakt vad man har i huvudet, så ibland får man negativa såväl som positiva överraskningar. Därför har jag en fråga till alla er som utvecklar sidor efter en kunds specifikation: Hur vill ni har specifikationerna?
För vanliga sidor, typ webshop, antar jag att det istort sett bara är att lista funktioner (top-lista, möjlighet att kommentera, osv)!? Dock bör det ju även kunna bli missförstånd här (t.ex. vad som ska vara redigerbart i admin osv.)
I ett projekt jag har nu, vilket är en sida vars funktion inte finns i exakt form någon annanstans, har jag satt mig och ritat en template för varje undersida i Illustrator. Det får mig själv att tänka till också, så att jag verkligen vet hur jag vill ha det. Jag har ännu inte lämnat in det, så jag vet inte resultatet. Jag har även en 2 sidors sammanfattning över funktionaliteten.
Går då och då igenom kravspecifikationer och allt som oftast får man fundera på vad kunden egentligen vill ha. Det är iof krav som inte är ställda utifrån ett av kunden känt system då det handlar om upphandlingar.
Men man kan som kravställare aldrig(?) vara alltför tydlig. Oftast får man krav på att händelse Y ska hända vid scenario X. X är ofta väldigt dåligt definierat och ibland kräver superintelligens av systemet. X måste vara väldefinierat typ om X.värde = 5 och X.tid = 10:00 så ska händelse Y hända. Vi människor har ju oftast lättare att förstå när händelse Y ska inträffa, vi vet när det är rimligt fast det kan vara snudd på omöjligt att få den intelligensen i systemet.
Ett tips kan vara att be någon annan läsa genom kravspecen innan du lämnar den till utvecklarna. Det ska då vara någon som inte är så insatt i jobbet, förstår de var du menar så är det mycket större chans att även utvecklarna gör det.
Bilder/exempel på hur det ser ut idag och hur du vill att det ska fungera är väldigt värdefulla. Oftast betyder väldefinierade exempel mycket mer än en beskrivning av förändringen.
Ska designen förändras så gör gärna några skisser på hur du vill att det ska se ut.
Som Micke skrev, du kan aldrig bli för tydlig i din kravspec.
Uhj uhj.. har läst alltför många kravspeccar för att jag skall kunna säga att de är speccade bra. Visst ibland har man stött på de som varit riktigt bra också.
Många gånger brukar man få stanna upp, klia sig i huvudet och ringa kunden och fråga: Vad menar du med .... ?
Jag tycker det är ett bra förslag att låta någon ej insatt i arbetet att läsa speccen innan man skickar ivägen den. För en själv brukar allt vara så självklart, men det är inte säkert att det är så självklart för utvecklarna. :)
Tydlighet är A&O men bara för det behöver den inte 1000 sidor text. :) Jag brukar föredra: KISS.
Varje funktion som ska byggas borde ha en funktionsspec som innehåller bakgrund, övergripande beskrivning, förutsättningar och en funktionell beskrivning. Specen ska uppdateras i takt med att funktionen eller projektet förändras, annars vet man inte vad som gäller efter ett tag. Den ska vara så tydlig att den inte går att tolka på olika sätt. Det ska inte finnas några antaganden och det borde finnas tillräckligt med detaljer att den går att testa.
Det är inte helt enkelt men jag antar att man lär sig med tiden.
Håller helt med dAEk.
Tror aldrig att jag har fått en komplett specifikation från kund.
Ofta är det några funktioner som man får gissa sig till hur kunden vill ha dom. Men jag specar alltid i offerten vilka funktioner som offerten är beräknad på.
Men oftast så kommer dom efteråt och säger saker som att "den där listan vill vi kunna sortera genom att klicka på rubrikerna" eller "vi vill ha en högerklicksmeny på den kontrollen" och då är man glad att man har specat ordentligt vad som ingår i offerten.
Under alla mina år i branchen, och det är många, har jag aldrig fått en specifikation som är komplett!
Orsaken är att kunden inte förstår vilka möjligheter som ligger inom ett ADB område.
Numera, med webben som mål, borde det gå att ta fram specifikationer som stämmer bättre.
Att använda fasta referenser som exempel dvs. sajter som till upplägg och beteende uppvisar de egenskaper som man har tänkt sig underlättar.
Sedan finns det massor med "back office" egenskaper som beställaren knappast kan ha full kontroll på.
0. Vad skall beställningen ha för syfte
1. Vad skall man kunna göra i det primära
2. Hur kan man förenkla
3. Vad skall göras när man har nått första etappen
4. När skall andra steget tas
Med svar på dessa frågor har man i varje fall en start säger Lasp
Personligen avskyr jag att arbeta gentemot statliga verk etcetera, som kräver upphandling. Fördrar ett agilt förhållningssätt där man tillsammans med kunden tar fram user stories och använder sedan dessa för att ge ett ungerfärligt estimat tidsåtgång, sedan får man förhandla fram ett risk and reward avtal. Alla vet att change request hantering etcetera bara är ofördelaktig för kunden. Up-front kravspec skapar system som blir dyrare att underhålla och vidareutveckla, i 9 av 10 fall.
Visst är det en tydlig kravställare så kan man använda dessa för bryta ner till user stories för att estimera dessa (vid upphandling) men beställarkompetens är något som det lider stor brist på.
I dagens CS sid 17. finns en intressant artikel om varför Scrum misslyckas! Pm det är RUP eller konventionell Vattenfallsutveckling så måste båda parter vara medvetna om vart startplatsen är och vart målet skall ligga. Kanske dags att bolla en kravspec med någon som står mitt emellan!
Jag erbjuder frågeställaren en stunds fri Idébollning här nere i Skåne.
Kan det vara en väg att komma närmare sanningen om utvecklingskostnad än att multiplicera med Pi?
Vi hade ett internt talesätt "Om kunden är dum, får kunden som han vill" Ett exempel på att kunskap inte alltid fans hos beställaren. Oftast kunde vi visa vad som skulle kunna hända innan det rasade.
RUP, som om inte vattanfall var tillräckligt ond. Agilitet kräver stor disciplin och duktiga utvecklare, inget som det sticks under stolen med. Att det sedan misslyckas beror snarare på att folk tror det är en lösning på alla problemen och för in det i organisationer som inte är redo, lämpliga för att arbeta agilt.
Folk tror de kan köra Scrum i sys.utvecklingsprojekt utan att föra in ett stort antal XP-practies, därav misslyckas de.
274 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
