I del ett av denna serie tog vi upp de många problem som är förknippade med den traditionella projektfinansieringsmodellen och nämnde att organisationer måste övergå från projekt till produktmodellen. Låt oss nu gå in på detaljerna kring varför detta skifte är så viktigt.
Varför gå från projekt till produkt?
Produktmodellen erbjuder ett alternativt tillvägagångssätt som hjälper organisationer att leverera mer värde, snabbare och på en högre nivå av hållbar kvalitet genom att ta itu med de problem som nämns ovan. Dessutom lägger produkttänkandet större vikt vid innovation och förbättring, vilket bidrar till att hålla organisationen i linje med kundens behov. Det gör man genom att gå ifrån tillfälliga team fyllda med lånade personer och ersätta dem med halvpermanenta tvärfunktionella team som består av kompetens från alla relevanta avdelningar, där varje team är inriktat på en produkt eller ett företag värdeflöde.
Målet med produktmodellen (eller värdeflödesmodellen) är att skapa team som klarar av att utföra minst 80 % av det arbete som de ska utföra utan att behöva ta hjälp av ytterligare personal. Därför är det vanligt att organisationer som arbetar med mjukvaruutveckling enligt denna modell har team som består av:
- Produktchefer
- Designers
- Front-end- och back-end-utvecklare
- Kvalitetstestare
- Utplaceringspersonal
- Någon annan som behövs för att slutföra merparten av arbetsleveransen
Detta skapar självförsörjande team som kan arbeta i alla faser av produktutvecklingen, från vision till värde, utan att behöva ytterligare hjälp. Att ändra fokus från projekt till produktutveckling är dessutom användbart för att bryta ned silos mellan avdelningar och skapa ett system som främjar äkta samarbete.
Istället för att låna arbetskraft för tillfälliga uppdrag sätts team i en sund situation där deras mål inte bara är att slutföra projekt utan att arbeta tillsammans för att se till att värde ständigt levereras för deras produkt eller värdeflöde på en konstant hög kvalitetsnivå och att de har den domänkunskap och de relationer som krävs för att se till att resultaten optimeras så att de uppfyller kundens behov.
Enligt SAFe®-modellen består dessa team i allmänhet av cirka 10 personer och arbetet tilldelas hela teamet, inte enskilda medlemmar. Teamen arbetar med Scrum eller Kanban, men -medlemmarna ingår alltid i samma team, oavsett hur arbetet levereras.
Det är viktigt att se till att människor inte arbetar i mer än ett team, eftersom det leder till att avdelningar konkurrerar med varandra om kapaciteten, vilket hindrar människor från att ägna sin tid och sina ansträngningar åt att utföra arbetet på ett effektivt sätt.
I en mindre organisation med mindre produkter och en modern, frikopplad teknikarkitektur kan dessa autonoma tvärfunktionella team vara allt som behövs för att uppnå smidighet i verksamheten. Men i många fall måste större organisationer hantera stora, komplexa produkter med gamla arkitekturer som verkligen kräver många samordnade team som arbetar tillsammans för att leverera verkligt värde. I det här fallet grupperas Agile-team i "team av team". SAFe kallar dessa Agile Release Trains (ARTs ). De kallas för flyg, stammar, vingar och många andra lokala termer, men i alla fall består de vanligtvis av 5-12 team och någonstans mellan 50-125 personer som arbetar med gemensamma tekniska och affärsmässiga mål, så att organisationen kan reagera på förändringar och leverera värde på ett effektivare sätt.
Slutresultatet är en affärsmodell som prioriterar återkoppling och anpassningsförmåga framför förutsägbar planering. På så sätt är organisationerna bättre rustade för att hålla sig i linje med kundernas behov och förväntningar, så att de kan leverera värde och åtgärda problem mer effektivt.
Omfördelning av kapacitet?
Även om det i produktmodellen är meningen att team ska arbeta tillsammans och vara anpassade till ett affärsområde under långa perioder, betyder det inte att det ska vara för evigt. Det är fortfarande vettigt att koncentrera produktionskapaciteten på de områden där den är mest fördelaktig för företaget.
I projektfinansieringsmodellen sker denna omfördelning när projekten avslutas, gamla team upplöses och nya team bildas för nytt arbete.
I produktmodellen är tanken att omfördela kapaciteten i en takt som baseras på affärsresultat.
Organisationer som följer SAFe® och andra skalade agila modeller kommer så långt det är möjligt att sätta sina team och team av team i en gemensam takt. Scrum-sprintar som genomförs varannan vecka är synkroniserade. Planeringsevenemang för stora lokaler på medellång sikt, ungefär en gång i kvartalet, är också synkroniserade. Dessa kadenser gör det mycket lättare att hantera samordningen inom teamet av team och med kunderna. De utgör också perfekta brytpunkter för att flytta kapacitet mellan produkter eller värdeflöden med minimala störningar.
Men hur vet man om och var man ska flytta kapaciteten?
Resultat framför produktion
I en produktmodell bör varje produkt eller värdeflöde upprätta en länkad uppsättning tidiga indikatorer och trattmätningar som är meningsfulla för deras del av verksamheten. Dessa bör i slutändan leda till intäkter, besparingar eller något annat resultat. Men dessa P&L-mätningar är ofta för långsamma för att vara användbara för styrning, och det tar många kvartal innan de rör sig tillräckligt mycket för att berätta för oss hur det går. Tidiga indikatorer och trattmätningar är inte lika definitiva, men de förändras mycket snabbare och ger oss data för beslutsfattande.
Exempel på tidiga indikatorer är:
- Antalet personer som använder en ny eller ändrad aspekt av ett system.
- den tid som de spenderar på en viss skärm
- den belastning som användarna lägger på systemet enligt våra övervakningssystem
- Antalet supportärenden (upp eller ner) som rör olika aspekter av systemet som vi har ändrat.
- kommentarer på sociala medier
När vi gör ändringar i våra produkter, förutsatt att vi har investerat i tillräcklig instrumentering, kan vi mycket snabbt se om våra kunder har märkt och utnyttjat förbättringarna och om de ser dem som förbättringar överhuvudtaget. Goda tidiga indikatorer bevisar inte att vi kommer att få bättre ekonomiska resultat, men de visar att vi har skapat värde för kunderna. Och bristen på tidiga indikatorer borde vara en enorm röd flagga som visar att vi slösar bort pengar och bör ompröva våra antaganden.
Om vi gör saker och ting rätt kommer tidiga indikatorer att leda till resultat på medellång sikt som, även om de fortfarande inte är traditionella P&L-mått, är mycket mer matematiskt kopplade på ett halvt förutsägbart sätt. För ett typiskt SaaS-programvaruföretag kan en tratt se ut ungefär så här:
- Ett visst antal besökare på webbplatsen kommer att ladda ner innehåll av något slag.
- Av dessa kommer en viss procentandel att anmäla sig till en provning av produkten.
- Av de provkonton som skapas kommer en viss procentandel fortfarande att vara aktiva några dagar senare.
- Av dessa aktiva försök kommer ett visst antal att kontakta vårt säljteam för att inleda ett köpsamtal.
- Vi omvandlar en procentandel av dessa till betalande konton efter i genomsnitt X antal dagar.
- Vårt typiska nya konto börjar med Y antal användare och växer vanligtvis till Z antal användare på ett år.
- Med ett genomsnittligt pris för en plats innebär det att vi kommer att generera en viss intäkt under år 1 för ett konto.
Vi skulle kunna gå vidare, men du förstår vad jag menar. Var och en av dessa förhållanden kommer att vara ofullkomliga. Men de kommer att vara tillräckligt förutsägbara för att vi rimligen ska kunna gissa hur en förändring av resultaten uppåt i tratten kommer att påverka resultaten nedåt i tratten. Istället för att utvärdera varje potentiell arbetsuppgift oberoende av varandra när ett affärsfall kommer över våra skrivbord, kan vi inrikta våra ansträngningar på förändringar som kommer att påverka vår tratt. Och alla känner till tratten så att alla i våra team har bättre förutsättningar att fokusera sina ansträngningar på resultat som gynnar helheten.
Investeringar där vi ser verkliga resultat
Med tiden kan vi använda dessa trattmätningar för att styra beslutsfattandet inom våra team och den produkt eller det värdeflöde som de stöder. Vi kan också använda dem för att avgöra var vi ska flytta kapaciteten. Om en del av vår verksamhet har haft 10 team i ett år och genererat oförändrade resultat i sina trattmätningar och en annan del har haft halva den kapaciteten och producerat 50% förbättringar, skulle det då inte vara klokt att flytta några team? Vi vet kanske inte exakt vilka funktioner som gav dessa resultat. Det betyder inte nödvändigtvis att de som hanterar det första värdeflödet fattar dåliga beslut. Men vi kan tydligt se var vi har produktiva investeringsmöjligheter och var vi inte har det. Och vi kan ändra lag i enlighet med detta.
Det produktcentrerade tillvägagångssättet ger grupper och individer större ansvar för sitt arbete och sina ansvarsområden. Eftersom människor inte ständigt hoppar från team till team har de en större känsla av ansvarstagande. Medarbetarna är inte bara intresserade av att få arbetet gjort och gå vidare till nästa projekt, utan även av att leverera innovation och kontinuerlig förbättring, eftersom en produktmodell håller teamen ansvariga för utveckling, support och underhåll i stället för att fördela ansvaret på tre olika grupper.
I slutändan gör produktmodellen det möjligt för teamet att gå från spekulativ planering till ett anpassningsbart tillvägagångssätt. Grupper arbetar tillsammans för att skapa värde genom kontinuerlig förbättring utifrån kundens behov som utvecklas. Detta skapar i sin tur en företagskultur där man prioriterar värdetillförsel framför att slutföra projekt. Genom att fastställa meningsfulla resultatmått för våra värdeflöden har vi ett sätt att flytta kapaciteten dit den kan göra mest nytta. Och genom att dra nytta av synkroniserade kadenser har vi ett minimalt störande sätt att flytta människor och team när det behövs.
Om du vill veta mer om hur Planview stöder övergången från projekt till produkter kan du titta på demotypen eller ladda ner vårt whitepaper "Lean Portfolio Management for the Enterprise" för att se hur organisationer använder LPM för att övergå till en produktcentrerad modell.
