Hopp til innholdet
BigTree108

Teknologi- og produktpartnere

For programvareleverandører og produktselskaper som trenger et utviklingsteam ved siden av sitt eget i årevis, ikke i én sprint. En modul vi eier fra A til Å, en plattform vi hjelper til med å drifte, eller et ekstra team som bærer roadmapen dere ikke kan bemanne, med de samme folkene værende lenge nok til å lære domenet.

Annerledes enn å kjøpe et prosjekt

Et prosjekt har en slutt, og alt ved hvordan det bemannes følger av det: folk tildeles, domenet læres godt nok til å bli ferdig, og kunnskapen forsvinner med dem. Et produkt tar aldri slutt. Det det trenger fra et eksternt team, er kontinuitet, interesse for at arkitekturen overlever de neste to årene, og folk som protesterer når en snarvei vil koste mer senere enn den sparer nå.

Det er forholdet denne siden beskriver. Kommersielt ser det som regel ut som et dedikert team; det som gjør det til et partnerskap, er at vi er ansvarlige for et resultat i produktet deres, ikke for en liste med tickets.

Hva vi typisk eier

  • En modul vi eier fra A til Å

    Én avgrenset del av produktet deres: integrasjonslaget, rapporteringssiden, administrasjonsflaten, mobilklienten. Vi eier den i kodebasen deres, etter arkitekturen deres, og er ansvarlige for feilene i den, ikke for et antall tickets.

  • Et ekstra team på roadmapen

    Alt dere vet dere bør bygge og ikke kan bemanne. Et parallelt team som jobber i repositoriene og rutinene deres, slik at roadmapen beveger seg på to fronter i stedet for å bli omprioritert ned til én.

  • Plattformen under

    Skyinfrastruktur deklarert i Terraform, pipelines, miljøer, observerbarhet, database- og sikkerhetsarbeid. Det et produktteam aldri har tid til, og som de merker mangelen på hver uke.

  • Å løfte et gammelt produkt fram

    Et produkt som selger, men har sluttet å være mulig å endre. Ni overtakelser så langt, den eldste skrevet i 2008, alltid med en skrivebeskyttet gjennomgang og en skriftlig liste over risikoer først, ikke et forslag om omskriving.

Det som får et langt partnerskap til å fungere

  • Folk som blir

    Oppdragene her varer i årevis, ikke i sprinter, og domenekunnskapen blir hos de samme folkene. Det verste for en partner er å betale to ganger for den samme læringskurven.

  • Deres arkitektur, ikke vår

    Vi er vant til å ta over det et produkt allerede kjører på i stedet for å styre det mot det vi tilfeldigvis kan. Et partnerteam som stadig foreslår å skrive om alt, er et partnerteam som har sluttet å være nyttig.

  • Regler som overlever en overlevering

    Tester følger med funksjonen, bygget slutter med null advarsler, sikkerheten nekter som standard og infrastrukturen er kode. Kode skrevet på denne måten kan deres egne utviklere ta over.

  • Én eier per opplysning

    Avledede verdier beregnes én gang og brukes overalt. I et produkt med flere team er duplisert sannhet feilen dere finner seks måneder senere og ikke kan forklare for en kunde.

  • Dekning som er vår, ikke fakturert

    Arkitekturgjennomgang, et ekstra par øyne på pull requests og dekning ved ferie kommer fra BigTree108, ikke fra budsjettet deres.

  • Deres IP hele veien

    Hver spesialist overdrar arbeidsresultatet sitt til selskapet før tilgang, og det overdras videre til dere, så ingenting ved et langt partnerskap gjør det uklart hvem som eier produktet.

Vi driver vårt eget produkt

Alt vi bruker internt, fra ansettelse og onboarding til tidsføring, kontrakter og fakturering, er én plattform på den stacken vi tilbyr partnere: .NET på Azure Functions, Angular, Azure SQL, Terraform. Det er ikke et utstillingsstykke; det er systemet selskapet er avhengig av, og vi har levd med våre egne arkitekturvalg lenge nok til å vite hvilke av dem som var feil.

Det er den dømmekraften en produktpartner faktisk kjøper. Casen beskriver hva den gjør og hvordan den er bygget.

Hvordan det starter

Med noe lite og reversibelt. Én utvikler på en avgrenset del av backlogen deres, eller en skrivebeskyttet gjennomgang av den delen av produktet dere er minst komfortable med, levert som en skriftlig liste over risikoer i rekkefølge etter betydning for produksjon. Begge er billige måter å finne ut om vi leser kodebasen deres slik dere ville at en partner skulle lese den.

Derfra er den vanlige formen et dedikert team som vokser med roadmapen. Vil dere på sikt heller eie teamet selv, er Build-Operate-Transfer de samme folkene med en overføring skrevet inn i kontrakten.

Trenger dere et ekstra team på produktet?

Send produktet, den delen av roadmapen som stadig glipper og en lenke til repositoriet hvis dere kan. Dere får spørsmålene vi fortsatt har, en tilnærming og et estimat innen én arbeidsdag.