Blog

Väldefinierade krav och hur man hittar dem – Del 2

Publiceringsdatum:

Del II – Intressenter och stödprocesser för att samla in rätt krav

Intressenter och deras roller i processen för att skapa krav

Att engagera rätt personer i projektet eller processen är en ledtråd och en garanti för resultatets kvalitet. Kravinsamlingsprojektet bör också inledas med att definiera rollerna i processen. Och det är så här det går till i praktiken.

Först och främst måste du definiera de roller som krävs för projektet, sedan välja ut representanter för dessa roller och slutligen gå igenom processen med att definiera krav. Jag beskriver detta här bara för att bättre understryka vikten av att välja rätt intressenter för hela processen med att skapa och hantera krav.

Intressent – alla som kommer att påverka processen för att samla in krav, definiera kraven eller använda slutprodukten. Typiska intressenter är t.ex:

– produktägaren – beslutar om investering i produkten, rapporterar kraven på allmän nivå. Behövs i olika stadier av arbetet med krav. Nödvändigt i stadiet för att definiera Vision och acceptans av uppsättningen utvecklade krav för vidare arbete, för investeringar. Detta är beslutsfattarens funktion i produktutvecklingsprocessen. Denna intressent bestämmer vad som slutligen ska levereras.

– användare av produkten – de personer som så småningom kommer att använda produkten, både från den operativa sidan och från ledningens sida. Alla förslag från produktanvändarna i samband med att kraven tas fram är mycket viktiga för att kraven ska bli fullständiga. Användaren ger mycket detaljerad information om hur processen fungerar, vilket kan översättas till ett väldefinierat krav. Man bör dock komma ihåg att det sätt på vilket produktanvändare ser på produkter och processer i hög grad är begränsat till användarens eget perspektiv. Användarna bär med sig sina egna erfarenheter av befintliga system eller andra system som de arbetar med. Alla dessa begränsningar bör hållas i åtanke när man behandlar användarens förslag till krav.

– arbetsledare – den person som övervakar hela teamets arbete, kontrollerar att resursfördelningen är korrekt och, i större organisationer, ansvarar för projektet på politisk nivå. Arbetsledarens engagemang i att skapa kraven är mycket litet, särskilt när det gäller att ge viktig input. Arbetsledaren har dock befogenhet att stoppa eller omdirigera vissa arbeten och har inflytande över många deltagare i processen. Denna person bör vara väl informerad om hur arbetet fortskrider, för att undvika att deras beslut orsakar onödiga hinder eller förseningar i utvecklingsprocessen.

– Processledare för kravinsamling – denna roll kan innehas av projektledaren eller den analytiker som projektledaren utser. Det som är viktigt att betona här är att processledaren fungerar som en länk mellan driftsättningsteamet och intressenterna för att säkerställa korrekt kommunikation och samarbete. Hans eller hennes roll är inte bara ledande eller analytisk: den bör kombinera båda. Han eller hon bör i viss mån förstå innebörden av kraven och kunna analysera dem för att underlätta kommunikationen och förståelsen av kraven för driftsättningsteamet eller dess representanter.

Implementeringsteam – består av affärsanalytiker, systemanalytiker, säkerhetsarkitekter, utvecklare och domänexperter.

Det är inte alltid möjligt för alla relevanta representanter för implementeringsteamet att vara involverade i kravutvecklingsprocessen. Naturligtvis bör nivån på deras engagemang vara lämplig för metodiken för hela projektledningen och typen av krav. Om projektet hanteras på ett agilt sätt kommer implementeringsteamet att vara djupt involverat i det redan från början. En mer vattenfallsliknande metod begränsar kontakterna och kommunikationen mellan intressenterna och medlemmarna i driftsättningsteamet. I ett sådant fall bör projektledaren se till att implementeringsgruppens representant spelar en aktiv roll som länk mellan implementeringsteamet och intressenterna för att så långt det är möjligt skapa en gemensam förståelse för varje krav som har utvecklats. Det är mycket viktigt att det nära samarbetet kring utvecklingen av de enskilda kraven diskuteras och att man kommer överens om detta.

Varför är det så viktigt att involvera driftsättningsteamet i det här skedet, även om vi inte hanterar projektet enligt den agila filosofin och det ännu inte finns något beslut om att starta implementeringen? Det spelar ingen roll hur exakt kraven beskrivs, om ledningsgruppen får kännedom om kraven först efter att de har skapats kommer den att behöva ytterligare tid för att bearbeta och förstå dem. Det kommer därför att krävas en rad interaktioner, möten och workshops för att uppnå den förväntade nivån av gemensam förståelse för kraven. Ofta måste vissa av kraven verifieras och förbättras. Att spara resurser i ett tidigt skede är en falsk ekonomi. Om driftsättningsteamet arbetar med att utveckla och förfina kraven redan från början av kravutvecklingsprocessen blir fördelarna för hela projektet enorma.

Stödjande processer

Slutligen bör man komma ihåg några av de viktiga stödprocesserna utan vilka själva kravprocessen kanske inte kan genomföras på rätt sätt eller de uppnådda resultaten kanske inte blir så bra som man ursprungligen antog. Dessa stödprocesser består av kommunikation, förhandling och medling samt lobbying.

Kommunikation – ge alla deltagare i processen tillgång till information om arbetsstatus. Tillgång till aktuell dokumentation. Tillgång till planer, scheman och deadlines. Tillgång till mötesanteckningar. Utarbetande av relevanta frågeformulär och tillhörande manualer för utbyte av data mellan processens deltagare. I en tid av digitala moln och databaslösningar med flera åtkomster för att komma åt dokumenten via nätverket är kommunikationsmöjligheterna enorma, men vi tenderar ofta att glömma bort dem. Det viktiga är att välja en lösning som alla deltagare i kravställningsprocessen har tillgång till och har de tekniska förutsättningarna för att använda, samt att förse dessa deltagare med användarmanualer. De mest användbara verktygen för uppgiftsstyrning är Kanban- och Scrum-tabeller. Det kan även vara en enkel lista på en whiteboard med processteg ritade på, med stöd av en delad disk för elektronisk dokumentregistrering. Dessa verktyg är idealiska för att stödja interaktiva och iterativa tillvägagångssätt, vilket förutsätts i IIRM-modellen (Interactive and Iterative Requirements Management Model). De är intuitiva att använda, underlättar kommunikationen mellan teammedlemmarna och visar tydligt status för hur arbetet fortskrider i processen. Alla kan snabbt förstå vilka krav som rapporteras, identifiera de krav som för närvarande utvecklas och skjuta upp dem som har klarat verifieringskriterierna, och slutligen hämta dem som fortfarande bör förbättras, kompletteras eller omdefinieras.

Förhandling och medling – kärnan i processen att skapa krav är ständiga förhandlingar – från början till slut. Det är ett ständigt sökande efter en lösning som är tillfredsställande för alla deltagare i processen och som samtidigt är förenlig med det som anges i visionen. Processledaren för kravinsamlingen är skyldig att förhandla med varje deltagare om omfattningen av det innehåll som ska levereras, deadlines och kvalitetsnivå, kostnader och engagerade resurser. Enbart förhandlingar är dock inte alltid tillräckligt. Chefen måste kunna fungera som en medlare mellan intressenterna eller mellan intressenterna och ledningsgruppen. Ofta uppstår tvister eller till och med akuta konflikter i gränslandet mellan de två världarna. Medlingsfärdigheter kommer säkert att vara till hjälp i sådana situationer.

Lobbying, kommunikation och förhandling är visserligen viktiga och avgörande, men de fungerar inte alltid i den takt som krävs för att en uppgift ska kunna utföras smidigt inom en given tidsram. Det finns situationer inom projekt där chefen måste vara beredd att använda andra övertalningsmedel för att få igenom en rad krav i tid. Det som är avgörande för att lobbying ska vara effektivt är att intressenterna analyseras och att man förstår deras intressen, samt att man använder lämpliga kommunikations- och övertalningstekniker. Vi nämner bara denna aspekt av aktiviteterna här. Ju större organisation som är involverad i processen, desto mer lobbying krävs och desto viktigare blir lobbyingprocessen. Lobbying är ett känsligt verktyg och det bör användas som en del av hela projektets kommunikationsstrategi.

Sammanfattning

Sammanfattningsvis kan man säga att vägen till väldefinierade krav kan följas i 5 enkla (till synes) steg.

  1. Identifiera rätt intressenter; identifiera dem som specifika personer i organisationen.
  2. Tilldela roller till specifika personer i processen, förhandla och kom överens om deras rättigheter och skyldigheter.
  3. Etablera och kommunicera processerna för att rapportera, granska, förkasta och acceptera krav. Processerna kan baseras på den adaptiva APM-modellen, dvs. IIRM-modellen för att samla in, definiera och utveckla krav i enlighet med agil filosofi, oavsett projektledningsmetodik.
  4. Kom överens om samarbetsreglerna med driftsättningsteamet i kravutvecklingsfasen och förbered teamet eller dess representant för att arbeta med kraven.
  5. Upprätta kriterier för att välja ut väldefinierade krav. INVEST-metoden för kriterierna kan vara till hjälp.

Det viktigaste är dock att inse att oavsett vilken metod som används för hela mjukvaruutvecklingsprojektet (oavsett om det är agilt eller vattenfall) är processen för att skapa krav inte linjär. Det är viktigt att säkerställa cyklisk iteration, direkt kommunikation i ett tvärvetenskapligt team och nära samarbete. Hela mjukvaruutvecklingsprojektet kan dra enorm nytta av ett sådant tillvägagångssätt.