Funktioner är enkelt …

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!

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.

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

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!

be smart, don't be stupid!

tänk EFTER FÖRE !

det gäller att tänka EFTER FÖRE !
att förstå trafikflöden i verkligheten och simulera hur det blir efter en förändring..

Sverige är världssämst på att förstå konsekvenser och våga analysera saker och att "inte hålla med"

någon i organisationen borde ställt sig upp och argumenterat men vi är för fega för att ha egna åsikter och så förbannat lättkränkta så att även vanliga projekt blir svårhanterade eftersom folk "tar åt sig" om man inte "håller med"

tyvärr så gäller det inte enbart trafiklösningar :-(

"Take it easy!"….yeah, right!

Have you ever made a "promise" to take it easy, with the really good intention to do just that, AND to end up in admitting that you did not?

The hindsight-effect is interesting. If we know BEFORE what the result will be, then we would most often act differently. 



But that is not the whole truth!

It is not only a simple decision on YES/NO on activities it is actually more complex than that!

The interpretation ("the semantic value") is always directly dependent on the context.
And it is also a subjective idea of adjusting the target values of a set of quaity requirements as well as accepting a set of constraints!

Let me give you an example. 

A monoskier has just recently operated both hips and is now refering to himself as "the Titanium man".
When going to a Monoski-meeting for a first contact with snow for almost 2 years, he promises his wife to "take it easy".

The "easy" is of course in relation to the baseline he affectuated before the operations, right! (?)
It means that a parameter like "speed" should be LOWER than the aforementioned baseline value
(e.g. 40km/h instead of 80 km/h on average).

But here he should have stoped and asked himself: 

"are there any OTHER parameters than speed that could or should be included  in the take-it-easy manipulation of values?

Are there relations between objects in the context that do not go well with "take it easy" ?

Can you "take it easy" in a black pist with a lot of moguls or in deep powder?
What happens if we reduce the speed in a steep slope and how does the effectuation of the "reduce the speed"-action effect the very thing that he wants to protect i.e. the hips?

The paradox that he SHOULD HAVE KNOWN by heart, is that If you are not riding on the edges on a monoski, you are NOT following the natural curve and speed of the ski. This means that it will cause MORE vibrations and hard work on the joints and muscles than if you "follow the ski"
… so the reduction of speed to enhance "take it easy" actually makes it worse than riding faster in a more natural speed !

Think about it…whit did he do wrong?


THINK!



The "take it easy" should not only change the speed parameter but also WHERE he should ski …if he stayed in less steep environments he could follow the natural flow of the ski without having to brake and reduce the speed at all!

So which lesson did I learn from this? (yes, it was me I was talking about all along)

When agreeing to a concept, be sure to analyze what that specific concept REALLY means!
Both the definition, all parameters involved (the quality attributes) as well as some of the constraints (e.g. "you can NOT ride in moguls if you have agreed to take it easy!")

The effect on my body was that the hips felt great, but the knees got sore and I had to end my skitrip after just 2 days

 …AND also suffer the comment from my wife: 

"why did you not listen to me! Why did you not take it easy!"

it is all about viewpoints!

Regarding viewpoints, it is a matter of definition of "completeness". In a world without any constraints we should aim for 110% completeness and have representation and surrogacy for all possible views... BUT we have to choose because we do have to deal with a rather large set of constraints, both project constraints (time, money and resources...) as well as legal stuff and "demanded requirements" etc ...

So we need a "scientific" way to prioritize and limit the viewpoints ... it is NOT easy!

This stakeholder managment skills (often uphold, explored and developed by a Business Analyst) involves soo much more than just a list of names and a communication strategy!

An "agile list of names" is NOT good enough...

Exploring, provoking, trawl and strategically "manipulating" to bring forward "that which can not be easily said or answered in a meeting" is a real skill that is not only about iterations. Iterations are only as strong as their inherent tranformational function!

We never see what is out there, we only see a representation of what we know, and that is a bottleneck for creativity and real change ...

Draw the f..g map!

Draw the f..g map! 

...that is my personal mantra for basically everything and anything...

If it is complex, it is complex! 

If you have more than 3 entities, grab a pen a draw it on the wall ..and you will definitely experience that TALK is not enough!! If you aspire to be "truly agile", you have to visualize it ALL!... to be smart you have to navigate ...to navigate you need a map ... don't be stupid!

"only talk" is just rubbish! ...instead, TALK about the map! 

Real understanding comes from visual knowledge representation and involvement and talking about the created maps (or diagrams forming the model)...

Visual thinking & understanding in BA / RE / ARCH practices used in industry product development

Tacit knowledge calibration

The concept of visual management and visual feedback is one of the pillars in Lean Product development for communication of status, progress, prognosis, and planning, e.g. tracking of work identified, ongoing and done in the development teams via kanban-like boards as well as the progress according to existing plan, expectations and what is actually delivered. 

The leaders of the development teams are more interested in the use of resources and the amount of work to be done, so future work can be planned accordingly. 

The downstream stakeholders like sales, manufacturing, marketing etc.. also need to SEE how the projects are doing so they can plan and be ready at the right time.

The knowledge needed and the representations used, are pragmatic and efficient for management and planning, and the focus is NOT on the visual thinking and understanding of what shall be done. 

Only the management and control aspects of the development are considered.

In the BA/RE practice you often get advice to use X or Y or Z but no direction on WHICH representation to use and no focus on reasoning regarding the effect on this choice for downstream development.

The often individual decisions are suspiciously sub-optimal with no supporting knowledge of consequence of the specific Knowledge Representational choice as it will most likely affect the way we see things, think and are able to invent …but most importantly the ignorance of what we do NOT see and what has been lost in the knowledge transformation along the way ---"the Software Engineering Chinese whispers game"(" Telephone-, Gossip game", "viskleken") aka "the agile guessing game"…

"Chinese whispers game"

The essence of the game is that "Whispered messages" are passed around the room and the version which comes back to the starting point bare no relation to the original message. This phenomenon of "whispering" can also be extended to "not really understanding" in a more general sense to describe every day "mis-telling" of stories and misunderstanding of knowledge in any setting or form, when only using talk and sloppy writing are used as for knowledge communication. In fact, the sheer existence of this "whispering effect" is one of the reasons why LEAN and AGILE will never really work in Software Engineering without a sincere and focused knowledge representation for thinking and understanding!

We are lacking a focus on HOW we make the decision between different Visual Knowledge representations and the effect of our choices both at the same level regarding knowledge, understanding, innovation, and creativity, but also the downstream understanding of WHAT is communicated and what is NOT represented at all. 

Most models are not explicitly showing the Visual Knowledge Representation, but can easily be enhanced by a VKR component. For example the VKR decision point in the MSDDRE model

The MSDDRE model developed by Krzysztof Wnuk 

Blekinge Tekniska Högskola (modified by the author)

And by the way, this is my research domain. Do you want a draft title?
OK here we go:

“Formal & informal Visual Knowledge Representation used for knowledge transfer 

in Requirements Engineering, Business Analysis and Software Architecture

- evaluation of real usage in industry, choice of representation and diagram narratives to identify difficulties and errors in thinking and how to find the Best Possible, Good-enough and Visual Knowledge Representation with focus on the properties required for formal modeling in practice"

Another example on the benefits of real RE and BA thinking!

read the short article : https://mobile.reuters.com/article/amp/idUSKBN1L11NN

The key to making this happen is of course the real understanding of the PARTS and components and the variability and possibilities combined with a "razor-sharp understanding" of the stakeholders and the real needs ...

"With the car retailing for 12,000 euros, pre-existing components keeps costs down. The engine, for example, is a modified version of a fork-lift powerplant, and the door handles come from the Fiat 500"

... "the instrumentation is bare bones. We have stripped a lot of the needless instruments out, said Oliver. "In modern cars you have so many buttons I honestly don't know what many of them are for."

It is very simple...if you do not know which knowledge you need to have and do not represent it in a way that "communicates", you are just guessing in the dark ...

Start with some good thinking and then some spicy "passion" and it becomes a great product! ...

RE = Requirements Engineering, BA = Business Analysis