Hoppa till innehåll
BigTree108

Teknik- och produktpartner

För mjukvaruleverantörer och produktbolag som behöver ett utvecklingsteam vid sidan av sitt eget i år snarare än en sprint. En modul vi äger från början till slut, en plattform vi hjälper till att driva, eller ett andra team som bär den roadmap ni inte kan bemanna, med samma personer som stannar tillräckligt länge för att lära sig domänen.

Annorlunda än att köpa ett projekt

Ett projekt har ett slut, och allt om hur det bemannas följer av det: personer tilldelas, domänen lärs tillräckligt väl för att avsluta, och kunskapen lämnar med dem. En produkt tar aldrig slut. Det den behöver av ett externt team är kontinuitet, ett intresse av att arkitekturen överlever de kommande två åren och personer som säger emot när en genväg kostar mer senare än den sparar nu.

Det är den relation den här sidan beskriver. Kommersiellt ser den oftast ut som ett dedikerat team; det som gör den till ett partnerskap är att vi svarar för ett utfall i er produkt och inte för en lista med ärenden.

Vad vi vanligtvis äger

  • En modul vi äger från början till slut

    En avgränsad del av er produkt: integrationslagret, rapporteringssidan, adminytan, mobilklienten. Vi äger den i er kodbas, enligt er arkitektur, och vi svarar för dess fel och inte för ett ärendeantal.

  • Ett andra team på roadmapen

    Allt ni vet att ni borde bygga och inte kan bemanna. Ett parallellt team som arbetar i era repositories och era ritualer, så att roadmapen rör sig på två fronter i stället för att prioriteras ned till en.

  • Plattformen under ytan

    Molninfrastruktur deklarerad i Terraform, pipelines, miljöer, observerbarhet, databas- och säkerhetsarbete. Den del ett produktteam aldrig har tid för och känner av varje vecka att den saknas.

  • Att föra en gammal produkt framåt

    En produkt som säljer men har slutat vara möjlig att ändra. Nio övertaganden hittills, det äldsta skrivet 2008, alltid med en skrivskyddad genomgång och en skriftlig riskförteckning först och inte ett förslag om omskrivning.

Vad som får ett långt partnerskap att fungera

  • Personer som stannar

    Uppdrag här löper i år snarare än sprintar, och domänkunskapen stannar hos samma personer. En partners värsta utfall är att betala två gånger för samma inlärningskurva.

  • Er arkitektur, inte vår

    Vi är vana att ta över det en produkt redan körs på i stället för att styra den mot det vi råkar kunna. Ett partnerteam som hela tiden föreslår en omskrivning är ett partnerteam som har slutat vara till nytta.

  • Regler som överlever en överlämning

    Tester levereras med funktionen, bygget slutar med noll varningar, säkerheten är nekad som standard och infrastrukturen är kod. Kod skriven på det här sättet är kod som era egna utvecklare kan ta över.

  • En ägare per faktum

    Härledda värden beräknas en gång och används överallt. I en produkt med flera team är duplicerad sanning den bugg man hittar sex månader senare och inte kan förklara för en kund.

  • Vikarier som är våra, inte debiterade

    Arkitekturgranskning, ett extra par ögon på pull requests och vikarie vid ledighet kommer från BigTree108 i stället för från er budget.

  • Ert IP hela vägen

    Varje specialist överlåter sitt arbetsresultat till bolaget före åtkomst, och det överlåts vidare till er, så ingenting i ett långt partnerskap komplicerar vem som äger produkten.

Vi driver en egen produkt

Allt vi använder internt, från rekrytering och introduktion till tidrapportering, avtal och fakturering, är en plattform på den stack vi erbjuder partner: .NET i Azure Functions, Angular, Azure SQL, Terraform. Det är inget portföljexempel; det är systemet bolaget är beroende av, och vi har levt med våra egna arkitekturbeslut tillräckligt länge för att veta vilka av dem som var fel.

Det är det omdöme en produktpartner faktiskt köper. Fallstudien beskriver vad den gör och hur den är byggd.

Hur det börjar

Med något litet och reversibelt. En utvecklare på en avgränsad del av er backlog, eller en skrivskyddad genomgång av den del av produkten ni är minst bekväma med, levererad som en skriftlig riskförteckning i ordning efter påverkan i produktion. Båda är billiga sätt att ta reda på om vi läser er kodbas så som ni vill att en partner ska läsa den.

Därifrån är den vanliga formen ett dedikerat team som växer med roadmapen. Om ni så småningom hellre vill äga teamet helt är Build-Operate-Transfer samma personer med en överföring inskriven i avtalet.

Behöver ni ett andra team på er produkt?

Skicka produkten, den del av roadmapen som fortsätter glida och en länk till ett repository om ni kan. Ni får de frågor vi fortfarande har, ett tillvägagångssätt och en uppskattning inom en arbetsdag.