TDP028 Projekt: Entreprenöriell programmering

Konkurrensanalys - övning

En konkurrensanalys för produktuteckling är en övning där man studerar konkurerande produkter för att identifiera 2 saker (måste-krav) och (utelämnande-krav). Man kan använda detta för att identifiera förändring men ockås för att inse vilken nivå man måste nå för att kunna konkurera med "first movers".

Ett skäl till att göra en konkurensanalys kan även vara att identifier en ny app som är fokuserad på en delmängd av redan existerande appar och som vidareutvecklar den delen.

Genomförande

• Välj ut 1 app som är lite större. Appen behöver vara så pass stor att det går att identifiera 10 stycken olika "krav" (du får helt enkelt ut mer av övningen om det är en icke-minimal app).
• Använd appen och analysera dess innehåll. Vad kan man göra i appen, vilka krav kan man se i efterhand att appen byggts för. Identifiera ca 10 stycken sådana krav.
• Använd en user-story-beskrivning för att beskriva kravet, (se nedan), model enligt "Som en [typ av användare] vill jag [göra något] för att [uppnå något]", för att beskriva dessa krav.
• Ta screen-shots av UI:ts utseende.
• Kategorisera dessa krav i två grupper:
  • Måste-krav, sådant som en konkurrerade uppgift förväntas ha, som en användare vill se för att en konkurerande app ska räknas (se nedan).
  • Egna-krav, sådant som om det eliminerades ändå inte skulle göra appen oanvändbar. Sådana krav kan vara grund för en helt ny app som den gamla appen inte kan konkurera med [se nedan](#must)
• Har du svårt att hitta en appidé, kan ett identifierat eget-krav vara grund för en ny appide som specialiserar sig gentemot konkurrensen.

User Story

En user-story är ett sätt att beskriva ett krav i en användares språk för att bryta ner de behov som en app ska levelrera. En förenklad version som vi ska använda skrivs på följande sätt:

En [typ av användare] ska kunna [göra något] för att [uppnå något]

Till exempel:

En [användare] ska kunna [skicka bilder] till någon annan för att [visa något]

...men ett sådant exempel kan även begränsas mer:

En [tonåring] ska kunna [skicka en bild på en produkt och pris till sin mamma] för att [fråga om köp]

Och i denna variant finns kontakten med andra, mer viktiga syften som att fatta beslut om köp och annat som kan leda vidare, t.ex. en app där mamma kan betala via telefon via Swish ... osv...

Ju mer detaljerade en user-stor är, desto mer kan de säga om vad man kan göra och vad som finns bortanför. Tänk på att ha en typ av användare, något man gör, och skälet till varför

Måste-krav

Ett måste krav är ett krav utan vilket en användare inte skulle anse produkten seriös eller acceptable. Ett exemple är (som i facebook och andra sociala tjäsnter idag) i samband med vän-förfrågan måste en parten fråga, andra parten accepters för att vänskape ska bli klart. Före facebook fans många vänskaps-funktioner där det räckte att ange en vän för att kunna skapa kopplingen men idag skulle det kunna anses oacceptabelt.

Ett måste-krav måste en konkurrerande app implementera och det kan inte heller vara grund till en ny app eftersom måste-kravet inte kan förenklas.

Egna krav är embryon till nya appar. Det som är bra med egna krav är att de både innebär en förenklig och ett konkuresverktyg. Ett typiskt exemple på detta är Instagram, Twitter eller Pintrest kotra Facebook. De applikationerna har egna krav som fanns i Facebook men eftersom facebook har mer kan facebook inte konkurera ut dessa "enklare", Facebook måste behålla sin funktionalitetsnivå.