Udvikling

Udvikling og Produktledelse


De tunge, proces-orienterede projektmodeller, som vi af en eller anden årsag har en præference for i Danmark, fungerer ikke godt til softwareproduktudvikling.

 

Projektmodellerne (som f.eks. SAFe) fører til komplekse vandfaldsudviklingsprojekter, masser af konflikter, og begrænset værdi. Vi får produceret en masse software, som i bedste fald leverer begrænset værdi og i værste fald leverer negativ værdi i form af besværlige arbejdsgange og en håbløs brugeroplevelse.

I stedet for vandfaldsudviklingsmodellerne skal vi kigge til de agile udviklingstilgange. Der er flere forskellige tilgange til agil udvikling så som Scrum, Kaban, og tidligere Extreme Programming (XP). Erfarende produktmennesker bruger ritualer og metoder fra flere af disse skoler på en pragmatisk måde, men holder fast i de basale agile principper:

 

  • Vi skal levere værdi til brugeren så hurtigt så muligt: Software, som fungerer i hænderne på brugeren, er vigtigere end dokumentation eller proces.
  • Værdifuldt software leveres hele tiden – helst hver anden uge eller hurtigere.
  • Produktchefen, UX-designeren, og udviklerne samarbejder og interagerer hver eneste dag i et psykologisk trygt udviklingsmiljø. I tilfælde af produkter, som er en platform for andre, arbejder man uden en designer, da resultatet typisk er en API, fremfor en brugeroplevelse.
  • Softwareudviklingen er bæredygtig – det betyder vi skal have kontrol over kodebasen mht. arkitektur, design og proces. Vi refaktorer koden jævnligt, så vi kan fortsætte vores agile udviklingsflow uendeligt.
  • Udviklingsteamet er så autonomt som overhovedet muligt og er ansvarlig for at forbedre egne processer.

 

Principperne tvinger os til at bruge den bedste praksis fra produktledelse, design, og programmering. Vi bliver tvunget til at have en god arkitektur, et godt design, regressionstests, gode redskaber til samarbejde, gode brugerhistorier, en optimeret pipeline (CI/CD), og en vedvarende samtale om hvilke dele af softwaren vi bygger og hvilke vi henter andet steds fra (open source, licenser, osv.). Opgaverne er mange, men bliver løst gennem et tæt samarbejde af kompetente mennesker.

 

Produktchefen skal naturligvis tage den administrative rolle som produktejer, som den er beskrevet i ovennævnte agile udviklingsprocesser. Det er en af produktchefens opgaver, men her er det vigtigt at holde sig for øje, at produktchefer ikke er produktejere. Det er en udbredt misforståelse, fordi de tunge projektmodeller (som SAFe) har begrænset fokus på de forretningsmæssige aspekter af produktchefens rolle. De taler kort om produktejerens arbejde med stakeholders om produktvisionen (fremfor udforskningsarbejdet med brugerne og kunden) og så er der fokus på roadmaps som en artefakt, der laves internt (fremfor det vedvarende udforskningsarbejde, som produktchefen er ansvarlige for). Hvis duhar Produktejer som titel, er det nok fordi din organisation er fanget i en af de store projektmodeller.

Hånden på hjertet: Hvilke opgaver ligger i arbejdet med udvikling?

 

De fleste produktledelses opgaver i udviklingsarbejdet er et resultat af god udforskning. Det er derfor oftest svært at skille de to ting ad, men hvis vi holder os til de agile udviklingstilgange, så opgaverne er som følger:

 

  • Vedligeholde produktgruppens katalog af brugerhistorier (som er resultatet af udforskningsarbejdet.)
  • Have et godt syn på prioriteringen af epics og brugerhistorier (med udgangspunkt i forretningsværdien som er etableret som en del af udforskningen)
  • Have klar mål for det enkelte sprint og det overordnede produktinitiativ (som oftest også kommer fra udforskningsarbejdet)
  • Forberede en gruppe af brugerhistorier til næste sprint
  • Deltage i planlægningen af næste sprint
  • Daglige møder (”standups”) med udviklere og designer for at flytte udviklingsarbejdet fremad
  • Skabe klarhed omkring brugerhistorier gennem ekstra data eller information fra andre funktioner i organisationen (altså opfølgning på det udforskningsarbejde, der allerede er lavet).
  • Gennemgå resultatet af et Sprint med produktteamet og vurdere om den forventede forretningsværdi blev realiseret
  • Deltage i at forbedre produktgruppens arbejdstilgang, redskaber, principper, og kultur


Privatlivspolitik

OK