STEP 1. Wie werden wir es bauen?

Die vier Säulen einer guten technischen Lösung

Wenn wir eine technische Lösung vorschlagen, stützen wir uns immer auf die während der Produktentwicklung gesammelten Erkenntnisse, wie z. B. die erwartete Anzahl der Benutzer oder Funktionen, die als Dienste von Drittanbietern integriert werden müssen.

Als Teil der technischen Lösung berücksichtigen wir für jedes Projekt sorgfältig:

• Architektur & Designprinzipien - MVC-Prinzipien, Microservices, Dienste von Drittanbietern (z. B. APIs, Social Media, Video-Player etc.)
• Tech stack (Backend und Frontend) - Programmiersprachen, Frameworks, Daten- und Dateispeicherung
• Datenbank-Architektur - Tabellenstruktur, Relationen, Indizes, Datenbankschema
• Servers & Deployment - Hosting-Lösungen, Server-Anforderungen und Auslieferung

Wenn wir zum Beispiel die technische Lösung für eine E-Commerce-Plattform entwerfen, konzentrieren wir uns auf Aspekte wie Erweiterbarkeit (wie einfach ist es, neue Module, Themes hinzuzufügen?), Integrationen, Ladegeschwindigkeit, schrittweise Auslieferung von Funktionen. Wir könnten dann beurteilen, ob es am besten ist, von Anfang an eine Microservices-basierte Architektur zu verwenden oder nicht, was die beste Hosting-Lösung ist, welche Funktionen als Drittanbieter oder Module integriert werden sollten, wie das Modul-Ökosystem funktionieren sollte usw.

Vielleicht ist es für eine einfache Zeiterfassungs-App in Ordnung, wenn alle Anfragen von einem einzigen Backend verarbeitet werden. Aber was ist mit einer umfangreichen Flottenmanagement-App, bei der Sie Gefahr laufen, Ihre Server zu überlasten? Und was ist, wenn Sie auch Entfernungen berechnen oder benutzerdefinierte Berichte erstellen möchten? Das erfordert Geschwindigkeit bei der Datenverarbeitung. Vielleicht wäre also der Einsatz einer auf Big Data spezialisierten Technologie, wie Python, eine gute Lösung. Oder die Verwendung eines anderen Servers, der die Berechnungen durchführt. Oder eine Vorkompilierung der am häufigsten verwendeten Berichte, um zukünftige Berichte viel schneller zu generieren.

All diese Entscheidungen und mehr fließen in die Suche nach der praktikabelsten technischen Lösung ein.

Die beste technische Lösung zu finden, ist ein (Last-)Balanceakt. Und noch mehr.

Um die beste technische Lösung zu finden, müssen Sie auch die perfekte Balance zwischen dem finden, was jetzt funktioniert, und dem, was in Zukunft funktionieren wird. Wie hoch ist die erwartete Anzahl der Benutzer? Kann die App eine wachsende Anzahl von gleichzeitigen Benutzern unterstützen? Wie wird sie mit einer exponentiellen Belastung der Datenbank umgehen?

Deshalb investieren wir von Anfang an viel in die Datenbankarchitektur. Auswahl und Design der Datenbank sind entscheidend, wenn die Web-App erfolgreich skalieren und große Datenmengen schnell verarbeiten soll. Noch wichtiger ist, dass sie sicher sein muss und eine optimale Serverbereitstellung und -sicherung ermöglicht.

Zum Beispiel bietet MySQL kritische Elemente für Datenbankanwendungen, die in der Cloud eingesetzt werden, wie Sicherheit, Hochverfügbarkeit, Datenintegrität, Überwachung und Ressourcenmanagement. Das wirkt Wunder, wenn Ihre Daten stark strukturiert sind und Sie nur minimale Änderungen am Datenbankschema erwarten. Für die flexible Speicherung großer Mengen unstrukturierter Daten könnte NoSQL oder eine Kombination aus MySQL und NoSQL jedoch die bessere Wahl sein.

Nachdem wir uns für eine Datenbanklösung entschieden haben, entwerfen wir das Schema, eine visuelle Darstellung, wie die Daten gespeichert werden. Dazu gehört, wie Informationen über Datenbanken und Tabellen innerhalb von Datenbanken organisiert werden, die Beziehung zwischen Datenbankobjekten, Ansichten, gespeicherten Prozeduren, Primärschlüsseln, Fremdschlüsseln usw. Kurz gesagt, eine visuelle Übersicht über das Datengerüst Ihrer App.

STEP 2. Wie lange wird es dauern?

Das Rätselraten aus der Zeitplanung entfernen

Laut einer Studie zum Thema Experteneinschätzung und Softwareeinschätzung können Gruppendiskussionen die Kostenschätzung anscheinend deutlich verbessern. Dies ist einer der Gründe, warum wir einen Planungspoker, ähnlich dem Scrum-Poker, verwenden, um genauere Zeitschätzungen zu generieren.

Bei der Produktentwicklung schreiben wir User Stories so, dass sie sich leicht in Features herunterbrechen lassen (z. B. "Kunde gibt Suchkriterien für Produkt ein"). Die Features werden dann je nach Größe des Projekts von zwei oder mehr Entwicklern separat geschätzt. Dadurch wird der Einfluss anderer Teilnehmer und die natürliche Tendenz, die ersten Zahlen als Präzedenzfall für nachfolgende Schätzungen zu nehmen, außer Kraft gesetzt. Nachdem jeder Entwickler seine separaten Schätzungen abgegeben hat, werden diese diskutiert und hohe und niedrige Schätzungen erläutert. Wenn es große Diskrepanzen gibt, werden die Schritte wiederholt, bis eine Einigung erzielt wird.

Der Planungspoker funktioniert so gut, weil:

• Es bündelt das Expertenwissen der Teammitglieder.
• Es erlaubt Teammitgliedern, relative statt absolute Schätzungen vorzunehmen.Das bedeutet, dass Entwickler neue Aufgaben mit bereits abgeschlossenen Aufgaben vergleichen, anstatt abstrakte Schätzungen vorzunehmen. Ist dieses Feature zum Beispiel eher so ein richtig kleines Ding? Oder ist es eher wie diese normal große Sache? Oder ist es wirklich riesig, wie dieses eine Stück Arbeit, das wir letzten Monat fertiggestellt haben? Dies erhöht die Genauigkeit erheblich, da die Schätzungen auf praktischen Erfahrungen beruhen.
• Es macht die Projektplanung und die Feature-Priorisierung einfacher. Weil es sich auf die Komplexität der Implementierung von Features konzentriert, macht es die Planungspoker-Methode wirklich einfach, diese Features in Must-have, Good-to-have und Nice-to-have zu gruppieren. Das macht die Projektplanung und Feature-Priorisierung, die nächste Stufe im Entwicklungslebenszyklus, sehr viel einfacher.

STEP 3. Wie viel wird es kosten?

Alles in Kostenvoranschläge umwandeln

Nachdem wir die technischen Anforderungen und den Zeitaufwand für die Umsetzung des Projekts ermittelt haben, rechnen wir alles in Kosten pro Monat, pro Team oder pro Gesamtprojekt um. Es gibt mehrere Elemente, die in die Kostenschätzung einfließen, zusätzlich zur Projektdauer und der Komplexität der technischen Lösung:

• Das Erfahrungsniveau der beteiligten Personen - Erfordert Ihr Projekt hochspezialisierte Personen? Für ein komplexes Projekt könnte ein Senior-Entwickler eine bessere und kostengünstigere Option sein als drei mittlere Entwickler. Das Gleiche gilt für Projektmanager, Tester, Designer usw.
• Die Dringlichkeit des Projekts- Wie schnell wollen Sie es einsetzen?
• Der Reifegrad des Projekts- In welchem Stadium seines Lebenszyklus befindet sich das Projekt? Handelt es sich um ein MVP im Frühstadium oder um ein Scale-up? Beginnen wir bei Null oder integrieren wir es in ein bereits bestehendes Ökosystem? Handelt es sich um ein Unternehmen oder ein Start-up?

Sind Sie bereit, loszulegen?

Wenn Sie ein Start-up sind und einen technischen Partner suchen, der Sie auf Ihrem Weg begleitet, sind Sie bei uns genau richtig. Wir sind darauf spezialisiert, Start-ups bei der Validierung, Einführung und Skalierung ihres MVP zu unterstützen. Kontaktieren Sie uns jetzt, um einen Kostenvoranschlag für Ihre App und die beste technische Lösung für diese Aufgabe zu erhalten.