Bliv gratis medlem
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
Opret bruger