Individuelle Softwareentwicklung für KMU

Individuelle Software lohnt sich, wenn der Prozess wirklich Ihrer ist, wenn kein Produkt eine Regel unterstützt, die Sie nicht aufgeben dürfen, oder wenn die behelfsmäßigen Lösungen stillschweigend teurer geworden sind, als das Werkzeug selbst zu besitzen. Diese Fälle gibt es, und sie sind häufiger, als Anbieter von Software zugeben. Sie sind aber nicht jeder Fall.

Bevor wir einen Eigenbau anbieten, vergleichen wir ihn deshalb mit den billigeren Antworten: etwas Vorhandenes konfigurieren, zwei Tools verbinden, für die Sie ohnehin zahlen, oder den Prozess selbst ändern. Gewinnt eine davon, sagen wir es. Ein Projekt, auf das keiner von uns stolz wäre, kostet uns mehr als eine kleinere Rechnung.

Gewinnt der Eigenbau, deckt die erste Version eine Aufgabe von Anfang bis Ende ab: die Masken, die Berechtigungen und das, was passiert, wenn jemand etwas Falsches tut. Keine Plattform für das Unternehmen, das Sie einmal werden könnten.

Die Anforderungen stehen selten in einem Dokument. Sie stecken in einer Tabelle mit drei Reitern, die sonst niemand öffnet, in einer E-Mail-Vorlage, in einer Prüfung, die jemand jeden Freitag aus dem Kopf macht, und in dem Grund, warum ein Kollege die Liste immer auf eine bestimmte Weise sortiert. Wir arbeiten mit echten Fällen, besonders den unangenehmen, denn dort wohnen die Regeln.

Alles Unsichere wird als Prototyp gebaut, solange Änderungen noch billig sind. Umfang, Zurückgestelltes und die Frage, woran wir Erfolg erkennen, bleiben schriftlich und für alle sichtbar. Menschen reagieren auf eine Maske, die ihrer Arbeit ähnelt, sehr viel besser als auf ein Diagramm davon, und diese Reaktion kommt, solange man noch darauf reagieren kann. Was wir am Anfang brauchen, sind vor allem Belege:

Die Anwendung ist um Daten herum organisiert, die Sie wiedererkennen würden, und um Regeln, die Sie laut erklären könnten. Authentifizierung, Autorisierung, Validierung und ein Protokoll der Prüfungen sitzen dort, wo das Risiko sitzt. Sie reflexhaft überall zu verteilen, bringt nichts. Integrationen gehen davon aus, dass das Netz ausfällt und die Gegenseite sich ändert, ohne Bescheid zu sagen. Backups und die Wiederherstellung werden mit dem Deployment entworfen, nicht erst, wenn das System etwas enthält, dessen Verlust Sie sich nicht leisten können.

Wir setzen bewusst langweilige Technik ein (TypeScript, Node.js, React, PostgreSQL) und lassen Infrastruktur weg, für die das Projekt keine Verwendung hat. Eine kleine Architektur lässt sich leichter testen, absichern, betreiben und übergeben. Die Arbeit an der Performance fließt in die Aktionen, die Menschen den ganzen Tag wiederholen, und in Mengen, die Sie realistisch erreichen, nicht in die auf einer Folie. Der eigentliche Test: Kann ein fähiger Entwickler, der uns nie getroffen hat, das übernehmen?

Eine Schätzung ist eine Wahrscheinlichkeit, kein Versprechen, und die ehrliche Fassung kommt mit ihren Annahmen. Was Software verspätet, ist selten der Code. Es ist eine Übernahme der Daten, die sich als deutlich schlimmer entpuppt als beschrieben, eine Integration, deren Dokumentation Fiktion ist, oder eine Entscheidung, für die drei Personen nötig sind, die nie in derselben Woche Zeit haben.

Deshalb sehen wir uns die riskanten Teile zuerst an, solange der Plan noch änderbar ist, und kürzen den Umfang, bevor die Qualität leidet. Wenn etwas rutscht, hören Sie es, sobald wir es wissen, und nicht am Stichtag. Eine kleinere erste Lieferung, die tatsächlich erscheint, ist mehr wert als eine vollständige, die sich immer weiter verschiebt.

Neue Software ersetzt meist etwas, das am Tag des Starts nicht einfach pausieren kann. Migration, Zugänge, Schulung und Rollout werden als ein Stück Arbeit geplant. Historische Daten werden bereinigt und zuerst in einen Probelauf importiert, dann gegen die alte Quelle abgeglichen: Summen, Anzahlen und eine Stichprobe von Datensätzen, die man wiedererkennt. Wo das Risiko höher ist, läuft eine Pilotgruppe eine Zeit lang auf beiden Systemen.

Deployments sind wiederholbar und bringen ihre eigene Konfiguration für jede Umgebung mit. Automatisierte Prüfungen decken das Verhalten ab, auf das es ankommt, und Logging macht ein Problem in der Produktion diagnostizierbar statt nur mit Glück reproduzierbar. Menschen bekommen kurze Anleitungen für die Aufgaben, die sie tatsächlich erledigen, kein Handbuch. Für alles Kritische gibt es einen vereinbarten Rückweg, damit eine gewöhnliche Auslieferung eine gewöhnliche bleibt.

Sobald sie im Einsatz ist, zeigt das Verhalten, welche Annahmen stimmten. Wo Menschen ein Formular abbrechen, wonach sie fragen, welcher Schritt langsam ist, wo sie doch wieder zur Tabelle zurückgekehrt sind. Das ergibt eine bessere Roadmap als eine Liste von Wünschen. Eine Option, die niemand öffnet, darf verschwinden. Eine Abkürzung bei einer Aufgabe, die vierzigmal am Tag anfällt, ist mehr wert als ein Feature.

Die Arbeit, die sie am Leben hält, wird geplant: Abhängigkeiten, Updates für die Sicherheit, Backups und die Integrationen, die sich unter Ihnen verändern. Die Dokumentation beschreibt den Betrieb des Systems und die Entscheidungen, die sich aus dem Code nicht ableiten lassen.

Quellcode, Daten und die Konten der Infrastruktur gehören Ihnen, von Anfang an so eingerichtet, damit am Ende nichts zu verhandeln bleibt. Alles, was an einen Anbieter gebunden ist, wird benannt, solange es noch eine Wahl ist, damit die Kosten eines Umzugs eine Zahl sind, die Sie kennen, und keine, die Sie entdecken.

Übernimmt eines Tages ein anderes Team, braucht es das Repository, den Prozess für das Deployment und eine Dokumentation, die die Entscheidungen erklärt. Die gibt es. Individuelle Software soll Ihnen mehr Kontrolle über einen wichtigen Prozess geben und nicht eine Abhängigkeit gegen eine andere tauschen.