Afhængighedsstyring: En komplet guide til projekter og produkter

Informatec Digital » Ressourcer » Afhængighedsstyring: En komplet guide til projekter og produkter

Afhængighedsstyring er et af de problemer, som alle kæmper med dagligt, men som få organisationer adresserer systematisk. Når det ikke er under kontrol, opstår der forsinkelser, tilsyneladende uforklarlige forhindringer, der afholdes krisemøder for at "slukke brande", og i sidste ende bliver projekter enten forsinkede eller aldrig ankommet.

Omvendt, når afhængigheder identificeres, visualiseres og styres effektivt, arbejder teams mere autonomt , deadlines ophører med at være et sats, og samarbejdet mellem afdelinger bliver meget mere gnidningsløst. I denne artikel vil vi undersøge detaljeret, hvad afhængigheder er i projekter og digitale produkter, de forskellige typer der findes, og hvordan man håndterer dem i praksis ved hjælp af agile tilgange, frameworks som Kanban og værktøjer som Jira eller projektstyringssoftware.

Hvad mener vi med afhængighed i projekt- og produktstyring?

I forbindelse med projekter og produktudvikling er en afhængighed et nødvendig forhold mellem to elementer i arbejdet: en opgave, et team, en teknisk komponent eller endda en ekstern leverandør. For at noget kan begynde, udvikle sig eller slutte, skal der ske noget andet først.

Fra et meget praktisk synspunkt kan en afhængighed enten være et funktionelt krav (for eksempel at have en indkøbskurv på et websted) eller et rent teknisk krav (at have en færdig API, adgang til et miljø eller implementering af en udgivelse). Selv når den "aktør", der forbruger resultatet, ikke er en person, men en anden tjeneste, omtaler vi det stadig som en afhængighed.

I projektledelse beskrives en opgave ofte som afhængig, når dens udførelse er betinget af færdiggørelsen, starten eller fremskridtet af en anden opgave. Hvis "Opgave B" har brug for, at "Opgave A" når et specifikt punkt for at kunne fortsætte, så har du en afhængighed.

Afhængigheder er ikke bare en gene: de udgør reelle risici . De øger sandsynligheden for forsinkelser, omkostningsoverskridelser og endda annullering af et initiativ, før det overhovedet når produktion. Som standard er enhver afhængighed en risiko med en vis sandsynlighed og effekt, der bør håndteres, ikke ignoreres.

Typer af afhængigheder: en komplet oversigt

For at håndtere afhængigheder effektivt skal de først klassificeres og navngives . Projektledelseslitteratur og produktpraksis skelner typisk mellem flere akser: i henhold til deres natur (logisk, ressourcebaseret, ekstern, præferentiel), i henhold til forholdet mellem opgaver og i henhold til det organisatoriske omfang.

Afdelinger efter deres art

Logiske eller kausale afhængigheder er dem, der følger en uundgåelig rækkefølge af trin . Du kan ikke male en væg, hvis du ikke har bygget den først; du kan ikke teste en funktion, hvis den ikke er blevet udviklet først. De er de mest intuitive.

Ressourceafhængigheder opstår, når flere opgaver eller projekter konkurrerer om den samme begrænsede ressource : en nøgleperson, en enkelt designer, et enkelt backend-team, en testmaskine osv. Arbejdsfremskridt bestemmes ikke så meget af den logiske rækkefølge, men af ​​den faktiske tilgængelighed af disse ressourcer.

Foretrukne afhængigheder er dem, der stammer fra interne procedurer eller bedste praksis , men som ikke er strengt nødvendige for at fuldføre leverancen. For eksempel en ekstra redaktionel gennemgang eller et yderligere QA-trin, som teamet beslutter at beholde, fordi det reducerer fejl, selvom projektet formelt kunne være "lukket" uden det.

Eksterne afhængigheder opstår, når teamet er bundet til faktorer, det ikke kontrollerer : en leverandør, der skal levere materiale, en juridisk afdeling, der skal godkende en kontrakt, vejrforhold, der påvirker et projekt, eller en tredjeparts betalingsgateway, der skal certificere sin service.

Opgaveafhængigheder: klassiske tidsmæssige relationer

Når man går ned på planlægningsniveauet, modelleres opgaveafhængigheder normalt med fire grundlæggende relationer, som du vil se i tidsplaner eller Gantt-diagrammer:

I en færdig-til-start (FS) relation kan den efterfølgende opgave ikke begynde , før den foregående opgave er færdig. Dette er den mest almindelige relation og den, der bruges som standard af de fleste værktøjer.

I en finish-to-finish (FF)-relation kan den næste opgave ikke fuldføre sit arbejde, før den forrige opgave også er færdig . Dette sker ofte, når en opgave faktisk er summen af ​​flere indbyrdes afhængige underopgaver.

I tilfælde af Start-to-Start (SS) skal begge opgaver aktiveres parallelt . Den efterfølgende opgave kan ikke starte før den foregående, selvom de derefter fortsætter i deres eget tempo.

Forholdet mellem start og slut (SF), som er mindre hyppigt, men stadig eksisterer, indebærer, at opgave A ikke kan betragtes som afsluttet, før opgave B er påbegyndt. Et typisk eksempel er et vagtskifte i kundeservice: én person kan ikke forlade stedet, før den næste ankommer.

Interne, eksterne og afhængigheder mellem teams

Ud over deres natur er det vigtigt at skelne mellem interne afhængigheder i projektet (mellem opgaver eller ressourcer, som teamet selv kontrollerer) og eksterne afhængigheder, som afhænger af tredjeparter.

I mellemstore og store organisationer bliver afhængigheder mellem teams stadig vigtigere: når flere teams, afdelinger eller leverandører skal koordinere for at levere et fælles resultat. Dette inkluderer afhængigheder mellem produktteams, mellem teams og tværfunktionelle teams (HR, indkøb, juridisk) og mellem tekniske teams såsom backend, frontend, mobil og drift.

Proaktiv vs. reaktiv afhængighedsstyring

Den måde, en organisation håndterer afhængigheder på, er afgørende for, om der er en "brandslukning"-kultur eller et langt sundere miljø. Vi kan tale om to grundlæggende strategier : proaktiv og reaktiv.

Reaktiv styring involverer kun at reagere på en afhængighed, når den eksploderer : når en tilladelse, adgang, komponent eller API mangler, og teamet sidder fast. Dette er den typiske situation med kontinuerlig nedetid, omplanlægning undervejs og brudte forpligtelser.

Proaktiv ledelse indebærer derimod, at man fra starten dedikerer en indsats til at identificere og planlægge afhængigheder . Behov forudses, kapacitet reserveres, forpligtelser mellem teams afklares, og risici identificeres, før de bliver til problemer.

Selvom der altid vil være en reaktiv komponent (man kan ikke forudse alt), skal en sund strategi for afhængighedsstyring have en stærk proaktiv komponent : analyse, prioritering, forberedelse af alternative scenarier og etablering af tilbagevendende begivenheder for at gennemgå status for disse afhængigheder.

Visualisering af afhængigheder: fra Kanban til matricer i Jira

Det første seriøse skridt i håndteringen af ​​afhængigheder er at gøre dem synlige for alle . Det, der ikke ses, håndteres ikke; det lider under det. Det er her, Kanban-praksisser, programtavler og forskellige visualiseringer kommer i spil.

I et Kanban-system er en af ​​de grundlæggende fremgangsmåder at visualisere arbejdet . Dette inkluderer at gøre det meget tydeligt, hvilke opgaver der er afhængige af andre, såvel som dem der blokerer andre teams. Tydelig markering af, hvilke elementer der "venter på afhængigheder", hjælper med at forhindre overraskelser.

I værktøjer som Jira er en meget praktisk tilgang at udnytte feltet "issue link" til at forbinde opgaver, der blokerer hinanden . Du kan bruge "blokke" eller "afhængig af"-relationer, hvor du skelner mellem stærke afhængigheder (som forhindrer den afhængige opgave i at starte) og svagere (som tillader parallel fremgang, mens den anden opgave løses).

Hvis den opgave, der skal løse afhængigheden, endnu ikke findes, kan du vælge at tagge problemet med en specifik markør, der angiver dette udestående behov. Dette tag giver dig derefter mulighed for at gruppere og vise disse uløste afhængigheder i paneler, køreplaner, efterslæb eller tavler.

Med disse oplysninger er det muligt at opbygge en afhængighedsmatrix, hvor den ene dimension repræsenterer organisationens teams eller grupper , og den anden repræsenterer tidslinjen. Dette viser, hvem der er afhængig af hvem og hvornår, hvilket letter kapacitetsallokering og prioriteringsforhandlinger.

Før den udbredte anvendelse af fjernarbejde blev disse matricer ofte tegnet på fysiske tavler. I dag giver Jira-plugins og moduler som Advanced Roadmaps, BigPicture og Structure mulighed for visuel repræsentation af disse afhængighedsnetværk i hybride eller fuldt fjerntliggende miljøer.

Reservationsklasser og reservationstavle i Kanban

Når du har et globalt overblik over afhængigheder på produkt- eller organisationsniveau, kan du gå et skridt videre og anvende konceptet med reservationsklasser fra Kanban-metoden til at tildele forskellige serviceniveauer til afhængighedsløsning.

En reservationsklasse bruges til at klassificere arbejde efter prioritet, hastende karakter eller påkrævet leveringstid. For at bruge denne tilgang med afhængigheder bruges en kalender til at allokere kapacitetspladser dedikeret til at løse dem, enten efter dage, uger eller iterationer (for eksempel Sprints i Scrum-teams).

Der er typisk tre hovedtyper af reserver. For det første er der garanterede ressourcer, som har kapacitet, der er specifikt reserveret til at sikre, at de er tilgængelige på en bestemt dato, hvis behovet opstår. Disse svarer normalt til uforudsete, men kritiske opgaver.

For det andet er der reserverede afhængigheder: disse er opgaver, der allerede har en fastsat tidsramme for færdiggørelse. De bruges ofte til stærke afhængigheder, hvis løsning gør det muligt for et andet team at begynde arbejdet.

Endelig falder standby-afhængigheder ind under en kategori, hvor de kun vil blive adresseret, hvis der er tilstrækkelig kapacitet . Disse er normalt afhængigheder, der midlertidigt kan undgås eller udskydes, mens der gøres fremskridt med andre dele af arbejdet.

Denne model minder meget om, hvordan flyselskaber administrerer deres billetter: der er meget dyre garanterede sæder, standardreservationer og billetter på venteliste, der afhænger af, at der ikke er overbooking. Et sæde på venteliste kan endda ændre status over tid og gå fra "venteliste" til "reserveret" eller "garanteret", når en måldato nærmer sig, og risikoen stiger.

Begivenheder til gennemgang af afhængigheder og koordinering af teams

Det er ikke nok at have en reservationstavle eller en afhængighedsmatrix, hvis den ikke er integreret i regelmæssige gennemgangsritualer . Det er afgørende at have mindst én begivenhed inden for den nuværende arbejdsgang, hvor disse afhængigheder gennemgås, og der foretages justeringer.

Det behøver ikke at være et nyt møde; det kan integreres som et fast punkt i dagsordenen for eksisterende møder: for eksempel i et iterationsplanlægningsmøde, i en SAFe-lignende PI-planlægning eller i en tværfaglig koordineringssession.

Det, der virkelig er vigtigt, er, at alle parter, der er involveret i at skabe og løse afhængigheder, er til stede under denne gennemgang . Uden denne ansigt-til-ansigt (eller skærm-til-skærm) samtale er det nemt, at der opstår falske forventninger, ensidige forpligtelser og løfter, der ikke kan holdes.

Gode ​​og dårlige afhængigheder: synkrone og asynkrone

Det lyder måske kontraintuitivt, men ikke alle afhængigheder er dårlige. Nogle afhængigheder fremmer et sundt samarbejde , mens andre skaber siloer og konstant friktion. En nyttig måde at skelne mellem dem er at tale om synkrone og asynkrone afhængigheder.

Asynkrone afhængigheder er dem, hvor teams ikke arbejder på samme tid eller i samme kadens. Et Scrum-team, der har til hensigt at integrere en udvikling i sit nuværende Sprint, som et andet team vil udføre i det næste Sprint, eller en presserende anmodning om adgang til en ressource, der afhænger af et tredje, overbelastet team, er eksempler på problematiske asynkrone afhængigheder.

Synkrone afhængigheder opstår derimod, når arbejdet foregår inden for samme tidsramme . For eksempel flere teams, der deler et udviklings- og testmiljø, eller et fælles softwarebibliotek, der er åbent for bidrag fra enhver udvikler i virksomheden.

Disse typer af afhængigheder opfordrer folk til aktivt at samarbejde og dele kontekst . Uden dem ville det være lettere for hvert team at isolere sig i sin silo. Og siloer, udover at begrænse det overordnede perspektiv, har en tendens til at undergrave empatien mellem afdelinger og komplicere beslutningstagning på organisationsniveau.

Den langsigtede strategi bør sigte mod at minimere asynkrone afhængigheder og forbedre synkrone afhængigheder, hvilket favoriserer teams med større end-to-end-autonomi og mere åbne samarbejdspraksisser.

Design af organisationer og grupper for at reducere afhængigheder

Organisationsstrukturen påvirker direkte antallet og typen af ​​afhængigheder. Efterhånden som et produkt vokser, og teams multipliceres, opstår der mere friktion, overlap og flaskehalse . Typisk begynder problemer at dukke op med så få som to hold og intensiveres med hvert nyt team, der oprettes.

I vertikalt integrerede, produktorienterede organisationer er målet typisk at skabe tværfaglige teams, der er så autonome som muligt , hvilket er meget i tråd med topologien "stream-aligned teams", der er beskrevet i Team Topologies. Disse teams er ansvarlige for et forretningsdomæne eller underdomæne fra start til slut.

Selv med autonome teams er der stadig behov for tilpasningsmekanismer for at sikre produktkonsistens og forhindre, at teamsamarbejdet bryder sammen: globale voldgiftsinstanser i forbindelse med roadmaps, fælles planlægningsbegivenheder inspireret af PI-planlægning, programtavler, der visualiserer afhængigheder, delte designsystemer og praksisfællesskaber, blandt andre mekanismer.

I praksis ender mange virksomheder med hybridmodeller, hvor ikke alle færdigheder kan findes i alle teams . Der opstår tværfunktionelle teams, der dækker produktdesign, data, QA, mobil, backend eller drift, og som betjener flere produktteams, hvilket introducerer yderligere afhængigheder, der skal håndteres effektivt.

Afdelinger med tværfaglige teams: HR, Indkøb, Jura…

Ud over tekniske områder er mange teams afhængige af tværfunktionelle virksomhedsteams såsom HR, indkøb eller juridiske afdelinger. Disse afhængigheder manifesterer sig ofte som nøgleansættelser, kapacitetsopbygning gennem eksterne leverandører, budgetstyring eller juridiske gennemgange.

Når en trup har brug for at skrive kontrakt med eller styrke sin trup og ikke kontrollerer dette flow , påvirkes deres time-to-market, og forudsigeligheden lider. Adskillige håndtag kan aktiveres for at afbøde disse situationer.

En mulighed er at delegere visse aktiviteter, der traditionelt administreres af HR eller indkøb, til teams (for eksempel en del af udvælgelsesprocessen eller det operationelle forhold til leverandører), med klar styring, men mindre bureaukrati.

En anden måde er at forhandle servicebudgetter, så hvert team har en autonom beslutningsmargen for, hvilke profiler eller tjenester de skal ansætte, og hvornår, inden for de aftalte rammer.

Det er også muligt at bruge lejlighedsvis integration af HR-, indkøbs- eller juridiske eksperter i teamene for at fremskynde kritiske beslutninger , især i tider med stærk vækst eller relevante strategiske ændringer.

Typiske tekniske afhængigheder: backend, drift og mobil

På et mere teknisk niveau er der tre særligt almindelige kilder til afhængigheder: separate backend-teams , isolerede driftsteams (Ops-teams) og uafhængige mobile teams.

Når et centraliseret backend-team betjener flere frontend-teams, skaber det et vanskeligt at administrere kunde-leverandør -forhold . Backend-teamet skal bygge API'er til alle, balancere eksterne prioriteter, det ikke kontrollerer, og modstå presset. Samtidig oplever produktteams forsinkelser og frustration over ikke at vide, hvornår de funktioner, de har brug for, vil være klar.

Som palliative foranstaltninger kan backend-udviklere midlertidigt integreres i teams , der kan defineres klare grænsefladekontrakter mellem backend og frontend, eller der kan udvikles mikroservicearkitekturer, hvor hvert team er ansvarlig for sine egne tjenester, idet der accepteres, at nye afhængigheder vil opstå, men langt mere håndterbare.

I tilfælde af operationsteams er afhængigheden normalt koncentreret om miljø og implementeringsstyring . Grupper færdiggør deres udvikling, men de har brug for operationer til at implementere dem i hvert miljø. Hvis operationer er overbelastede, hober udgivelser sig op, prioriteres uigennemsigtigt, og risikoen for forsinket eller forhastet levering øges.

For at forbedre dette område kan der implementeres en Kanban-lignende visuel styring af leveringsflowet, brugerhistorier specifikke for operationskrav kan integreres i enhedernes ordrebeholdning, og "software-as-a-service-fabrikker", der automatiserer en stor del af pipelinen, kan tilbydes.

Alligevel kommer det virkelig betydningsfulde spring, når en moden DevOps-kultur implementeres , hvor udvikling og drift samarbejder tæt, test og implementeringer automatiseres, og teams har mulighed for sikkert at bringe deres ændringer i produktion.

Noget lignende sker med uafhængige mobile teams: Deres meget specifikke færdigheder (iOS, Android, mobildesign, platformretningslinjer) får mange organisationer til at gruppere dem i et enkelt team, som ender med at betjene flere squads. Dette skaber køer, kompleks prioritering og flaskehalse, når alle teams anmoder om ændringer i mobilapplikationen samtidigt.

En mulig strategi er at opretholde disse mobile hold med en explorer- holdlogik , der ledsager holdene, markeringsmønstre, genanvendelige komponenter og god praksis, og opløse den enhed, når det mobile funktionelle omfang svarer til webversionen.

Administration af softwareafhængigheder: biblioteker, frameworks og sikkerhed

Ud over organisation refererer ordet afhængighed i softwareudvikling normalt til eksterne biblioteker, frameworks og komponenter , som din applikation har brug for for at fungere. Her taler vi om afhængighedsadministratorer som Maven, Gradle, npm eller Composer.

Dårlig håndtering af disse afhængigheder kan føre til versionskonflikter , integrationsproblemer, langvarige vedligeholdelsesvanskeligheder eller sikkerhedssårbarheder. Derfor er det så vigtigt at bruge værktøjer, der automatiserer download, versionshåndtering og kontrollerede opdateringer.

Det er tilrådeligt at holde afhængigheder rimeligt opdaterede og finde en balance mellem sikkerhed og stabilitet. Obsessive opdateringer kan introducere uventede fejl, men sjældne opdateringer gør projektet sårbart over for kendte sårbarheder eller ondsindede versioner på npm.

Det er også god praksis at minimere antallet af afhængigheder: Før du tilføjer et nyt bibliotek, er det værd at spørge dig selv, om det virkelig tilføjer værdi , eller om det er noget, der kunne håndteres mere enkelt. Hver tilføjet afhængighed betyder mere vedligeholdelsesoverflade, potentielle konflikter og i mange tilfælde en påvirkning af ydeevnen.

Alt dette bør ledsages af tydelig dokumentation for, hvilke afhængigheder der bruges, med hvilke versioner og til hvilket formål, samt grundig automatiseret testning for at verificere, at en opdatering ikke ødelægger eksisterende funktionalitet. Sikkerhedsanalyseværktøjer hjælper også med at opdage kendte sårbarheder i de tilføjede afhængigheder.

Praktiske tips til håndtering af afhængigheder i projekter

I den daglige projektledelse findes der en række fremgangsmåder, der i høj grad letter kontrol over afhængigheder . Adskillige værktøjer (Asana, Wrike, Jira osv.) anbefaler en række fremgangsmåder.

For det første er det afgørende at organisere opgaver i et robust projektstyringsværktøj , der giver dig mulighed for at modellere opgaveafhængigheder, visualisere tidslinjer og hurtigt se, hvad der er blokeret, og hvorfor. Dette reducerer risikoen for at overse vigtige forbindelser.

Det er også meget nyttigt at visualisere afhængigheder tydeligt ved hjælp af Gantt-diagrammer, køreplaner eller Kanban-tavler . At se udførelsesrækkefølgen og blokeringspunkterne hjælper teamet med bedre at forstå, hvorfor bestemte opgaver kommer før eller efter dem, og hvordan de påvirker deres kolleger.

Et andet kritisk aspekt er at overvåge potentielle risici relateret til afhængigheder. I projektplanens indledende faser er det tilrådeligt at brainstorme specifikke afhængighedsrisici : overbelastning af nøglepersonale, eksterne leverandører, udestående tilladelser eller udestående forretningsbeslutninger.

Endelig er åben kommunikation mellem interessenter afgørende. Kommunikation er aldrig overflødig, når man har at gøre med afhængigheder: Hvis nogen ved, at de vil blive forsinket med en opgave, som andre er afhængige af, er det bedst at underrette dem så hurtigt som muligt, så alle andre kan justere deres planer og undgå at blive hårdt ramt.

Afhængigheders indflydelse på projektets succes

At mestre afhængighedsstyring har en direkte indflydelse på et projekts succes. På den ene side giver det mulighed for mere omfattende kontrol og bedre informeret strategisk planlægning , da projektlederen kan se, hvordan alle brikkerne passer sammen, og definere en realistisk arbejdsordre.

På den anden side forbedrer det tidsstyringen og forebyggelsen af ​​forsinkelser betydeligt . Ved at forstå kritiske opgavesekvenser og afhængigheder kan deadlines justeres mere præcist, virkelig kritiske opgaver kan prioriteres, og konsekvenserne af en opgave, der flyttes, kan registreres øjeblikkeligt.

Derudover hjælper god afhængighedsstyring med at reducere fejl og optimere ressourcer . Det undgår dobbeltarbejde, minimerer unødvendigt omarbejde og skaber en udførelsesrækkefølge, der begrænser marginen for dyre fejl.

Alt dette resulterer i større fleksibilitet og tilpasningsevne: Når ændringer er uundgåelige, giver et klart kort over afhængigheder dig mulighed for at reorganisere planen med mindre lidelse , forudse konsekvenser og omkonfigurere prioriteter med mere dømmekraft.

Samlet set bliver effektiv håndtering af afhængigheder mellem opgaver, teams og tekniske komponenter en central succesfaktor i både enkeltstående projekter og den løbende udvikling af komplekse digitale produkter. Organisationer, der prioriterer autonome teams, klar visualisering, koordineringsritualer og en stærk teknisk kultur, reducerer flaskehalse, forbedrer deres time-to-market og gør det muligt for deres teams at arbejde med mindre friktion og større fokus på at levere reel værdi til slutbrugeren.