Var går gränsen mellan process och produkt?

Sketches

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

5 reaktioner på ”Var går gränsen mellan process och produkt?”

  1. Jo, det du beskriver är en organisation som inte kan skala agilt på ett vettigt sätt. Det vanligaste ramverket för agil utveckling, Scrum, förutsätter att ett arbetslag kan möta ett helt behov. I större organisationer behöver detta kompletteras så att flera lag kan svärma runt ett helt värdeflöde. Det är inte speciellt svårt att göra men kunskapen är inte så spridd. Men man utgår från värdeflödena, och använder kravfångnings- och koordineringstekniker som är anpassade för smidigt samarbete mellan arbetslag, i en mix med beställare och utförare.

  2. Ola, tack för din kommentar.

    Håller med dig om att min lösning inte skalar i större organisationer. Men om man hade en aula full med folk och man bad åhörarna att räcka upp handen om de kände igen sig i situationerna som beskrivits så tror jag tyvärr att många skulle räcka upp handen.

    Jag vet inte om det är okunskap eller svårighet som gör att det faktiskt är en vanlig fälla att hamna i och eftersom du tycks besitta kunskapen och inte tycker att denna orkestrering inte är svår så är jag ivrig att höra mer … har du några organisationer där detta fungera bra? Vilka metoder och tekniker är det du refererar till?

    // Vetgirig

  3. Robert, jag håller med dig i din beskrivning, tycker du har en intressant vinkling och ordval på ett tema som upptagit mig mycket de senaste åren. Jag håller inte med den moderna trenden som innebär en tro att saker bara kan skalas vid att bygga ner hierarkier/nivåer och sen kasta dit flera lag som ska ”svärma” som Ola kallar det. En sådan metodik kräver antigen en enkel både affärs- och IT-miljö (som man iofs alltid bør sträva mot ändå), alternativt att man tillåter en uppsjö av oberoende lösningar med dels överlappande funktionalitet men med ett lag runt varje.
    I en organisation jag arbetat mycket senaste åren bygger man aktivt ner skikten i arbetssättet men har samtidigt ett behov av att samordna runt veldigt många delar i arkitekturen, ex reskontror med kompliserat affärslogik, gemensamt kundregister, säkerhetslösningar, arkiveringslösningar mmm. Det är omöjligt för ett lag att ratta allt detta och förvirringen blir oftast total när man försöker blanda flera lag (eller även bilda nya tillfälliga lag vid att plocka från specialistlagen), och ingen kan riktigt greppa affärens perspektiv och kanske även ingen kliver fram och tar ansvar för lösningsövergripande beslut. Resultatet blir ett oerhörd slöseri med tid och pengar, som enkelt kunde undvikits vid att lägga en liten mängd krut på att initialt arbeta med affärens systemoberoende behov (storymapping, affärsregler, kanske infobehov) och med systemövergripande inriktningsbeslut för realiseringen. Rädslan att fastna i klassiska ”kravdöden” är stor och man väljer i stället att kasta ut bebisen med badvattnet.

  4. ”Den verkliga beställarsidan på företag är processorienterade” – sällan eller aldrig säger mig mina 30 år i branschen.

    ”processorientering, detta medför i det flesta fall att deras IT-stöd består av fler än ett verktyg.”
    – Alltid.

    ”Många gånger är IT-sidan på företag orienterade efter verktyg, åtminstone när det kommer till verklig implementering och exekvering.” – Alltid utom i en produktaffär som Spotify. Men du kan ge dig på att de har samma problem som alla andra när det kommer till Admin-IT. = ekonomi, marknadsföring …

    ”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.”
    Jajamen så är det. Dina IT-produkter kommer alltid se ut på det sättet till verksamheten ändrar på sig.

    VAD KRÄVS??
    – tyvärr finns det ingen silverkula!
    – Verksamheten måste organisera sig efter en operativ modell baserad på förmågor och värdeflöden.
    – Kika på ”Enterprise Architecture as a Strategy” – Ross, Weill, Robertson, – här förklaras allt i detalj. Tyvärr är det sjukt svårt att ta sig till Business modularity.
    – Agila metoder hjälper men det är lätt att gå vilse. (LeSS, SAFe, Scrum of Scrums hjälper inte).
    – Företagets governance, performance management och incentive management måste sluta styra, mäta och belöna efter linjefunktion.
    – Styr, mät Värdeflöde och Förmåge maturity ökning med en kollaborativ incentive modell.
    – Styrning, Leverans, Mätning måste bygga på självbestämmande och en kombination av bottom up+top-down+outside-in – inkludera kunder, leverantör, partners i värdeflödena.

  5. Tack Björn och Alexander för era kommentarer och att ni nyanserar och kompletterar bilden av både situation och lösning!

    Definitivt ett område att jobba vidare kring och förkovra sig i, i både det lilla och stora perspektivet.

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *