Identifierade  utmaningar

4.2.1 Upprätthålla kommunikationskanaler

I   projektet   har   kommunikationsverktyg   som   Skype,   Dropbox,   email,   Basecamp,   Google  Hangouts,  InVision  och  Slack  använts.  Genom  observationer  i  mitten  av   januari  blev  det  för  första  gången  tydligt  att  antalet  kommunikationskanaler  var   en  utmaning  som  försvårade  samarbetet.  Detta  beskrev  vi  i  ett  narrativ  baserat   på  anteckningarna  från  observationer:

Då   vi   i   mitten   av   januari   behövde   komma   i   kontakt   med   back-­‐end-­‐

utvecklaren  för  att  diskutera  designlösningar,  visste  vi  inte  riktigt  hur  och   var  vi  på  bästa  sätt  skulle  få  tag  på  honom:  Om  vi  exempelvis  skulle  ringa   honom   och   boka   ett   möte,   eller   om   det   skulle   räcka   att   maila   en   länk.   Vi   visste   heller   inte   vad   han   hade   för   telefonnummer   eller   vilken   mailadress   han   hade.   Vi   hade   nämligen   inte   fått   tillgång   till   ett   dokument   med   kontaktuppgifter   till   de   övriga   deltagarna,   eftersom   något   sådant   inte   fanns.  (Utdrag  från  narrativ)

Denna   utmaning   bekräftades   senare   i   de   intervjuer   vi   genomförde   med   projektdeltagare.   Projektledaren   menade   på   att   det   var   problematiskt   att   alla   föredrog   sina   egna   sätt   att   kommunicera:   att   designsidan   föredrog   prototypverktyg   och   utvecklarsidan   snarare   ville   jobba   i   GitHub   eller   tekniska   verktyg,   alternativt   Slack.   Vidare   föredrog   marknad   och   business-­‐sidan   att   kommunicera  via  email.  Det  slutade  med  att  alla  blev  forcerade  till  att  vara  i  en   kanal   de   inte   trivdes   med   vilket   resulterade   i   att   deltagarna   kommunicerade   mindre.  Vidare  skilde  sig  aktivitetsgraden  i  kommunikationskanalerna  betydligt   mellan  olika  projektdeltagare,  vilket  skapade  ett  glapp  i  kommunikationen.  Back-­‐

end-­‐utvecklaren  beskrev  sin  övertygelse  om  att  använda  verktyg  som  Slack  men   att   han   önskade   att   de   andra   skulle   vara   mer   aktiva: ”Man   behöver   inte   fråga   någon  om  hjälp,  men  man  kan  ju  skriva  var  man  är  som  en  statusuppdatering.”  

Interaktionsdesignern   höll   med   om   att   det   uppstått   kommunikationsproblem   i   projektet: ”...jag  vet  inte  riktigt  hur  utvecklarna  ligger  till,  där  känner  jag  att  det   finns  en  kommunikationsutmaning.”

De   många   olika   kommunikationskanalerna   var   en   utmaning   som   försvårade   samarbetet   mellan   projektdeltagarna.   Det   faktum   att   det   fanns   skilda   preferenser  kring  val  av  kommunikationskanaler  bidrog  till  att  samarbetet  och   kommunikationen   mellan   deltagare   försämrades.   Baserat   på   både   data   ifrån   djupintervjuer  och  observation  av  konversationer  i  kommunikationskanaler  blev   det  tydligt  att  aktivitetsgraden  skiljde  sig  mellan  olika  projektdeltagare.  Somliga   projektdeltagare  kommunicerade  dagligen  i  flera  kanaler  medan  andra  använde   kommunikationskanalerna   väldigt   sparsamt   och   höll   sig   endast   till   en   enskild   kanal.  

4.2.2 Upprätthålla momentum

I   projektet   Just   Arrived   har   projektets   olika   deltagare   och   team   inte   varit   samlokaliserade,   och   således   inte   befunnit   sig   på   samma   fysiska   plats.   Antalet   möten   mellan   samarbetspartners   har   varit   begränsade   på   grund   av   detta,   men   också   på   grund   av   tidsbrist   och   att   deltagare   varit   upptagna   med   en   mängd   andra   projekt   än   Just   Arrived.   Denna   observerade   utmaning   kring   samlokalisering   resulterade   i   svårigheter   att   upprätthålla   momentum,   och  

bekräftades  även  i  de  intervjuer  vi  genomförde  med  projektdeltagare.  Back-­‐end-­‐

utvecklaren   menade   att   den   största   utmaningen   i   projektet   har   varit   att   ingen   projektdeltagare   driver   det   på   heltid   och   att   arbetet   mellan   olika   team   sker   asynkront:

Och  det  har  varit  rent  generellt  sett  en  av  de  största  utmaningarna  med  det   här  projektet,  att  ingen  av  oss  driver  det  här  på  heltid  och  dessutom  så  är  vi   på  olika  platser,  jobbar  vid  olika  tillfällen  och  vid  olika  delar  av  veckan.

Interaktionsdesignern   menade   på   att   hon   upplevt   ett   avstånd   mellan   designteamet   och   frontend-­‐teamet.   Hon   hade   gärna   sett   att   hon   kunnat   sitta   bredvid   frontend-­‐utvecklarna   för   att   överskåda   deras   arbete   och   föreslå   ändringar:

..initialt   så   hade   vi   ett   gäng   frontend-­‐utvecklare   som   skulle   sitta   här   och   tanken   var   att   till   exempel   jag   skulle   kunna   sitta   bredvid   dem   och   bara   säga:  ”ja  men  gör  såhär  och  sen  ändrar  vi  om  det  såhär”,  men  det  har  vart   ett   avstånd   mellan   oss   och   utvecklarna   som...   för   ett   så   pass   lättviktigt   projekt   så   kanske   det   hade   kunnat   vara   tightare   men   det   kanske   är   någonting  som  kommer  att  bli  tightare.

Vi   beskrev   även   utmaningen   i   ett   narrativ   baserat   på   anteckningar   från   observationer:

Utmaningen  kring  att  upprätthålla  momentum  inom  projektet  blev  för  oss   tydlig   under   ett   möte   med   interaktionsdesignern   i   början   februari.   Under   mötet  berättade  hon  att  front-­‐end-­‐utvecklarna  nyligen  gett  besked  kring  att   de  inte  kommer  kunna  avsätta  den  tid  till  projektet  som  de  först  utlovat.  I   samma   skede   berättade   hon   även   att   front-­‐end-­‐utvecklarna   vid   den   tidpunkten  endast  implementerat  delar  av  designen  i  CSS,  medan  design  och   utveckling   av   back-­‐end   hade   ett   betydande   försprång.   (Utdrag   från   narrativ)  

För  Just  Arrived  har  tidsbristen  hos  olika  samarbetspartners  inneburit  att  flera   aktörer  inom  mjukvaruutveckling  har  behövt  anlitas  istället  för  en  enskild  aktör   som  sköter  all  utveckling.  Den  huvudsakliga  utmaningen  med  detta  är  att  det  inte   funnits   en   enskild   aktör   inom   front-­‐end-­‐utveckling   som   varit   med   sedan   projektets  början.  Detta  har  resulterat  i  att  utvecklingen  av  tjänstens  front-­‐end  ej   ägt   rum   i   symbios   med   designen,   vilket   har   reducerat   momentum   i   projektet.  

Utmaningen   har   inte   berört   utvecklingen   av   back-­‐end   vilken   för   projektet   hela   tiden   befunnit   sig   i   fas   med   designen.   Antalet   aktörer   involverade   inom   mjukvaruutveckling   har   reducerat   projektets   arbetstempo   eftersom   dessa   aktörer   tvingats   synkronisera   med   varandra   och   hållas   uppdaterade   om   förändringar  och  ny  information.  

4.2.3 Tillgång till målgrupp

Att   genomföra   kontinuerliga   användningstester   och   valideringar   av   designlösningar   med   tjänstens   målgrupper   har   varit   en   utmaning   i   projektet.  

Detta   grundar   sig   i   att   vi   inte   haft   regelbunden   tillgång   till   målgruppen  

uppdragsgivare  och  nyanlända.  I  synnerhet  har  målgruppen  nyanlända  varit  svår   att   genomföra   regelbundna   användningstester   med   då   majoriteten   av   dessa   individer  varken  kan  engelska  eller  svenska,  samt  att  det  är  en  målgrupp  som  är   svåra  att  komma  i  kontakt  med.  

För   att   kunna   validera   konceptet   och   designlösningar   genom   intervjuer   och   användningstester   behövde   vi   som   interaktionsdesigners   få   tillgång   till   målgruppen  nyanlända.  Under  två  möten  med  projektledaren,  som  var  ansvarig   för  att  rekrytera  användare  till  dessa  sessioner,  påpekade  han  att  det  var  en  svår   målgrupp  att  nå.  Detta  beskrev  vi  i  ett  narrativ  baserat  på  anteckningarna  från   observationer:

Under   ett   möte   med   projektledningen   i   slutet   av   januari   berättade   projektledaren  att  de  har  varit  svårt  att  boka  studiebesök  på  asylboenden,   och  att  överhuvudtaget  komma  i  kontakt  med  nyanlända  är  svårare  än  vad   de  tidigare  trott.  (Utdrag  från  narrativ)

Interaktionsdesignern   berättade   vid   ett   annat   tillfälle   att   de   under   projektets   början   hade   haft   svårt   att   validera   konceptet.   Hon   hade   då   besökt   Migrationsverket  i  Stockholm  i  november  för  att  prata  med  flyktingar  som  precis   anlänt,  där  det  visade  sig  vara  svårt  att  få  tillgång  till  nyanlända.  De  intervjuer  vi   genomförde   med   deltagare   i   projektet   bekräftade   denna   problematik.  

Interaktionsdesignern   beskrev   det   som   att   det   har   varit   en   utmaning   att   nå   målgruppen,  trots  att  den  är  stor,  och  att  detta  varit  en  begränsning  i  projektet.  

Projektledaren  beskrev  det  som:

Ja..   det   är   svårt   att   få   tag   på   nyanlända,   det   märkte   ju   ni   liksom.   Det   är   förvånansvärt..i  ett  vanligt  scenario  då  vet  man  ju  målgrupp  och  man  söker   upp   dem.   Men   den   här   målgruppen   är   svår   att   få   tag   på,   så   det   var   en   utmaning.

Att  validera  designlösningar  kring  språkhantering  och  översättning  har  varit  en   utmaning,   vilket   belystes   av   back-­‐end-­‐utvecklaren.   Han   sade   att   projektdeltagarna   har   haft   svårigheter   med   att   hantera   designen   av   språkhanteringen   eftersom   ingen   i   projektet   kunde   arabiska,   vilket   har   varit   problematiskt.  Att  målgruppen  varit  otillgänglig  har  resulterat  i  att  designförslag   och   koncept   inte   kunnat   testas   lika   kontinuerligt   som   vi   hade   velat.   Detta   har   medfört   att   somliga   designbeslut   har   tvingats   tas   utan   hänsyn   till   slutanvändarnas  behov.

4.2.4 Definition av MVP

I   Just   Arrived   har   det   främsta   målet   varit   att   leverera   en   första   version   av   tjänsten   på   marknaden   vid   det   angivna   lanseringsdatumet.   Dock   har   datumet   förskjutits  under  projektets  gång  på  grund  av  förändrade  omständigheter  i  och   med  att  hypoteserna  har  verifierats.  Genom  observationer  har  det  framkommit   att   begreppet   MVP   (Minimum   Viable   Product)   haft   olika   betydelse   för   de   olika   parterna  inom  design,  back-­‐end,  front-­‐end  respektive  projektledning.  Vi  beskrev   detta  i  ett  narrativ  baserat  på  data  från  observationer:

Vid   ett   tillfälle   i   mitten   av   februari   publicerade   projektledaren   en   kommentar  i  InVisionprototypen  som  tydligt  indikerade  på  att  han  hade  en   annan  bild  av  vad  en  MVP  är  än  designteamet.  I  kommentaren  skrev  han  att   notifikationsfunktionen   inte   kommer   kunna   prioriteras   i   MVP:n   som   är   tänkt   att   lanseras   i   slutet   av   april,   och   att   vi   därmed   behöver   revidera   designlösningen.  (Utdrag  från  narrativ)

De   varierande   definitionerna   är   något   som   bekräftats   genom   intervjuer.   Back-­‐

end-­‐utvecklaren  menade  på  att  han  ansåg  att  den  MVP  som  kommer  att  släppas   snarare  är  en  version  1.0  och  inte  en  MVP:  ”Sedan  när  vi  släpper  MVP:n  nu  som  vi   kallar  den..eller..jag  tycker  egentligen  i  mina  ögon,  åter  igen  allting  är  relativt..att   det  är  en  1.0  vi  släpper.  Inte  en  MVP.”

Projektägaren  beskrev  sin  syn  på  det  som  att  han  tagit  fram  MVPs  kopplade  till   de   presentationer   han   har   gjort.   Han   har   presenterat   en   MVP   informationsmässigt,   alltså   det   mista   möjliga   som   behövdes   för   att   väcka   intresse   och   få   företag   att   vilja   vara   med: “...informationsmässigt   och   presentationsmässigt  så  har  jag  arbetat  utifrån  en  MVP.”  

Projektledningen   har   benämnt   MVP   som   den   första   versionen   av   tjänsten   som   lanseras.  För  oss  som  interaktionsdesigners  har  MVP  syftat  till  något  som  bidrar   till  att  hypoteser  verifieras  som  exempelvis  en  lo-­‐fi  prototyp.  De  olika  parterna   har  således  haft  olika  definitioner  kring  vad  en  MVP  behöver  innehålla.  För  oss   som  varit  ansvariga  för  design  har  prioriteringar  gjorts  så  att  helhetsupplevelsen   för   användarna   blir   så   bra   som   möjligt,   medan   exempelvis   back-­‐end   har   prioriterat  att  det  inte  ska  finnas  några  edge-­‐case  som  koden  inte  kan  besvara.  

Detta  har  exempelvis  inneburit  att  vi  som  varit  ansvariga  för  designen  prioriterat   en  notifikationsfunktion  och  argumenterat  för  att  implementera  den  funktionen   vid  lansering,  medan  back-­‐end  menat  på  att  det  är  ett  slöseri  med  tid.

Att  begreppet  MVP  haft  olika  betydelse  för  olika  parter  var  något  som  visade  sig   främst   i   kommentarer   i   prototyper   samt   vid   flertalet   möten   med   projektledningen.   Vi   blev   genom   dessa   kommunikationskanaler   exempelvis   ombedda  att  fundera  kring  designlösningar  där  funktionen  för  notifikationer  var   exkluderad,   vilket   enligt   projektledaren   var   en   av   de   funktioner   som   behövde   elimineras   inför   lanseringen   av   det   han   kallade   för   en   MVP.   Detta   eftersom   notifikationer   var   en   av   de   funktioner   som   ansågs   vara   för   resurskrävande   att   implementera  inför  en  första  lansering.  Detta  indikerade  på  att  projektledningen   förväxlade   begreppet   MVP   med   en   MMP,   vilket   är   en   produkt   med   minsta   möjliga  antalet  funktioner  som  möter  användarnas  behov,  och  som  kan  lanseras.  

Detta  innebär  att  projektdeltagarna  haft  olika  uppfattningar  om  vad  som  behövt   prioriteras   i   projektet,   vilket   medfört   att   den   gemensamma   förståelsen   kring   produkten  tagit  skada.