Gästinlägg: Troy Magennis från Focused Objective
Vi på Planview AgilePlace har länge arbetat med IT och förstår därför hur jobbigt det är att bli tillfrågad om detaljerade uppskattningar om saker som vi aldrig har gjort och kanske aldrig kommer att göra. Mycket tid går åt till att bygga upp detaljerade planer som till slut inte har något med verkligheten att göra. Tanken på att få människor att sitta på tråkiga statusmöten för att ge uppskattningar av hur många procent av projektplanen som är färdigställda för mestadels irrelevanta poster gör oss illamående. Därför stöder vi helhjärtat drivkraften i Lean-Agile-världen att gå bort från detaljerade planer och uppskattningar på taktisk nivå. Vi anser att de kapacitetsmått du kan få från ett väl utformat Kanban-system är mycket mer användbara för kortsiktiga prognoser. Tips, tips.
Men ...
Chefer som fattar investeringsbeslut behöver en viss uppfattning om vart ett stort projekt kan leda innan de på ett ansvarsfullt sätt kan ge grönt ljus för att börja köpa utrustning och licenser, anställa personal, i vissa fall hyra byggnader osv. En av våra äldre IT-chefer beskrev att hans affärskamrater ställde frågan "Vilken klippa driver du oss mot?". På den här nivån är det viktigt att göra uppskattningar.
Vår vän Troy Magennis är av samma åsikt. Troy har länge samarbetat med David Anderson, Dan Vacanti och andra viktiga personer inom Kanban-rörelsen. Man kan säga att de var närvarande vid skapandet. Han var teknisk ledare för Travelocity - ett mycket stort och beundransvärt Agile corporate software development företag. Han har nu skrivit en mycket intressant bok om behovet av effektiva prognoser för att stödja Agile at Scale. Och han håller på att bygga några fantastiska verktyg för att beräkna ledningens kostnader som vi ser fram emot med spänning.
Hans uppsats är ett måste för agilister som menar allvar med att utveckla rörelsen.
----
Agilisterna måste acceptera att inkomst- och budgetprognoser måste tas på allvar.
Det är lätt att ansluta sig till kören av åsikter om att uppskattning av mjukvaruprojekt är slöseri och måste elimineras. Jag kan förstå invändningarna mot att spendera värdefull tid på att förbereda och rationalisera en uppsättning uppskattningar för dåligt definierade funktioner eller projekt, men i det här inlägget förklaras motsatserna - varför uppskattningar är nödvändiga och varför det ligger i ditt eget intresse att delta.
Jag försvarar inte det uppenbara slöseriet med att bli ombedd att uppskatta ett arbete som kommer att fortsätta oavsett hur lång tid och kostnad det tar att slutföra det; det finns knappast någon rationell anledning att slösa tid på att göra dessa uppskattningar. Jag menar att de flesta företag kommer att behöva någon form av uppskattningar från IT för att kunna växa och vara konkurrenskraftiga. I det här inlägget behandlas två grundläggande orsaker till att företag kräver uppskattning -
- Välj rätt projektportfölj och fastställer nästa års intäktsmål.
- Planering och anställning av personal för framtiden och fastställande av nästa års kostnadsmål.
Portföljval och intäktsmål
Ett företag konfronteras ofta med flera olika projekt- och funktionsidéer. Människor på produkt- och marknadsföringssidan föreslår många idéer och försöker få sina idéer högre upp i portföljen genom att höja intäktsberäkningen för varje funktion (och ja, produkt- och marknadsföringsfolket hatar också att ge en skriftlig intäktsberäkning, men de måste också göra det). En kommitté eller en enskild person filtrerar sedan igenom denna enorma lista och bestämmer vilka produkter och funktioner som ger bäst avkastning på investeringen, vilket leder till ett mål för nästa års förväntade intäkter. Ungefär under den här perioden sker det många avbrott i utvecklingsområdet av personer som vill ha en uppskattning av hur lång tid det skulle ta att bygga x (där x är en beskrivning på en rad av en komplex funktion).
Om du någonsin har deltagit i "budgetolympiaden" som genomförs varje år i medelstora och stora företag vet du att det är en brutal, konkurrensutsatt, politisk och frustrerande process. Det är svårt att försvara den eventuella riktigheten i detta äventyr, men i stället för att sura föreslår jag att IT-hanteringen nu måste ta ett steg framåt och vara tillgänglig och villig att hjälpa till. IT-avdelningen måste ställa korrekta förväntningar och erbjuda verksamheten alternativ för vilka projekt som kan genomföras, och vilken personal som kommer att behövas för att uppfylla dessa drömmar och ambitioner när det gäller företagets intäktsmål. Om man inte tar del av denna process leder det bara till att IT-enheten får skriva under på dåligt övervägda projektleveransdatum och till att man inte kan visa balansen mellan ytterligare personal och personalstyrka för drifts- och underhållsuppgifter som vanligt. Alltför ofta antas det felaktigt att all IT-personal är tillgänglig för nya projekt, och kommentarerna lyder: "Ni har 400 personer och ni säger att ni inte kan göra x!".
De portfölj- och budgetresultat som krävs för att verksamheten ska kunna ge löften med viss säkerhet är -
- Ett intäktsmål för företaget nästa år.
- En uppfattning om när varje portföljprojekt kommer att börja generera intäkter.
- Antalet anställda för att beräkna personalkostnaden.
Du kanske tycker att IT-skattningar är nödvändiga bara för 2 och 3 ovan, men i själva verket är det den första produktionen (intäktsmålet) som är den viktigaste drivkraften. En produkt som levereras i mars kommer att ge intäkter från april till december, dvs. hela nio månader. En produkt som levereras i november ger en månads intäkt. Detta innebär att för att företaget ska kunna offentliggöra (eller visa interna och externa investerare) en plan för tillväxt under nästa period är det avgörande att förstå när en funktion börjar generera intäkter. Ange det beräknade leveransdatumet för programvaruprojektet.
För närvarande gör våra "agila" och "lean" metoder det svårt att ge klarhet och säkerhet kring de nödvändiga svaren. Detta är ofta en orsak till friktion mellan dem som försöker förbereda en portfölj/budget och dem inom IT som försöker leverera kvalitetsprodukter (värde) med jämna mellanrum, men med tvetydiga kalenderdatum för varje enskild funktion (alla former av Agil utveckling). För att verksamheten ska kunna förstå hur varje funktion/produkt påverkar intäkterna måste det finnas en viss precision i fråga om datum för lansering. Att möta detta behov med vad som verkar vara en ursäkt som "vi är agila" gör att ledningen blir frustrerad och besviken på IT. Vi måste samarbeta med verksamheten för att välja rätt projekt, ge dem en indikation på när en funktion kommer att vara intäktsförberedd och tydligt uttrycka riskerna och sannolikheten för att nå dessa datum. Detta innebär att du måste arbeta entusiastiskt tillsammans med dem när det gäller val av omfattning och ge dem en uppskattning av leveransdatum så tidigt som möjligt. Vi måste också samarbeta med dem om personalplaner och kostnader som vi täcker nu.
Lämpliga och nödvändiga beslut om bemanning
Finansieringen av ett projekt eller en produktfunktion är ofta det första steget eller en uppgift som utförs varje år i de flesta organisationer. För att bygga mjukvara krävs människor, och dessa människor kostar pengar. Att förstå hur många personer och vilka färdigheter dessa personer behöver är en viktig uppgift för IT-förvaltningen, och det finns ingen enda korrekt formel. Om du lägger till fler personer kan du minska tiden till marknaden (eller kanske inte om du lägger till vid fel tidpunkt eller om personerna har fel kompetens), men hur mycket kortare? Och även om vi levererade tidigare, skulle mer intäkter redovisas under året eller rapporteringsperioden? Alla dessa frågor kräver en förståelse för hur mycket arbete som krävs för ett projekt och hur många personer som krävs för varje leveransscenario OCH för att bibehålla de nuvarande produkterna som levererar värde.
Om du inte återanvänder ett befintligt team, OCH de personer som satsar pengar på projektet är glada att acceptera risken att inte veta datumet för startdatumet, OCH är övertygade om att det kommer att levereras vid första möjliga tillfälle - kan du inte hoppa över uppskattningen. Om du gör det kommer du troligen att behöva göra nödutökningar av personal under hela projektet för att kunna hålla ett godtyckligt måldatum som fastställts av någon som inte har någon erfarenhet av mjukvaruutveckling. Det kanske inte alltid är uppenbart, men att delta tidigt, se till att du har fått ditt inflytande och din välsignelse över alla måldatum och att du bemannar ett projektteam som ska klara av att nå det datumet är överlägset minst stress och arbetsbelastning.
Företagsledningen förlorar förtroendet för IT varje gång någon måste göra en akut personalrekrytering eller en nedskärning av omfattningen för att få ett projekt tillbaka på rätt spår. Den enda lösningen är att se till att avvägningarna och förväntningarna fastställs tidigt, och att de som arbetar på affärssidan deltar i avvägningen mellan kostnader (människor) och intäktsmål tidigt, helst under portfölj- och budgetprocessen innan projektet startar. Du vill att produkt- och marknadsföringsgrupperna ska stå på din sida när du ber om mer personal; det är mycket kraftfullt när verksamheten, inte bara IT-ledningen, ber om mer personal för att konsolidera ett intäktsmål (genom att leverera i tid eller tidigare), och detta är det enda försvaret mot åsiktsspiralen "IT ber om mer och mer personal".
Att ha förmågan att bygga upp och formulera personalresursalternativen för en IT portfölj med nya arbetsuppgifter och den personal som krävs för att fortsätta verksamheten som vanligt är nyckeln till att återuppbygga affärsledarnas förtroende för IT-ledningen. Att föreslå alternativ för att öka personalen strategiskt för att hjälpa företaget att nå eller överträffa sina intäktsplaner ger IT-ledningen den hjältestatus vi förtjänar, i motsats till de nördcowboys från andra våningen som ofta stämplas som vi nu får.
Sammanfattning
I ett framtida inlägg kommer jag att sammanfatta strategierna för hur man bygger och kommunicerar uppskattningar av programvara, för både datum- och personalprognoser, och hur man minimerar tiden och störningarna för IT samtidigt som man hjälper verksamheten genom hela budgetprocessen. Det här materialet är hämtat från min bok Forecasting and Simulating Software Development Projects - Effective Modeling of Kanban and Scrum Projects using Monte-carlo Simulation . Jag har haft möjlighet att se båda sidor av argumentet om uppskattning och har byggt verktyg och skrivit om hur man snabbt och tillförlitligt kan modellera programvaruprojekt (du hittar mer på FocusedObjective.com).
Jag skulle gärna vilja leva i en värld som inte alls kräver uppskattningar av programvaruprojekt, men jag tror inte att det finns i alla utom de minsta projekten och företagen. Det bästa sättet att förändra ledningens uppfattning om IT-cheferna och återge IT den hjälte-status den förtjänar är att vara kunnig i varför uppskattningar är nödvändiga och hur man samarbetar med sina affärskamrater för att erbjuda lösningar och åsikter i ett tidigt skede av portfölj- och budgeteringsfasen.
Om författaren
Troy is an experienced executive who has been involved in many leading software organizations over 20 years. Most recently, Troy founded Focused Objective to build tools and training for simulating and forecasting software development projects, including the Monte-carlo techniques as described in his book Forecasting and Simulating Software Development Projects – Effective modeling of Kanban and Scrum projects using Monte-carlo simulation. You can follow Troy on Twitter at @AgileSimulation or contact him by e-mail at [email protected].
