Et it-projekt handler om at levere noget til kunden. Og vi skal levere det, som kunden forventer, og helst til tiden... og til den aftalte pris. Så det gør vi, og alle glade, og dét var så dét blog indlæg. Eller hvad?
Ja, hvis virkeligheden så sådan ud, så ville der flyde mælk og honning på gangene hos landets it-leverandører, og ikke mindst hos alle deres kunder, men det gør der ikke – sidst jeg så efter…
I stedet for er virkeligheden fuld af kuldsejlede it-projekter både inden for den offentlige sektor (dem vi hører om, for her taler vi skattekroner..) og inden for den private sektor (dem vi IKKE hører så meget om... hmmm). Nuvel, der findes mange vellykkede it-projekter, men de er i denne sammenhæng ikke så interessante – og jeg tør godt vove det ene øje på, at de heller ikke udgør et flertal.
Der er rigtig mange kloge mennesker, der har skrevet mange kloge ord om dette emne – senest har jeg læst om ”5 holdninger til statslige it-understøttede forretningsprojekter”, der er formuleret af DANSK IT. Her står mange fornuftige ting, der helt sikkert ikke alene gælder for it-projekter i det offentlige, men også i den private sektor. Hent de 5 holdninger i pdf-format hos DANSK IT her.
Men hvordan ser det dårlige it-projekt egentlig ud indefra, dér hvor udviklerne sidder og tamper febrilsk i tasterne, høje på pizza & coca-cola, alt imens projektlederne kæmper med graferne og forsøger at overbevise kunden om, at der bliver leveret til tiden…
Det er hér vi kommer til leverancens forbandelse. For når et it-projekt er presset, så kommer det alt for ofte til at handle om AT levere, og ikke om HVAD der bliver leveret. Det skyldes som udgangspunkt den indgåede kontrakt, som kan indeholde meget rigide deadlines, og hårde bodsbetingelser hvis ikke der leveres. Og det betyder, at der bliver gået på kompromis med... hvad som helst! Udviklerne bliver bedt om at lave hurtige løsninger på komplekse problemer, og de leveringsansvarlige laver kreative fortolkninger af kravspecifikationen, fordi vi SKAL jo levere – koste hvad det vil.
Så der BLIVER leveret, i bedste fald noget halvfærdigt, i værste fald noget ubrugeligt. Den tekniske gæld eskalerer, og når der skydes genveje i den interne kvalitet – f.eks. mangelfulde eller helt udeladte unittest, dårligt design, etc., så kan det have alvorlige langsigtede konsekvenser, som der aldrig bliver kompenseret for. For hvornår bliver der tid & penge til at rette op på dårlige tekniske beslutninger taget under hårdt pres før en deadline? Never, ever...
Og mens kunden får en dårlig leverance og leverandøren et dårligt ry, så mister teknikerne – udviklere, arkitekter, testere - deres integritet, ja måske oven i købet troen på, at deres arbejde bliver taget alvorligt. For selvom softwareudvikling er en kreativ proces, så er det i højeste grad også et håndværk, hvor dygtige og stolte håndværkere står værn om kvaliteten af deres arbejde.
Når softwareudvikling derfor blive reduceret til ”at levere”, hvor det er sekundært hvad der bliver leveret, så er det et spil, som kun har tabere – kunden, leverandøren og udviklerne.
Hvad skal vi så gøre for at imødegå dette scenarie, når vi ofte arbejder i et landskab med fastpriskontrakter, hvor it-projekter på samme tid er tids- og funktionalitetbundet?
Det vil jeg komme med et bud på i et kommende indlæg på denne blog, men indtil da, kære læser, kan du jo tænke over, om du ville bygge dit hus eller en storebæltsbro eller et operahus på samme måde, som vi nogen gange accepterer at bygge software.
Ingen kommentarer:
Send en kommentar