Eror av systemutveckling.
Den första eran, upp till tidigt 1970-tal, när det gäller systemutveckling gjordes utan några metoder och problemområdet kantades i huvudsak av tekniska datafrågor (Avison & Fitzgerald , 2008, s577). Utvecklarna var tekniskt kunniga men inte så kunniga om organisationer, kommunikation eller kravinsamling . Projekten kantades av utdragna tider och skenande kostnader och behovet av metoder var starkt. Från tidigt 1970-tal till tidigt 1980-tal skapades den kända vattenfallsmetoden (SDLC). Men en rad kritik till SDLC, med bl.a. att det fortfarande tog lång tid att utveckla, gjorde att det från mitten av 1980-talet till sent 1990-tal skapades en mängd olika metoder för att följa marknadens snabba förändringar och behov. Perioden från mitten av 1990-talet och framåt karaktäriseras av att företag fortfarande inte var nöjda med de metoder som fanns och skapade egna, för vissa har detta fungerat, men för vissa har det inte heller fungerat och många vill därför omvärdera konceptet metoderna bygger på. Dessutom tycker många utvecklare att de flesta organisationer inte är praktiskt och funktionellt uppbyggda för att vara så flexibla som utvecklingsmetoder kräver och historiskt är det ofta så att även om metoden genomförs korrekt, kan den resulterande informationssystem misslyckas på grund av en felaktig tillämpning (White Baker, 2011).
Ett av många problem är ”Goal displacement” som enligt Avison & Fitzgerald (2008, s584) betyder att utvecklare lägger för stort fokus på att följa metodiken istället för att fokusera på de verkliga behoven och därmed döljs de viktiga frågorna. Vidare säger Avison & Fitzgerald att utvecklare blir tvungna att exakt följa metodikens alla delar för att kunna hantera svårigheter och stress. I dag löser många företag dessa svårigheter med att arbeta nära kunden i agila projekt som förlitar sig på anpassningsförmåga, flexibilitet och lyhördhet (Fitzgerald et al, 2006;. Lee & Xia, 2010, i Cram & Chen). Även Yoon et. al. (2012) menar att tjänstens kvalitet mäts av kunden vid det ögonblick tjänsten används, vilket leder det till nöjda kunder.
Ett annat problem är ”Difficulties in adopting a methodology” som enligt Avison & Fitzgerald (2008, s585) betyder att ett företags nya metodik inte uppfyller användarnas önskan om hur de vill jobba. Att omorganisera och utbilda begränsar utvecklarnas frihet och skicklighet, anser de. Varje metodik måste omformas för att passa ett företag och deras verksamhet och blir en ”in house” metodik. De menar att vissa leverantörer av metodikerna att organisationer inte gjort tillräckligt för att genomföra metodiken. Det kan vara sant men användare av metodikerna upplever ändå besvikelse och otillräcklighet och några söker fortfarande efter den heliga graalen för metodiker. Dessutom beror systemutvecklingen på vilken typ av utvecklare det är som kommer samt vilken erfarenhet utvecklaren har och arbetserfarenhet. ”Det beror på!” sade Urban Sandström på Knowit Norrland i Umeå. ”Det viktiga är inte att följa en viss metod utan att vi tar hand om kunden och våra anställda”, säger Urban vidare. Yoon et. al. (2012) menar att det finns ett holistiskt och ett ontologiskt perspektiv på hur man ser på projekt, metoder och tekniker. Åter igen visar detta på att det inte är viktigt att följa en viss metodik utan fokus är på att jobba agilt och nära kunden via arbetssätt som kunden känner igen, tex Scrum och fokuset ligger på att upprätta långa och många kundrelationer med nöjda kunder.
Ett tredje problem är om skapandet av metodiker har lett till bättre system? ”No improvements” , som Avison & Fitzgerald (2008, s586) kallar det. De menar att vissa företag verkligen har försökt arbeta med olika metodiker men det hjälpte inte, och det kan ha aktivt hindrat utvecklingen av bättre metoder. Tre personer som jag pratat med och som jobbar på olika företag säger sig ha utarbetade metoder som är omgjorda för att passa deras verksamhet och har fått egna ”coola” namn (företaget måste ju verka proffsigt). Men det intressanta är att de inte följer sin egen metod till punkt och pricka utan mycket bygger på erfarenhet, skicklighet och magkänsla hos utvecklaren. Att jobba ”Ad hoc ” anses av Avison & Fitzgerald som att återgå till tiden före skapandet av metodiker, men tydligen jobbar idag många företag utifrån ”Ad hoc” i alla fall utifrån ett agilt perspektiv, dvs. jobbar tillsammans med kunden.
Källor:
- Avison, D.E. & Fitzgerald, G. (2008). Information Systems Development - methodologies, techniques & tools. (Fjärde upplagan.) London: McGraw-Hill
- Byungun Yoon, Sojung Kim, Jongtae Rhee. (2012). An evaluation method for designing a new product-service system. Expert Systems with Applications, Volume 39, Issue 3, 15 February 2012, Pages 3100-3108
- White Baker, E. (2011), Why situational method engineering is useful to information systems development. Information Systems Journal, 21: 155–174. doi: 10.1111/j.1365-2575.2010.00352.x
Sammanställt av: Andreas Gustavsson 13-02-22