Nja, Ett system/modul/program kan fungera till 100 % eller inte alls eller precis allt därimellan. I varje fall i den riktiga värden. Har du aldrig varit med om att beställare och utförare har olika uppfattning om vad som fungerar eller inte? Jag tror att du har hamnat i den situationen nu. Detta är ngt som proffessionella utförare gärna vill undvika. För att testa om ett system/en modul/ett program fungerar elller inte krävs därför en kravspecifikation och därifrån specificerade testfall som täcker alla utfall. Dina kravspecar existerar inte eller är väldigt vagt formulerade. I dennna situation är det DIN uppgift som professionell utförare att tillse att dessa kravspecar samt testfall finns, samt att beställarna förstår dom till 100%. Snälla GmT specificera vad du ska utföra och få dina motdebbattörer att förstå det. Det är DIN uppgift som professionell utförare. Detta ansvar kan du aldrig lägga på beställaren för då kommer du alltid att hamna i dessa situationer. Ärligt talat har väl dom flesta professionella utförare hamnat i denna situation en eller annan gång. Och vad har vi lärt oss av det?
mvh
Hallå där, mamma bäng´fan!
Jag håller faktiskt med noBuzz även denna gång genom att jag tycker att det var ett bra inlägg, OM det nu hade gällt leveransen av ett datasystem till MPR. Där hade jag inte heller accepterat luddigheter och flax.
Men kravspecifikation på diskussionsinlägg? En vacker tanke säkert, men ack så utopiskt! Man skulle kunna säga att du ändå ligger långt före din och min tid, hehe.
Men skämt åsido, så förstår jag vad du menar och jag visserligen har gjort mina misstag när det gäller luddiga formuleringar i kravspecifikationen (i mitt jobb, inte här, för guds skull!). Och jag fick betala dyrt för det genom kreditfakturor och obetalda extrainsatser, bara för att inte förlora en kund. Samtidigt ligger kravspecifikationen ofta till grund för om man kan få ett uppdrag eller ej, så det gäller att väcka förhoppningar utan att binda upp sig. Precis denna balansgång har jag nog lärt mig genom åren.
Att man från ett systems beställare- resp. utföraresidan oftast har olika synpunkter ligger väl i sakens natur, inte minst ekonomiskt. Så det är väl därför det alltid viftas med kravspecifikationen i högsta hugg så snart man inte är överens om en detalj. Och om du har befunnit dig på utföraresidan vet du också hur lätt beställarsidan tenderar till närmast uppsåtliga feltolkningar och missförstånd när det kommer till kritan (=betalning). Representerar man inte ett jättestort och okänslig konsultföretag är det oftast bara att bita i det sura äpplet och hädanefter göra ALLT för att undvika sådana "missförstånd".
Tror mig, även det har jag gått igenom i mitt verkliga liv (ja, det finns). Men på MPR? Skall det verkligen behövas med att visa upp pass, stämplar OCH kravspecifikation för att få en syl i vädret? Det tycker jag är lite väl mycket begärt och jag antar vi kan låta saken bero genom att bara skämta om den.
F.ö. menar jag med att fungera eller inte fungera snarare en enskild uppgift (task) som kan vara en funktion eller dyl i ett system. Självfallet måste alla enskilda funktioner hantera sina resp. uppgifter korrekt för att systemet i sin helhet ska kunna fungera korrekt. Men omvänt kan man naturligtvis inte härleda ett sammansatt systems (affärsmässiga) funktionsduglighet i sin helhet ur detta. Men då kan ju utföraresidan alltid vifta med kravspecifikationen och säga "det var ju det ni beställde!" för att få lite mer pengar. Men det här är ett annat spel och det spelet känner du säkert till.
KravSpecifiera Mera! GmT
