Teknologi- og produktpartnere
Til softwareleverandører og produktvirksomheder, der har brug for et udviklingsteam ved siden af deres eget i årevis og ikke i et sprint. Et modul, vi ejer fra start til slut, en platform, vi hjælper med at drive, eller et andet team, der bærer det roadmap, I ikke kan bemande, med de samme folk, som bliver længe nok til at lære domænet.
Noget andet end at købe et projekt
Et projekt har en slutning, og alt ved, hvordan det bemandes, følger af det: folk tildeles, domænet læres godt nok til at blive færdig, og viden går med dem, når de rejser. Et produkt slutter ikke. Det, det har brug for fra et eksternt team, er kontinuitet, en interesse i, at arkitekturen overlever de næste to år, og folk, der siger fra, når en genvej vil koste mere senere, end den sparer nu.
Det er det forhold, denne side beskriver. Kommercielt ligner det som regel et dedikeret team; det, der gør det til et partnerskab, er, at vi er ansvarlige for et resultat i jeres produkt og ikke for en liste af tickets.
Hvad vi typisk ejer
Et modul, vi ejer fra start til slut
Én afgrænset del af jeres produkt: integrationslaget, rapporteringssiden, administrationsfladen, mobilklienten. Vi ejer den i jeres kodebase, efter jeres arkitektur, og vi er ansvarlige for dens fejl og ikke for et antal tickets.
Et andet team på roadmappet
Alt det, I ved, I bør bygge, men ikke kan bemande. Et parallelt team, der arbejder i jeres repositories og jeres ritualer, så roadmappet bevæger sig på to fronter i stedet for at blive omprioriteret ned til én.
Platformen nedenunder
Cloudinfrastruktur deklareret i Terraform, pipelines, miljøer, observability samt database- og sikkerhedsarbejde. Den del, et produktteam aldrig har tid til, og hver uge mærker, at den mangler.
At føre et gammelt produkt fremad
Et produkt, der sælger, men ikke længere kan ændres. Indtil videre ni overtagelser, den ældste skrevet i 2008, altid med en skrivebeskyttet gennemgang og en skriftlig liste over risici som start og ikke et forslag om omskrivning.
Hvad der får et langt partnerskab til at fungere
Folk, der bliver
Samarbejder her løber i år og ikke i sprints, og domæneviden bliver hos de samme folk. En partners værste udfald er at betale to gange for den samme læringskurve.
Jeres arkitektur og ikke vores
Vi er vant til at overtage det, et produkt allerede kører på, i stedet for at styre det hen imod det, vi tilfældigvis kender. Et partnerteam, der bliver ved med at foreslå en omskrivning, er et partnerteam, der er holdt op med at være til nytte.
Regler, der overlever en overdragelse
Tests udkommer sammen med funktionen, buildet slutter med nul advarsler, sikkerhed er deny-by-default, og infrastruktur er kode. Kode skrevet på den måde er kode, jeres egne udviklere kan overtage.
Én ejer pr. faktum
Afledte værdier beregnes én gang og bruges overalt. I et produkt med flere teams er duplikeret sandhed den fejl, man finder seks måneder senere og ikke kan forklare en kunde.
Afløsning, der er vores og ikke faktureres
Arkitekturgennemgang, et ekstra par øjne på pull requests og afløsning under orlov kommer fra BigTree108 og ikke fra jeres budget.
Jeres IP hele vejen igennem
Hver specialist overdrager sit arbejdsresultat til selskabet før adgang, og det overdrages videre til jer, så intet ved et langt partnerskab komplicerer, hvem der ejer produktet.
Vi driver selv et produkt
Alt, hvad vi bruger internt, fra rekruttering og onboarding til tidsregistrering, kontrakter og fakturering, er én platform på den stack, vi tilbyder partnere: .NET på Azure Functions, Angular, Azure SQL, Terraform. Det er ikke et referenceeksempel; det er det system, virksomheden afhænger af, og vi har levet med vores egne arkitekturbeslutninger længe nok til at vide, hvilke af dem der var forkerte.
Det er den dømmekraft, en produktpartner egentlig køber. Casen beskriver, hvad den gør, og hvordan den er bygget.
Sådan starter det
Med noget lille og reversibelt. Én udvikler på et afgrænset stykke af jeres backlog eller en skrivebeskyttet gennemgang af den del af produktet, I er mindst trygge ved, leveret som en skriftlig liste over risici i rækkefølge efter betydning for produktionen. Begge er billige måder at finde ud af, om vi læser jeres kodebase, som I ville ønske, at en partner læste den.
Derfra er den sædvanlige form et dedikeret team, der vokser med roadmappet. Hvis I på sigt hellere vil eje teamet helt og holdent, er Build-Operate-Transfer de samme folk med en overførsel skrevet ind i kontrakten.
Har I brug for et andet team på jeres produkt?
Send produktet, den del af roadmappet, der bliver ved med at skride, og et link til et repository, hvis I kan. I får de spørgsmål, vi stadig har, en fremgangsmåde og et estimat inden for én arbejdsdag.