Doxa

Softwareleverandørens Tip #3: Vær tilstede, vær engageret og forvent åbenhed

2010-07-08T19:02:00Z

Som teamleder på en del større danske ehandelsprojekter har jeg gjort nogle observationer omkring hvilke forhold der typisk gør, at projektet trækker ud, og ender med ikke at kunne gå i luften ifølge tidsplanen og/eller bliver dyrere end forventet. I denne serie af subjektive og ensidige betragtninger omkring softwareprojekter vil jeg forsøge at formulere nogle gode råd set fra softwareleverandørens perspektiv, der kan hjælpe dig med at navigere igennem processen at søsætte et nyt it-projekt.

Af Joachim Lykke Andersen - http://devtalk.dk

At købe en skræddersyet e-handelsløsning eller for så vidt en hvilken som helst it-løsning, er ikke det samme som at købe en maskine, et forretningslokale eller et parti varer. For at projektet kan lykkedes, kræves at leverandøren i en hvis udstrækning har indsigt i dit domæne-område - i det du laver, og i den måde din virksomhed gør tingene på. Virksomheder er forskellige, som mennesker er forskellige, og to virksomheder inden for samme branche med samme målgruppe, kan internt fungere helt forskelligt, og have vidt forskellige kulturer.

Derfor er det væsentligt for et samarbejde at man har et åbent samarbejde, hvor man reelt arbejder sammen om at nå det fælles mål, og ikke suboptimerer dele af projektet.

Suboptimeringsspiral

Det der ofte sker er at forskellige leverandører f.eks. webudviklingen, konsulenterne på økonomisystemet, marketingsafdelingen, den interne it-afdeling, reklamebureauet osv. har forskellige målsætninger, og alle bliver målt på projektet ud fra forskellige vinkler. Det leder hurtigt til, at enkelte dele af projektet suboptimeres, og forsøger at vinde overskud i et presset projekt, ved enten passivt at udstille andre dele af projektet, og i sjældne tilfælde at sabotere andres udvikling ved at tilbageholde viden.

Intet af dette sker fordi nogen vil at projektet skal fejle. Alle ønsker faktisk at det hele lykkedes, og det bliver en succes. Man har givetvis også sympati for andre involverede i projektet - men som man siger: når krybben er tom bides hestene. Når alles ressourcer er presset i bund, så vil alle instinktivt forsøge at undgå, at være dén der ser ud til at have den største andel i, at projektet er forsinket.

Er projektet kommet ud i denne spiral, vil man se symptomer som "cc" krig, hvor alle cc'er gud og hver mand ind på selv de mest trivielle mails, telefon-møde helvede, hvor ligeledes alle mulige interessenter i projektet deltager, ingen tidligere har set eller hørt noget til, daglige statusmails til og fra alle. En generel paranoia, hvor al viden bliver sendt til alle, på mange forskellige måde med meget kort tid i mellem.

Dette er ikke en særligt produktiv atmosfære. For det første går der alt for meget tid med dette overflod af krise kommunikation. For det andet, så bliver der ikke arbejdet sammen om at løse problemerne. Man løser kun sine egne problemer og engagerer sig ikke i projektet som helhed. Ofte vil det betyde at der ikke er nogen der reelt tager vare på slutresultatet og tager ansvar for at helheden vil fungere til sidst.

Hvad gik der galt?

For det første blev der ikke etableret et reelt samarbejde fra starten, og for det andet blev ikke vedligeholdt undervejs.

Fra starten af projektet, er det meget væsentligt, at der bliver etableret en samarbejde, hvor alle er enige om, at det er en fælles process der skal lykkedes, at du som kunde er indstillet på, at det også er dit ansvar at det lykkedes. At alle er indforstået med at der eksisterer områder i projektet, også hos andre, hvor der er en risiko for at der kan ske forsinkelser. Her skal man være enige om at det VIL forekomme, og så træffe en beslutning om hvordan det skal håndteres. Laver man software til VM, ja så er der jo en deadline der er overskredet; den er ikke til forhandling; det er for sent nu. Det kræver én type håndtering. I andre sammenhænge er kvaliteten vigtigere end tidspunktet. Men hvis alle er enige om hvordan man griber det an, når projektet, et eller andet sted, bliver forsinket, så er man allerede på forkant.

I det daglige vedligehold af det gode samarbejde er der to vigtige elementer. Det er vigtigt at man kan være ærlig omkring de problemer der opstår undervejs. Der er altid, i softwareudvikling, uforudsete vanskeligheder: data der ikke er godt nok, ting der ikke er tænkt godt nok igennem, forkerte beslutninger der er truffet. Det er ok. Det er et sundhedstegn for projektet, at de kommer til overfladen, for de er der et eller andet sted. Så hvis du aldrig har hørt om problemer fra din leverandør, så vær meget bekymret!

Derudover er engagementet fra dig som kunde, enormt vigtigt. Du har dels en masse viden, som vi som leverandør skal bruge, men det er også din opgave at være drivkraft i, at få denne åbenhed og ærlighed etableret og vedligeholdt. Så hvis du ikke som minimum deltager til et scrum-møde eller lignende status møde, en gang hver 14. dag, så er dit projekt sandsynligvis allerede på afveje. Du skal være der, høre udviklerne snakke, og bidrage med alle de ressourcer du ligger inde med, være kritisk og nysgerrig - og åben over for at forstå hvilke problemer udviklerne slås med, for de er lige så meget dine problemer som det er deres.

Skal dit projekt med andre ord være en succes, skal du være til stede, være engageret og forvente åbenhed af alle parter uanset hvor dårlige nyheder du modtager. Det siger sig selv - men det kræver hårdt arbejde og mod at gennemføre i praksis!

Andre tips

Softwareleverandørens Tip #1: Content, content, content

Softwareleverandørens Tip #2: Byg en kerne og udvid senere

2010-05-08T07:08:00Z

Af Joachim Lykke Andersen - http://devtalk.dk

Når man nu har besluttet sig for at få en lækker ny webshop, så vil det typisk inspirere til en brainstorm session, hvor man bringer alle de fede ideer på banen, som man overhovedet kan komme i tanke om, og finde rundt omkring på konkurrenternes shops. Der er mange interesser i organisationen der skal tilfredsstilles,der går også let politik i den omkring hvilke områder på sitet der skal have prioritet, og der dukker alskens darlings på banen, som man har forelsket sig i. Alt i alt vil man bare gerne gå i luften med et site som Amazon fra dag et.

Ud fra dette bliver der så skrevet en projektbeskrivelse og/eller lavet en foranalyse, og i mange tilfælde bliver projektet sat i værk med en enorm backlog af featureønsker, som skal gennemføres før projektet er "færdigt". Og det er her det går galt, for prioriteterne ender ofte med at blive uklare, mudret af alle de feature ønsker man glæder sig til at se på shoppen. Derved ender fokus med at ligge på elementer der ikke indgår i det, der er allermest fundamentalt for en webshop: At man kan lægge et produkt i kurven, og gennemføre et køb.

Prioritetskampen om hvilken darling der er vigtigst, og nørkleriet om hvordan konkret alle detaljerne skal implementeres er en af de største årsager til at et softwareprojekt bliver forsinket. Udviklerne bliver forvirrede hvis prioriteter ændrer sig hele tiden, og der er desuden en masse overhead i at context-switche fra en opgave til en anden, og tilbage igen. Derudover vil den øgede mængde features også give en øget kompleksitet i projektet og i projektplanlægningen. Det er ikke en ukendt sag, at man i softwarehuse kaster ekstra folk på et projekt der er ved at løbe af sporet, fordi der er mange features der kan løses som "selvstændige opgaver", hvilket aldrig gør noget godt for processen.

Når man når den kritiske fase til sidst i projektet retter fokus sig altid på det der er vigtigst, at kunne handle. Og når indkøbskurven ikke helt spiller, og produktlisterne er langsomme, vil det altid føles som den største ærgelse, at man har lagt en masse energi på at lave en liste over medarbejdere, en blog eller twitter integration.

Tip: Lav kernen først

Hvis du vil hurtigt i mål med din shop så gør dig og din leverandør den tjeneste at lave et projektforløb, der fokuserer på at få lavet kernefunktionaliteten først. Lav en prioriteret liste over hvad der absolut er need to have, aflever den prioritetsliste til leverandøren og lav den ikke om. Alle ændringer, tilføjelser og udvidelse gemmes til efter kernen er færdig og afleveret.

Der er ingen der siger, at du skal gå live kun med kernen, men lav den først og hold prioriteterne. Modtag det og test det rigtigt godt igennem. Sørg for at det performer godt også ved det besøgstal i forventer. Når det er sket, så tag en iteration mere, test det - og fortsæt indtil du vurderer sitet er klar.

Prøv at lade være med at holde leverandøren fast på en endegyldig fast leveringsdato, men aftal en tidsramme og følg med i den udvikling der sker, så du kan se at fremskridt sker som planlagt, og vær tæt på projektet så du ved når der er forhindringer i vejen, som du måske kan være med til at få afklaret.

Andre tips

Softwareleverandørens Tip #1: Content, content, content

2010-05-05T15:33:00Z

Af Joachim Lykke Andersen - http://devtalk.dk

The Bleeding Obvious

Det at købe en ny shop på internettet hos en softwareleverandør svarer lidt til at bestille en ny butik hos en entreprenør - altså bygningen og de fysiske rammer. Når du som forretningsdrivende overtager din nye butik, vil du selvfølgelig gå igang med at indrette butikken med dine varer og sørge for at de præsenterer sig bedst muligt for kunden, samt at der er det rigtige flow i butikken, så du maksimerer dit salg. Så du forventer ikke at du bare kan møde op på dagen, hvor entreprenøren er færdig med butikken, og så åbne direkte op for kunder. Der er stadig masser af forberedende arbejde før butikken kan åbne.

Dette gør sig også gældende når du skal åbne din butik på nettet. Du skal sørge for at produkterne tager sig godt ud og at der er det rigtige flow i din butik. Men hvor den fysiske butik kan give køberen varen i hånden, så de kan føle på den og se den an, så har du ikke samme mulighed på nettet. Derfor er det ekstra vigtigt at billederne er flotte, i god nok opløsning og viser det man som køber vil se; det er vigtigt at beskrivelserne er gode, sælgende og optimerede til organiske søgninger; der skal være alle relevante specifikationer, relaterede produkter og produktforslag osv. osv. som gør at man som køber føler sig tryg nok og overbevises om at det er det rigtige valg.

At blive enige om dette, er nok ikke vanskeligt. Jeg tror vi allesammen er med hertil.

Integrationsløgnen

Men i praksis har rigtigt mange virksomheder der går på nettet med deres forretning ikke gjort sig klart, hvor meget arbejde der egentlig ligger i at klargøre butikkens indhold. Jeg støder meget ofte på den holdning, at alt dette data kan integreres fra økonomisystemet hvor der jo allerede ligger produktdata, og eventuelt data fra andre systemer der måske indeholder data og billeder til kataloger eller andet. På denne måde forestiller man sig, at det er muligt at slippe let udenom den opgave, og at man er klar til at gå i luften når websitet leveres fra leverandøren.

Det viser sig dog aldrig at være tilfældet, og det ender med at have en af to mulige konsekvenser: Enten så går butikken først online meget senere end man havde planlagt, eller også går butikken online med dårligt indhold og konverterer katastrofalt dårligt.

De tekster man kan finde i økonomisystemet er sjældent web-rettede tekster, og er i mange tilfælde interne tekster, som ikke er tænkt at en kunde skulle se. Teksterne kan være formateret dårligt, mangle korrekturlæsning og findes måske reelt kun på 60% af produkterne, og er ihvertfald slet ikke optimerede til søgemaskiner. Billederne er typisk tiltænkt helt andre formål, og passer ikke til produktpræsentation på web og er i mange tilfælde ikke i god nok kvalitet. De produktrelationer man kan finde, giver måske ingen mening som "relaterede produkter" i en webshop.

Derudover har man måske i sine designskabeloner bygget en hel indholdsstruktur med artikler om virksomheden og om virksomhedens produkter, og måske endda en community sektion.

Tip

Så når man sætter gang i sit e-handelsprojekt nytter det ikke noget, at man overdrager sitet til softwareleverandøren, og så ellers afventer at man modtager sin nøglefærdige shop, og regner med at data kan samles sammen fra hid og did - for det vil ikke fungere!

Det er vigtigt at man allerede mens man går igennem design-iterationer på sin shop, at man sørger for at afklare hvor data skal komme fra, og får afklaret kvaliteten af data, man mener allerede eksisterer.

Det vil sige at man går produktsidens tekster, billeder, relationer mv. igennem én for én og afgør hvem der er ansvarlig for, at det pågældende data er klar, beriget eller forfattet - ikke til launch, men i rigtig god tid inden: Det er meget væsentlig at sitet bliver testet med det rigtige indhold, og ikke blot med "lorem ipsum" tekster og dummy data, som udvikleren jo selvfølgeligt har styr over. Det er noget ganske andet med rigtigt data fra andre systemer.

Man skal sørge for at alle planlagte artikler og tekster bliver skrevet, korrekturlæste og eventuelt oversat til relevante sprog. Der skal være planlagt indholdselementer, som bannere og kampagner.

Kort sagt: Brug tiden mens softwareleverandøren udvikler løsningen til at få udarbejdet content til din shop, og vær bevidst om, at det ligeså høj grad er kvaliteten af content der konverterer, som det er den tekniske kvalitet af shoppen - hvis ikke højere.

Andre tips

Softwareleverandørens Tip #2: Byg en kerne og udvid senere