Funktioner är
enkla att hitta och spåna fram och de flesta blir "höga" på sin egen
innovativa förmåga och när väggen är full av smarta idéer så känner man sig både
duktig och glad.
Men det riktiga arbetet som kravingenjör eller verksamhetsanalytiker i tjänste-/produkt utveckling handlar primärt INTE om funktioner utan snarare om hur bra existerande funktioner ska vara, att ha kontroll över sin omvärld och de kvalitetsattributsvärden som alla konkurrenter innehar på liknande funktioner, att förstå sin omvärld helt enkelt!
Ett bra sätt att skapa förståelse är att göra en snabb kravanalys baserad på traditionell kravingenjörsskap á la IREB. Att snabbt skapa en representation av kontexten, begränsningarna, existerande funktioner, värden på kvalitetsattribut på existerande funktioner, domäner och på tjänsten/produkten som helhet och att "provköra" analysen och kunskapsrepresentationen gentemot scenarier i den kontext som prioriterats utifrån de "ögon" (stakeholders/intressenter/roller) som har fått vara med att "se och beskriva verkligheten".
Ett exempel är elscootrarna som ligger "överallt" på stan.
Vilka scenarier kan du spela upp som har som resultat att en elscooter "ligger slängd" istället för att vara "parkerad"?
ett scenario är givetvis att "scooterhyraren" faktiskt parkerar den korrekt men att sedan en extern kraft påverkar den att falla och övergå från tillstånden "korrekt parkerad" till "slängd på marken". Ett objekt som kan åberopas (om man gjort sin hemläxa och skapat en statisk representation av objektet i form av en funktionell nedbrytning), är att kvalitetsattributen på ett objekt kan vara en direkt orsak till problemet.
Aktiviteten "att parkera" innebär involvering av "objektet" stöd. Och hur bra detta stöd är kommer påverka utfallet av aktiveten parkera!
Men det riktiga arbetet som kravingenjör eller verksamhetsanalytiker i tjänste-/produkt utveckling handlar primärt INTE om funktioner utan snarare om hur bra existerande funktioner ska vara, att ha kontroll över sin omvärld och de kvalitetsattributsvärden som alla konkurrenter innehar på liknande funktioner, att förstå sin omvärld helt enkelt!
Ett bra sätt att skapa förståelse är att göra en snabb kravanalys baserad på traditionell kravingenjörsskap á la IREB. Att snabbt skapa en representation av kontexten, begränsningarna, existerande funktioner, värden på kvalitetsattribut på existerande funktioner, domäner och på tjänsten/produkten som helhet och att "provköra" analysen och kunskapsrepresentationen gentemot scenarier i den kontext som prioriterats utifrån de "ögon" (stakeholders/intressenter/roller) som har fått vara med att "se och beskriva verkligheten".
Ett exempel är elscootrarna som ligger "överallt" på stan.
Vilka scenarier kan du spela upp som har som resultat att en elscooter "ligger slängd" istället för att vara "parkerad"?
ett scenario är givetvis att "scooterhyraren" faktiskt parkerar den korrekt men att sedan en extern kraft påverkar den att falla och övergå från tillstånden "korrekt parkerad" till "slängd på marken". Ett objekt som kan åberopas (om man gjort sin hemläxa och skapat en statisk representation av objektet i form av en funktionell nedbrytning), är att kvalitetsattributen på ett objekt kan vara en direkt orsak till problemet.
Aktiviteten "att parkera" innebär involvering av "objektet" stöd. Och hur bra detta stöd är kommer påverka utfallet av aktiveten parkera!
Med andra ord,
har du ett kass stöd på scootern så är chansen stor att den ramlar i de Göteborgska
kastvindarna ganska stor.
Hur stor är chansen att denna scooter kommer ramla?
Det är troligtvis
en (1) av orsakerna till nedskräpningen. En annan kan ju vara att "scooterhyraren"
har en annan definition av "parkering" och att slänga den på marken
är en form av parkering i dess begreppsvärld, men det behöver ju inte vara
fallet!
Genom att MÄTA
och skapa fakta på vad som verkligen sker i ett stort antal olika parkeringsscenarion
för elscootrar, så kan skapa en förståelse som kan leda till en smart lösning.
Ett annat alternativ är att fundera på kvalitetsattributen från starten.
Ett annat alternativ är att fundera på kvalitetsattributen från starten.
Att inte nöja sig
med att -"ja vi har ett stöd och ja man kan parkera den stående med hjälp
av stödet", utan att även fortsätta med "kvaliteten på stödet är
sådant att det står emot kastvindar och folk som råkar stöta till scootern när
de går förbi.
dvs tänk SMART redan innan man "itererar i verkligheten" och ställer ut scootrar som ramlar bara man tittar på dem och sen får brottas med en allt starkare opinion som vill ha bort "nedskräpningen".
dvs tänk SMART redan innan man "itererar i verkligheten" och ställer ut scootrar som ramlar bara man tittar på dem och sen får brottas med en allt starkare opinion som vill ha bort "nedskräpningen".
Hur stor är chansen att denna scooter kommer ramla?
Allt hänger ihop! Det bästa är att tänka EFTER FÖRE!
Med traditionella
kravingenjörsmetoder kan man tänka snabbt och bli effektivt SMART, inte bara
stå och prata och kramas och hitta på nya funktioner.
EN möjlig lösning är givetvis att ha ett dubbelstöd. Jag menar hur svårt kan det vara ?
De uthyrare som inte har tänkt till, kallar jag "f...g stupid!"
"Wind" är med andra ord SMARTA!
EN möjlig lösning är givetvis att ha ett dubbelstöd. Jag menar hur svårt kan det vara ?
De uthyrare som inte har tänkt till, kallar jag "f...g stupid!"
"Wind" är med andra ord SMARTA!
be smart, don't be stupid!
No comments:
Post a Comment