Wenn Sie lange genug Engineering-Organisationen geleitet haben, hätten Sie Probleme bei der Technologieauswahl für Ihr Produkt/Ihre Teams angegangen. Und zumindest ein paar Mal waren Sie nicht sehr zufrieden mit den Entscheidungen, die Sie grünes Licht gegeben hatten. Diese Entscheidungspunkte treten normalerweise zu Beginn eines Projekts auf oder sich ändernde Geschäftsanforderungen zwingen Sie, vorhandene Lösungen/Technologien zu ersetzen. Ich möchte Ihnen ein praktisches Werkzeug an die Hand geben, um das Risiko in diesem Prozess zu reduzieren und ein besseres Gefühl für das „Warum“ hinter Ihrer Entscheidung zu bekommen.
Lassen Sie mich mit einigen Beispielen aus meinem Leben als technischer Leiter beginnen. Wir waren ein winziges Unternehmen und haben Zapier gerne verwendet, um unsere Hauptanwendung mit dem SFDC zu integrieren. Ich hielt Zapier für eine gute Wahl für unsere Größe und unser zukünftiges 100-faches Wachstum, da es billig war, seinen Zweck erfüllte und laufende Probleme einfach zu beheben waren. Zapier hat seine Grenzen, aber diese waren billig zu handhaben (dh es wurde keine große Anzahl von Entwicklungsstunden verbraucht). Aber der verlangsamte Druck durch die verlangsamten/abflachenden Verkäufe erforderte, dass ein Versuchskaninchen (gp) die Schuld auf sich nahm und Zapier zu diesem gp wurde. Und plötzlich sprach die ganze Firma davon, Zapier durch „A Weltklasse iPaaS“. Nachdem wir die Top-Konkurrenten verglichen hatten, wählten wir einen aus, das Integrations-Engineering-Team wurde eingestellt und ein Pilotprojekt gestartet. Das Pilotprojekt war ein Spielzeugprojekt und es dauerte immer noch viel länger, es zu implementieren und bereitzustellen. Aber es wurde als Sieg gefeiert (ja, mit „death to zapier“-Gesängen). Echte Integrationsprojekte liefen noch langsamer und waren unzuverlässig. Dennoch musste jede Funktion im Hauptprodukt, die mit Geschäftssystemen interagieren musste, über iPaaS darauf zugreifen, was uns erheblich verlangsamte. Wir haben auch festgestellt, dass die Ausführung aller unserer Integrationsanforderungen auf iPaaS noch mehr kosten würde (keine Überraschung hier – die Lizenzierung der iPaaS-Anbieter erforderte die Bereitstellung zusätzlicher Kerne in der Cloud für zusätzliche Szenarien, also mehr Geld zum Berappen), also müssen wir jetzt leiten Ingenieure, wann iPaaS zu verwenden ist und wann nicht. Dies ist ein klassisches Beispiel für die Auswahl von Technologien für kurzfristige politische Erfolge, gepaart mit der Hoffnung auf eine langfristig robuste Infrastruktur. Es ist an beiden Fronten gescheitert.
Die Wahl der Entwickler hat auch einen großen Einfluss auf die Technologieauswahl. Einmal stellte mir ein sehr erfahrener Entwickler CockroachDB vor und sagte, er werde nur in Golang programmieren! Und ich musste Stunden damit verbringen, ihn davon zu überzeugen, dass diese beiden Entscheidungen zu diesem Zeitpunkt nicht das Richtige für uns waren. Da der Rest des Teams aus erfahrenen Java-Entwicklern bestand und über umfassende Erfahrung mit Postgres verfügte, befand sich CockroachDB noch in der frühen Beta-Phase. Und unsere Veröffentlichungsrichtlinie des Unternehmens würde es uns nicht erlauben, irgendetwas damit in Produktion zu bringen.
Ich hoffe, diese beiden Beispiele geben Ihnen genügend Hintergrundinformationen zu dem Problem. Das Ziel dieser beiden Beispiele ist nicht, irgendjemanden zu verprügeln, sondern die Tatsache hervorzuheben, dass die Technologieauswahl an sich ein schwieriges Problem ist, aber die nicht-technischen Aspekte sind es oft schwieriger. Je objektiver Sie bei Ihrem Auswahlverfahren sind, desto mehr Erfolg haben Sie bei der Auswahl der richtigen Option
Es gibt zwei Hauptakteure bei der Technologieauswahl:
- Entwickler, die es verwenden müssen
- Budgetmanager (CXOs)
Sie müssen Ihre Entwickler (die diese Technologie beherrschen und einsetzen müssen) sowie das Management an Bord holen. Das Management (Personen, die das Budget genehmigen) würde radikale Verbesserungen am Produkt/Service/UX/DX usw. erwarten.
Ein Spickzettel zur Technologieauswahl
Machen wir es Schritt für Schritt:
- Schreiben Sie die Problemstellung so genau wie möglich auf.
zB „Finden oder erstellen Sie eine Lösung, damit jeder Entwickler in der Lage sein sollte, mit einem einzigen Klick oder einem einzigen Befehl eine produktionsähnliche Umgebung für Entwicklungstests zu erstellen.“
2. Stellen Sie eine Tabelle zusammen, in der bestimmte Attribute/Funktionen aufgeführt sind, die Sie in der Lösung/Technologie sehen möchten. Führen Sie eine schnelle Websuche durch, ein Teil dieser Arbeit würde bereits von anderen erledigt werden (nutzen Sie es). Dieses Blatt muss funktionale und nicht funktionale Anforderungen enthalten (z. B. Lizenzbedingungen, Kosten, Support, Verlängerung, While-Labeling usw.). Sie verwenden diese Tabelle, um verfügbare Optionen zu vergleichen. Wenn Sie kein Experte für diese Technologie sind, lassen Sie die technischen Kriterien von einem leitenden Ingenieur ermitteln
3. Sortieren Sie Optionen aus, die einfach gut klingen, aber die Mehrheit Ihrer in der Tabelle identifizierten Auswahlkriterien nicht erfüllen. Oder sie sind unerschwinglich teuer oder mit verrückten Lizenzbedingungen.
4. Bevor Sie intensiv mit Anbietern zusammenarbeiten, vergewissern Sie sich, dass Sie über ein Budget für den Kauf/die Implementierung dieser Technologie verfügen. Es ist in Ordnung, frühzeitig Demos zu erhalten oder hochrangige Diskussionen mit Anbietern über das Problem zu führen, das Sie zu lösen versuchen. Wenn die Budgetgenehmigung nicht sicher ist, Timebox POCs/Evaluierungen, damit Sie keine Entwicklungszyklen für Lösungen verbrennen, die nicht finanziert werden.
5. Achten Sie bei der technischen Bewertung darauf, die Tabelle mit den Auswahlkriterien auszufüllen. Ermutigen Sie Bewerter, ihre Eindrücke, Notizen, Links und Vor- und Nachteile aufzuschreiben, während sie diese Technologie verwendet haben.
6. Präsentieren Sie dem Budgetmanager Ihre Empfehlung mit den Vor- und Nachteilen jeder in Betracht gezogenen Option. Wenn möglich Stack-Rank verfügbare Optionen. Es ist möglich, dass Sie aus Kosten- oder anderen Gründen nicht Ihre beste Wahl treffen können.
7. Beachten Sie bei der Besprechung von Optionen mit dem Budgetmanager, dass es beim Kauf von Software immer Raum für Preis-/Laufzeitverhandlungen gibt. Wenn Sie es noch nie getan haben, suchen Sie Hilfe von Menschen, die es getan haben. (Unternehmen bieten gegen Ende des Quartals, Jahres, Monats usw. bessere Angebote an, kleinere Unternehmen ermöglichen Ihnen, ein Pilotprojekt in der Produktion durchzuführen, bevor Sie mit der Zahlung beginnen, usw.)
8. Unter der Annahme, dass das Budget von uns genehmigt wurde, sprechen Sie mit formellen Referenzkunden und informell mit Ihren Branchenkollegen über ihre Erfahrungen mit dieser Technologie und diesem Anbieter
9. Binden Sie Ihre Rechtsabteilung frühzeitig ein – wenn Sie Ihre Gespräche mit Anbietern beginnen. Die Rechtsabteilung muss die Verträge prüfen/unterzeichnen, eine frühere Einbindung hilft dabei, den Vertrag ohne Verzögerungen abzuschließen. Sie werden Sie auch anleiten, wenn die Lizenzbedingungen für Ihr Unternehmen nicht optimal sind.
9. Stellen Sie vor Vertragsunterzeichnung sicher, dass Sie Engineering-Zeit für die Implementierung dieser Technologie eingeplant haben. In meiner Karriere habe ich eine Reihe von technischen Evaluierungen durchgeführt, die Zeit und Aufwand für die Entwicklung gekostet haben, aber nie umgesetzt wurden, weil Unternehmen sich nicht auf die Lizenzkosten und die für die Implementierung benötigte Entwicklungszeit festlegen konnten.
Gehen Sie das Gespräch
Machen wir eine Übung zur Technologieauswahl für ein hypothetisches Startup, das gerade damit beginnt, eine echte Webanwendung aus der POC-Anwendung zu erstellen, die von einem Gründer erstellt wurde. Hier konzentrieren wir uns auf die Datenbankauswahl.
Problemstellung
Wählen Sie ein Datenbank-Backend aus, das für eine B2B-Anwendung verwendet wird, die verwendet wird von:
- Tausende von täglich aktiven Benutzern
- Benutzeraktionen generieren Lese-Schreib-Vorgänge in der DB (mit schwer vorhersagbaren Prozentsätzen von Lese- und Schreibvorgängen).
- Es wird Bedarf an Geschäftsberichten/Analysen geben (mit der Option, Daten in einen anderen Speicher zu verschieben, z. B. Data-Lake/DW usw.)
- DB muss ein Managed Service sein
- Null Ausfallzeit (2 Neunen)
- Primäre Anwendungsanforderungen sind für den relationalen Speicher (wir werden No-SQL und ausgefallenere Graph-DBs vorerst aus dieser Analyse heraushalten)
Auswahlkriterien-Tabelle:
(Dieses Arbeitsblatt dient als Beispiel, und ich habe absichtlich einige Zeilen leer gelassen. In einer echten Übung werden Sie viel Zeit und Gehirnleistung aufwenden, um Auswahlkriterien zu identifizieren.)
Was tun, wenn es keinen klaren Sieger gibt?
- Bevor Sie zu diesem Schluss kommen, überprüfen Sie die Bewertungskriterien, um sicherzustellen, dass Sie nichts übersehen haben und dass Sie die zukünftigen Anforderungen im Auge behalten (z. B. 100-fache Skalierung usw.) und jede Zeile angemessen bewertet wird.
- Wenden Sie vernünftige Kriterien an, um einen Gewinner auszuwählen:
A. Vertrautheit (z. B. 80 % der Ingenieure haben Postgress vs. CockroachDB verwendet)
B. Günstigere Vertragsbedingungen (z. B. Jahrespreise mit der Option zur monatlichen Zahlung, keine zusätzlichen Gebühren für Überschreitungen)
C. Bereitschaft des Anbieters, mit Ihnen zusammenzuarbeiten (einige Beispielimplementierungen in Unternehmen ähnlicher Größe)
D. Preise (laufende und Verlängerungsbedingungen)
Abschluss
Die Technologieauswahl ist eine der wichtigsten Aufgaben eines jeden technischen Leiters. Manchmal bekommt es nicht die Aufmerksamkeit, die es verdient. Dies kann zu teuren Nacharbeiten, Umrüstungen und unzufriedenen Entwicklern/Ops und Kunden führen. Anstatt sich auf Ihr Bauchgefühl zu verlassen bzw Großhirn dieses einen Architekten Machen Sie diesen Prozess im Team objektiv, binden Sie leitende Ingenieure ein, und Sie würden es weniger bereuen!
