March, 2006   

Teknisk ateism i religionernas värld

Att nämna vattenfallsmodellen i en metoddiskussion är som att svära i kyrkan. Denna ”gamla hederliga” metod ses nämligen som en dinosaurie i projektmetodik, en relik från gamla tider som man gör bäst i att glömma. Allra helst skulle nog många projektledare och IT-konsulter vilja se det som att de gått vidare och lämnat vattenfallsmodellerna bakom sig.
      Istället sysslar man med modern teknik och moderna metoder, som är både dynamiska, iterativa och ”agile”. Systemförvaltning, funktionalitet och effektivitet är hopplöst förlegat--nu är det life-cycle management, on-demand, XP, RUP och usability som gäller.
      Vid första anblicken verkar det vara en djungel av buzzwords snarare än något konkret, men visst är skillnaden mellan den moderna iterativa metodiken och den tidigare rigida vattenfallsmodellen viktig. Problemet är emellertid att metoden, oavsett vilken som för tillfället gäller, av branschen ses som frälsaren för projekten på samma sätt som tekniken föreslås frälsa kunderna.
      Metod och teknik är emellertid endast medel i strävan att uppnå ett mål: affärs- eller verksamhetsnytta. Det kan aldrig vara ett mål i sig att använda en viss metod. De som idag talar sig hesa för metoder som är ”agile” är i mångt och mycket samma sorts personer som tidigare propsade på att Boehms spiral var oslagbar i alla möjliga och omöjliga lägen. Detsamma gäller tekniken: precis som stordatorn visade sig oförmögen att frälsa oss, kan inte heller webben göra detta. Att de frälsta konverterat till en ny religion löser inte problemet med den blinda tron.
      Om IT skulle innebära ett värde i sig för verksamheten, på samma sätt som produktion eller försäljning, så skulle allt vara frid och fröjd. Men så är aldrig fallet--verksamheten söker stöd av IT, men inte tvärtom. Kunder kan stå inför problemet att faktureringsprocessen är långsam och genererar en mängd fel, vilket man kanske kan lösa med hjälp av IT och automatisering. Men det bör inte vara så att ett företag står med ett större IT-system som man söker verksamhetsprocesser till.
      Likaså kan utvecklingsföretaget söka stöd i metoder för det enskilda projektet och därigenom styra upp arbetet och undvika vanliga fallgropar. Men att göra tvärtom, att ha en metod och söka projekt som tvingas in i metoden, är direkt kontraproduktivt och leder ofta till mer problem än nytta. Ändå är det ofta det senare som gäller: ”Vi gör system på det här sättet, vilken sorts lösning var det du ville köpa av oss?” En metodisk utvecklingsprocess är inte samma sak som att använda en formell metod!
      Både metod och teknik blir vad man gör dem till. Att se till att använda RUP i ur och skur, och utan eftertanke, blir nästan alltid för dyrt och omständligt. Att utveckla ett helt nytt system i .NET, där endast en smärre förändring i det befintliga RPG-systemet skulle klara biffen, kostar mycket mer än det smakar. Kunden söker den bästa lösningen på problemet, knappast en predikan om vad som tillfället är den ”enda” vägen.
      Det blir faktiskt ofta fel när representanter för IT-branschen går in i uppdrag med en tydlig bild om vilken teknik som ska lösa problemet och med vilken metod lösningen ska utvecklas. Man verkar begränsad till att se produkter, när man i själva verket säljer tjänster; man har ett statiskt synsätt när man borde ha ett dynamiskt och flexibelt. Det är få arkitekter som redan innan de träffat kunden bestämt husets utseende och storlek, samt vilka material som ska användas. Det är heller inte ofta man träffar på en frisör som bara vill klippa en sorts frisyr--på ett sätt.
      När man säljer tjänster är kundens behov det centrala; det finns alltså inga ”löpande band” för produktion av IT-system och -tjänster. Det är en sanning som alla känner till och en gyllene regel många anser sig efterfölja. Men om kundens behov är det centrala, hur kommer det sig då att det som levereras sällan stämmer överens med kundens förväntningar? Varför föreslås lösningar i en och samma teknik, som utvecklas på ett och samma sätt, oavsett vem kunden är eller vilka problem denne har?
      Ibland är det faktiskt tillräckligt med något gammalt och beprövat, oavsett hur häftigt och hip det nya är. För vissa är ett textbaserat faktureringssystem på AS/400 en bättre lösning än ett integrerat faktureringssystem med on-demand-tjänster och webbgränssnitt. I många projekt är en enkel metod med fasta och entydiga milstolpar mycket billigare, snabbare och bättre än den senaste agile-metoden med life-cycle management och obligatoriska iterativa usability-moment. Gammalt behöver inte betyda dåligt.
      För mig är det således inget problem att svära i kyrkan, för jag är inte troende. Hellre ser jag till att en kund får en fungerande vattenfallsmodell att styra upp sin process, än att kunden kan stoltsera med en mängd buzzwords medan problemet i allt väsentligt kvarstår olöst. När alla andra verkar tävla i att med starkast stämma sjunga herrans lov, ser jag hellre min konsultroll som den nyttokalkylerande ateisten i en sekulariserad IT-bransch.




Subscribe to the PerBylund.com Update! Subscribers receive a short e-mail message every time one of Per Bylund’s columns is published, with a synopsis and link.

Subscribe here: www.PerBylund.com/notifier/?p=subscribe