Jag börjar med att sticka ut hakan genom att generalisera rörande hur man är organiserad på större företag:
- Den verkliga beställarsidan på företag är processorienterade, detta medför i det flesta fall att deras IT-stöd består av fler än ett verktyg.
- Många gånger är IT-sidan på företag orienterade efter verktyg, åtminstone när det kommer till verklig implementering och exekvering.
Moderna utvecklingsmetoder förespråkar att man som beställare ska jobba nära implementationsteamet. Detta betyder, tillsammans med ovanstående generalisering, att en beställare kan ha fler än en motpart när det kommer till att realisera sina behov.
De senaste åren har jag jobbat både som kravställare och som kravhanterare. Jag har därmed erfarenhet av både egen och andras frustration kring när produkt/projekt krockar med process.
Här kommer två konkreta utmaningar som jag observerat:
-
Lösningen är satt / begränsad i och med val av team/produktägare (PO). Trattning av krav måste ta sig igenom ett applikationsneutralt filter som gör att man som beställare får rätt motpart. Dock måste man fortfarande i dessa lägen veta vad man ska kravställa mot vilket team, vilket förstås resulterar i frustation. Det är nog inte ovanligt att det applikationsneutrala lagret missar detaljer som potentiellt gör att lösningen borde ha spridits över fler applikationer. Många diskussioner hålls ju rätt ”långt” nere vilket gör att man söker lösning på problem i de team man har framför sig. Det kan lätt bli ett klassiskt fall av – "you don't know what you don't know". Hur kan man som verksamhet / beställare eller som IT veta att något är olämpligt eller helt fel att implementera i ett visst system, då man inte har kunskap om helheten? Det kräver en kunnig beställare och IT för att detta ska undvikas.
-
Lösningen bor i många team så vem har ansvaret att inse detta, och att koordinera? IT som ska komma med lösningen, eller beställaren som äger processen? Är det rimligt att beställarsidan (=verksamheten) ska bestämma lösningen på problemet man har? För det är enligt mig de facto det man gör i situationer då man kräver denna insikt av beställaren. Alternativet är att teamet och produktägaren (PO) faktiskt inte är plattforms- eller applikationsknutna utan supportar verksamheten med ett spann av IT verktyg. Så är ju sällan fallet, och igen kommer det applikationsneutrala lagret som en räddning.
En annan utmaning, med samma troliga lösning, är att man råkar implementera samma sak i flera system, dvs varken IT och beställarsidan är koordinerade över flera initiativ.
Agila utvecklingsmetoder som SAF, samt moderna kravhanteringsmetoder, hanterar alla på ett eller annat sätt problemet genom att man har ett systemabstrakt lager. Detta lager hanterar trattandet av krav och övervakar det totala systemlandskapet. Det intressanta med det är dock att man adresserar IT:s utmaningar och inte hur beställarsidan bör vara organiserad för att minska slitningarna som process/produkt innebär. För skapar man en spegling av IT:s organisation på beställarsidan så har man plötsligt en situation där:
- IT inte längre har tillgång till den "riktiga" beställaren.
-
Man försöker hitta lösningar i den applikation man representerar. "You don't know what you don't know" utmaningarna kvarstår alltså, då teamen (inkl beställare/PO) i slutändan är det som är ansvariga att finna lösningarna. I och med det öppnar man upp för redundanta och "felaktigt" implementerade kapabiliteter.
Men vänta nu - vi verkar vara tillbaka på ruta minus ett! :(
Ett sätt att organisera sig på, som jag har erfarenhet av och som kan förhindra vissa fallgropar, är att man har verksamhetsanalytiker och/eller arkitekter som är operationellt aktiva i implementationen. De behöver då vara delaktiga på en tillräckligt detaljerad nivå för att fånga upp lösningar "på drift" och övervaka det totala lösningslandskapet. På detta sätt blir de ett komplement till teamet, PO:n och de verkliga beställarna/slutanvändarna.
Via tillgänglighet och delaktighet av personer som rör sig vertikalt genom de olika abstraktionslagrena bryggar man över gap som annars får information att fastnat i överlämningar mellan olika faser, backloggar, personer, etc. Det handlar helt enkelt om att kortsluta och minimera överlämningar, vilket inte är ett direkt kontroversiellt koncept. Det är dock inte lätt att få till, men vem har sagt att det ska vara lätt att få saker gjorda rätt. Jag tror att detta kan fungera om de vertikalt frifräsande personerna kan tänka sig att tumma lite på sin prestige.
Vore intressant och höra vad ni tycker om min ide eller om någon där ute har hittat någon "silver bullet" och vill beskriva hur det ska gå till?
Robert Wallerblad, Require AB