Technologie- und Produktpartner
Für Softwarehersteller und Produktunternehmen, die über Jahre statt für einen Sprint ein Entwicklungsteam neben ihrem eigenen brauchen. Ein Modul in unserer Verantwortung von Anfang bis Ende, eine Plattform, die wir mitbetreiben, oder ein zweites Team, das die Roadmap trägt, die Sie nicht besetzen können, mit denselben Personen, die lange genug bleiben, um die Domäne zu lernen.
Anders als der Einkauf eines Projekts
Ein Projekt hat ein Ende, und alles an seiner Besetzung folgt daraus: Personen werden zugewiesen, die Domäne wird gerade gut genug gelernt, um fertig zu werden, und das Wissen geht mit ihnen. Ein Produkt endet nicht. Was es von einem externen Team braucht, ist Kontinuität, ein Interesse daran, dass die Architektur die nächsten zwei Jahre übersteht, und Menschen, die widersprechen, wenn eine Abkürzung später mehr kostet, als sie jetzt spart.
Das ist die Beziehung, die diese Seite beschreibt. Kommerziell sieht sie meist wie ein dediziertes Team aus; zu einer Partnerschaft macht sie, dass wir für ein Ergebnis in Ihrem Produkt einstehen und nicht für eine Liste von Tickets.
Was wir typischerweise verantworten
Ein Modul in unserer Verantwortung von Anfang bis Ende
Ein abgegrenzter Teil Ihres Produkts: die Integrationsschicht, die Berichtsseite, die Admin-Oberfläche, der mobile Client. Wir verantworten ihn in Ihrer Codebasis, nach Ihrer Architektur, und wir stehen für seine Defekte ein und nicht für eine Ticketzahl.
Ein zweites Team an der Roadmap
Alles, was Sie bauen sollten und nicht besetzen können. Ein paralleles Team, das in Ihren Repositories und nach Ihren Ritualen arbeitet, sodass die Roadmap an zwei Fronten vorankommt, statt auf eine heruntergestuft zu werden.
Die Plattform darunter
Cloud-Infrastruktur, in Terraform deklariert, Pipelines, Umgebungen, Observability, Datenbank- und Sicherheitsarbeit. Der Teil, für den ein Produktteam nie Zeit hat und dessen Fehlen es jede Woche spürt.
Ein altes Produkt voranbringen
Ein Produkt, das sich verkauft, aber nicht mehr änderbar ist. Bisher neun Übernahmen, die älteste geschrieben im Jahr 2008, immer beginnend mit einer rein lesenden Prüfung und einer schriftlichen Risikoliste statt eines Vorschlags für ein Neuschreiben.
Was eine lange Partnerschaft gelingen lässt
Menschen, die bleiben
Aufträge laufen hier über Jahre statt Sprints, und das Domänenwissen bleibt bei denselben Personen. Das schlimmste Ergebnis für einen Partner ist, dieselbe Lernkurve zweimal zu bezahlen.
Ihre Architektur, nicht unsere
Wir sind es gewohnt, das aufzugreifen, worauf ein Produkt bereits läuft, statt es zu dem hinzulenken, was wir zufällig kennen. Ein Partnerteam, das ständig ein Neuschreiben vorschlägt, ist ein Partnerteam, das aufgehört hat, nützlich zu sein.
Regeln, die eine Übergabe überstehen
Tests werden mit dem Feature ausgeliefert, der Build endet mit null Warnungen, Sicherheit gilt nach dem Prinzip Deny-by-Default, und die Infrastruktur ist Code. So geschriebener Code ist Code, den Ihre eigenen Entwickler übernehmen können.
Ein Verantwortlicher je Fakt
Abgeleitete Werte werden einmal berechnet und überall verwendet. In einem Produkt mit mehreren Teams ist doppelt vorhandene Wahrheit der Fehler, den man sechs Monate später findet und einem Kunden nicht erklären kann.
Vertretung, die bei uns liegt und nicht abgerechnet wird
Architektur-Review, ein zweites Augenpaar bei Pull Requests und Urlaubsvertretung kommen von BigTree108 und nicht aus Ihrem Budget.
Ihr geistiges Eigentum durchgehend
Jeder Spezialist überträgt seine Arbeitsergebnisse vor dem Zugang an das Unternehmen, und sie werden an Sie weiter übertragen, sodass nichts an einer langen Partnerschaft die Frage verkompliziert, wem das Produkt gehört.
Wir betreiben ein eigenes Produkt
Alles, was wir intern nutzen, von Recruiting und Onboarding bis zu Zeiterfassung, Verträgen und Rechnungsstellung, ist eine Plattform auf dem Stack, den wir Partnern anbieten: .NET auf Azure Functions, Angular, Azure SQL, Terraform. Es ist kein Portfolio-Stück, sondern das System, von dem das Unternehmen abhängt, und wir leben lange genug mit unseren eigenen Architekturentscheidungen, um zu wissen, welche davon falsch waren.
Dieses Urteilsvermögen kauft ein Produktpartner tatsächlich ein. Die Fallstudie beschreibt, was es leistet und wie es gebaut ist.
Wie es beginnt
Mit etwas Kleinem und Umkehrbarem. Ein Entwickler an einem abgegrenzten Stück Ihres Backlogs oder eine rein lesende Prüfung des Teils Ihres Produkts, bei dem Sie sich am unwohlsten fühlen, geliefert als schriftliche Risikoliste in der Reihenfolge der Auswirkung auf die Produktion. Beides sind günstige Wege herauszufinden, ob wir Ihre Codebasis so lesen, wie Sie es von einem Partner erwarten.
Von dort ist die übliche Form ein dediziertes Team, das mit der Roadmap wächst. Wenn Sie das Team irgendwann lieber ganz besitzen möchten, ist Build-Operate-Transfer dieselben Menschen mit einer im Vertrag festgeschriebenen Übertragung.
Sie brauchen ein zweites Team für Ihr Produkt?
Senden Sie uns das Produkt, den Teil der Roadmap, der immer wieder rutscht, und wenn möglich einen Repository-Link. Sie erhalten innerhalb eines Werktags die Fragen, die wir noch haben, einen Ansatz und eine Schätzung.