Partenaires technologiques et produit
Pour les éditeurs de logiciels et les entreprises produit qui ont besoin d’une équipe d’ingénierie à côté de la leur pendant des années plutôt que le temps d’un sprint. Un module que nous prenons en charge de bout en bout, une plateforme que nous aidons à exploiter, ou une seconde équipe qui porte la feuille de route que vous ne pouvez pas staffer, avec les mêmes personnes qui restent assez longtemps pour apprendre le domaine.
Différent de l’achat d’un projet
Un projet a une fin, et tout ce qui concerne son staffing en découle : les personnes sont affectées, le domaine est appris suffisamment pour terminer, et la connaissance s’en va avec elles. Un produit ne s’arrête pas. Ce qu’il attend d’une équipe extérieure, c’est de la continuité, un intérêt à ce que l’architecture survive aux deux prochaines années, et des personnes qui s’opposent quand un raccourci coûtera plus tard davantage qu’il ne fait gagner maintenant.
C’est la relation que décrit cette page. Commercialement, elle ressemble généralement à une équipe dédiée ; ce qui en fait un partenariat, c’est que nous répondons d’un résultat dans votre produit et non d’une liste de tickets.
Ce dont nous sommes généralement responsables
Un module que nous prenons en charge de bout en bout
Une partie délimitée de votre produit : la couche d’intégrations, le côté reporting, l’interface d’administration, le client mobile. Nous la prenons en charge dans votre base de code, selon votre architecture, et nous répondons de ses défauts plutôt que d’un nombre de tickets.
Une seconde équipe sur la feuille de route
Tout ce que vous savez devoir construire sans pouvoir le staffer. Une équipe parallèle qui travaille dans vos dépôts et vos rituels, de sorte que la feuille de route avance sur deux fronts au lieu d’être repriorisée jusqu’à n’en garder qu’un.
La plateforme en dessous
Infrastructure cloud déclarée dans Terraform, pipelines, environnements, observabilité, travail sur les bases de données et la sécurité. La partie dont une équipe produit n’a jamais le temps de s’occuper et dont elle ressent l’absence chaque semaine.
Remettre un vieux produit à niveau
Un produit qui se vend mais n’est plus modifiable. Neuf reprises à ce jour, la plus ancienne écrite en 2008, qui commencent toujours par une revue en lecture seule et une liste écrite des risques plutôt que par une proposition de réécriture.
Ce qui fait tenir un long partenariat
Des personnes qui restent
Les missions durent ici des années plutôt que des sprints, et la connaissance du domaine reste chez les mêmes personnes. Le pire résultat pour un partenaire est de payer deux fois la même courbe d’apprentissage.
Votre architecture, pas la nôtre
Nous avons l’habitude de reprendre la technologie sur laquelle tourne déjà un produit plutôt que de l’orienter vers ce que nous connaissons. Une équipe partenaire qui propose sans cesse une réécriture est une équipe partenaire qui a cessé d’être utile.
Des règles qui survivent à une passation
Les tests sont livrés avec la fonctionnalité, le build se termine sans aucun avertissement, la sécurité est refus par défaut et l’infrastructure est du code. Du code écrit ainsi est du code que vos propres ingénieurs peuvent reprendre.
Un seul propriétaire par fait
Les valeurs dérivées sont calculées une seule fois et consommées partout. Dans un produit où interviennent plusieurs équipes, une vérité dupliquée est le bug que l’on trouve six mois plus tard et que l’on ne sait pas expliquer à un client.
Une suppléance qui est la nôtre, non facturée
La revue d’architecture, un second regard sur les pull requests et la suppléance pendant les congés viennent de BigTree108 et non de votre budget.
Votre propriété intellectuelle, tout au long
Chaque spécialiste cède ses livrables à l’entreprise avant l’accès, et ils vous sont cédés à leur tour, de sorte que rien dans un long partenariat ne complique la question de savoir à qui appartient le produit.
Nous exploitons un produit à nous
Tout ce que nous utilisons en interne, du recrutement et de l’onboarding au suivi du temps, aux contrats et à la facturation, est une seule plateforme sur la stack que nous proposons aux partenaires : .NET sur Azure Functions, Angular, Azure SQL, Terraform. Ce n’est pas une pièce de portfolio ; c’est le système dont l’entreprise dépend, et nous avons vécu assez longtemps avec nos propres décisions d’architecture pour savoir lesquelles étaient mauvaises.
C’est le discernement qu’un partenaire produit achète réellement. L’étude de cas décrit ce qu’il fait et comment il est construit.
Comment cela démarre
Par quelque chose de petit et de réversible. Un ingénieur sur une partie circonscrite de votre backlog, ou une revue en lecture seule de la partie du produit qui vous met le moins à l’aise, livrée sous forme d’une liste écrite des risques par ordre d’impact en production. Ce sont deux façons peu coûteuses de savoir si nous lisons votre base de code comme vous voudriez qu’un partenaire la lise.
À partir de là, la forme habituelle est une équipe dédiée qui grandit avec la feuille de route. Si vous préférez à terme posséder l’équipe en propre, le Build-Operate-Transfer réunit les mêmes personnes avec un transfert inscrit au contrat.
Vous avez besoin d’une seconde équipe sur votre produit ?
Envoyez le produit, la partie de la feuille de route qui ne cesse de glisser et un lien vers un dépôt si possible. Vous recevez les questions qu’il nous reste, une approche et une estimation sous un jour ouvré.